Method and apparatus for communicating in a communication system supporting multi-talker critical mission push-to-talk (MCPTT)

Abstract

In an embodiment of the present disclosure, the present disclosure relates to a method and apparatus for efficiently communicating between a client and a server supporting mission-critical push-to-talk (MCPTT) in a communication system. The method is performed by a client device supporting the MCPTT in the communication system, and the method includes: sending a session description protocol (SDP) proposal to a server, the SDP proposal including a synchronization source (SSRC) value as a media attribute of the session description protocol (SDP); and receiving an SDP response from the server in response to the SDP proposal, wherein the SDP response includes the same SSRC value in response to the SSRC value in the SDP proposal not being in use or a new SSRC value in response to the SSRC value in the SDP proposal being in use.

Description

Technical Field

[0001] The present disclosure relates to a method and apparatus for communication between a client and a server in a communication system supporting Multi-Talker Critical Mission Push-to-Talk (MCPTT). Background Art

[0002] In a multi-talker MCPTT call, when all group members are silent, a group member can press a Push-To-Talk (PTT) button, which indicates a request for permission to speak. The floor participant entity of the group member reflects this request to the floor control server by sending a Floor Request message. If the floor control server decides to grant permission, it notifies this permission by sending a Floor Granted message to the requesting group member. The floor control server notifies other group members of the initiation of speaking by sending a Floor Taken message.

[0003] In addition, in the case of a multi-talker MCPTT call, multiple real-time protocol (RTP) streams are identified by the synchronization source (SSRC) value in the floor message. The SSRC identifier uniquely identifies the floor participant within the session of the multi-talker MCPTT call. The SSRC value is generated by the floor requester and sent in the floor request message.

[0004] Unless explicitly stated in the INVITE request or in the SIP REFER request, the floor control server will not process the original INVITE request or Session Initiation Protocol (SIP) REFER request used to establish an MCPTT chat group call or rejoin an ongoing MCPTT call as an implicit floor control request message. The MCPTT client needs to include various attributes when a SIP request should be interpreted as an implicit floor request.

[0005] In the case of the implicit floor request method, the floor request is referenced in the INVITE itself and there is no explicit floor request message from the client. There is no mechanism defined in the 3rd Generation Partnership Project (3GPP) Mission Critical Services (MCX) specification to exchange SSRC values ​​between the client and the server in the case of the implicit floor request method.

[0006] Therefore, there is a need to address such concerns and provide another method implemented in a system to exchange SSRC values ​​between a client and a server for implicit floor requests. Summary of the invention

[0007] Technical issues

[0008] This Summary is provided to introduce a selection of concepts in a simplified format that are further described in the Detailed Description of the present disclosure. This Summary is neither intended to identify key or essential inventive concepts of the present disclosure nor is it intended to determine the scope of the present disclosure.

[0009] The present disclosure will provide a method and apparatus for efficiently communicating between a client and a server supporting MCPTT in a communication system.

[0010] Solution to the problem

[0011] In an embodiment of the present disclosure, the present disclosure provides a method performed by a client device supporting MCPTT in a communication system, the method comprising: sending a session description protocol (SDP) proposal to a server, the SDP proposal including a synchronization source (SSRC) value as a media attribute of the session description protocol (SDP); and receiving an SDP response from the server in response to the SDP proposal, wherein the SDP response includes the same SSRC value in response to the SSRC value in the SDP proposal not being in use or a new SSRC value in response to the SSRC value in the SDP proposal being in use.

[0012] In an embodiment of the present disclosure, the present disclosure provides a method performed by a server supporting MCPTT in a communication system, the method comprising: receiving an SDP proposal including an SSRC value as a media attribute of the SDP from a client device; in a case where the SSRC value in the SDP proposal is not in use, sending an SDP response including the same SSRC value to the client device; and in a case where the SSRC value in the SDP proposal is in use, sending an SDP response including a new SSRC value to the client device.

[0013] In an embodiment of the present disclosure, the present disclosure provides a client device supporting MCPTT in a communication system, the client device comprising: a transceiver; and a processor, the processor being configured to control the transceiver to send an SDP proposal including an SSRC value as a media attribute of the SDP to a server via the transceiver, and to receive an SDP answer in response to the SDP proposal from the server via the transceiver, wherein the SDP answer includes the same SSRC value in response to the SSRC value in the SDP proposal not being in use or a new SSRC value in response to the SSRC value in the SDP proposal being in use.

[0014] In an embodiment of the present disclosure, the present disclosure provides a server supporting MCPTT in a communication system, the server comprising: a transceiver; and a processor, the processor being configured to receive an SDP proposal including an SSRC value as a media attribute of the SDP from a client device via the transceiver, and in a case where the SSRC value in the SDP proposal is not in use, control the transceiver to send an SDP response including the same SSRC value to the client device, and in a case where the SSRC value in the SDP proposal is in use, control the transceiver to send an SDP response including a new SSRC value to the client device.

[0015] The present disclosure provides a method for exchanging SSRC values ​​between a client and a server for an implicit floor request according to a mission-critical push-to-talk (MCPTT) multi-talker call. The method includes sharing, by the client, an SSRC value as a format specific parameter (FMTP) media attribute of a session description protocol (SDP) in an outgoing INVITE request to the server. If the SSRC value is not in use, the client receives the same SSRC value formatted according to a 200 OK response from the server. Thereafter, if the SSRC value is in use, the client receives a new SSRC value formatted according to a 200 OK response from the server.

[0016] The present disclosure provides a method for identifying a client among multiple clients during an MCPTT call. The method includes: receiving, by at least one client, a floor seizure message associated with each of the multiple clients from a server, the floor seizure message including an SSRC value formatted according to a 200 OK response. The method includes: receiving, by at least one client, from multiple clients, multiple real-time transport protocol (RTP) streams accompanied by SSRC values ​​associated with each of the multiple clients. The method further includes: identifying, by at least one client, each of the multiple clients based on the SSRC value received in the floor seizure message associated with each of the multiple clients and the SSRC value received with the multiple RTP streams.

[0017] In an embodiment of the present disclosure, a method and apparatus for exchanging SSRC values ​​between a client and a server for an implicit floor request is provided. In one embodiment, exchanging SSRC values ​​between a client and a server for an implicit floor request is accomplished with explicit grant support during a multi-speaker MCPTT call, where the SSRC is shared in the FMTP media attribute of a session description protocol (SDP). In another embodiment, exchanging SSRC values ​​between a client and a server for an implicit floor request is accomplished with implicit grant support during a multi-speaker MCPTT call, where the SSRC is shared in the FMTP media attribute of the SDP. In another embodiment, exchanging SSRC values ​​between a client and a server for an implicit floor request is accomplished with implicit / explicit grant support during a multi-speaker MCPTT call, where the SSRC is shared in the FMTP media attribute of the SSRC and SDP.

[0018] In an embodiment of the present disclosure, a method performed by a server in a communication system supporting mission-critical push-to-talk (MCPTT) is provided, the method comprising: sharing a synchronization source (SSRC) value as a format specific parameter (FMTP) media attribute of a session description protocol (SDP) in an outgoing INVITE request from a client; if the SSRC value is not in use, sending the same SSRC value formatted according to a 200 OK response to the client; and if the SSRC value is in use, sending a new SSRC value formatted according to the 200 OK response to the client.

[0019] In an embodiment of the present disclosure, a server device in a communication system supporting mission-critical push-to-talk (MCPTT) is provided, the server device comprising: a transceiver; and a processor, the processor being configured to: share a synchronization source (SSRC) value as a format specific parameter (FMTP) media attribute of a session description protocol (SDP) in an outgoing INVITE request from a client; if the SSRC value is not in use, send the same SSRC value formatted according to a 200 OK response to the client; and if the SSRC value is in use, send a new SSRC value formatted according to a 200 OK response to the client.

[0020] In addition, the method disclosed in this specification can be implemented in any system supporting MCPTT, including but not limited to mobile devices, soft clients, etc.

[0021] Furthermore, the methods disclosed in the specification can be used for other MCX services such as MCVideo, MCData and not limited to MCPTT.

[0022] In order to further illustrate the advantages and features of the present disclosure, a more specific description of the present disclosure will be presented by referring to the specific embodiments shown in the accompanying drawings. It should be understood that these drawings only depict typical embodiments of the present disclosure and should not be considered as limiting the scope thereof. The present disclosure will be described and explained with additional details and details together with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] These and other features, aspects, and advantages of the present disclosure will become better understood when the following detailed description is read with reference to the accompanying drawings, in which like numerals refer to like parts throughout, and in which:

[0024] Figure 1a Method operations according to embodiments of the present subject matter are illustrated;

[0025] Figure 1b A call flow diagram for exchanging SSRC values ​​for implicit floor request with explicit grant support during a multi-talker MCPTT call according to an embodiment of the present disclosure is shown;

[0026] Figure 2 A call flow diagram for exchanging SSRC values ​​for implicit floor request with implicit grant support during a multi-talker MCPTT call according to an embodiment of the present disclosure is shown;

[0027] Figure 3 A call flow diagram for exchanging SSRC values ​​for implicit floor request with implicit / explicit authorization support during a multi-talker MCPTT call according to an embodiment of the present disclosure is shown;

[0028] Figure 4 The method operation of identifying a client among a plurality of clients during an MCPTT call according to an embodiment of the present disclosure is shown; and

[0029] Figure 5 The embodiment according to the present disclosure is shown Figure 1a and Figure 1b The method operates based on an implementation of a computing device.

[0030] Furthermore, the skilled artisan will appreciate that the elements in the drawings are illustrated for simplicity and may not necessarily be drawn to scale. For example, a flow chart illustrates the method in terms of the most important operations involved to help improve understanding of the various aspects of the present disclosure. Furthermore, with respect to the construction of the device, one or more components of the device may have been represented in the drawings with conventional symbols, and the drawings may show only those specific details relevant to understanding the embodiments of the present disclosure so as not to obscure the drawings with details that would be readily apparent to one of ordinary skill in the art having the benefit of the description herein. DETAILED DESCRIPTION

[0031] In order to promote an understanding of the principles of the present disclosure, reference will now be made to the embodiments shown in the drawings and specific language will be used to describe them. It will be understood, however, that no limitation of the scope of the present disclosure is intended thereby, and that such changes and further modifications in the systems shown, and such further applications of the principles of the present disclosure as shown therein will normally occur to those skilled in the art to which the present disclosure relates.

[0032] Those skilled in the art will understand that both the foregoing general description and the following detailed description are illustrative of the present disclosure and are not intended to be limiting.

[0033] Before carrying out the following specific embodiments, it may be helpful to set forth the definitions of certain words and phrases used throughout this patent document. The term "coupling" and its derivatives refer to any direct or indirect communication between two or more elements, whether or not those elements are in physical contact with each other. The terms "send", "receive" and "communication" and their derivatives include direct and indirect communication. The terms "include" and "comprise" and their derivatives mean including but not limited to. The term "or" is inclusive, meaning and / or. The phrase "associated with..." and its derivatives mean including, included therein, interconnected with..., contain, be contained therein, be connected to or connected therewith, be coupled to or coupled therewith, can communicate with..., cooperate with..., interlace, parallel, approach, be bound to or bound therewith, have, have the nature of..., be related to or have a relationship therewith, etc. The term "controller" means any device, system or part thereof that controls at least one operation. Such a controller can be implemented with hardware or a combination of hardware and software and / or firmware. The functions associated with any particular controller can be centralized or distributed, whether locally or remotely. The phrase "at least one of," when used with a list of items, means that different combinations of one or more of the listed items may be used, and that only one item in the list may be needed. For example, "at least one of A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A, B, and C. Likewise, the term "set" means one or more. Thus, a set of items may be a single item or a collection of two or more items.

[0034] In addition, the various functions described below can be implemented or supported by one or more computer programs, each of which is formed by a computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, processes, functions, objects, classes, instances, related data or parts thereof that are applicable to implementation in a suitable computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code and executable code. The phrase "computer-readable medium" includes any type of medium that can be accessed by a computer, such as a read-only memory (ROM), a random access memory (RAM), a hard drive, a compact disk (CD), a digital video disk (DVD) or any other type of memory. "Non-transitory" computer-readable media does not include wired, wireless, optical or other communication links that transmit temporary electrical signals or other signals. Non-transitory computer-readable media include media that can permanently store data and media that can store and rewrite data later, such as rewritable optical disks or erasable storage devices.

[0035] References throughout the specification to "one aspect," "another aspect," or similar language mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, appearances of the phrases "in an embodiment," "in another embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0036] The terms "comprises," "comprising," or any other variation thereof are inclusive, such that a process or method that includes a list of operations includes not only those operations, but may also include other operations not expressly listed or inherent to such process or method. Similarly, one or more devices or subsystems or elements or structures or parts followed by "comprising ..." does not preclude the presence of other devices or other subsystems or other elements or other structures or other parts or additional devices or additional subsystems or additional elements or additional structures or additional parts, without more constraints.

[0037] Unless otherwise defined, e has the same meaning as commonly understood by one of ordinary skill in the art to which the present disclosure belongs. The systems, methods, and examples provided herein are illustrative only and are not intended to be limiting.

[0038] According to the present disclosure, a system and method for exchanging SSRC values ​​between a client and a server for an implicit floor request with at least one of implicit authorization support, explicit authorization support, or implicit / explicit authorization support during a multi-talker MCPTT call is disclosed. The method disclosed in the specification is not limited to MCPTT services and can be used for MCX services such as MCVideo, MCData, etc.

[0039] According to an embodiment of the present disclosure, a new SDP FMTP attribute "mc_ssrc" is created for sending SSRC values.

[0040] Figure 1a A method for exchanging SSRC values ​​between a client and a server for an implicit floor request in accordance with a Mission Critical Push-to-Talk (MCPTT) multi-talker call is shown.

[0041] The method includes sharing, by the client, an SSRC value of an FMTP media attribute of a Session Description Protocol (SDP) in an outgoing INVITE request to the server (operation 102). Sharing the SSRC value by the client includes sharing the SSRC value by adding the SSRC value to an "mc_ssrc" fmtp attribute of an application m-line of an SDP offer for the outgoing INVITE request.

[0042] In an example, sending and receiving SSRC values ​​is defined as exchanging SSRC values ​​between a client and a server for implicit floor requests with explicit grant support during a multi-talker MCPTT call, wherein the SSRCs are shared in FMTP media attributes of a Session Description Protocol (SDP).

[0043] In another example, sharing the SSRC value by the client includes performing the SSRC sharing as an FMTP media attribute of the SDP in an application m-line or a media m-line.

[0044] The method includes: if the SSRC value is not in use, receiving, by the client from the server, the same SSRC value formatted according to the 200 OK response (operation 104). Receiving the SSRC value from the server includes: receiving from the server the same SSRC value included in an "mc_ssrc" fmtp attribute of an application m-line in an SDP answer to a 200 OK response to the INVITE.

[0045] The method further includes receiving, by the client from the server, a new SSRC value formatted according to the 200 OK response if the SSRC value is in use (operation 106). Receiving the new SSRC value from the server includes receiving the new SSRC value in an explicit floor grant message from the server.

[0046] In other examples, receiving the new SSRC value from the server includes receiving the new SSRC value from the server included in an "mc_ssrc" fmtp attribute of an application m-line in an SDP answer of a 200 OK response to the INVITE.

[0047] In yet another example, receiving the new SSRC value from the server includes receiving implicit / explicit authorization support during a multi-talker MCPTT call, wherein SSRC sharing is performed via an FMTP attribute of an application m-line in the SDP.

[0048] Figure 1b A call flow diagram corresponding to operations 102 to 106 for exchanging SSRC values ​​for implicit floor request with explicit authorization support during a multi-talker MCPTT call according to an embodiment of the present disclosure is shown. The method is implemented in a device such as a mobile phone, a soft client, etc. that supports MCPTT. According to this embodiment, the SSRC is shared in the FMTP media attribute of the SDP. Figure 1b , in operation 112, the client (202) shares the SSRC value by adding the SSRC value to the "mc_ssrc" fmtp attribute of the application m-line of the SDP offer for the outgoing INVITE request.

[0049] In the example, in operation 114, if this SSRC value is not in use, the server (204) sends the same SSRC value to the client (202). The server (204) sends the same SSRC value by including the SSRC value to the "mc_ssrc" fmtp attribute of the application m-line in the SDP answer of the 200 OK response to the INVITE. The same can be illustrated as:

[0050] proposal:

[0051] m = application 1234udp MCPTT

[0052] a=fmtp:MCPTT mc_priority=5; mc_implicit_request; mc_ssrc=11111

[0053] answer:

[0054] m = application 1234udp MCPTT

[0055] a=fmtp:MCPTT mc_priority=5; mc_implicit_request; mc_ssrc=11111

[0056] In another example, in operation 114, if the SSRC value is already in use, the server (204) generates a new SSRC value. The server 204 shares the new SSRC with the client 202 in a 200 OK response. The embodiment ensures that the SSRC usage is unique across multiple sending clients in a group call. In addition, in operation 116, the server 204 can send the SSRC in an explicit floor grant message to the client 202. The same can be illustrated as:

[0057] proposal:

[0058] m = application 1234udp MCPTT

[0059] a=fmtp:MCPTT mc_priority=5; mc_implicit_request; mc_ssrc=11111

[0060] answer:

[0061] m = application 1234udp MCPTT

[0062] a=fmtp:MCPTT mc_priority=5; mc_implicit_request; mc_ssrc=22222

[0063] Figure 2 A call flow diagram corresponding to operations 102 to 106 for exchanging SSRC values ​​for implicit floor request with implicit grant support during a multi-talker MCPTT call according to an embodiment of the present disclosure is shown. The method is implemented in a device such as a mobile phone, a soft client, etc. that supports MCPTT. According to this embodiment, the SSRC is shared in the FMTP media attribute of the SDP. Figure 2 In operation 206, the client 202 shares the SSRC value by adding the SSRC value to the "mc_ssrc" fmtp attribute of the application m-line of the SDP offer for the outgoing INVITE request.

[0064] In an example, in operation 208, if the SSRC value is not in use, the server 204 sends the same SSRC value to the client 202 by including the same SSRC value to the "mc_ssrc" fmtp attribute of the application m-line in the SDP answer of the 200 OK response to the INVITE. The same can be illustrated as:

[0065] proposal:

[0066] m = application 1234udp MCPTT

[0067] a=fmtp:MCPTTmc_priority=5; mc_implicit_request; mc_granted; mc_ssrc=11111

[0068] answer:

[0069] m = application 1234udp MCPTT

[0070] a=fmtp:MCPTTmc_priority=5; mc_implicit_request; mc_granted; mc_ssrc=11111

[0071] In another example, in operation 208, if the SSRC value is already in use, the server 204 generates a new SSRC value and shares it with the client 202 in the 200 OK response. This ensures that the SSRC usage is unique across multiple sending clients in the group call. The same can be illustrated as:

[0072] proposal:

[0073] m = application 1234udp MCPTT

[0074] a=fmtp:MCPTTmc_priority=5; mc_implicit_request; mc_granted; mc_ssrc=11111

[0075] answer:

[0076] m = application 1234udp MCPTT

[0077] a=fmtp:MCPTTmc_priority=5; mc_implicit_request; mc_granted; mc_ssrc=22222

[0078] Figure 3 A call flow diagram corresponding to operations 102 to 106 for exchanging SSRC values ​​for implicit floor request with implicit / explicit authorization support during a multi-talker MCPTT call according to an embodiment of the present disclosure is shown. The method is implemented in a device such as a mobile phone, a soft client, etc. that supports MCPTT. According to this embodiment, the SSRC is shared in the FMTP media attributes of the SSRC and SDP. Figure 3In operation 302, the client 202 shares the SSRC value by adding the SSRC value as an attribute to the media m-line of the SDP offer for the outgoing INVITE request.

[0079] In an example, in operation 304, if this SSRC value is not in use, the server 204 sends the same SSRC value to the client 202 by including the same SSRC value to the "mc_ssrc" fmtp attribute of the application m-line in the SDP answer of the 200 OK response to the INVITE. The same can be illustrated as:

[0080] proposal:

[0081] m=audio 14000RTP / AVP 105

[0082] a=ssrc:11111cname:MCPTTUser@example.com

[0083] m = application 1234udp MCPTT

[0084] a=fmtp:MCPTT mc_priority=5; mc_granted; mc_implicit_request

[0085] answer:

[0086] m=audio 14000RTP / AVP 105

[0087] a=ssrc:xxxxx cname:MCPTTServer@example.com

[0088] m = application 1234udp MCPTT

[0089] a=fmtp:MCPTT mc_priority=5; mc_granted; mc_implicit_request; mc_ssrc=11111

[0090] In another example, in operation 304, if the SSRC value is already in use, the server 204 generates a new SSRC value. The server 204 shares the new SSRC value with the client in a 200 OK response. The same can be illustrated as:

[0091] proposal:

[0092] m=audio 14000RTP / AVP 105

[0093] a=ssrc:11111cname:MCPTTUser@example.com

[0094] m = application 1234udp MCPTT

[0095] a=fmtp:MCPTT mc_priority=5; mc_granted; mc_implicit_request

[0096] answer:

[0097] m=audio 14000RTP / AVP 105

[0098] a=ssrc:xxxxx cname:MCPTTServer@example.com

[0099] m = application 1234udp MCPTT

[0100] a=fmtp:MCPTT mc_priority=5; mc_granted; mc_implicit_request; mc_ssrc=22222

[0101] Thus, embodiments of the present disclosure ensure uniqueness of SSRC usage across multiple sending clients in a group call.

[0102] Figure 4 A method of identifying a client among a plurality of clients during an MCPTT call according to an embodiment of the present disclosure is shown.

[0103] In an embodiment, the method includes receiving (operation 402) by at least one client from a server a floor take message associated with each of a plurality of clients, the floor take message including an SSRC value formatted according to a 200 OK response. In an embodiment, the server sends the floor take message associated with each of a plurality of clients in response to receiving an outgoing INVITE request from each of the plurality of clients, the outgoing INVITE request including an SSRC value as an FMTP media attribute of a Session Description Protocol (SDP). In addition, the server may be configured to share the SSRC value formatted according to the 200 OK response in the floor grant message with the plurality of clients in response to receiving each of the outgoing INVITE requests.

[0104] In an embodiment, the method includes receiving (operation 404), by at least one client, from a plurality of clients, a plurality of real-time transport protocol (RTP) streams accompanied by SSRC values ​​associated with each of the plurality of clients.

[0105] In an embodiment, the method includes identifying (operation 406), by at least one client, each client among the plurality of clients based on an SSRC value received in a floor seizure message associated with each of the plurality of clients and SSRC values ​​received with the plurality of RTP streams.

[0106] Figure 5 Another exemplary implementation of an embodiment of the present disclosure is shown, and another typical hardware configuration of a networked node is shown by a computer device 1200. The computer device 1200 can include an instruction set that can be executed to cause the computer device 1200 to perform any one or more of the disclosed methods. The computer device 1200 can work as a standalone device or can be connected to other computer devices or peripheral devices, for example, using a network. The client 202 and the server 204 can also be implemented with a processor and a transceiver.

[0107] In a networked deployment, the computer device 1200 can work as a server (device) 204 or a client (device) 202 in a server-client user network environment, or as a peer computer device in a point-to-point (or distributed) network environment. The computer device 1200 can also be implemented as or incorporated across various devices such as the following: a personal computer (PC), a tablet PC, a personal digital assistant (PDA), a mobile device, a palmtop computer, a laptop computer, a desktop computer, a communication device, a wireless phone, a landline phone, a network appliance, a network router, a switch or a bridge, or a machine capable of running a set (sequential or otherwise) of instructions that specify actions to be taken by the machine. In addition, although a single computer device 1200 is shown, the term "device" should also be considered to include any collection of devices or sub-devices that individually or jointly run one or more sets of instructions to perform one or more computer functions.

[0108] Computer device 1200 may include processor 2502, for example, a central processing unit (CPU), a graphics processing unit (GPU), or both. Processor 2502 may be a component in a variety of devices. For example, processor 2502 may be part of a standard personal computer or workstation. Processor 2502 may be one or more general purpose processors, digital signal processors, application specific integrated circuits, field programmable gate arrays, servers, networks, digital circuits, analog circuits, combinations thereof, or other now known or later developed devices for analyzing and processing data. Processor 2502 may implement software programs such as artificially generated (i.e., programmed) codes.

[0109] The computer device 1200 may include a memory 2504, such as a memory 2504 capable of communicating via a bus 2508. The memory 2504 may include, but is not limited to, computer-readable storage media such as the following: various types of volatile and non-volatile storage media, including but not limited to random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, tape or disk, optical media, etc. In one example, the memory 2504 includes a cache or random access memory for the processor 2502. In an alternative example, the memory 2504 is separate from the processor 2502, such as a cache memory, device memory, or other memory of the processor. The memory 2504 may be an external storage device or database for storing data. The memory 2504 is operable to store instructions that can be executed by the processor 2502. The functions, behaviors, or tasks shown or described in the various figures may be performed by a programmed processor 2502 for executing the instructions stored in the memory 2504. The functions, behaviors, or tasks are independent of a specific type of instruction set, storage medium, processor, or processing strategy, and may be performed by software, hardware, integrated circuits, firmware, microcode, etc., working alone or in combination. Likewise, processing strategies may include multi-processing, multi-tasking, parallel processing, etc.

[0110] As shown, the computer device 1200 may or may not further include a display 2510, such as a liquid crystal display (LCD), an organic light emitting diode (OLED), a flat panel display, a solid state display, a cathode ray tube (CRT), a projector, a printer, or other display devices now known or later developed for outputting certain information. The display 2510 can serve as an interface for a user to view the functions of the processor 2502, or specifically as an interface with software stored in the memory 2504 or the drive unit 2516.

[0111] Additionally, the computer device 1200 may include an input device 2512 configured to allow a user to interact with any component of the device 1200. The computer device 1200 may also include a disk or optical drive unit 2516. The disk drive unit 2516 may include a computer-readable medium 2522 in which one or more sets of instructions 2524 (e.g., software) can be embedded. In addition, the instructions 2524 may embody one or more of the methods or logic as described. In a specific example, the instructions 2524 may reside completely or at least partially in the memory 2504 or in the processor 2502 during operation by the computer device 1200.

[0112] The present disclosure contemplates a computer-readable medium 2522 that includes instructions 2524 or receives and executes instructions 2524 in response to a propagation signal, so that a device connected to a network 2526 can transmit voice, video, audio, images, or any other data through the network 2526. In addition, instructions 2524 can be sent or received through the network 2526 via a communication port or interface 2520 or using a bus 2508. The communication interface 2520 can also be a transceiver referring to a receiver and a transmitter. The communication port or interface 2520 can be part of the processor 2502 or can be a separate component. The communication port 2520 can be created with software or can be a physical connection in hardware. The communication port 2520 can be configured to connect to the network 2526, an external medium, a display 2510, or any other component in the device 1200, or a combination thereof. The connection to the network 2526 can be a physical connection, such as a wired Ethernet connection, or can be established wirelessly as discussed later. Likewise, additional connections to other components of device 1200 may be physical or may be established wirelessly. Network 2526 may alternatively be connected directly to bus 2508 .

[0113] The network 2526 may include a wired network, a wireless network, an Ethernet AVB network, or a combination thereof. The wireless network may be a cellular telephone network, an 802.11, 802.16, 802.20, 802.1Q, or WiMax network. In addition, the network 2526 may be a public network such as the Internet, a private network such as an intranet, or a combination thereof, and may utilize various networking protocols available now or developed later, including but not limited to TCP / IP-based networking protocols. The device is not limited to operating using any particular standard and protocol. For example, standards for Internet and other packet-switched network transmissions (e.g., TCP / IP, UDP / IP, HTML, and HTTP) may be used.

[0114] Although specific language has been used to describe this subject, it is not intended to bring any limitation. As will be apparent to those skilled in the art, various work modifications can be made to the method in order to realize the inventive concept as taught herein. The accompanying drawings and the foregoing description give examples of embodiments. It will be appreciated by those skilled in the art that one or more of the described elements may also be combined into a single functional element. Alternatively, some elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment.

Claims

1. A method performed by a client device supporting mission-critical push-to-talk (MCPTTT) in a communication system, the method comprising: Sending a session initiation protocol invite request including a session description protocol SDP proposal to a server, wherein the session initiation protocol is SIP, the invitation is INVITE, and the SDP proposal includes a synchronization source SSRC value as a media attribute of the session description protocol SDP and a first format specific parameter fmtp attribute for an implicit request; as well as receiving from the server a SIP response including an SDP answer, the SIP response being responsive to sending a SIP INVITE request including the SDP offer, wherein the SIP INVITE request including the first fmtp attribute of the implicit request represents an implicit floor request, The SDP answer includes a first fmtp attribute for the implicit request and includes one of the following: responsive to the SSRC value in the SDP offer not being in use, and a new SSRC value in use in response to the SSRC value in the SDP offer, and The same SSRC value or the new SSRC value corresponds to the second fmtp attribute of the application m-line of the SDP.

2. The method according to claim 1, wherein: The SDP offer and the SDP answer also include a third fmtp attribute for authorization of the implicit request.

3. The method according to claim 1, wherein: The SIP response is a SIP 200 OK response.

4. The method according to claim 1, wherein: The SDP offer includes the SSRC value as a media attribute in the application m-line or media m-line of the SDP offer.

5. A method performed by a server supporting mission-critical push-to-talk (MCPTTT) in a communication system, the method comprising: receiving a session initiation protocol invite request including a session description protocol SDP offer from a client device, the session initiation protocol being SIP, the invite being INVITE, the SDP offer including a synchronization source SSRC value as a media attribute of the session description protocol SDP and a first format specific parameter fmtp attribute for an implicit request; sending a SIP response including an SDP answer to the client device, the SDP answer including the same SSRC value, if the SSRC value in the SDP offer is not in use; as well as sending a SIP response including an SDP answer to the client device, the SDP answer including a new SSRC value, if the SSRC value in the SDP offer is in use, wherein the SIP INVITE request including the first fmtp attribute of the implicit request represents an implicit floor request, wherein the SDP response further includes the first fmtp attribute for the implicit request, and The same SSRC value or the new SSRC value corresponds to the second fmtp attribute of the application m-line of the SDP.

6. The method according to claim 5, wherein: The SDP offer and the SDP answer also include a third fmtp attribute for authorization of the implicit request.

7. The method according to claim 5, wherein: The SIP response is a SIP 200 OK response.

8. The method according to claim 5, wherein: The SDP offer includes the SSRC value as a media attribute in the application m-line or media m-line of the SDP offer.

9. A client device supporting mission-critical push-to-talk (MCPTTT) in a communication system, the client device comprising: Transceiver; as well as A processor, the processor being configured to: controlling the transceiver to send a session initiation protocol invite request including a session description protocol SDP offer to a server via the transceiver, the session initiation protocol being SIP, the invite being INVITE, the SDP offer including a synchronization source SSRC value as a media attribute of the session description protocol SDP and a first format specific parameter fmtp attribute for an implicit request, and receiving, via the transceiver, from the server a SIP response including an SDP answer, the SIP response being responsive to sending a SIP INVITE request including the SDP offer, wherein the SIP INVITE request including the first fmtp attribute of the implicit request represents an implicit floor request, The SDP answer includes a first fmtp attribute for the implicit request and includes one of the following: responsive to the SSRC value in the SDP offer not being the same SSRC value in use, and a new SSRC value in use in response to the SSRC value in the SDP offer, and The same SSRC value or the new SSRC value corresponds to the second fmtp attribute of the application m-line of the SDP.

10. The client device according to claim 9, wherein: The processor is configured to perform the method of any one of claims 2 to 4.

11. A server supporting mission-critical push-to-talk (MCPTTT) in a communication system, the server comprising: Transceiver; as well as A processor, the processor being configured to: receiving, via the transceiver, a session initiation protocol invite request including a session description protocol SDP offer from a client device, the session initiation protocol being SIP, the invite being INVITE, the SDP offer including a synchronization source SSRC value as a media attribute of the session description protocol SDP and a first format specific parameter fmtp attribute for an implicit request, controlling the transceiver to send a SIP response including an SDP answer to the client device if the SSRC value in the SDP offer is not in use, the SDP answer including the same SSRC value, and controlling the transceiver to send a SIP response including an SDP answer to the client device if the SSRC value in the SDP offer is in use, the SDP answer including a new SSRC value, wherein the SIP INVITE request including the first fmtp attribute of the implicit request represents an implicit floor request, wherein the SDP response further includes the first fmtp attribute for the implicit request, and The same SSRC value or the new SSRC value corresponds to the second fmtp attribute of the application m-line of the SDP.

12. The server according to claim 11, wherein: The processor is configured to perform the method of any one of claims 6 to 8.

Images