Multi-Users Real-Time Transcoding System and Method for Multimedia Sessions
Claim Score by NHIP
Abstract
A method an system for establishing a multi-user communication session, having a session description, between terminals with incompatible media characteristics, in which users with terminals having incompatible media characteristics are invited to participate in the communication session. A transcoding session is set up for enabling transcoding between the incompatible media characteristics of the terminals based on information about the terminals of the users having accepted the invitation, this information comprising the media characteristics of the users' terminals. The session description is established according to the transcoding session and, during the communication session, media streams from the terminal of one user are transcoded according to the transcoding session and the transcoded media streams are transmitted according to the session description to the other users participating in the communication session, using the media characteristics of the terminals of those other users.
Term
No projected expiry on record.
- Priority
- Filed
- Published
- Today
67 claims: 4 independent, 63 dependent
- 67Broadest claimClaim Score 60, broad(NHIP)A method for establishing a multi-user communication session, having a session description, between at least three terminals having incompatible media characteristics, the method comprising:inviting users with terminals having incompatible media characteristics to participate in the communication session;setting up a transcoding session enabling transcoding between the incompatible media characteristics of the terminals based on information about the terminals of the users having accepted the invitation, said information comprising the media characteristics of the users' terminals;establishing the session description according to the transcoding session;during the communication session, transcoding media streams from the terminal of one user according to the transcoding session and transmitting the transcoded media streams according to the session description to the other users participating in the communication session, using the media characteristics of the terminals of said other users;and during the communication session, updating the transcoding session as new users join the communication session based on information about the terminals of the new users and as participating users leave the communication session.
- 86A system for establishing a multi-user communication session, having a session description, between at least three terminals having incompatible media characteristics, the system comprising:means for inviting users with terminals having incompatible media characteristics to participate in the communication session;means for setting up a transcoding session enabling transcoding between the incompatible media characteristics of the terminals based on information about the terminals of the users having accepted the invitation, said information comprising the media characteristics of the users' terminals;means for establishing the session description according to the transcoding session;during the communication session, means for transcoding media streams from the terminal of one user according to the transcoding session and transmitting the transcoded media streams according to the session description to the other users participating in the communication session, using the media characteristics of the terminals of said other users;and during the communication session, means for updating the transcoding session as new users join the communication session based on information about the terminals of the new users and as participating users leave the communication session.
- 87A system for establishing a multi-user communication session, having a session description, between at least three terminals having incompatible media characteristics, the system comprising:a network element for inviting users with terminals having incompatible media characteristics to participate in the communication session;and a transcoding server for setting up a transcoding session enabling transcoding between the incompatible media characteristics of the terminals based on information about the terminals of the users having accepted the invitation, said information comprising the media characteristics of the users' terminals;wherein: the transcoding server establishes the session description according to the transcoding session;during the communication session, the transcoding server transcodes media streams from the terminal of one user according to the transcoding session and transmits the transcoded media streams according to the session description to the other users participating in the communication session, using the media characteristics of the terminals of said other users;and during the communication session, the transcoding server updates the transcoding session as new users join the communication session based on information about the terminals of the new users and as participating users leave the communication session.
Independent claims3
104 paragraphs in 8 sections, as filed
CROSS REFERENCE TO RELATED APPLICATIONS
p-0002This application claims the benefit of U.S. Provisional Application No. 60/754,194, filed on Dec. 28, 2005 and entitled, “REAL-TIME TRANSCODING ARCHITECTURE FOR PoC”, which is incorporated herein in its entirety.<sub>[0]</sub>
FIELD OF THE INVENTION
p-0003The present invention generally relates to a system and method for establishing a multi-user communication session. More specifically, but not exclusively, the present invention is concerned with a multiparty real-time transcoding system and method for push to talk over cellular multimedia sessions.
BACKGROUND OF THE INVENTION
p-0004The Push to Talk Over Cellular (PoC) service allows mobile users to create group sessions where participants can have voice and data communications on a one-to-one or one-to-many basis [1]. The voice communications are similar to walkie-talkie services where the terminals have dedicated ‘talk’ buttons. Only one person can talk at a given time and each talk burst is relatively short, for example, it lasts for a few seconds. Users can also exchange instant messages. Soon the talk bursts will evolve to bursts of voice and video streams, and the instant messages will contain rich media content such as audio, video, text, animation, etc.
p-0005The Push to Talk Over Cellular (PoC) service specifications is defined by the Open Mobile Alliance (OMA). It is based on the Session Initiation Protocol (SIP) in the Third Generation Partnership Project (3GPP or 3GPP2) Internet Protocol Multimedia Subsystem (IMS) architecture. More specifically, the PoC service is built on top of a SIP/IP core which can meet the specifications of the 3GPP IP Multimedia Sub-system (IMS) [4, 5] or the 3GPP2 IMS [6, 7].
p-0006The overall PoC architecture for the generic case comprises a plurality of PoC clients, each one of them connected to its own Participating PoC Function (over its own network), participating to a common session controlled by a central Controlling PoC Function. All the PoC Functions are connected to the central Controlling PoC Function.
p-0007It is important to note that the Controlling PoC Function is responsible for managing who has permission to talk (i.e. who has the permission to send audiovisual media or multimedia packets) at any given time and for copying media packets from one source to multiple destinations. The Participating PoC function cannot perform those operations.
p-0008Because of the diversity of the terminals and networks, interoperability issues are arising. For instance, 3GPP mandates the use of AMR (Adaptive Multi-Rate) narrowband speech codec as the default speech codec in the PoC service [2]. 3GPP also mandates the support of the AMR wideband speech codec, if the User Equipment on which the PoC Client is implemented uses a 16 kHz sampling frequency for the speech. On the other hand, 3GPP2 mandates the EVRC (Enhanced Variable Rate Coded) speech codec as the default speech codec [3]. Therefore, 3GPP and 3GPP2 PoC terminals supporting AMR and EVRC audio codecs respectively would not be able to establish a PoC session together, due to incompatibilities. The same incompatibilities are expected to arise for the instant messages containing video and media. To solve this problem, transcoding is required. Transcoding allows converting, in a network element, from one format to another to meet each participant's terminal capabilities.
p-0009Since the PoC service is built on top of a 3GPP/3GPP2 IMS SIP/IP core, the media is controlled and processed by the MRFC/MRFP (Media Resource Function Controller/Media Resource Function Processor) [4, 8], which uses the H.248/MGCP (Media Gateway Control Protocol) protocol [9-11] for communication purposes. However these specifications are quite complex and developing a solution which conforms to those protocols requires a huge effort. Also, H.248/MGCP is being criticized and challenged because it is complex, costly and it is the only IMS key system component which is not SIP-based. For those reasons, there is a need to address the problem of transcoding in the PoC application with a more generic framework, which is not limited to MRFC/MRFP and H.248/MGCP. Also, although the MRFC/MRFP functionalities and interfaces are well-defined, their usage in a PoC context is not defined.
p-0010In the PoC standard, the need for transcoding is recognized but no detailed solutions are provided. It is said in [1] that transcoding may be performed by both the Controlling PoC Function (CPF) and/or the Participating PoC Function (PPF) without further details. It is therefore important to develop a transcoding architecture that supports various configurations and use cases. In some cases, it is also highly desirable that transcoding be added in a transparent fashion, so that it can work and fit with the already deployed PoC equipment.
p-0011In summary, there is a need for a generic solution supporting transcoding in the PoC context. The solution should be compatible with the existing PoC architecture and protocols so as to be accepted and integrated into the standard schemes such as 3GPP, 3GPP2 and OMA. Also the solution needs to be flexible to be able to adapt to different equipment deployment scenarios and constraints.
OBJECTS OF THE INVENTION
p-0012A non-limitative object of the present invention is therefore to provide a multiparty real-time transcoding system and method for push and talk over cellular (PoC) multimedia sessions.
SUMMARY OF THE INVENTION
p-0013More specifically, in accordance with the present invention, there is provided a method for establishing a multi-user communication session, having a session description, between terminals having incompatible media characteristics, the method comprising: inviting users with terminals having incompatible media characteristics to participate in the communication session; setting up a transcoding session enabling transcoding between the incompatible media characteristics of the terminals based on information about the terminals of the users having accepted the invitation, this information comprising the media characteristics of the users' terminals; establishing the session description according to the transcoding session; and during the communication session, transcoding media streams from the terminal of one user according to the transcoding session and transmitting the transcoded media streams according to the session description to the other users participating in the communication session, using the media characteristics of the terminals of said other users.
p-0014The present invention also relates to a system for establishing a multi-user communication session, having a session description, between terminals having incompatible media characteristics, the system comprising: means for inviting users with terminals having incompatible media characteristics to participate in the communication session; means for setting up a transcoding session enabling transcoding between the incompatible media characteristics of the terminals based on information about the terminals of the users having accepted the invitation, this information comprising the media characteristics of the users' terminals; means for establishing the session description according to the transcoding session; and during the communication session, means for transcoding media streams from the terminal of one user according to the transcoding session and transmitting the transcoded media streams according to the session description to the other users participating in the communication session, using the media characteristics of the terminals of said other users.
p-0015The present invention still further relates to a system for establishing a multi-user communication session, having a session description, between terminals having incompatible media characteristics, the system comprising: a network element for inviting users with terminals having incompatible media characteristics to participate in the communication session; a transcoding server for setting up a transcoding session enabling transcoding between the incompatible media characteristics of the terminals based on information about the terminals of the users having accepted the invitation, this information comprising the media characteristics of the users' terminals; wherein: the transcoding server establishes the session description according to the transcoding session; and during the communication session, the transcoding server transcodes media streams from the terminal of one user according to the transcoding session and transmits the transcoded media streams according to the session description to the other users participating in the communication session, using the media characteristics of the terminals of said other users.
p-0016The foregoing and other objects, advantages and features of the present invention will become more apparent upon reading of the following non-restrictive description of illustrative embodiments thereof, given by way of example only with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
p-0017In the appended drawings:
p-0018<figref idrefs="DRAWINGS">FIG. 1</figref> is a schematic diagram illustrating an “one-to-many” group session with voice transmission in a PoC architecture;
p-0019<figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a generic PoC architecture;
p-0020<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates a high-level architecture of the PoC application with transcoding in accordance with a first non-restrictive illustrative embodiment of the present invention;
p-0021<figref idrefs="DRAWINGS">FIG. 4</figref> illustrates a SDP session description contained within a SIP INVITE request when setting up a session;
p-0022<figref idrefs="DRAWINGS">FIGS. 5A and 5B</figref> are schematic diagrams illustrating the role of the CPF in the PoC application to ensure a proper communication session, where in <figref idrefs="DRAWINGS">FIG. 5A</figref> the CPF does not support transcoding and in <figref idrefs="DRAWINGS">FIG. 5B</figref> the CPF supports transcoding;
p-0023<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates a media flow of the transcoding scheme centralized at the CPF and where all the media packets arrive at the CPF before the TS (Transcoding Server) in the architecture of <figref idrefs="DRAWINGS">FIG. 3</figref>;
p-0024<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates a non-limitative example of media flow of the transcoding scheme centralized at the CPF and where all the media packets arrive at the TS before going to the CPF;
p-0025<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates a session control flow of the transcoding scheme centralized at the CPF of <figref idrefs="DRAWINGS">FIG. 7</figref>;
p-0026<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates a control flow for the case when a new participant has the permission to talk in the transcoding scheme centralized at the CPF of <figref idrefs="DRAWINGS">FIG. 7</figref>;
p-0027<figref idrefs="DRAWINGS">FIG. 10</figref> illustrates a signaling flow for the transcoding scheme centralized at the CPF of <figref idrefs="DRAWINGS">FIG. 7</figref>;
p-0028<figref idrefs="DRAWINGS">FIG. 11</figref> illustrates an IP address and port routing setup between the Transcoding Server (TS), the CPF and the users' terminals for the transcoding scheme centralized at the CPF of <figref idrefs="DRAWINGS">FIG. 7</figref>;
p-0029<figref idrefs="DRAWINGS">FIG. 12</figref> illustrates an architecture of the transcoding scheme performed at the invited users' PPFs in accordance with a second non-restrictive illustrative embodiment of the present invention;
p-0030<figref idrefs="DRAWINGS">FIG. 13</figref> illustrates an architecture of the transparent transcoding scheme centralized at the CPF in accordance with a third non-restrictive illustrative embodiment of the present invention;
p-0031<figref idrefs="DRAWINGS">FIG. 14</figref> illustrates a signaling flow of the transparent transcoding scheme centralized at the CPF of <figref idrefs="DRAWINGS">FIG. 13</figref>; and
p-0032<figref idrefs="DRAWINGS">FIG. 15</figref> illustrates an exemplary IP address and port routing setup between the TS, the CPF and the users' terminals of the transparent transcoding scheme centralized at the CPF of <figref idrefs="DRAWINGS">FIG. 13</figref>.
DETAILED DESCRIPTION
p-0033In the following description, reference is made to the accompanying drawings which form a part hereof, and in which are shown various non-restrictive illustrative embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized, and structural and operational changes may be made without departing from the scope of the present invention.
p-0034In the following description, the present invention will be described in the context of the Push to Talk Over Cellular (PoC). However the present invention is not restricted to the PoC application and may be applied in other multiparty multimedia architectures where only one participant has the permission to talk at any given time; this permission being managed by a central network element. The central network element may be any central element to the session including a Controlling PoC Function and a Multipoint Control Unit (MCU). The permission to talk may also be, in a more general context, any audiovisual media stream which is derived from one or many users and distributed to all users (e.g. a video mosaic made from the video streams of several users or a mixing of several audio streams). It is to be noted also that although reference is made to talk burst and permission to talk, talking refers generally to the permission to send media streams to other participants, whether the media streams are audio, video, text, graphics or of other type. Therefore the term ‘talk burst’ will be used although the term ‘media burst’ may be more appropriate. This usage does not limit the scope of the invention, which applies to all types and combinations of media. Finally, a user or party participating in the communication session, within the scope of the present invention, is not limited to a person participating to the multimedia session using a terminal or any other device but also includes any autonomous device participating to the conference such as a monitoring or recording device.
p-0035Generally, the illustrative embodiments of the present invention presents a system and method for enabling interoperability between terminals supporting different media characteristics (types, formats, codecs, or attributes) which otherwise would not be able to establish a multi-user multimedia session where only one user has the permission to send media streams (such as audio and video) at any given time. Although interoperability is the main concern, the proposed system may also perform transcoding for convenience. For instance, a user's terminal may support audio but the user may prefer the media to be converted into text if he/she is in a meeting, where the use of audio is not allowed. Such usages are considered within the scope of the present invention and included in the use of the term incompatibilities in this invention. The system and method enable interoperability by customizing session offerings to each user and modifying, as required, the media streams between users to comply with each participant's terminal capabilities and even preferences. The system and method addresses multiparty multimedia sessions and can be applied to the context of PoC multimedia sessions. The present specification describes several embodiment alternatives. The choice of the specific embodiment depends on the constraints associated with deploying a specific service. In some cases, performance may be of chief importance while in other cases, it may be transparent transcoding.
p-0036One of the possible applications of interest of the present invention is in a PoC service, as illustrated in <figref idrefs="DRAWINGS">FIG. 1</figref>. This service allows mobile users to create group sessions where participants can have voice and data communications on an one-to-one or one-to-many basis [1]. <figref idrefs="DRAWINGS">FIG. 1</figref> shows a PoC system <b>100</b> where a mobile terminal <b>102</b>, having the permission to talk, sends a media stream via the transmitting antenna <b>104</b>, the wireless network <b>106</b> and the receiving antennas <b>108</b> and <b>110</b> to terminals <b>112</b>, <b>114</b>, <b>116</b>, and <b>118</b>. A central element (not shown) in the wireless network <b>106</b> is responsible for the duplication and transport of the media streams to the destination terminals <b>112</b>, <b>114</b>, <b>116</b>, and <b>118</b>.
p-0037An example of a generic PoC architecture <b>200</b> is illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref>. The terminals <b>202</b> and <b>204</b> are connected to their local Participant PoC Function (PPF) <b>206</b>, located within their own local network <b>208</b>, which is connected to the Controlling PoC Function (CPF) <b>210</b>, located within a central network <b>212</b>. Furthermore, the terminal <b>214</b> is connected to its local PPF <b>216</b> within its local network <b>218</b>. The local PPF <b>216</b> is also connected to the CPF <b>210</b>. Therefore, the terminals <b>202</b> and <b>204</b> are interconnected to the terminal <b>214</b> via the central network <b>212</b>. The terminals <b>202</b>, <b>204</b> and <b>214</b> participate to a common communication session controlled by the CPF <b>210</b>. It should be noted that the architecture <b>200</b> can be also composed of a plurality of local networks such as <b>208</b> and <b>218</b>, comprising a plurality of PPFs such as <b>206</b> and <b>216</b>, connected to a plurality of terminals such as <b>202</b>, <b>204</b> and <b>214</b>.
1. Transcoding in a PoC Application
1.1 Elements to Consider for Enabling Transcoding in a PoC Application
p-0038In the PoC version 1.0 standard [1] [14] [15], the need for transcoding is recognized but no detailed solution is given. It is said in [1] that transcoding may be performed by both the Controlling PoC Function (CPF) and/or the Participating PoC Function (PPF). A transcoding architecture that supports various configurations and use cases is therefore required. The overall solution should involve several elements such as: <ul><li id="ul0001-0001" num="0038">1. System-level protocol flow, interaction between different entities such as clients or users, the transcoding server (TS), PoC servers, and modification of messages exchanged between the different entities.</li><li id="ul0001-0002" num="0039">2. Processing architecture of the Transcoding Server (the internal processing taking place in the TS).</li><li id="ul0001-0003" num="0040">3. Transcoding Interface (TI) between the Transcoding Server and the PoC Functions.</li></ul>
p-0039These elements are illustrated in <figref idrefs="DRAWINGS">FIG. 3</figref>. More specifically, <figref idrefs="DRAWINGS">FIG. 3</figref> illustrates a high-level architecture <b>300</b> of the PoC application, which is substantially similar to that of <figref idrefs="DRAWINGS">FIG. 2</figref>, but with transcoding capabilities. N local networks <b>302</b><sub>1 </sub>to <b>302</b><sub>N </sub>are interconnected to each other via a central network <b>304</b>. Each local network <b>302</b><sub>n</sub>, for 1≦n≦N, comprises a user's terminal <b>306</b><sub>n</sub>, connected to a PPF <b>308</b><sub>n</sub>. The central network <b>304</b> comprises a CPF <b>310</b> to which each PPF <b>308</b><sub>n </sub>is connected. The connection between the different entities can be of different types such as wireless, wireline, using cables, etc. Furthermore, to each local network <b>302</b><sub>n </sub>and to the central network <b>304</b>, a transcoding server <b>312</b><sub>n </sub>and <b>314</b> are connected respectively. More specifically, the transcoding server <b>312</b><sub>n </sub>is connected to the PPF <b>308</b><sub>n </sub>through a transcoding interface <b>316</b><sub>n</sub>. And the TS <b>314</b> is connected to the CPF <b>310</b> through the transcoding interface <b>318</b>. Such a configuration <b>300</b> allows the N users <b>306</b><sub>1 </sub>to <b>306</b><sub>N </sub>to participate in a common communication session, controlled by the central network element CPF <b>310</b> and where one user at the time can transmit media streams.
p-0040Moreover, <figref idrefs="DRAWINGS">FIG. 3</figref> also illustrates a session flow between the different entities, for setting up the session. Once the session is active, the media flow may, for example, travel directly through the TS <b>312</b><sub>n </sub>or pass by the CPF <b>310</b> and/or PPF <b>308</b><sub>n </sub>prior to arriving at the TS <b>312</b><sub>n</sub>. Note that a PoC server may include the Controlling PoC Function (CPF), the Participating PoC Function (PPF) or both, i.e. the CPF and PPF may constitute a single server, although they are logically separate function-wise.
1.2 The Session Description Protocol
p-0041A Session Description Protocol (SDP) <b>400</b>, as illustrated in <figref idrefs="DRAWINGS">FIG. 4</figref>, is a key element of SIP-based (Session Initiation Protocol) multimedia sessions and is defined in [13]. The SDP <b>400</b> comprises a plurality of fields which define a session's parameters. Each line corresponds to a field. The SDP <b>400</b> is contained within a SIP INVITE request [14], sent by a user when initiating a group session with the other users.
p-0042The following SDP parameters are especially of interest: <ul><li id="ul0002-0001" num="0045">The IP address where the media stream is to be received is described with the field ‘c=’ on line <b>422</b>, where, for example, an IPV6 address of 1000:900:800:700:600:efdf:2edf:3ece is illustrated.</li><li id="ul0002-0002" num="0046">The list of media characteristics is described with the field ‘m=’ on lines <b>424</b> and <b>432</b>, showing, as an example, two medias in this session: <ul><li id="ul0003-0001" num="0047">Audio over RTP (Real-Time Protocol) received at port 3456, with associated RTCP (Real-Time Control Protocol), is shown in line <b>424</b>. For audio media, two codecs are offered and are tagged <b>97</b> and <b>98</b>.</li><li id="ul0003-0002" num="0048">The talk burst control protocol (TBCP) received at port 2000 using UDP (User Datagram Protocol) is shown in line <b>432</b>.</li></ul></li><li id="ul0002-0003" num="0049">The details of these two medias are described in the field ‘a=’ on lines <b>426</b>, <b>428</b>, <b>430</b> and <b>434</b>: <ul><li id="ul0004-0001" num="0050">For audio media, the two tags <b>97</b> and <b>98</b> correspond to two distinct codecs, which are offered: the AMR codec or the EVRC codec at 8000 Hz as shown in lines <b>426</b> and <b>428</b>.</li><li id="ul0004-0002" num="0051">RTCP at port 5560 is provided in line <b>430</b>.</li><li id="ul0004-0003" num="0052">For TBCP, several options are provided in line <b>434</b>.</li></ul></li></ul>
2. The PoC Signaling Flow for the Transcoding Scheme Centralized at the Controlling PoC Function
p-0043The PoC specification describes several types of sessions which may contain several invitation methods, which are described in the PoC specification produced by the Open Mobile Alliance (OMA) and which are not described here for conciseness. A person of ordinary skill in the art will be able to apply the present invention in a straightforward manner to all the cases supported by PoC standard.
p-0044In the first non-restrictive illustrative embodiment of the present invention, the case where the transcoding scheme is centralized at the Controlling PoC Function, is considered.
2.1 Roles of the Controlling PoC Function in a Session Flow
p-0045In the first non-restrictive illustrative embodiment of the present invention as illustrated in <figref idrefs="DRAWINGS">FIG. 3</figref>, the whole transcoding process, in addition to the talk permissions, are managed by the CPF <b>310</b>. Regardless of the type of PoC group session established, the CPF <b>310</b> has two main responsibilities: <ul><li id="ul0005-0001" num="0056">1. Ensure Proper Session Offering and Setup Between the Users: <ul><li id="ul0006-0001" num="0057">As PoC users may have incompatible formats/codecs, the CPF <b>310</b> may have to change the SDP <b>400</b> (see <figref idrefs="DRAWINGS">FIG. 4</figref>) offering to the various users in order to include formats/codecs that they can use during the group session and for which a proper transcoding to other formats/codecs is possible. For instance, a user supporting only AMR would not be able to establish a direct session with a user supporting only EVRC. A CPF supporting AMR-EVRC transcoding would include both EVRC and AMR in the session offerings. This is illustrated in the system <b>500</b> of <figref idrefs="DRAWINGS">FIG. 5</figref>, which outlines the role of the CPF to ensure a proper session offering. In the example A) of <figref idrefs="DRAWINGS">FIG. 5</figref>, a terminal <b>504</b> supporting only the AMR audio codec invites, with a session description (not shown), a terminal <b>506</b> supporting only the EVRC audio codec, to a communication session through the CPF <b>502</b>, which does not alter the invitation's session description. An error “4xx Request Failure” is then generated by the terminal <b>506</b> since it can't support the offered AMR audio codec. In the example B), a terminal <b>508</b> supporting only the AMR audio codec invites, with a session description (not shown), a terminal <b>510</b> supporting only the EVRC audio codec to a communication session through the CPF <b>512</b>, which now alters the session description of the invitation to meet with the capabilities of the terminal <b>510</b>. Although the session description of the invitation, issued by the terminal <b>508</b>, contains only the AMR audio codec, since the CPF <b>512</b> expands the session description to include also the EVRC audio codec for the terminal <b>510</b>, the terminal <b>510</b> will accept the invitation by issuing a 200 OK response with the EVRC codec as the chosen codec. The CPF <b>512</b> will modify the invitation acceptation for the terminal <b>508</b> to include the AMR codec instead of the EVRC codec so that the session can take place between the terminals <b>508</b> and <b>510</b> and data can be exchanged between them.</li></ul></li><li id="ul0005-0002" num="0058">2. Manage the Flow of Media Streams Between Users: <ul><li id="ul0007-0001" num="0059">When transcoding is required, the media streams will have to flow through a Transcoding Server (TS) (not shown in <figref idrefs="DRAWINGS">FIG. 5</figref>), where they will be adapted/transcoded and then be sent to their destination. This requires that the flow of media streams be managed by the CPF <b>512</b>. Regarding the media flow, two types of traffics have to be managed by the CPF <b>512</b>: Talk Burst Control (TBC) and usual media. The first type relates to talk requests, such as requesting permissions to talk, and responses between the users and the CPF <b>512</b>. The second type relates to the usual media streams containing useful information and actual data to be transferred (e.g. AMR over RTP and RTCP). Each type of traffic is assigned to some specific port numbers. Therefore, the CPF <b>512</b> and the TS comprise respectively at least a port for the TBC traffic, such as the TBCP (Talk Burst Control Protocol) port.</li></ul></li></ul>
2.2 Roles of the Controlling PoC Function in the Media Flow
p-0046For the media flow, two options are possible. Therefore, two media flow schemes are considered and are illustrated in the architecture <b>600</b> of <figref idrefs="DRAWINGS">FIG. 6</figref> and the architecture <b>700</b> of <figref idrefs="DRAWINGS">FIG. 7</figref>. As a non-limitative example, both <figref idrefs="DRAWINGS">FIGS. 6 and 7</figref> are illustrating an architecture using AMR/EVRC transcoding.
p-0047The first media flow scheme is illustrated in the architecture <b>600</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>, when transcoding is centralized at the CPF <b>602</b> and where all the media packets arrive at the CPF <b>602</b> before the Transcoding Server (TS) <b>604</b>. A user from a terminal <b>606</b>, using an AMR codec, wants to communicate and exchange media streams with a user from a terminal <b>608</b>, which uses an EVRC codec. The terminal <b>606</b> sends AMR packets over the Real Time Protocol (RTP) in a media flow <b>610</b> to the CPF <b>602</b>. The CPF <b>602</b> sends those AMR packets over RTP in a media flow <b>612</b> to the TS <b>604</b> for adaptation and transcoding. The TS <b>604</b> returns the adapted EVRC packets over RTP in a media flow <b>614</b> back to the CPF <b>602</b>, which then forwards them in a media flow <b>616</b> to the terminal <b>608</b>. In another alternative, the TS <b>604</b> can directly send the adapted EVRC packets to the terminal <b>608</b>, without going through the CPF <b>602</b>.
p-0048While the CPF <b>602</b> forwards the usual media streams to the TS <b>604</b>, it processes itself the TBC packets arriving at its TBCP port, from the terminal <b>606</b> and returns the results back to the terminal <b>606</b>, in message flow <b>618</b>. Indeed, the media flow <b>618</b>, containing the TB requests and responses, is communicated between the terminal <b>606</b> and the CPF <b>602</b> only, without involving the TS <b>604</b> in the communication path.
p-0049The second media flow scheme is illustrated in the architecture <b>700</b> of <figref idrefs="DRAWINGS">FIG. 7</figref>, when transcoding is centralized at the CPF <b>702</b> and where all the media packets arrive at the TS <b>704</b> before (or instead of) the CPF <b>702</b>. A terminal <b>706</b> sends AMR packets over RTP in a media flow <b>708</b> to the TS <b>704</b>. The TS <b>704</b> transcodes the AMR packets into EVRC packets and sends the thus adapted EVRC packets over RTP in a flow <b>710</b> to the terminal <b>712</b>. A media flow <b>714</b> containing TB requests and responses is exchanged between the terminal <b>706</b> and the CPF <b>702</b> only via the TS <b>704</b>. More specially, the TS <b>704</b> forwards the incoming packets of the media flow <b>714</b> to the outgoing packets of the media flow <b>716</b>, to the CPF <b>702</b>. And the TS <b>704</b> forwards the incoming packets of the media flow <b>716</b>, from the CPF <b>702</b>, to the outgoing packets of the media flow <b>714</b>, to the terminal <b>706</b>. In the same manner, the terminal <b>712</b> and the CPF <b>702</b> may exchange TB requests and responses with each other only via the TS <b>704</b>.
p-0050Therefore, the TS <b>704</b> forwards the TBC packets arriving at its TBCP port to the CPF <b>702</b>, while it transcodes the usual media streams and sends them to their destination, such as to the terminal <b>712</b>. The CPF <b>702</b> manages the TBC messages arriving at its TBCP port and returns the responses to the TS <b>704</b>, which forwards them to their destination, or alternatively, the CPF <b>702</b> returns the responses directly to their destination.
p-0051The architecture <b>700</b> of <figref idrefs="DRAWINGS">FIG. 7</figref> is considered to be the preferred media flow scheme because it requires a lighter flow of packets between the TS <b>704</b> and the CPF <b>702</b>.
2.3 Session Control Managed by the Controlling PoC Function
p-0052In addition to the media flow described above, a session control flow must also be managed/provided. The session control flow is illustrated in <figref idrefs="DRAWINGS">FIG. 8</figref> and is managed by the CPF <b>802</b>, which also has to manage the session itself. The session may impact the media flow. Indeed, after a communication session is set up, when the session parameters change, such as to account for a joining or departing of a user, or when a different user has the permission to talk, the CPF <b>802</b> has to inform the TS <b>804</b> of the situation so that proper transcoding and routing of the media streams can be performed.
p-0053More specifically, the architecture <b>800</b> of <figref idrefs="DRAWINGS">FIG. 8</figref> illustrates a control flow taking place between the CPF <b>802</b>, the TS <b>804</b> and the terminals <b>806</b> and <b>808</b> when setting up a session. In the architecture <b>800</b>, interoperability between AMR and EVRC audio codecs is addressed as a non-limitative example. The setup of the session is as follows: <ul><li id="ul0008-0001" num="0068">1. A user of the terminal <b>806</b> invites another user to a session by sending an invitation, with a session description containing its supported audio visual formats/codecs (such as the AMR codec) in message <b>810</b>.</li><li id="ul0008-0002" num="0069">2. The CPF <b>802</b> receives the invitation, containing offered session media formats/codecs information and IP addresses and ports information, and requests the TS <b>804</b> in message <b>812</b> to set up a transcoding session and to provide a list of acceptable formats/codecs to offer to other users participating to the session.</li><li id="ul0008-0003" num="0070">3. The TS <b>804</b> sets up the transcoding resources and returns the IP addresses and ports information along with the formats/codecs information to the CPF <b>802</b> in message <b>814</b>. In this particular example, the EVRC codec is added to the list.</li><li id="ul0008-0004" num="0071">4. The CPF <b>802</b> forwards the invitation with the enhanced media formats/codecs and IP addresses and ports information to the invited terminal <b>808</b> in message <b>815</b>.</li><li id="ul0008-0005" num="0072">5. The terminal <b>808</b> accepts the invitation with its own supported codec (EVRC in the example) in message <b>816</b>, destined to the CPF <b>802</b>.</li><li id="ul0008-0006" num="0073">6. Upon receiving message <b>816</b>, the CPF <b>802</b> requests the TS <b>804</b>, in message <b>818</b>, to update the transcoding session according to the information provided by the invited terminal <b>808</b>, who has accepted the invitation; the information concerns the accepted formats/codecs and IP addresses and ports to be used for the terminal <b>808</b>.</li><li id="ul0008-0007" num="0074">7. The TS <b>804</b> performs the requested operations and provides updated session information, to the CPF <b>802</b>, including formats/codecs and IP addresses and ports information, in message <b>820</b>.</li><li id="ul0008-0008" num="0075">8. The CPF <b>802</b> then informs the terminal <b>806</b> that the invitation has been accepted with the formats/codecs to be used, and supported by the terminal <b>806</b>, in message <b>820</b>.</li><li id="ul0008-0009" num="0076">9. The terminal <b>806</b> then obtains the permission to talk using the existing PoC mechanisms.</li><li id="ul0008-0010" num="0077">10. The terminal <b>806</b> starts sending AMR packets to the TS <b>804</b>. Then in conformance with the architecture <b>700</b> of <figref idrefs="DRAWINGS">FIG. 7</figref>, the TS <b>804</b> transcodes the AMR packets to EVRC packets and forwards them to the terminal <b>808</b>. If the architecture <b>600</b> of <figref idrefs="DRAWINGS">FIG. 6</figref> were used instead, then the packets would first arrive at the CPF <b>802</b> prior to being transcoded in the TS <b>804</b>. More details are provided in the detailed signaling flow in <figref idrefs="DRAWINGS">FIG. 10</figref>, which will be described herein below.</li></ul>
p-0054Referring now to <figref idrefs="DRAWINGS">FIG. 9</figref>, the architecture <b>900</b> illustrates an example of the control flow taking place between the CPF <b>902</b>, the TS <b>904</b> and the users <b>906</b> and <b>908</b>, when a user, such as <b>906</b>, requests permission to talk. Generally it is assumed that initially no one has the permission to talk. The steps are as follows: <ul><li id="ul0009-0001" num="0079">1. The terminal <b>906</b> requests permission to talk by issuing a TB (Talk Burst) request message <b>910</b>. In this example, the media flow of <figref idrefs="DRAWINGS">FIG. 7</figref> is assumed, but one of ordinary skill in the art can derive easily appropriate message flows for the media flow according to <figref idrefs="DRAWINGS">FIG. 6</figref>.</li><li id="ul0009-0002" num="0080">2. The TB request message <b>910</b> arrives at the TS <b>904</b> and is forwarded to the CPF <b>902</b> in message <b>912</b>.</li><li id="ul0009-0003" num="0081">3. The CPF <b>902</b> informs the TS <b>904</b> that the user terminal <b>906</b> is asking permission to talk in message <b>914</b>, so that the TS <b>904</b> can allocate transcoding resources properly and accordingly, as well as enforce proper control over media streams.</li><li id="ul0009-0004" num="0082">4. After the TS <b>904</b> confirms with the CPF <b>902</b> that the request is granted in message <b>916</b>, the CPF <b>902</b> informs the user terminal <b>906</b> that his request to talk is granted by sending a TB Confirm message <b>918</b> to the TS <b>904</b>, which forwards it in message <b>920</b> to the user terminal <b>906</b>.</li><li id="ul0009-0005" num="0083">5. The user terminal <b>906</b> can then start sending AMR packets over RTP transport in media flow <b>922</b>.</li><li id="ul0009-0006" num="0084">6. The media flow <b>922</b> arrives at the TS <b>904</b>. The TS <b>904</b> transcodes the media information from AMR to EVRC formats and then sends the transcoded media to the user terminal <b>908</b> in media flow <b>924</b>.</li><li id="ul0009-0007" num="0085">7. Then, RTCP reports for media <b>924</b>, for example the number of packets received by the terminal <b>908</b>, are sent from the terminal <b>908</b> to the TS <b>904</b> in media flow <b>926</b>.</li><li id="ul0009-0008" num="0086">8. RTCP reports for media <b>922</b> are sent from the TS <b>904</b> to the user <b>906</b> in media flow <b>928</b>.</li></ul>
p-0055The use of the AMR and EVRC codecs are only illustrative of the operations to perform in the architecture <b>900</b>, which is not limited to them. The architecture <b>900</b> can support various formats/codecs and combinations of formats/codecs including combinations of audiovisual formats/codecs such as AMR, AVRC, H.263, MPEG-4 part 2, MPEG-4 part 10, etc. For instance, the architecture <b>900</b> may support transcoding of AMR/H.263 to and from EVRC/MPEG-4 part 2. Also, in the present application, the TB (Request/Confirm) messages flow between the TS <b>904</b> and the CPF <b>902</b>, for illustration purposes only. In other modifications and embodiments of the present invention, an IP switch can be used to route such messages directly to the CPF <b>902</b>, without having to go through the TS <b>904</b> for such operations.
2.4 Detailed Signaling Flow for Adaptation Centralized at the CPF
p-0056Now referring to <figref idrefs="DRAWINGS">FIG. 10</figref>, the detailed signaling flow of the transcoding scheme centralized at the CPF is described. Several group session cases and their variants can be considered. However, this would make the present specification quite tedious to read without providing additional benefit. Therefore, a representative use case, provided with the corresponding detailed signaling flow will be described. This signaling flow can be applied in a straightforward manner to all the other cases by those of ordinary skill in the art.
p-0057In the following, the case of “Confirmed indication using On-demand Session with Manual answer described in the PoC specifications” will be presented. The signaling details regarding the SIP/IP core will not be described since they are obvious and would only increase the complexity of the flow without any benefit. In addition, the case where all the media packets arrive at the TS is considered. However, it would be straightforward for one of ordinary skill in the art to consider the case where they all arrive at the CPF.
p-0058<figref idrefs="DRAWINGS">FIG. 10</figref> illustrates an exemplary embodiment <b>1000</b> of the detailed signaling flow between the CPF <b>1002</b>, the TS <b>1004</b>, the user terminals <b>1006</b> and <b>1008</b> with their respective PPFs <b>1010</b> and <b>1012</b>, for the case of the transcoding scheme centralized at the CPF and where all the media streams arrive at the TS. The steps are as follows: <ul><li id="ul0010-0001" num="0091">0. The PoC User <b>1006</b> presses the PoC Button of the corresponding PoC terminal to initiate a group session.</li><li id="ul0010-0002" num="0092">1. By doing so, the user <b>1006</b> issues a SIP INVITE method including a SDP information, noted SDP-A, in message <b>1014</b>. The SIP INVITE first arrives at the PPF <b>1010</b> in the network of the user <b>1006</b> (for example, his home PPF). For instance, the SDP-A could include, as a non-limitative example: <ul><li id="ul0011-0001" num="0093">c=lN IP6 FF1E:03AD::7F2E:172A:1E24</li><li id="ul0011-0002" num="0094">m=audio 3456 RTP/AVP 97</li><li id="ul0011-0003" num="0095">a=rtpmap: 97 AMR</li><li id="ul0011-0004" num="0096">a=rtcp:5560</li><li id="ul0011-0005" num="0097">m=application 2000 udp TBCP</li><li id="ul0011-0006" num="0098">a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1</li></ul></li><li id="ul0010-0003" num="0099">2. The SIP INVITE is then sent from the PPF <b>1010</b> to the CPF <b>1002</b> in message <b>1016</b>. The CPF <b>1002</b> can be on any network, such as the one of the user <b>1006</b>, of the user <b>1008</b> or a different one.</li><li id="ul0010-0004" num="0100">3. The CPF <b>1002</b> contacts the TS <b>1004</b> to set up transcoding resources for the session in message <b>1018</b>. The request includes the formats/codecs included in the SDP-A along with IP address and port information. The codec information is used to know the invitee's formats/codecs, such as the user <b>1008</b>, and to determine which additional formats/codecs could be added to the session offering to other users. The IP address and port information is used to determine where the trancoded results from other users need to be sent after transcoding in order to reach the inviting client, the user <b>1006</b> in this case. Since all the media packets arrive at the TS <b>1004</b>, the IP address and port information will also be used to determine where the Talk Burst (TB) responses, coming from the CPF <b>1002</b>, need to be sent in order to reach the user <b>1006</b>. Also, the IP address and port information of the CPF <b>1002</b> is needed in order for the inviting client (user <b>1006</b>) to forward the Talk Burst requests to. For instance, if the IP address of the CPF <b>1002</b> is IP6 FF1E:03AD::7F2E:172A:1E28, then the information using SDP is provided as follows (although the interface doesn't need to use SDP): <ul><li id="ul0012-0001" num="0101">c=IN IP6 FF1E:03AD::7F2E:172A:1E28</li><li id="ul0012-0002" num="0102">m=application 2002 udp TBCP</li></ul></li><li id="ul0010-0005" num="0000"> Furthermore, the Setup Transcoding operation normally calls two TS API (Application Program Interface) methods: i) SetupTranscodingSession(SDP-A, SDP-CPF) and ii) Addinvitee(Session ID). <ul><li id="ul0013-0001" num="0103">i) This first method initiates a new transcoding session. It creates a new Session ID context and memorizes the IP addresses and ports for reaching the user <b>1006</b> and the CPF <b>1002</b> for all its media. It also memorizes the media formats/codecs and protocols supported by the user <b>1006</b>, the inviting party. The method returns a session ID. The reservation process inside the TS <b>1004</b> for the user <b>1006</b> is shown in dotted lines <b>1110</b> in <figref idrefs="DRAWINGS">FIG. 11</figref>.</li><li id="ul0013-0002" num="0104">ii) The second method provides information to invite a new participant to the session ID. The method returns a user ID and IP address and ports where that user can send media streams and where the CPF <b>1002</b> can send the TB responses to this user through the TS <b>1004</b>. All the information is updated in the Session ID's context.</li></ul></li><li id="ul0010-0006" num="0105">4. Then, the TS <b>1004</b> will return the following information to the CPF <b>1002</b> in message <b>1020</b>: <ul><li id="ul0014-0001" num="0106">For the call to SetupTranscodingSession(SDP-A, SDP-CPF) in message <b>1018</b>, it will return a session ID for future references.</li><li id="ul0014-0002" num="0107">For the call to Addinvitee(Session ID), it will return (as shown in short dashed lines <b>1116</b> in <figref idrefs="DRAWINGS">FIG. 11</figref>): a user ID for future references (such as users having accepted the invitation or departing users), list of formats/codecs to provide in the session offering to the invitee <b>1008</b> (i.e. list of formats/codecs between which the TS <b>1004</b> can support transcoding with the ones offered by the user <b>1006</b>), list of addresses/input ports where the invited user <b>1008</b> can send his/her media for transcoding to other participants, list of addresses/input ports where the CPF <b>1002</b> can send Talk Burst responses to the TS <b>1004</b> for the invited user <b>1008</b>.</li><li id="ul0014-0003" num="0108">The TS <b>1004</b> can provide the information using SDP as follows (although the interface doesn't need to use SDP): i) for inviting other participants: <ul><li id="ul0015-0001" num="0109">c=IN IP6 FF1E:03AD::7F2E:172A:1E30</li><li id="ul0015-0002" num="0110">m=audio 53456 RTP/AVP 97 98</li><li id="ul0015-0003" num="0111">a=rtpmap: 97 AMR</li><li id="ul0015-0004" num="0112">a=rtpmap: 98 EVRC/8000</li><li id="ul0015-0005" num="0113">a=rtcp:53080</li><li id="ul0015-0006" num="0114">m=application 50000 udp TBCP</li><li id="ul0015-0007" num="0115">a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1</li></ul></li><li id="ul0014-0004" num="0116">and ii) for sending the TB responses from the CPF <b>1002</b>: <ul><li id="ul0016-0001" num="0117">c=IN IP6 FF1E:03AD::7F2E:172A:1E30</li><li id="ul0016-0002" num="0118">m=application 53458 udp TBCP</li></ul></li><li id="ul0014-0005" num="0119">It should be noted that each time that the CPF <b>1002</b> wants to invite a new user to the session, it will have to make a call to Addinvitee(Session ID). Also, if all the media streams were to enter the CPF <b>1002</b> before going to the TS <b>1004</b> (the other option), the IP address and ports in step 3 (with message <b>1018</b>), instead of corresponding to SDP-A would correspond to IP adresses and ports in the CPF <b>1002</b>. Also, since there would not be any flow of TBCP between the CPF <b>1002</b> and TS <b>1004</b>, the line ‘m=’ with media TBCP would not be present in the parameters. The TS <b>1004</b> would therefore know that it doesn't need to handle any Talk Burst Control Message (TBCM).</li></ul></li><li id="ul0010-0007" num="0120">5. The information response received from the TS <b>1004</b> is processed by the CPF <b>1002</b> and a modified invitation SDP-A′ is generated and then sent to the invitee <b>1008</b> through its PPF <b>1012</b> in message <b>1022</b>.</li><li id="ul0010-0008" num="0121">6. The PPF <b>1012</b> forwards the received invitation to the PoC user <b>1008</b> in message <b>1024</b>.</li><li id="ul0010-0009" num="0122">7. An Alerting message is sent from the user <b>1008</b> to its PPF <b>1012</b> in message <b>1026</b>. The alerting message notifies the inviting user <b>1006</b> that the invited user <b>1008</b> has received the invitation but has not accepted it yet.</li><li id="ul0010-0010" num="0123">8. The Alerting message is then sent from the PPF <b>1012</b> to the CPF <b>1002</b> in message <b>1028</b>.</li><li id="ul0010-0011" num="0124">9. The Alerting message is then sent from the CPF <b>1002</b> to the PPF <b>1010</b> of the user <b>1006</b> in message <b>1030</b>.</li><li id="ul0010-0012" num="0125">10. The Alerting message is finally received by the user <b>1006</b>, sent by the PPF <b>1010</b> in message <b>1032</b>.</li><li id="ul0010-0013" num="0126">11. The user <b>1008</b> accepts the invitation and provides the selected media information in a SDP-AB′ to its PPF <b>1012</b> in message <b>1034</b>. For instance, the SDP-AB′ could include: <ul><li id="ul0017-0001" num="0127">c=INIP6FF1E:03AD::7F2E:172A:1E34</li><li id="ul0017-0002" num="0128">m=audio 5458 RTP/AVP 98</li><li id="ul0017-0003" num="0129">a=rtpmap: 98 EVRC/8000</li><li id="ul0017-0004" num="0130">a=rtcp: 5480</li><li id="ul0017-0005" num="0131">m=application 4000 udp TBCP</li><li id="ul0017-0006" num="0132">a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1</li></ul></li><li id="ul0010-0014" num="0133">12. The message <b>1034</b> is forwarded by the PPF <b>1012</b> to the CPF <b>1002</b> in message <b>1036</b>.</li><li id="ul0010-0015" num="0134">13. The CPF <b>1002</b> then contacts the TS <b>1004</b> to update the transcoding session in message <b>1038</b>. The request actually involves the following two TS API methods: <ul><li id="ul0018-0001" num="0135">Join(Session ID, User ID, SDP-AB′, SDP-CPF) (shown in solid lines <b>1112</b> in <figref idrefs="DRAWINGS">FIG. 11</figref>): this method informs the TS <b>1004</b> that the user <b>1008</b> has accepted the invitation. It updates the Session ID context by memorizing the IP address and ports for reaching the user <b>1008</b> corresponding to User ID and the CPF <b>1002</b> for its entire media. It also memorizes the media formats/codecs and protocols supported by User ID, the joining party <b>1008</b>. For instance, the CPF <b>1002</b> would have to provide information about its IP addresses and ports to which TB requests from User ID can be sent: <ul><li id="ul0019-0001" num="0136">c=IN IP6 FF1E:03AD::7F2E:172A:1E28</li><li id="ul0019-0002" num="0137">m=application 2008 udp TBCP</li></ul></li><li id="ul0018-0002" num="0138">The reservation process inside the TS <b>1004</b> for the user <b>1008</b> is shown in solid lines <b>1112</b> in <figref idrefs="DRAWINGS">FIG. 11</figref>.</li><li id="ul0018-0003" num="0139">AcceptInvite(Session ID, SDP-AB′, SDP-CPF): this method informs the TS <b>1004</b> that the invitation from the user <b>1006</b> has been accepted by at least one person. It updates the Session ID context by memorizing what formats/codecs the user <b>1006</b> is expected to use for each input port. The method returns IP addresses and ports where the user <b>1006</b> can send media streams along where the CPF <b>1002</b> can send the TB responses to the user <b>1006</b> through the TS <b>1004</b>. The reservation process inside the TS <b>1004</b> for the user <b>1006</b> is shown in long dashed lines <b>1114</b> in <figref idrefs="DRAWINGS">FIG. 11</figref>.</li></ul></li><li id="ul0010-0016" num="0140">14. The TS <b>1004</b> then returns the following information to the CPF <b>1002</b> in message <b>1040</b>: <ul><li id="ul0020-0001" num="0141">The status of the request of the call to Join(Session ID, User ID, SDP-AB′, SDP-CPF) performed in message <b>1038</b>. The status would normally report the success of adding the new user to the session or the reasons why he could not be added.</li><li id="ul0020-0002" num="0142">the returned parameters of the call to AcceptInvite(Session ID, SDP-AB′, SDP-CPF) performed in message <b>1038</b> comprising: list of addresses/input ports where the user <b>1006</b> can send his/her media streams for transcoding to other participants' formats, the formats/codecs to be used, list of addresses/input ports where the CPF <b>1002</b> can send Talk Burst responses to the TS <b>1004</b> for the user <b>1006</b>. The TS <b>1004</b> could provide the information using SDP as follows, shown in long dashed lines <b>1114</b> in <figref idrefs="DRAWINGS">FIG. 11</figref>, (although the interface doesn't need to use SDP): i) for transmitting data during the session to the user <b>1006</b>: <ul><li id="ul0021-0001" num="0143">c=IN IP6 FF1E:03AD::7F2E:172A:1E3</li><li id="ul0021-0002" num="0144">m=audio 48456 RTP/AVP 97</li><li id="ul0021-0003" num="0145">a=rtpmap: 97 AMR</li><li id="ul0021-0004" num="0146">a=rtcp: 48080</li><li id="ul0021-0005" num="0147">m=application 48000 udp TBCP</li><li id="ul0021-0006" num="0148">a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1</li></ul></li><li id="ul0020-0003" num="0149">ii) for sending the TB responses coming from the CPF <b>1002</b>: <ul><li id="ul0022-0001" num="0150">c=IN IP6 FF1E:03AD::7F2E:172A:1E30</li><li id="ul0022-0002" num="0151">m=application 48400 udp TBCP</li></ul></li></ul></li><li id="ul0010-0017" num="0152">15. The information response from the TS <b>1004</b> is processed by the CPF <b>1002</b>, which then sends a modified invitation SDP-AB* for the inviting party <b>1006</b> through its PPF <b>1010</b> in message <b>1042</b>. It basically includes the media formats/codecs to be used and the IP addresses and ports where to send the media streams.</li><li id="ul0010-0018" num="0153">16. The PPF <b>1010</b> forwards the invitation to the PoC user <b>1006</b> in message <b>1044</b>.</li><li id="ul0010-0019" num="0154">17. The CPF <b>1002</b> informs the TS <b>1004</b> that the user <b>1006</b> has the permission to talk in message <b>1046</b>. This can be done using the following API method: TalkBurstInform(Session ID, User ID). The information is updated in the Session ID's context.</li><li id="ul0010-0020" num="0155">18. The TS <b>1004</b> acknowledges the permission by sending message <b>1048</b> to the CPF <b>1002</b>.</li><li id="ul0010-0021" num="0156">19. The CPF <b>1002</b> sends a Talk Burst Confirm destined to the user <b>1006</b> through its PPF <b>1010</b> in message <b>1050</b>.</li><li id="ul0010-0022" num="0157">20. The PPF <b>1010</b> sends the Talk Burst Confirm to the user <b>1006</b> in message <b>1052</b>.</li><li id="ul0010-0023" num="0158">21. The user <b>1006</b> is granted the right to talk in notification <b>1054</b>.</li><li id="ul0010-0024" num="0159">22. The CPF <b>1002</b> sends a Receiving Talk Burst message to the user <b>1008</b> through its PPF <b>1012</b> in message <b>1056</b>.</li><li id="ul0010-0025" num="0160">23. The PPF <b>1012</b> forwards the Receiving Talk Burst message in message <b>1060</b> to the user <b>1008</b>.</li><li id="ul0010-0026" num="0161">24. The user <b>1008</b> is notified that the user <b>1006</b> was granted the right to talk in notification <b>1062</b>.</li><li id="ul0010-0027" num="0162">25. Media streams travel from the user <b>1006</b> to the TS <b>1004</b> in media flow <b>1064</b>. In the present illustrative embodiment, AMR packets are sent. It would be straightforward to show the case where the media streams travel through the CPF <b>1002</b> instead of the TS <b>1004</b>. All it would take from the session initiation process (SIP) would be to provide different addresses and ports to the users, which would point to the CPF <b>1002</b> instead of the TS <b>1004</b>, and IP addresses and ports of the CPF <b>1002</b> as output destinations to the TS <b>1004</b>.</li><li id="ul0010-0028" num="0163">26. Then, the TS <b>1004</b> knows that the user <b>1006</b> has the right to talk and transcodes media streams from AMR to EVRC in operation <b>1066</b>.</li><li id="ul0010-0029" num="0164">27. Then, the TS <b>1004</b> sends EVRC transcoded packets to the user <b>1008</b> in media flow <b>1068</b>.</li><li id="ul0010-0030" num="0165">28. The user <b>1006</b> releases the PoC button.</li><li id="ul0010-0031" num="0166">29 to 41. The remaining steps are usual PoC operations and do not require further explanations, which concern transcoding the last packet sent by the user terminal <b>1006</b> and the end of the media stream transmission, indicated by a Talk Burst Idle Notification, after the user <b>1006</b> releases the PoC button.</li></ul>
p-0059However, subsequent re-pressing of the PoC button by one of the users <b>1006</b> and <b>1008</b> will be processed as described in the foregoing description, for example through operations <b>1046</b> (with Talk Burst Inform from the user who desires to transmit media streams) to <b>1076</b> of <figref idrefs="DRAWINGS">FIG. 10</figref> (for transmitting and transcoding media streams), in order to allow the said one user to transfer media streams to the other participant(s). Operations <b>1070</b> to <b>1094</b> describe what happens in the signaling flow when the said one user releases the PoC button.
p-0060The media flow architecture <b>1100</b> of <figref idrefs="DRAWINGS">FIG. 11</figref> illustrates an exemplary embodiment of the routing of media flows through the CPF <b>1102</b> and the TS <b>1104</b> for the case of the transcoding scheme centralized at the CPF <b>1102</b>. The input IP addresses and ports at the TS <b>1104</b> for media issued from the inviting terminal <b>1106</b>, in addition to TBCP messages from the CPF <b>1102</b> to the terminal <b>1106</b>, are illustrated in long dashed lines <b>1114</b>. The input IP addresses and ports from the terminal <b>1106</b> are mapped to various types of media flows, such as codec, RTCP and TBCP, as illustrated in media flow <b>1114</b>. Similarly, the input IP addresses and ports at the TS <b>1104</b> for media issued from the invited terminal <b>1108</b>, in addition to TBCP messages from the CPF <b>1102</b> to the terminal <b>1108</b>, are illustrated in short dashed lines <b>1116</b>. The input IP addresses and ports from the terminal <b>1108</b> are mapped to various types of media flows, such as codec, RTCP and TBCP, as illustrated in media flow <b>1116</b>. The destination IP addresses and ports at the TS <b>1104</b> for media to be sent to the inviting terminal <b>1106</b>, in addition to TBCP messages to the CPF <b>1102</b> from the terminal <b>1106</b>, are illustrated in dotted lines <b>1110</b>. The input IP addresses and ports at the terminal <b>1106</b> are mapped to various types of media flows, such as codec, RTCP and TBCP, as illustrated in media flow <b>1110</b>.
p-0061The destination IP addresses and ports at the TS <b>1104</b> for media to be sent to the invited terminal <b>1108</b>, in addition to the IP addresses and ports for the TBCP messages destined to the CPF <b>1102</b> from the terminal <b>1108</b>, are illustrated in solid lines <b>1112</b> in <figref idrefs="DRAWINGS">FIG. 11</figref>. The input IP addresses and ports at the terminal <b>1108</b> are mapped to various types of media flows, such as codec, RTCP and TBCP, as illustrated in media flow <b>1112</b>. It should be observed that the TS <b>1104</b> has an IP address, in the example, which ends with “1E30” and is used for all incoming media flows shown in <b>1114</b> and <b>1116</b>, although a different port is used for every distinct flow. For outgoing flows, an IP address ending with “1E24” is destined to the terminal <b>1106</b>, an IP address ending with “1E28” is destined to the CPF <b>1102</b> and an IP address ending with “1E34” is destined to the terminal <b>1108</b>.
p-0062Some further explanations and variations to the described illustrative embodiment require attention: <ul><li id="ul0023-0001" num="0000"><ul><li id="ul0024-0001" num="0171">Case of multiple participants: in this case, for each participant to be invited, the CPF <b>1102</b> would have to make a call to AddInvitee(Session ID) prior to sending the SDP INVITE and a call to Join(Session ID, User ID, SDP-AB′, SDP-CPF) once the user has accepted. When participants leave the session, the CPF <b>1102</b> has to make a call to Leave(Session ID, User ID) which updates the Session ID, taking into account the user ID that is leaving the session.</li><li id="ul0024-0002" num="0172">Case where all the media packets arrive at the CPF <b>1102</b>: this alternative case was discussed hereinabove in reference to <figref idrefs="DRAWINGS">FIG. 10</figref>. All it would take from the session initiation process would be to provide different addresses and ports to the users, which point to the CPF <b>1002</b> instead of the TS <b>1004</b>, and to provide the CPF <b>1002</b> IP addresses and ports as output destinations to the TS <b>1004</b>. Also, when providing media information to the TS <b>1004</b>, no TBCP media would be part of the session description since it would be fully managed by the CPF <b>1002</b>. It should be noted that this is the ‘safe’ case to assume in PoC applications, as it is said in [1] section 9.12, where all the media flows must pass through the CPF <b>1002</b> (because of packet replication). However, the other case (where all the media streams arrive at the TS) is far more efficient and scalable as it delegates media handling to the TS <b>1004</b>. In a way, the TS <b>1004</b> can be considered as being an extension of the CPF <b>1002</b>.</li></ul></li></ul>
p-0063Note that many variations can be made to the above described illustrative embodiment without departing from the nature and scope of the present invention. For instance, in a variation, the TBCP messages may not flow through the TS <b>1004</b>. The TS behavior can be classified as being tightly controlled or loosely controlled. When tightly controlled, the TS <b>1004</b> either monitors TBCP messages to determine who has permission to talk or receives specific control messages from the CPF <b>1002</b>. When loosely controlled, the TS <b>1004</b> knows who talks by monitoring media streams activity. The specific methods and APIs between the CPF <b>1002</b> and the TS <b>1004</b> may also be modified without departing from the scope of this invention. Furthermore, the media elements such as PPF <b>1006</b>, CPF <b>1002</b>, and TS <b>1004</b> are represented as distinct logical elements but in practice one or many of them may be combined together into a single server without departing from the scope of this invention.
3. The PoC Signaling Flow Where the Transcoding Scheme is at the Invited Participating PoC Function
p-0064This sub-section presents a second non-restrictive illustrative embodiment of the present invention, where transcoding is performed at the PPF of the invited parties.
3
.
1
Roles of the Participating and Controlling PoC Functions
p-0065In the case where transcoding is performed at the invited PPF, the whole transcoding process is managed by the PPF, while the talk permissions and routing of media streams, including making copies of media packets, to each destination is still managed by the CPF. Regardless of the type of group session established, the PPF has two main responsibilities, which are essentially the same as those described in 2.1. First, the PPF ensures proper session offering and setup between the users. Secondly, the PPF manages the flow of media streams between the user and the CPF. It should be noted that although all the media streams must travel through the CPF, they do not have to travel through all the PPFs. However, the session control messages must pass through all the PPFs and the CPF.
p-0066The CPF's role is to: i) control who has permission to talk and ii) duplicate and route media packets of the talking user to the other users.
p-0067The main differences between the present case and the case where the transcoding scheme is centralized at the CPF are: <ul><li id="ul0025-0001" num="0000"><ul><li id="ul0026-0001" num="0178">i) the PPF will control transcoding between the user and the CPF (so there is one user at the input and one at the output) while, in the previous case, the CPF had to control the transcoding to all destinations (many users). This is because the PPF is not allowed to duplicate packets to various destinations; the duplication can only be performed by the CPF.</li><li id="ul0026-0002" num="0179">ii) the PPF doesn't have to control who talks; the CPF still does it. Therefore the PPF control over the transcoding server can be done in 2 ways: a) loosely controlled—the transcoding server is always active and is always ready to perform transcoding once the session is set up, but some channels may be idle; b) tightly controlled—the PPF would listen to TBCM and inform the transcoding server to start or stop transcoding, alternatively, the PPF may analyze the TBCM and determine who has permission to talk.</li></ul></li></ul>
p-0068In this second non-restrictive illustrative embodiment of the invention, the adaptation or transcoding is performed at the PPFs of the invited participants. The inviting terminal sends an invitation to other parties, containing its media session description. Each invited participant's PPF will perform the same operations as the CPF was doing in <figref idrefs="DRAWINGS">FIG. 8</figref>. This will lead to a situation where the inviting party's PPF doesn't have to perform transcoding but it is the responsibility of the PPF of the other parties participating in the session (e.g. the invited users). Therefore, media in formats supported by the inviting party will flow within the CPF. The computing resources required for transcoding in the system can be reduced if many invited parties participating to the session support the inviting party's media formats.
p-0069<figref idrefs="DRAWINGS">FIG. 12</figref> illustrates an exemplary architecture <b>1200</b> for transcoding at the invited parties' PPF. In the case A), transcoding is made at the receiving PPF. The inviting terminal <b>1202</b>, who has permission to talk, sends media streams in its supported format (AMR in this particular example). Such streams, in the format supported by the inviting terminal <b>1202</b> and agreed upon session establishment, flow within the CPF <b>1204</b>. The invited parties' PPFs <b>1214</b> and <b>1216</b> receive the media streams in the format supported by the terminal <b>1202</b> and then transcode them as required to meet capabilities of the invited terminals <b>1212</b> and <b>1210</b>. In this example, the PPF <b>1214</b> forms a TS that transcodes the received media streams from AMR to EVRC for the user <b>1212</b> while the PPF <b>1216</b> doesn't have to perform any transcoding for the user <b>1210</b>, since the terminal of the user <b>1210</b> already supports AMR.
p-0070It should be noted that in this example, the elements <b>1202</b>, <b>1212</b> and <b>1214</b>, each forms a combination of a PPF and TS incorporated into a single server.
p-0071As also illustrated in <figref idrefs="DRAWINGS">FIG. 12</figref>, the case B) corresponds to the case where transcoding happens at the sending and receiving PPFs. The user <b>1224</b> initiates a group session and invites the users <b>1232</b> and <b>1220</b> to participate in. The invited user <b>1220</b> has the permission to talk. The PPF <b>1222</b> transcodes the media flow from the format supported by the user <b>1120</b> to those supported by the inviting terminal <b>1224</b> and agreed upon during session establishment. For instance, the PPF <b>1222</b> transcodes from EVRC to AMR since AMR is the format supported by the inviting terminal <b>1224</b> and agreed upon during the session establishment and thus flowing within the CPF <b>1226</b>. The PPF <b>1228</b> of the inviting terminal <b>1224</b> performs no transcoding. The PPF <b>1230</b> normally performs transcoding for the invited terminal <b>1232</b>. However, since the media flow provided by the CPF <b>1226</b> is in the format supported by the invited terminal <b>1232</b>, then the PPF <b>1230</b> establishes that no transcoding needs to be performed. In fact, since the terminal <b>1232</b> supports the same format/codec agreed upon during session establishment for the terminal <b>1224</b> and flowing within the CPF <b>1226</b>, then no transcoding at the terminal <b>1232</b> is needed to and from the terminal <b>1232</b>, regardless of who is talking. For instance, in this example, AMR will always flow within the CPF <b>1226</b> and since AMR is also supported by the terminal <b>1232</b>, then the PPF <b>1230</b> will have to perform no transcoding. Again, the elements <b>1222</b>, <b>1228</b> and <b>1230</b>, each forms a combination of a PPF and TS incorporated into a single server.
p-0072In the remaining description, the formats supported by the inviting terminal and agreed upon session establishment (thus flowing within the CPF) will be called “common stream format” (CSF).
3.2 Media Flow and Types of Traffics Managed by the Participating PoC Function
p-0073For media flows, similarly to the case where the transcoding scheme is centralized at the CPF, two schemes can be considered, as illustrated in <figref idrefs="DRAWINGS">FIGS. 6 and 7</figref>, with the following modification however: instead of a CPF <b>602</b> or <b>702</b>, a PPF is interacting with the TS <b>604</b> or <b>704</b>. The main difference, besides the fact that the TS interacts with the PPF instead of the CPF, is that TB requests arriving at the PPF or TS would be forwarded to the CPF and TB responses would come from the CPF before arriving at the PPF or TS.
3.3 Session Control Managed by the Participating PoC Function
p-0074The PPF has very little session management responsibilities. For instance, unlike the CPF, a local PPF does not have to care if new users join or leave the session, as long as the session is still in progress and the user it serves is still participating, since it only manages the transcoding from and to the CSF for a given user. Also it doesn't have to manage who has permission to talk; in the worst case it only monitors it.
p-0075Therefore the session flow of <figref idrefs="DRAWINGS">FIG. 8</figref> and the control flow of <figref idrefs="DRAWINGS">FIG. 9</figref> would still apply for this case, except that the TBCM are also routed to/from the CPF and that the TS would be replaced by an invited party's PPF.
3.4 Detailed Signaling Flow for Adaptation Centralized at the PPF
p-0076The detailed signaling flow for the case of transcoding performed at the PPF would be very similar to the case where transcoding is centralized at the CPF. <figref idrefs="DRAWINGS">FIG. 10</figref> would remain the same, except that the interaction with the transcoding server would be handled at each invited party's PPF. The rule is that the PPF of each invited terminal has to perform transcoding from/to that terminal's supported media format to/from the CSF. This also requires session description changes by the invited party's PPF in order to allow session establishment. This is done in the same way as the CPF <b>1002</b> in <figref idrefs="DRAWINGS">FIG. 10</figref> was doing. The function calls to the TS <b>1004</b> would also be similar.
4. Transparent PoC Transcoding
p-0077This section describes a third non-restrictive illustrative embodiment of the present invention, where transcoding is transparent PoC transcoding. Transparent transcoding means that the PoC terminals and servers are not aware that transcoding is taking place and behave as any conventional PoC entity would do in a context where no transcoding is performed. The Transcoding Server is inserted as a proxy in the communication path. The main advantage of this approach is that it does not require any modification to existing PoC terminals and servers. Indeed, an operator who has already deployed a PoC system can add PoC transcoding without any change to the already deployed PoC terminals and servers. This approach has been proven effective to smoothly introduce transcoding in the Multimedia Messaging Service.
4.1 Transparent PoC Transcoding Centralized at the CPF
p-0078In this embodiment, the Transcoding Server (TS) is placed in a central location of the network, so it is co-located with the CPF and can therefore take advantage of being placed in this unique manner with respect to the CPF. The TS is placed after the CPF in the media path but prior to it in the session control path. Furthermore, all the media packets (usual media and TBCP) travel through the CPF, which is located before the TS in the media stream flow.
p-0079The architecture <b>1300</b> of <figref idrefs="DRAWINGS">FIG. 13</figref> illustrates an exemplary architecture for transparent transcoding at the CPF <b>1302</b>. The CPF <b>1302</b>, being in the media path, will make copies of the usual incoming media stream(s) and attempt to distribute it (them) to the other users in the session. Each of those output streams will enter the TS <b>1304</b> and will individually be transcoded as needed to meet the destination terminal capabilities and be distributed to each destination terminal <b>1306</b> and <b>1308</b> afterwards. TBCP packets will also enter the TS <b>1304</b>, which will forward them to their destinations. The TS <b>1304</b> can learn who has permission to talk by either monitoring the content of TCBP packets sent from the CPF <b>1302</b>, or by identifying the incoming usual media streams, which are inactive (since the talking user is the one for which there is no media streams delivered by the CPF <b>1302</b>). Based on that, the TS <b>1304</b> will decide on the transcoding operations to perform for each destination. For instance, if the talking person uses the AMR codec, then AMR to EVRC needs to be performed for a user supporting the EVRC codec; but no transcoding is needed if the talking person uses the EVRC codec, instead of the AMR one.
p-0080Furthermore, in <figref idrefs="DRAWINGS">FIG. 13</figref>, the CPF <b>1302</b> makes copies, for all destination users, of the AMR streams obtained from the user <b>1310</b>. The TS <b>1304</b> intercepts those media streams and transcodes them to suit the capabilities of the destination users <b>1306</b> and <b>1308</b> and sends the transcoded media streams to their destination. Thus, AMR media destined to the terminal <b>1306</b> entering the TS <b>1304</b> becomes EVRC media for the terminal <b>1306</b> at the output of the TS <b>1304</b>, while AMR media destined to the terminal <b>1308</b> at the input of the TS <b>1304</b> remains AMR media for the terminal <b>1308</b> at the output of the TS <b>1304</b>. The TS <b>1304</b> also forwards the unchanged TBCP messages to each destination user <b>1306</b> and <b>1308</b>.
p-0081For the media streams to travel through the CPF <b>1302</b> and then through the TS <b>1304</b>, certain SDP modifications have to be made, during the session establishment process. The CPF <b>1302</b> will be given IP address and port information of the TS <b>1304</b>, regarding where to send information. The users will be given IP address and port information of the CPF <b>1302</b>, regarding where to send information. The TS <b>1304</b> manages the connection between those sets of IP addresses and ports and where the different entities expect to receive their data.
p-0082<figref idrefs="DRAWINGS">FIG. 14</figref> illustrates an exemplary embodiment of the detailed signaling flow between the CPF <b>1402</b>, the TS <b>1404</b> and the terminals <b>1405</b> and <b>1406</b>, for the case of transparent transcoding centralized at the CPF <b>1402</b>. The PPFs of the terminals <b>1405</b> and <b>1406</b> are not illustrated in order to simplify the description without however any loss of generality. In the following, the session offering changes, such as offered formats/codecs, from the CPF <b>1402</b> to the TS <b>1404</b>, in rerouting of the media stream procedure, are described. The signaling flow is as follows: <ul><li id="ul0027-0001" num="0000"><ul><li id="ul0028-0001" num="0195">1. The PoC User <b>1405</b> presses the PoC Button to initiate a group session in operation <b>1410</b>.</li><li id="ul0028-0002" num="0196">2. The PoC user <b>1405</b> issues a SIP INVITE method, including a session description with a SDP information in message <b>1412</b>. The SIP INVITE is intercepted by the TS <b>1404</b>, which can be, for example, located in the same network as the CPF <b>1402</b>. For instance, the SDP-A could include: <ul><li id="ul0029-0001" num="0197">c=INP6 FF1E03AD::7F2E:172A:1E24</li><li id="ul0029-0002" num="0198">m=audio 3456 RTP/AVP 97</li><li id="ul0029-0003" num="0199">a=rtpmap: 97 AMR</li><li id="ul0029-0004" num="0200">a=rtcp:5560</li><li id="ul0029-0005" num="0201">m=application 2000 udp TBCP</li><li id="ul0029-0006" num="0202">a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1</li></ul></li><li id="ul0028-0003" num="0203">3. The TS <b>1404</b> changes the formats/codecs and the IP address and port information provided by the user <b>1405</b> so that any media stream destined to the user <b>1405</b> will arrive first at the TS <b>1404</b>, before being delivered to the user <b>1405</b> (see the dotted lines in <figref idrefs="DRAWINGS">FIG. 15</figref>). It also stores binding information between the new offered SDP and the SDP initially offered by the user <b>1405</b>. In addition, the TS <b>1404</b> enhances the session description by adding media formats/codecs, for which it can support transcoding from and to the ones offered by the user <b>1405</b>. Then, the TS <b>1404</b> sends the invitation with the updated SDP session description to the CPF <b>1402</b> in message <b>1414</b>. For instance, the SDP provided by the TS <b>1404</b> could be: <ul><li id="ul0030-0001" num="0204">c=IN IP6 FF1E:03AD::7F2E:172A:1E30</li><li id="ul0030-0002" num="0205">m=audio 18456 RTP/AVP 97 98</li><li id="ul0030-0003" num="0206">a=rtpmap: 97 AMR</li><li id="ul0030-0004" num="0207">a=rtpmap: 98 EVRC/8000</li><li id="ul0030-0005" num="0208">a=rtcp:18080</li><li id="ul0030-0006" num="0209">m=application 18000 udp TBCP</li><li id="ul0030-0007" num="0210">a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1</li></ul></li><li id="ul0028-0004" num="0000"> One should note the substitution of IP addresses from the user <b>1405</b> to the TS <b>1404</b> in line “c=” and the addition of EVRC codec in line “a=”.</li><li id="ul0028-0005" num="0211">4. The CPF <b>1402</b> receives the SDP session description, modifies it so that media streams first pass through it. It then sends the modified invitation to the user <b>1406</b> in message <b>1416</b>. The CPF <b>1402</b> also knows the mapping of IP addresses and ports so it can forward incoming packets to the right destination. For instance, it could be as illustrated in <figref idrefs="DRAWINGS">FIG. 15</figref> (see short dashed lines): <ul><li id="ul0031-0001" num="0212">c=IN IP6 FF1E:03AD::7F2E:172A:1E28</li><li id="ul0031-0002" num="0213">m=audio 53456 RTP/AVP 97 98</li><li id="ul0031-0003" num="0214">a=rtpmap: 97 AMR</li><li id="ul0031-0004" num="0215">a=rtpmap: 98 EVRC/8000</li><li id="ul0031-0005" num="0216">a=rtcp:53080</li><li id="ul0031-0006" num="0217">m=application 50000 udp TBCP</li><li id="ul0031-0007" num="0218">a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1</li></ul></li><li id="ul0028-0006" num="0219">5. An Alerting message <b>1418</b> is sent from the user <b>1406</b> to the TS <b>1404</b>.</li><li id="ul0028-0007" num="0220">6. The Alerting message <b>1420</b> is sent from the TS <b>1404</b> to the CPF <b>1402</b>.</li><li id="ul0028-0008" num="0221">7. The Alerting message <b>1422</b> is sent from the CPF <b>1402</b> to the user <b>1405</b>.</li><li id="ul0028-0009" num="0222">8. The user <b>1406</b> accepts the invitation and provides the selected media information in SDP-AB′ in message <b>1424</b>. The request is intercepted by the TS <b>1404</b>. For instance, the SDP-AB′ could include: <ul><li id="ul0032-0001" num="0223">c=IN IP6 FF1E:03AD::7F2E:172A:1E34</li><li id="ul0032-0002" num="0224">m=audio 5458 RTP/AVP 98</li><li id="ul0032-0003" num="0225">a=rtpmap: 98 EVRC/8000</li><li id="ul0032-0004" num="0226">a=rtcp: 5480</li><li id="ul0032-0005" num="0227">m=application 4000 udp TBCP</li><li id="ul0032-0006" num="0228">a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1</li></ul></li><li id="ul0028-0010" num="0229">9. The TS <b>1404</b> reserves transcoding resources and ports and provides a modified SDP session to the CPF <b>1402</b> in message <b>1426</b>. For instance the SDP could be: <ul><li id="ul0033-0001" num="0230">c=IN IP6 FF1E:03AD::7F2E:172A:1E30</li><li id="ul0033-0002" num="0231">m=audio 28456 RTP/AVP 97</li><li id="ul0033-0003" num="0232">a=rtpmap: 97 AMR</li><li id="ul0033-0004" num="0233">a=rtcp: 28080</li><li id="ul0033-0005" num="0234">m=application 28000 udp TBCP</li><li id="ul0033-0006" num="0235">a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1</li></ul></li><li id="ul0028-0011" num="0236">10. The information response is further modified by the CPF <b>1402</b> to include itself first in the media path. The CPF <b>1402</b> then sends the modified response to the user <b>1405</b> in message <b>1428</b>. For instance, the SDP could be: <ul><li id="ul0034-0001" num="0237">c=INIP6 FF1E:03AD::7F2E:172A:1E28</li><li id="ul0034-0002" num="0238">m=audio 48456</li><li id="ul0034-0003" num="0239">a=rtpmap: 98 EVRC/8000</li><li id="ul0034-0004" num="0240">a=rtcp:48080</li><li id="ul0034-0005" num="0241">m=application 48000 udp TBCP</li><li id="ul0034-0006" num="0242">a=fmtp:TCBP queuing=1; tb_priority=2; timestamp=1</li></ul></li><li id="ul0028-0012" num="0243">11. The “Talk Burst Confirm” message for the user <b>1405</b> is initiated by the CPF <b>1402</b> in message <b>1430</b> and arrives at the TS <b>1404</b> (since it is next after the CPF <b>1402</b> in the media path).</li><li id="ul0028-0013" num="0244">12. The “Task Burst Confirm” message is sent to the user <b>1405</b> from the TS <b>1404</b> in message <b>1432</b>.</li><li id="ul0028-0014" num="0245">13. The “Talk proceed” notification is sent to the user <b>1405</b> in notification <b>1434</b>.</li><li id="ul0028-0015" num="0246">14. Receiving the “Talk burst” from the user <b>1408</b> in message <b>1436</b>, to the user <b>1406</b> is initiated from the CPF <b>1402</b> and arrives at the TS <b>1404</b>, since it is next after the CPF <b>1402</b> in the media path.</li><li id="ul0028-0016" num="0247">15. Receiving the “Talk burst” from the user <b>1405</b> in message <b>1438</b> is sent from the TS <b>1404</b> to the user <b>1406</b>.</li><li id="ul0028-0017" num="0248">16. The “talker ID” notification is sent to the user <b>1406</b> in notification <b>1440</b>.</li><li id="ul0028-0018" num="0249">17. Media packets sent in flow <b>1442</b> from the user <b>1405</b> arrive at the CPF <b>1402</b> since it is the first in the media path (see the long dashed lines in <figref idrefs="DRAWINGS">FIG. 15</figref>).</li><li id="ul0028-0019" num="0250">18. The CPF <b>1402</b> duplicates the received media streams as required and forwards the duplicated media streams to the TS <b>1404</b> in media flow <b>1444</b>.</li><li id="ul0028-0020" num="0251">19. The TS <b>1404</b> transcodes the streams as needed in operation <b>1446</b>.</li><li id="ul0028-0021" num="0252">20. The TS <b>1404</b> forwards the adapted and transcoded media streams to the user <b>1406</b> in media flow <b>1448</b>.</li><li id="ul0028-0022" num="0253">21. The rest of the signaling flow is straightforward. When the user <b>1406</b> talks, the media flow from the user <b>1406</b> to the user <b>1408</b> is as illustrated in short dashed and dotted lines in <figref idrefs="DRAWINGS">FIG. 15</figref>. <br /> When multiple terminals are involved in a session, the CPF <b>1402</b> and the TS <b>1404</b> perform SDP modifications to modify the path of media streams in a similar way for each joining terminal (so that the CPF <b>1402</b> is first in the path and the TS <b>1404</b> is next). Both the TS <b>1404</b> and the CPF <b>1402</b> are also aware of which IP addresses and ports pairs belong to which session description in order to perform the right transcoding and routing. </li></ul></li></ul>
p-0083It is important to note that while the CPF <b>1402</b> is before the TS <b>1404</b> in the media flow, the TS <b>1404</b> is always before the CPF <b>1402</b> in the session flow. This can be ensured by using an IP switch in the network, so that each SIP packet with the CPF <b>1402</b> as destination not coming from the TS <b>1404</b> is routed to the TS <b>1404</b>. Indeed, every session control message destined to the CPF <b>1402</b> first travels through the TS <b>1404</b>, which can modify its content.
p-0084Finally, <figref idrefs="DRAWINGS">FIG. 15</figref> illustrates a routing example of IP addresses between the CPF <b>1504</b>, the TS <b>1506</b>, and the terminals <b>1502</b> and <b>1508</b>, during a transcoding session setup. The incoming traffic to the CPF <b>1504</b> has an IP address ending with “1E28”. The incoming traffic to the TS <b>1506</b> has an IP address ending with “1E30”. And the outgoing traffic from the TS <b>1506</b> destined to the terminal <b>1508</b> has an IP address ending with “1E24”. Regarding the outgoing traffic from the TS <b>1506</b> destined to the terminal <b>1502</b>, the outgoing traffic uses an IP address ending with “1E34”
p-0085Many modifications and other embodiments of the present invention will come to mind to those of ordinary skill in the art to which this invention pertains having described several implementation alternatives for architectures and signaling flows. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used to clarity the implementation in the scope of the PoC service and not for purposes of limiting the scope of the present invention in any way.
p-0086Although the present invention has been described in the foregoing specification by means of non-restrictive illustrative embodiments, these embodiments can be modified at will within the scope of the appended claims without departing from the spirit and nature of the subject invention.
REFERENCES
p-0087<ul><li id="ul0035-0001" num="0258">[1] Open Mobile Alliance, “Push to Talk Over Cellular (PoC)—Architecture. OMMD_PoC-V1<sub>—</sub>0-20041117-D.”</li><li id="ul0035-0002" num="0259">[2] 3GPP TS 26.235, “Packet switched conversational multimedia applications; Default codecs (Release 6).”</li><li id="ul0035-0003" num="0260">[3] 3GPP2 S.R0100-0, “Push to Talk Over Cellular (PoC) System Requirements.”</li><li id="ul0035-0004" num="0261">[4] 3GPP TS 23.228, “IP Multimedia Subsystem (IMS); Stage 2.”</li><li id="ul0035-0005" num="0262">[5] 3GPP TS 24.229, “IP Multimedia Call Control based on SIP and SDP; Stage 3.”</li><li id="ul0035-0006" num="0263">[6] 3GPP2 X.S0013.2, “IP Multimedia Subsystem (IMS); Stage 2.”</li><li id="ul0035-0007" num="0264">[7] 3GPP2 X.S0013.4, “IP Multimedia Call Control Protocol, Based on SIP and SDP stage 3.”</li><li id="ul0035-0008" num="0265">[8] 3GPP TS 23.218, “Multimedia (IM) session handling; stage 2.”</li><li id="ul0035-0009" num="0266">[9] IETF RFC 3435, “Media Gateway Control Protocol; version 1.”</li><li id="ul0035-0010" num="0267">[10] IETF RFC 3525, “Gateway Control Protocol; version 1.”</li><li id="ul0035-0011" num="0268">[11] ITU Recommendation H.248, “Gateway control protocol.”</li><li id="ul0035-0012" num="0269">[12] E. Burger and Guy Redmill, “Media Services in the IMS: Evolution for Innovation,” <i>Brooktrouth Technology, </i>May 2005.</li><li id="ul0035-0013" num="0270">[13] IETF RFC 2327, “SDP: Session Description Protocol.”</li><li id="ul0035-0014" num="0271">[14] Open Mobile Alliance, “Push to Talk Over Cellular (PoC)—Control Plane Document. OMA-TS-PoCControlPlane-V1<sub>—</sub>0.”</li><li id="ul0035-0015" num="0272">[15] Open Mobile Alliance, “Push to Talk Over Cellular (PoC)—User Plane. OMA-TS-PoC-UserPlane-V1<sub>—</sub>0.”</li></ul>
Contents8
16 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US9628831B2 | Cited by | United States of America | Search report |
| US2009185523A1 | Cited by | United States of America | Pre-grant |
| US10218826B2 | Cited by | United States of America | Search report |
| US9462123B2 | Cited by | United States of America | Applicant |
| US9065875B2 | Cited by | United States of America | Search report |
| US2015098316A1 | Cited by | United States of America | Pre-grant |
| US2013246632A1 | Cited by | United States of America | Pre-grant |
| US2010150141A1 | Cited by | United States of America | Pre-grant |
| US10375538B1 | Cited by | United States of America | Applicant |
| US8923812B1 | Cited by | United States of America | Applicant |
| US8855103B2 | Cited by | United States of America | Search report |
| US8255785B2 | Cited by | United States of America | Search report |
| US2015326440A1 | Cited by | United States of America | Pre-grant |
| US2011231558A1 | Cited by | United States of America | Pre-grant |
| US2008214104A1 | Cited by | United States of America | Pre-grant |
| US10841842B2 | Cited by | United States of America | Search report |
| US9998593B1 | Cited by | United States of America | Applicant |
| US9374457B2 | Cited by | United States of America | Applicant |
| US9806938B2 | Cited by | United States of America | Applicant |
| US11083028B2 | Cited by | United States of America | Applicant |
| US9590825B2 | Cited by | United States of America | Search report |
| US10079722B2 | Cited by | United States of America | Search report |
| US9660836B2 | Cited by | United States of America | Applicant |
| US10033771B2 | Cited by | United States of America | Applicant |
| US9408241B2 | Cited by | United States of America | Search report |
| US10542396B1 | Cited by | United States of America | Applicant |
| GB2495435A | Cited by | United Kingdom | Search report |
| US9559895B2 | Cited by | United States of America | Search report |
| US9769215B2 | Cited by | United States of America | Applicant |
| US2017134231A1 | Cited by | United States of America | Pre-grant |
| US2012294352A1 | Cited by | United States of America | Pre-grant |
| CN106165405A | Cited by | China | Search report |
| US9219764B2 | Cited by | United States of America | Applicant |
| US9894128B2 | Cited by | United States of America | Applicant |
| US10225399B2 | Cited by | United States of America | Applicant |
| US2006153102A1 | Cited by | United States of America | Pre-grant |
| US10264131B2 | Cited by | United States of America | Search report |
| US8995965B1 | Cited by | United States of America | Applicant |
| WO2012006151A3 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US10158557B2 | Cited by | United States of America | Applicant |
| US9203960B1 | Cited by | United States of America | Applicant |
| US10136272B2 | Cited by | United States of America | Applicant |
| US8832298B2 | Cited by | United States of America | Search report |
| US11032678B1 | Cited by | United States of America | Applicant |
| WO2012006151A2 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US2016157136A1 | Cited by | United States of America | Search report |
| US9462124B2 | Cited by | United States of America | Applicant |
| US2003028643A1 | Cites | United States of America | Pre-grant |
| US2003235184A1 | Cites | United States of America | Pre-grant |
| US2006052127A1 | Cites | United States of America | Pre-grant |
| US2006052130A1 | Cites | United States of America | Pre-grant |
10 priority claims, no other members on record
Priority claims10
| Document | Office | Kind | Date |
|---|---|---|---|
| 75419405 | United States of America | P | |
| 75419405 | United States of America | P | |
| 2006002134 | Canada | W | |
| 2006002134 | Canada | W | |
| 9795006 | United States of America | A | |
| 60754194 | – | – | – |
| PCTCA0602134 | – | – | – |
| US20050754194P | – | – | – |
| US20060097950 | – | – | – |
| WO2006CA02134 | – | – | – |
20 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Maintenance fee paymentMAFP | MAFP | |
| Fee payment procedureENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Fee payment procedure7.5 YR SURCHARGE - LATE PMT W/IN 6 MO, SMALL ENTITY (ORIGINAL EVENT CODE: M2555); ENTITY STATUS OF PATENT OWNER: SMALL ENTITYFEPP | FEPP | |
| Maintenance fee paymentMAFP | MAFP | |
| Fee payment procedureMAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: SMALL ENTITYFEPP | FEPP | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Fee paymentFPAY | FPAY | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS | |
| AssignmentAS | AS |
Numbers
- Publication, DOCDB
- 2010004014
- Publication, EPODOC
- US2010004014
- Application
- 12097950
- Application, DOCDB
- 9795006
- Application, EPODOC
- US20060097950
Titles
- English
- Multi-Users Real-Time Transcoding System and Method for Multimedia Sessions
Classification
- CPC, 11
- H04L65/4061
- H04W88/181
- H04L65/1016
- H04L65/1043
- H04L65/104
- H04L65/103
- H04L65/1104
- H04L65/765
- H04W76/30
- H04W4/10
- H04W84/042
- IPC, 3
- H04B7 00
- H04W88 18
- H04L69 14
- USPC, 1
- 455519000