Method, Server and System to manage a "push-to-talk" session

The present invention concerns the field of telecommunications and, specifically, the walkie-talkie type communication services using wireless telecommunication networks. These services are commonly referred to by the English term "push to talk".

A service 'push to talk' in a telecommunication network without Wireless offers subscribers to communicate using the well-known principle of talkie Walkie. Thus, a first subscriber may be in immediate communication by walkie talkie with a list of one or more subscribers, prérépertoriés simply by pressing a button on their terminal. For their part, other Subscribers hear their voice terminal of the first user without press any buttons.

Thus, with the service 'push to talk' of a mobile network subscribers may come into contact with a group of people instantly, without even dial a phone number. Users have the option to send messages to one or more receiving terminals participating in the session simultaneously. Typically, they only need to select one or more contacts from a list displayed on the screen of their terminal and press a button to transmit their information. The terminal becomes transformed by phone and walkie-talkie.

A session 'push to talk' is initiated very simply by a initiating terminal to one or more terminals solicited to participate in the session, the latter being referenced in the following sections by terms 'participating terminals'. After a few steps to be described below, the session is established between the originating terminal and terminal participants. A single one of the terminals of the session is allowed to provide both a license to broadcast can be attributed to a terminal on request of the latter, a terminal is authorized to issue designated by "transmitting terminal". The other terminals of the session receive transmitter device data, and are referenced in the following sections by the terms 'receiving terminals'.

Generally, terminals connected receivers are conventionally warned by a beep and receive immediately after the beep information sent by the sender terminal.

Data sent in a session 'push to talk' can be for example voice data or, in one embodiment in courses, images, including video data.

The simplicity and low cost of communication 'push to talk' allows operators to offer a very attractive and convenient service to the professionals such as taxi drivers for example. Other areas application are the recreation and play with family or friends in extended Locations such as the ski slopes or amusement parks.

The service 'push to talk' is commonly controlled by a server server called 'push to talk'. This server plays a role in both the establishment of the session 'push to talk', in the award of an authorization of transmitting and in the transmission of data transmitted by a terminal transmitter to the receiver terminals.

However, managing a session between a walkie talkie plurality of terminals, each having respective capacities of coding and decoding speech signals and / or images, said session connecting said plurality of terminals via a server, through a first network wireless telecommunication terminals and which are connected second network connected to the server, now poses problems.

In such a context, indeed, the parameters defining some aspects of the session being established, including the type of coding to be used for data transmission, is negotiated with a first called terminal. Accordingly, the initiator terminal code data transmitted according to an encoding type determined by the capacity of coding and decoding it has in common with the first terminal that responded to the session establishment. In the case where several terminals are asked to participate in the session, it is therefore possible that second terminal among the terminals has not solicited capacity of encoding and decoding enabling it to decode the data transmitted by the initiating terminal. In this case, the second terminal can not decode the information received.

Furthermore, when a participating terminal is allowed to transmit, it is possible that he also uses an incompatible encoding with other connected devices.

A disadvantage also appears when a new participant connects to an already established session. Indeed, in this case, terminals already connected to the session does not have the knowledge capabilities encoding and decoding of the new terminal participant. It is possible that that the already connected devices use standard encodings incompatible with coding capabilities and decoding new participating terminal.

The present invention improves the situation.

A first aspect of the invention provides a method of managing a session walkie talkie fashion ( "push to talk") between a plurality of terminals, each having respective capacities of encoding and decoding speech signals and / or images, said session connecting said plurality terminals via a server, through a first network wireless telecommunication terminals which are connected and a second network connected to the server, wherein the server comprises an encoder / decoder data, and in which, after establishing a session at the request of one of terminals:<ul><li>a transmitter terminal transmits data coded according to type of initial coding to one or more other terminals receivers connected via the server;</li><li>the server receives such data coded in said type initial coding;</li><li>the server processes said data according to said capacity respective terminals of said receivers to ensure a compatibility between data encoded according to said type initial coding and data received by the terminals receptors, where appropriate according to at least one encoding type different from the initial coding type;</li><li>the server transmits said processed data to terminals receptors.</li></ul>

A second aspect of the invention provides a server for managing a session in walkie talkie mode ( "push to talk") comprising means for implement a method according to the first aspect.

A third aspect of the invention provides a management system of a session in walkie talkie mode ( "push to talk") comprising means for implement a method according to the first aspect.

Thanks to these provisions, a UMTS network can provide service of 'push to talk' to the adaptive capabilities of the terminals.

Other aspects, objects and advantages of the invention will appear reading the description of one of its embodiments.

The invention will also be better understood with the aid of drawings, which :<ul><li>Figure 1 shows the architecture of an IMS type of multimedia IP network standardized for UMTS Release 5;</li><li>2 illustrates an exchange of messages for the establishment of a session in such an architecture illustrated in Figure 2;</li><li>3 shows a network architecture for managing a session of "push to talk";</li><li>Figure 4 is a representation of the exchange of messages between various network elements for managing a transmission session data 'push to talk' according to one embodiment of the invention.</li></ul>

The following describes the UMTS Release 5 which introduces the IMS (for "Internet Protocol Multimedia Subsystem "). A big change made to this architecture belongs to the correlation between the packet switching domain the UMTS network, designated 7 in Figure 1, as regards the transporting data, and the network, designated 8, based on a IP protocol type (for "Internet Protocol") with mechanisms transport control.

Reference is made to Figure 1 to describe the architecture of an IP network Multimedia standardized IMS type for UMTS Release 5. The heart IP architecture for UMTS Release 5, called IMS (for "Internet Protocol Multimedia Subsystem ") is comprised of equipment CSCF (for" Call State Control Functions ") referenced 4, 5 and 6 that control the multimedia sessions in the IMS network type and interact with others entities of the IMS network type such as application servers. We distinguish several types of CSCFs equipment in the type of network architecture IMS:<ul><li>P-CSCFs modules ( "Proxy-CSCFs"), designated 4, who are the first contact points for terminals in the IMS; these entities include a control function of PDF-type resources,</li><li>S-CSCFs modules (for "Serving-CSCFs"), designated 5, that control sessions of a terminal during the period when the latter is registered in the IMS; and</li><li>modules I-CSCFs (for "Interrogating-CSCFs"), designated 6 which are the entry points to such a network for sessions 8 multimedia between a user of the network and a user belonging to a another similar network.</li></ul>

The network element 9, designated by HSS (for "Home Subscriber Server ") is introduced in the UMTS Release 5 as HLR (for" Home Register Location ") further containing IP domain related functions multimedia. In other words, the HSS network element also contains the basis of subscriber data of a multimedia IP domain. S-CSCFs 5 have a interface with the HSS network elements 9.

The protocol "Session Initiation Protocol" SIP is used by Terminals 1, the type of equipment CSCFs (with references 4, 5 and 6) and application servers. In such an architecture, a SIP session establishes packet transport sessions for services multimedia. The nodes of IP multimedia domain and domain 8 switching UMTS packet 7 are linked such that there is a correlation between the transport layer which provides the resources and the layer application that controls the resources provided to users through the layer transport. Thus, the architecture of an IMS type of multimedia IP network provides resource control. UMTS Version 5 normalizes the establishment a communication session in such an architecture, notably between a terminal 1 of the UMTS network 7, recorded in multimedia IP network IMS type bearing the reference 8, and another terminal or an application server recorded in an IP network.

For the establishment of a session in the IMS domain, a terminal therefore uses the SIP protocol. It first registers in the IMS domain to, among others, to discover the P-CSCF module and the S-CSCF module support this session. Once the terminal is registered in the field IMS, it may initiate a session with one or more other terminals. For this to the terminal uses the procedure 'GUEST' as illustrated in Figure 2.

Figure 2 details the exchange of messages between the different entities of the UMTS network and the Internet. A terminal 1 which is a subscriber packet switched UMTS network 7 and the IMS, register in the Internet 8. This procedure, well known the art, is not described in this description. The description assumes that the terminal 1 is already registered to the network 8. The terminal is authorized to establish a data transmission session. To do this, the terminal initiates the establishment of such a session by sending a message 'INVITE' 21 according to the SIP protocol to the SGSN network element 2. The SGSN network element transmits this message to the network element 3 GGSN, which transmits it to the P-CSCF network element 4. The latter sends this message to the S-CSCF 5 network element which finally sends it to a recipient who can be an application server or a terminal. This Post 21 includes parameters requested by the terminal 1 defining certain aspects of the session being established. The settings can indicate the type of media that will be transmitted during this session (eg video, audio or other). They can also indicate ports on which the terminal wishes to receive data as well as encoders decoders to be used, these may be selected by media type or other parameters characterizing the session. These parameters are typically transmitted in the message SIP INVITE '21 according to SDP.

When the recipient receives the message 'GUEST', they compare parameters requested by the terminal 1 and his own abilities. Of this comparing the recipient deducted from the negotiated parameters it sends to Terminal 1 in a message '183 Session Progress' 22 according to the SIP protocol in response to the message 21. This message 22 is transmitted to the terminal 1 via the successive network elements S-CSCF, P-CSCF, GGSN and SGSN finally.

The terminal 1 sends a message 'PRACK' 23 according to the SIP protocol response to the message '183 Session Progress' 22 according to the SIP protocol. This Post 23 includes parameters common to the recipient and the terminal 1 initiator.

The terminal 1 then requests the network element GGSN 3, the reservation of transmission resources 24 required for the session being established for data transport within the UMTS network packet switching.

Finally on receiving the message 'PRACK' 23 according to the SIP protocol, the data transmission session is established. A message '200 OK' 25 according to the SIP protocol informs the terminal 1.

According to a preferred embodiment of the present invention, the architecture of a service 'push to talk' in a UMTS network is based on IMS whose principles were set out above. Such a architecture is described below with reference to Figure 3.

Indeed, in Figure 3, a first, a second and a third terminal, respectively referenced 31, 32 and 33 are connected to the UMTS network packet switching with the reference 7. A server 'push to talk' is 30 introduced into the IMS domain.

An embodiment of the present invention introduced into a architecture as described above, a server 'push to talk' has the ability to establish session '' push to talk ', and further having the ability manage and adapt the transmission of encoded data received from a terminal being authorized to be transmitted to each of the receiving terminals according to the coding data received from the transmitting terminal and respective capabilities encoding and decoding of the receiver terminals.

In order to achieve such an adjustment in the transmission of data, the server knows preferably coding capabilities and decoding each of the terminals connected to the session. To do this, the server stores the respective capabilities of encoding and decoding terminals connected to the session at the exchange of messages between terminals during the session establishment as described in detail in the following sections. However, the invention covers any other manner, for the server, storing the respective capabilities of coding and decoding terminals connected to the session.

In one embodiment of the invention, the server 'push to talk' advantageously includes features allowing it to handle, for each of the receiving terminals, a received packet to extract the data Useful (removing the transport header) to determine whether the data received are coded such that the respective receiving terminal is capable of decoding. When the server 'push to talk' detects that a terminal receiver does not have the ability to decode the data coded by the transmitter, server adapts the coding data to be transmitted by coding again the data so that the receiving terminal is capable of the decode.

In a preferred embodiment of the invention, the server 'push to talk 'is advantageously provided with an encoder / decoder adapted to perform an adaptive coding of data received in accordance with the capacity of terminals involved in the session 'push to talk'.

At the end of this adaptive coding, server 'push to talk' adds the header transport each recoded data packet before forwarding these data to the terminal to which the adaptive coding was performed.

In one embodiment of the invention these coders / decoders are encoders / decoders like AMR (for "Adaptive Multi Rate"). A encoder / decoder AMR type conventionally available in 8 different modes defining different flow rates. Thus, the initiator terminal indicates modes It supports AMR in the requested parameters. Encoders / decoders AMR are given for illustration, the invention covers course other Types of encoders / decoders.

In one embodiment of the invention, a session is established 'Push to talk' according to the SIP protocol and manages the allocation of authorization issue according to the protocol "Real Time Control Protocol 'or PSTN.

Figure 4 depicts such an embodiment of the present invention.

In Figure 4, the terminal 31 initiates the session 'push to talk' by sending a message 'GUEST' 401 according to the SIP server 'push to talk '30. This message preferably contains settings for the service 'Push-to-talk', such as for example the coding capabilities and decoding initiating terminal (that is to say the codecs that can be used by the initiator terminal). These parameters are preferably transmitted in SDP.

The server 'push to talk' 30 transmits this message 'GUEST' according to the SIP terminals 32, 33 participants in this session 'push to talk' through posts referenced 402 and 403.

The server stores preferably the coding capacity and Decoding the initiator terminal contained in this message 'GUEST' 401.

Participants terminals 32, 33 meet each server 'push to talk '30 with a message' 200 OK 'as referenced SIP respectively 404 and 409. Preferably, these messages '200 OK' 404, 409 also contain a description of the types of media and type of encoding and decoding supported by the respective participating terminals 32 and 33. Such a description can be transmitted according to the SDP.

Preferably, upon receipt of a message '200 OK' according to protocol SIP, the server stores the coding and decoding capabilities on this terminal.

Furthermore, upon receiving the first message '200 OK' as the SIP, which is the message '200 OK' 404 sent by the participating terminal 32, the server 30 sends the initiator terminal a message according RTCP referenced 405 for the permit to be issued. The server then sends a message '200 OK' 406 according to the SIP protocol to the terminal initiator 31 indicating the coding capabilities and decoding of the first terminal participating respondents.

Then the server sends a message 411 to the RTCP protocol participating terminal 32 who responded, to indicate that it is the terminal 31 which is authorized to issue.

The other participating terminal 33 responds to the message 'GUEST' according to the SIP protocol by sending a message '200 OK' 409 according to the SIP protocol server 'push to talk' 30, which contains its own encryption capabilities and decoding. The server 'push to talk' 30 stores coding capabilities and Decoding the participating terminal 33 and returns a message 412 according to the RTCP protocol to the terminal 33.

Then, the initiator terminal session 'push to talk' receives from the server 'Push to talk' 30 messages notifications 408 and 410 informing the connection of participating terminals 32, 33.

When the initiator terminal allowed to transmit data to code issue, it selects a type of initial coding among the types of coding it has in common with the participating terminal 32 that responded to the first message 'INVITE according to the SIP protocol and that have been indicated in the reply message '200 OK' 406 according to the SIP protocol received from the server 'Push to talk' 30. Then the initiator terminal sends the encoded data 415.

Data transmission is preferably performed using the Protocol "Real Time Protocol" or RTP.

The server receives the message encoded data 415 and processes these data. Indeed, the server checks the compatibility of the respective capabilities receiving terminals with the original encoding type used by the terminal transmitter. This control is performed based on the stored information on coding capabilities and decoding of connected devices.

Following this control, the server detects that the terminal capabilities receiver 32 is compatible with the initial coding type used by the transmitting terminal 31. Thus, the server transmits the encoded data 415 as they were received, that is to say, coded according to the initial coding type.

By cons, the server detects a mismatch between the capacity of encoding and decoding of the receiving terminal 33 and the original encoding type used by the sender terminal 31. Accordingly, the server services the follows for each received data packet: <ul><li>extraction of useful data contained in the packet (that is to say, removal of the transport header corresponding generally the following protocols RTP layers and UDP for "User Datagram Protocol", then for IP "Internet Protocol ')</li><li>selecting an encoding type compatible with the capacities the terminal 33 stored;</li><li>coding the payload of the packet according to the type of coding selected;</li><li>adding the transport header;</li><li>transmitting the packet to the receiving terminal 33.</li></ul>

The transmission of data encoded according to the encoding type selected by the server to the participating terminal 33 is referenced 416.

It should be noted that according to a service 'push to talk' of the prior art, server does not realize encoding type of adaptation and therefore the data coded according to the initial coding type received from the terminal 31 is transmitted participants terminals 32 and 33 coded according to the initial coding type. By Therefore, the participating terminal 33 is not able to decode.

When the transmitter initiator terminal has finished sending, it sends a message 'release' as RTCP referenced 417 to indicate it finished transmitting. On receipt of this message, the server 'push to talk' sends message 'idle' according RTCP each participating terminal, respectively referenced 418, 419, informing them that they may ask broadcasting authorization.

Thus, when a participating terminal, having the right to issue, issues data to the other terminals connected to the session via the server, server operates in the same manner as described above to adapt the type of coding of data transmitted.

In one embodiment of the present invention, when a new terminal wishes to participate in the session 'push to talk' established, it sends a message 'INVITE' as SIP server 'push to talk' containing the or the coding types that it supports. Therefore, the server stores the coding capabilities and decoding of this new terminal connected to to operate as previously described when transmissions Subsequent encoded data.

An embodiment of the invention therefore advantageously provides a service architecture 'push to talk' simple, very flexible and adaptive. In Indeed, it allows terminals with coding capacity and Incompatible decoding yet be communicated without introducing functionality at the terminal.

In addition, an embodiment of the invention is easy to deals with a UMTS network Release 99, 4, 5, 6 and by the following Therefore.