Patent Description:
In a Multi-Talker MCPTT call, when all group members are silent, a group member can press the Push-To-Talk (PTT) button, which is indicative of a request for permission to talk. A floor participant entity of said group member reflects this request to the floor control server by sending a Floor Request message. If the floor control server decides to permit, it informs this permission by sending a Floor Granted message to the requesting group member. The floor control server informs the initiation of the talk to the other group members by sending a Floor Taken message.

Further, in case of Multi-talker MCPTT calls, multiple Real Time Protocol (RTP) streams are identified through synchronization source (SSRC) value in the floor messages. The SSRC identifier uniquely identifies the floor participant within a session of a Multi-talker MCPTT call. The SSRC value is generated by the floor requester and sent in a Floor REQUEST message.

The original INVITE request or Session Initiation Protocol (SIP) REFER request to establish an MCPTT chat group call or to rejoin an ongoing MCPTT call is not handled as an implicit floor control request message by the floor control server, 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 shall be interpreted as an implicit floor request.

In case of implicit floor request method, the floor request is referred in INVITE itself and there is no explicit Floor REQUEST message from client. There is no mechanism defined in 3rd Generation Partnership Project (3GPP) Mission Critical Services (MCX) specs to exchange the SSRC value between client and server in case of implicit floor request method.

Therefore, it is required to address such concerns and to provide one more method implemented in a system to exchange the SSRC value between the client and the server for implicit floor requests.

Document <CIT> discloses an enhanced push to talk (PTT) method, a network, and a PTT server provide floor control and media traffic optimization for push to talk over cellular (PoC).

Document <NPL> discloses the indications of the "mc_granted" and "mc_implicit_request" fmtp attribute parameters within an SDP offer or an SDP answer.

This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the disclosure. This summary is neither intended to identify key or essential inventive concepts of the disclosure and nor is it intended for determining the scope of the disclosure.

The present disclosure is to provide a method and apparatus for communicating efficiently between a client and a server in a communication system supporting the MCPTT.

The present disclosure provides a method to exchange an SSRC value between client and server for implicit floor requests in accordance with Mission Critical Push-To-Talk (MCPTT) Multi-Talker call. The method comprises sharing by the client, SSRC value as Format Specific Parameter (FMTP) media attribute of a session description protocol (SDP) in an outgoing INVITE request to the server. The same SSRC value formatted in accordance with <NUM> OK response is received by the client from the server if the SSRC value is not in use. Thereafter, a new SSRC value formatted in accordance with <NUM> OK response is received by the client from the server if the SSRC value is in use.

The present disclosure provides a method to identify a client amongst a plurality of clients during a MCPTT call. The method comprises receiving, by at least one client, from the server a floor taken message associated with each of the plurality of clients comprising a SSRC value formatted in accordance with <NUM> OK response. The method comprises receiving, by the at least one client, a plurality of Real-Time Transport Protocol (RTP) streams from the plurality of clients with the SSRC value associated with each of the plurality of clients. The method further comprises identifying, by the at least one client, each client amongst the plurality of clients based on the SSRC value received in the floor taken message associated with each of the plurality of clients and the SSRC value received with the plurality of RTP streams.

In embodiment of the present disclosure, a method and apparatus to exchange an SSRC value between a client and a server for implicit floor requests are provided. In one embodiment, the exchange of the SSRC value between the client and the server for implicit floor requests is being done with Explicit Grant Support during a Multi-Talker MCPTT call where the SSRC sharing in FMTP media attribute of Session Description Protocol (SDP). In another embodiment, the exchange of the SSRC value between the client and the server for implicit floor requests is being done with Implicit Grant Support during a Multi-Talker MCPTT call where the SSRC sharing in FMTP media attribute of SDP. In another embodiment, the exchange of the SSRC value between the client and the server for implicit floor requests is being done with Implicit/Explicit Grant Support during a Multi-Talker MCPTT call where the SSRC sharing in SSRC and FMTP media attribute of SDP.

In 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 comprises sharing a synchronization source (SSRC) value as format specific parameter (FMTP) media attribute of a session description protocol (SDP) in an outgoing INVITE request from a client, transmitting, to the client, the same SSRC value formatted in accordance with <NUM> OK response if the SSRC value is not in use, and transmitting, to the client, a new SSRC value formatted in accordance with <NUM> OK response if the SSRC value is in use.

In embodiment of the present disclosure, a server device in a communication system supporting mission critical push-to-talk (MCPTT) is provided, the server device comprises a transceiver, and a processor configured to share a synchronization source (SSRC) value as format specific parameter (FMTP) media attribute of a session description protocol (SDP) in an outgoing INVITE request from a client, transmit, to the client, the same SSRC value formatted in accordance with <NUM> OK response if the SSRC value is not in use, and transmit, to the client, a new SSRC value formatted in accordance with <NUM> OK response if the SSRC value is in use.

Further, the methods disclosed in the specification can be implemented in any MCPTT supported system which includes but not limited to Mobile device, soft clients etc..

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

To further clarify the advantages and features of the present disclosure, a more particular description of the disclosure will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the disclosure and are therefore not to be considered limiting of its scope. The disclosure will be described and explained with additional specificity and detail with the accompanying drawings.

Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have been necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent operations involved to help to improve understanding of aspects of the present disclosure. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having benefit of the description herein.

For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as illustrated therein being contemplated as would normally occur to one skilled in the art to which the disclosure relates.

It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the disclosure and are not intended to be restrictive thereof.

The term "couple" and its derivatives refer to any direct or indirect communication between two or more elements, whether those elements are in physical contact with one another. Likewise, the term "set" means one or more. Accordingly, a set of items can be a single item or a collection of two or more items.

Reference throughout this specification to "an aspect", "another aspect" or similar language means 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 phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but do not necessarily, all refer to the same embodiments.

The terms "comprises", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of operations does not include only those operations but may include other operations not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by "comprises. "A does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are illustrative only and not intended to be limiting.

According to the present disclosure, systems and methods are disclosed to exchange the SSRC value between a client and a server for implicit floor requests with at least one of implicit grant support, explicit grant support or implicit/explicit grant support during a Multi-Talker MCPTT call. The methods disclosed in the specification are not limited to the MCPTT service and can be used for other MCX services such as MCVideo, MCData, etc..

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

<FIG> illustrates a method to exchange an SSRC value between client and server for implicit floor requests in accordance with Mission Critical Push-To-Talk (MCPTT) Multi-Talker call.

The method comprises sharing (operation <NUM>) by the client, SSRC value as FMTP media attribute of a session description protocol (SDP) in an outgoing INVITE request to the server. The sharing by client the SSRC value comprises sharing the SSRC value by adding it to the "mc_ssrc" FMTP attribute of the application m-line of SDP offer for the outgoing INVITE request.

In an example, the sending and receiving the SSRC value is defined as an exchange of the SSRC value between the client and the server for implicit floor requests with Explicit Grant Support during a Multi-Talker MCPTT call where the SSRC is shared in FMTP media attribute of the Session Description Protocol (SDP).

In other example, the sharing by the client the SSRC value comprises performing the SSRC sharing as an FMTP attribute of SDP, either in application m-line or media m-line.

The method comprises receiving (operation <NUM>) by the client from the server the same SSRC value formatted in accordance with <NUM> OK response if the SSRC value is not in use. The receiving from the server the SSRC value comprises receiving from the server the same SSRC value included in the "mc_ssrc" fmtp attribute of the application m-line in SDP answer of the <NUM> OK response for INVITE.

The method further comprises receiving (operation <NUM>) by the client from the server a new SSRC value formatted in accordance with <NUM> OK response if the SSRC value is in use. The receiving from the server the new SSRC value comprises receiving from the server the new SSRC value in an explicit Floor GRANT message.

In other example, the receiving from the server the new SSRC value comprises receiving from the server the new SSRC value included in the "mc_ssrc" fmtp attribute of the application m-line in SDP answer of the <NUM> OK response for INVITE.

In yet other example, the receiving from the server the new SSRC value comprises receiving an Implicit/Explicit Grant Support during the Multi-Talker MCPTT call where the SSRC sharing is performed via FMTP attribute of application m-line in SDP.

<FIG> illustrates a call flow diagram corresponding to operations <NUM> to <NUM> to exchange SSRC value for implicit floor requests with explicit grant support during Multi-talker MCPTT calls, according to an embodiment of the present disclosure. The method is implemented in devices such as Mobile, soft clients, etc. that supports MCPTT. According to the embodiment, the SSRC is shared in the FMTP media attribute of SDP. Referring to <FIG>, in operation <NUM>, the client (<NUM>) shares the SSRC value by adding it to the "mc_ssrc" fmtp attribute of the application m-line of SDP offer for Outgoing INVITE request.

In an example, in operation <NUM>, if this SSRC value is NOT in use, the server (<NUM>) sends the same SSRC value to client (<NUM>). The server (<NUM>) sends said same SSRC value by including said value to the "mc_ssrc" fmtp attribute of the application m-line in SDP answer of <NUM> OK response for INVITE. The same can be exemplified as:.

In another example, in operation <NUM>, if the SSRC value is already in use, the server (<NUM>) generates a new SSRC. The server <NUM> shares the new SSRC to the client <NUM> in <NUM> OK response. Said embodiment ensures uniqueness of SSRC usage across multiple transmitting clients in a group call. Also, in operation <NUM>, the server <NUM> can send the SSRC in the explicit Floor GRANT message to the client <NUM>. The same can be exemplified as:.

<FIG> illustrates a call flow diagram corresponding to operations <NUM> to <NUM> to exchange SSRC value for implicit floor requests with implicit grant support during Multi-talker MCPTT calls, according to an embodiment of the present disclosure. The method is implemented in devices such as Mobile, soft clients, etc. that supports MCPTT. According to the embodiment, the SSRC is shared in the fmtp media attribute of SDP. Referring to <FIG>, in operation <NUM>, the client <NUM> shares the SSRC value by adding it to the "mc_ssrc" fmtp attribute of the application m-line of SDP offer for Outgoing INVITE request.

In an example, in operation <NUM>, if the SSRC value is NOT in use, the server <NUM> sends the same SSRC value to the client <NUM> by including it to the "mc_ssrc" fmtp attribute of the application m-line in SDP answer of <NUM> OK response for INVITE. The same can be exemplified as:.

In another example, in operation <NUM>, if the SSRC value is already in use, the server <NUM> generates a new SSRC and share it to the client <NUM> in <NUM> OK response. This ensures uniqueness of SSRC usage across multiple transmitting clients in a group call. The same can be exemplified as:.

<FIG> illustrates a call flow diagram corresponding to operations <NUM> to <NUM> to exchange SSRC value for implicit floor requests with implicit/explicit grant support during Multi-talker MCPTT calls, according to an embodiment of the present disclosure. The method is implemented in devices such as Mobile, soft clients, etc. that supports MCPTT. According to the embodiment, the SSRC is shared in ssrc and fmtp media attribute of SDP. Referring to <FIG>, in operation <NUM>, the client <NUM> shares the SSRC value by adding it as an attribute to the media m-line of SDP offer for Outgoing INVITE request.

In an example, in operation <NUM>, if this SSRC value is NOT in use, the server <NUM> sends the same SSRC value to the client <NUM> by including it to the "mc_ssrc" fmtp attribute of the application m-line in SDP answer of <NUM> OK response for INVITE. The same can be exemplified as:.

In another example, in operation <NUM>, if the SSRC value is already in use, the server <NUM> generates a new SSRC. The server <NUM> shares it to client in <NUM> OK response. The same can be exemplified as:.

Thus, the embodiments of the present disclosure ensures uniqueness of SSRC usage across multiple transmitting clients in a group call.

<FIG> illustrates a method to identify a client amongst a plurality of clients during a MCPTT call, in accordance with an embodiment of the present disclosure.

In an embodiment, the method includes receiving (operation <NUM>), by at least one client, from the server a floor taken message associated with each of the plurality of clients comprising a SSRC value formatted in accordance with <NUM> OK response. In an embodiment, the server transmits the floor taken message associated with each of the plurality of clients in response to receiving an outgoing INVITE request comprising SSRC value as FMTP media attribute of a session description protocol (SDP) from each of the plurality of clients. Further, the server may be configured to sharing in response to receiving each of the outgoing INVITE requests, the SSRC value formatted in accordance with <NUM> OK response in a floor grant message with the plurality of clients.

In an embodiment, the method includes receiving (operation <NUM>), by the at least one client, a plurality of Real-Time Transport Protocol (RTP) streams from the plurality of clients with the SSRC value associated with each of the plurality of clients.

In an embodiment, the method includes identifying (operation <NUM>), by the at least one client, each client amongst the plurality of clients based on the SSRC value received in the floor taken message associated with each of the plurality of clients and the SSRC value received with the plurality of RTP streams.

<FIG> illustrates yet another exemplary implementation in accordance with the embodiment of the disclosure, and yet another typical hardware configuration of the networking nodes through a computer device <NUM>. The computer device <NUM> can include a set of instructions that can be executed to cause the computer device <NUM> to perform any one or more of the methods disclosed. The computer device <NUM> may operate as a standalone device or may be connected, e.g., using a network, to other computer devices or peripheral devices. The client <NUM> and the server <NUM> may be also implemented with a processor and a transceiver.

In a networked deployment, the computer device <NUM> may operate as the server (device) <NUM> or as a client (device) <NUM> in a server-client user network environment, or as a peer computer device in a peer-to-peer (or distributed) network environment. The computer device <NUM> 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 communications device, a wireless telephone, a land-line telephone, a web appliance, a network router, switch or bridge, or any other machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while a single computer device <NUM> is illustrated, the term "device" shall also be taken to include any collection of devices or sub-devices that individually or jointly execute a set, or multiple sets, of instructions to perform one or more computer functions.

The computer device <NUM> may include a processor <NUM> e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both. The processor <NUM> may be a component in a variety of devices. For example, the processor <NUM> may be part of a standard personal computer or a workstation. The processor <NUM> may be one or more general 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. The processor <NUM> may implement a software program, such as code generated manually (i.e., programmed).

The computer device <NUM> may include a memory <NUM>, such as a memory <NUM> that can communicate via a bus <NUM>. The memory <NUM> may include, but is not limited to computer-readable storage media such as 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, magnetic tape or disk, optical media and the like. In one example, memory <NUM> includes a cache or random access memory for the processor <NUM>. In alternative examples, the memory <NUM> is separate from the processor <NUM>, such as a cache memory of a processor, the device memory, or other memory. The memory <NUM> may be an external storage device or database for storing data. The memory <NUM> is operable to store instructions executable by the processor <NUM>. The functions, acts or tasks illustrated in the figures or described may be performed by the programmed processor <NUM> for executing the instructions stored in the memory <NUM>. The functions, acts or tasks are independent of the particular type of instructions set, storage media, processor or processing strategy and may be performed by software, hardware, integrated circuits, firmware, micro-code and the like, operating alone or in combination. Likewise, processing strategies may include multiprocessing, multitasking, parallel processing and the like.

As shown, the computer device <NUM> may or may not further include a display unit <NUM>, 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 now known or later developed display device for outputting determined information. The display <NUM> may act as an interface for the user to see the functioning of the processor <NUM>, or specifically as an interface with the software stored in the memory <NUM> or the drive unit <NUM>.

Additionally, the computer device <NUM> may include an input device <NUM> configured to allow a user to interact with any of the components of device <NUM>. The computer device <NUM> may also include a disk or optical drive unit <NUM>. The disk drive unit <NUM> may include a computer-readable medium <NUM> in which one or more sets of instructions <NUM>, e.g. software, can be embedded. Further, the instructions <NUM> may embody one or more of the methods or logic as described. In a particular example, the instructions <NUM> may reside completely, or at least partially, within the memory <NUM> or within the processor <NUM> during execution by the computer device <NUM>.

The present disclosure contemplates a computer-readable medium that includes instructions <NUM> or receives and executes instructions <NUM> responsive to a propagated signal so that a device connected to a network <NUM> can communicate voice, video, audio, images, or any other data over the network <NUM>. Further, the instructions <NUM> may be transmitted or received over the network <NUM> via a communication port or interface <NUM> or using a bus <NUM>. The communication interface <NUM> may be also the transceiver that refers to a receiver and a transmitter. The communication port or interface <NUM> may be a part of the processor <NUM> or maybe a separate component. The communication port <NUM> may be created in software or maybe a physical connection in hardware. The communication port <NUM> may be configured to connect with a network <NUM>, external media, the display <NUM>, or any other components in device <NUM>, or combinations thereof. The connection with the network <NUM> may be a physical connection, such as a wired Ethernet connection or may be established wirelessly as discussed later. Likewise, the additional connections with other components of the device <NUM> may be physical or may be established wirelessly. The network <NUM> may alternatively be directly connected to the bus <NUM>.

The network <NUM> may include wired networks, wireless networks, Ethernet AVB networks, or combinations thereof. The wireless network may be a cellular telephone network, an <NUM>, <NUM>, <NUM>, <NUM>. 1Q or WiMax network. Further, the network <NUM> may be a public network, such as the Internet, a private network, such as an intranet, or combinations thereof, and may utilize a variety of networking protocols now available or later developed including, but not limited to TCP/IP based networking protocols. The device is not limited to operation with any particular standards and protocols. For example, standards for Internet and other packet-switched network transmissions (e.g., TCP/IP, UDP/IP, HTML, and HTTP) may be used.

Claim 1:
A method performed by a client device (<NUM>) in a communication system supporting mission critical push-to-talk, MCPTT, the method comprising:
transmitting (<NUM>), to a server (<NUM>), a session initiation protocol, SIP, INVITE request including a session description protocol, SDP, offer, the SDP offer including a format specific parameter, fmtp, attribute for an implicit request and a synchronization source, SSRC, value as a media attribute of a session description protocol, SDP; and
receiving (<NUM>), from the server (<NUM>), a SIP response including an SDP answer in response to transmission of the SIP INVITE request including the SDP offer, the SDP answer including the fmtp attribute for the implicit request and either the same SSRC value or a new SSRC value;
wherein the SIP INVITE request, including the fmtp attribute of the implicit request, represents an implicit floor request;
wherein the SDP answer includes either the same SSRC value in response to the SSRC value in the SDP offer not being in use or the new SSRC value in response to the SSRC value in the SDP offer being in use; and
wherein the SDP answer includes either the same SSRC value or the new SSRC value as an fmtp attribute of an application m-line of the SDP.