Method and apparatus for communicating in communication system supporting multi-speaker-critical task push-to-talk (MCPTT)

Abstract

In an embodiment of the present disclosure, a method and apparatus for communication in a communication system supporting multi-speaker critical task push-to-talk (MCPTT) are disclosed. In one embodiment, exchange of the SSRC value between the client and the server for an implicit floor request is accomplished with explicit authorization support during a multi-speaker MCPTT call, where the SSRC is shared in FMTP media attributes of a Session Description Protocol (SDP). In another embodiment, exchange of the SSRC value between the client and the server for an implicit floor request is accomplished with implicit authorization support during a multi-speaker MCPTT call, where the SSRC is shared in FMTP media attributes of an SDP. In another embodiment, exchange of the SSRC value between the client and the server for an implicit floor request is accomplished with implicit / explicit authorization support during a multi-speaker MCPTT call, where the SSRC is shared in FMTP media attributes of the SSRC and SDP.

Description

[0001] This application is a divisional application of a patent application with an application date of May 20, 2021, application number 202180036423.7, and invention name “Method and device for communication in a communication system supporting multi-speaker critical mission push-to-talk (MCPTT)”. Technical Field

[0002] 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

[0003] 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.

[0004] Additionally, 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.

[0005] The floor control server does 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 unless explicitly stated in the INVITE request or in the SIP REFER request. The MCPTT client needs to include various attributes when a SIP request should be interpreted as an implicit floor request.

[0006] In 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 case of the implicit floor request method.

[0007] 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

[0008] Technical issues 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 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.

[0011] 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.

[0012] In an embodiment of the present disclosure, a method and apparatus for exchanging SSRC values ​​between a client and a server for an implicit right to speak request are provided. In one embodiment, exchanging SSRC values ​​between a client and a server for an implicit right to speak request is accomplished with Explicit Grant Support during a multi-speaker MCPTT call, where the SSRC is shared in the FMTP media attributes of a Session Description Protocol (SDP). In another embodiment, exchanging SSRC values ​​between a client and a server for an implicit right to speak request is accomplished with Implicit Grant Support during a multi-speaker MCPTT call, where the SSRC is shared in the FMTP media attributes of the SDP. In another embodiment, exchanging SSRC values ​​between a client and a server for an implicit right to speak request is accomplished with Implicit / Explicit Grant Support during a multi-speaker MCPTT call, where the SSRC is shared in the FMTP media attributes of the SSRC and SDP.

[0013] 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.

[0014] 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.

[0015] 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.

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

[0017] 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

[0018] 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.

[0019] Figure 1a Method operations according to embodiments of the present subject matter are shown.

[0020] 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.

[0021] 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.

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

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

[0024] Figure 5 A computing device-based implementation of the method operation of FIG. 1 according to an embodiment of the present disclosure is shown.

[0025] 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

[0026] 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.

[0027] 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.

[0028] Before proceeding to 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, connected to or connected therewith, coupled to or coupled therewith, can communicate with..., cooperate with..., interlaced, parallel, close to, bound to or bound therewith, have, have the nature of..., be related to or have a relationship with, 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.

[0029] 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 suitable for 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 do 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 later rewrite data, such as rewritable optical disks or erasable storage devices.

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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.

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

[0035] 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.

[0036] 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.

[0037] 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 SSRC is shared in an FMTP media attribute of a Session Description Protocol (SDP).

[0038] 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.

[0039] The method includes receiving, by the client, from the server the same SSRC value formatted according to the 200 OK response if the SSRC value is not in use (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.

[0040] 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.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] 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: proposal: m=application 1234 udp MCPTT a=fmtp: MCPTT mc_priority=5; mc_implicit_request; mc_ssrc=11111 answer: m=application 1234 udp MCPTT a=fmtp:MCPTT mc_priority=5; mc_implicit_request; mc_ssrc=11111 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: proposal: m=application 1234 udp MCPTT a=fmtp: MCPTT mc_priority=5; mc_implicit_request; mc_ssrc=11111 answer: m=application 1234 udp MCPTT a=fmtp:MCPTT mc_priority=5; mc_implicit_request; mc_ssrc=22222 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.

[0045] 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: proposal: m=application 1234 udp MCPTT a=fmtp:MCPTTmc_priority=5;mc_implicit_request; mc_granted; mc_ssrc=11111 answer: m=application 1234 udp MCPTT a=fmtp:MCPTTmc_priority=5;mc_implicit_request; mc_granted; mc_ssrc=11111 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: proposal: m=application 1234 udp MCPTT a=fmtp:MCPTTmc_priority=5;mc_implicit_request; mc_granted; mc_ssrc=11111 answer: m=application 1234 udp MCPTT a=fmtp:MCPTTmc_priority=5;mc_implicit_request; mc_granted; mc_ssrc=22222 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 3 In 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.

[0046] 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: proposal: m=audio 14000 RTP / AVP 105 a=ssrc:11111 cname: MCPTTUser@example.com m=application 1234 udp MCPTT a=fmtp:MCPTT mc_priority=5; mc_granted;mc_implicit_request answer: m=audio 14000 RTP / AVP 105 a=ssrc:xxxxx cname:MCPTTServer@example.com m=application 1234 udp MCPTT a=fmtp:MCPTT mc_priority=5;mc_granted;mc_implicit_request;mc_ssrc=11111 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: proposal: m=audio 14000 RTP / AVP 105 a=ssrc:11111 cname: MCPTTUser@example.com m=application 1234 udp MCPTT a=fmtp:MCPTT mc_priority=5;mc_granted;mc_implicit_request answer: m=audio 14000 RTP / AVP 105 a=ssrc:xxxxx cname:MCPTTServer@example.com m=application 1234 udp MCPTT a=fmtp:MCPTT mc_priority=5;mc_granted;mc_implicit_request;mc_ssrc=22222 Thus, embodiments of the present disclosure ensure uniqueness of SSRC usage across multiple sending clients in a group call.

[0047] 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.

[0048] 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 the plurality of clients in response to receiving an outgoing INVITE request from each of the plurality of clients, the outgoing INVITE request including the 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.

[0049] 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.

[0050] 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.

[0051] 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.

[0052] 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 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 of (sequential or additional) 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 run one or more sets of instructions to perform one or more computer functions, either individually or jointly.

[0053] 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.

[0054] 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.

[0055] 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.

[0056] 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 within the memory 2504 or within the processor 2502 during operation by the computer device 1200.

[0057] The present disclosure contemplates a computer-readable medium that includes instructions 2524 or receives and runs instructions 2524 in response to a propagation signal, so that a device connected to a network 2526 can transmit voice, video, audio, image, 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 a 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. Similarly, additional connections to other components of the device 1200 can be physical or can be established wirelessly. The network 2526 may alternatively be connected directly to the bus 2508 .

[0058] 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 that are now available 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 switching network transmissions (e.g., TCP / IP, UDP / IP, HTML, and HTTP) may be used.

[0059] 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 mission-critical push-to-talk (MCPTTT) client device in a communication system, the method comprising: In case the MCPTT client initiates a call with an implicit floor request, sending a session description protocol SDP proposal to the MCPTT server, the SDP proposal including a synchronization source SSRC value and a format specific parameter fmtp attribute for the implicit floor request; as well as Responsive to whether the SSRC value in the SDP offer is being used, receiving an SDP answer from the MCPTT server including the same SSRC value or a new SSRC value.

2. The method according to claim 1, wherein: Based on the implicit floor request, the SDP answer includes the same SSRC value or a new SSRC value as an fmtp attribute.

3. The method according to claim 1, wherein: Receiving an SDP response from the MCPTT server includes: In response to the SSRC value in the SDP offer not being used, receiving an SDP answer including the same SSRC value from the MCPTT server.

4. The method according to claim 1, wherein: Receiving an SDP response from the MCPTT server includes: In response to the SSRC value in the SDP offer being used, receiving an SDP answer including a new SSRC value from the MCPTT server.

5. The method according to claim 1, wherein: The MCPTT client device sends a Session Initiation Protocol SIP INVITE request including the SDP offer to the MCPTT server, and The MCPTT client device receives a SIP 200 OK response including the SDP answer from the MCPTT server.

6. A mission-critical push-to-talk (MCPTTT) client device in a communication system, the MCPTT client device comprising: Transceiver; one or more processors, the one or more processors comprising processing circuitry; as well as a memory storing instructions which, when executed individually or collectively by the one or more processors, cause the MCPTT client device to: In case the MCPTT client initiates a call with an implicit floor request, sending a session description protocol SDP offer to an MCPTT server via the transceiver, the SDP offer including a synchronization source SSRC value, and Responsive to whether the SSRC value in the SDP offer is being used, receiving an SDP answer including the same SSRC value or a new SSRC value from the MCPTT server via the transceiver.

7. The MCPTT client device according to claim 6, wherein: The SDP offer also includes a format specific parameter fmtp attribute for the implicit floor request, and Wherein, based on the implicit floor request, the SDP answer includes the same SSRC value or a new SSRC value as an fmtp attribute.

8. The MCPTT client device according to claim 6, wherein: When the instructions are executed by the one or more processors individually or collectively, the instructions cause the MCPTT client device to: In response to the SSRC value in the SDP offer being unused, receiving, via the transceiver, an SDP answer from the MCPTT server including the same SSRC value.

9. The MCPTT client device according to claim 6, wherein: When the instructions are executed by the one or more processors individually or collectively, the instructions cause the MCPTT client device to: In response to the SSRC value in the SDP offer being used, receiving an SDP answer including a new SSRC value from the MCPTT server via the transceiver.

10. The MCPTT client device according to claim 6, wherein: When the instructions are executed by the one or more processors individually or collectively, the instructions cause the MCPTT client device to: sending, via the transceiver, a Session Initiation Protocol SIP INVITE request including the SDP offer to the MCPTT server, and A SIP 200 OK response including the SDP answer is received from the MCPTT server via the transceiver.

11. A method performed by a mission-critical push-to-talk (MCPTTT) server in a communication system, the method comprising: receiving a session description protocol (SDP) offer from an MCPTT client device, the SDP offer including a synchronization source (SSRC) value and a format specific parameter (fmtp) attribute for an implicit floor request; In a case where the SSRC value in the SDP offer is not used, sending an SDP answer including the same SSRC value to the MCPTT client device; as well as In the event that the SSRC value in the SDP offer is being used, an SDP answer including a new SSRC value is sent to the MCPTT client device.

12. The method according to claim 11, wherein: Based on the implicit floor request, the SDP answer includes the same SSRC value or a new SSRC value as an fmtp attribute.

13. The method according to claim 11, wherein: The SDP answer includes the same SSRC value or a new SSRC value as the "mc_ssrc" fmtp attribute.

14. The method of claim 11, further comprising identifying whether the SSRC value in the SDP offer is being used.

15. The method according to claim 11, wherein: The MCPTT server receives a Session Initiation Protocol (SIP) INVITE request including the SDP offer from the MCPTT client device, and The MCPTT server receives a SIP 200 OK response including the SDP answer from the MCPTT client device.

16. A mission-critical push-to-talk (MCPTTT) server in a communication system, the MCPTT server comprising: Transceiver; as well as one or more processors, the one or more processors comprising processing circuitry; as well as a memory storing instructions, which, when executed individually or collectively by the one or more processors, cause the MCPTT server to: receiving, via the transceiver, a session description protocol (SDP) offer from an MCPTT client device, the SDP offer comprising a synchronization source (SSRC) value and a format specific parameter (fmtp) attribute for an implicit floor request; In a case where the SSRC value in the SDP offer is not used, sending, via the transceiver, an SDP answer including the same SSRC value to the MCPTT client device; as well as In the event that the SSRC value in the SDP offer is being used, an SDP answer including a new SSRC value is sent to the MCPTT client device via the transceiver.

17. The MCPTT server according to claim 16, wherein: Based on the implicit floor request, the SDP answer includes the same SSRC value or a new SSRC value as an fmtp attribute.

18. The MCPTT server according to claim 16, wherein: The SDP answer includes the same SSRC value or a new SSRC value as the "mc_ssrc" fmtp attribute.

19. The MCPTT server according to claim 16, wherein: When the instructions are executed by the one or more processors individually or collectively, the instructions cause the MCPTT server to: Identifying whether the SSRC value in the SDP offer is being used.

20. The MCPTT server according to claim 16, wherein: When the instructions are executed by the one or more processors individually or collectively, the instructions cause the MCPTT server to: receiving, via the transceiver, from the MCPTT client device a Session Initiation Protocol SIP INVITE request including the SDP offer, and A SIP 200 OK response including the SDP answer is sent to the MCPTT client device via the transceiver.

Images