用于多媒体会话的多用户实时代码转换系统与方法

摘要

一种用来建立在具有非兼容媒体特性的终端之间的、具有会话描述的多用户通信会话的方法与系统，其中邀请具有非兼容媒体特性的终端的用户参加通信会话。设置代码转换会话，使之能够根据关于接受了邀请的用户的终端的信息，进行终端的非兼容媒体特性之间的代码转换，信息包含该用户的终端的媒体特性。根据代码转换会话，建立会话描述；以及在通信会话期间，利用参加通信会话的其他用户的终端的媒体特性，根据代码转换会话，对来自一个用户的终端的媒体流进行代码转换，并且根据会话描述，将代码转换的媒体流发送给其他用户。

说明书

相关申请的交叉引用

本申请要求2005年12月28日提交的名为“REAL-TIME TRANSCODINGARCHITECTURE FOR PoC”的美国临时申请第60/754,194号的优先权，其内容通过引用融入本文。

技术领域

一般地，本发明涉及用来建立多用户通信会话的系统与方法。更具体地而不是排他地，本发明涉及用于蜂窝式多媒体会话上的推压讲话(push to talk)的多方实时代码转换系统与方法。

背景技术

蜂窝式推压讲话(PoC)服务允许移动用户建立组会话，其中参加者可以在一对一或者一对多基础上进行语音与数据通信[1]。语音通信类似于步话机服务，其中终端具有专用的“讲话”按钮。在给定时间，只有一个人可以讲话，并且每次讲话猝发都相对较短，例如，其持续几秒钟。用户也可以交换即时消息。不久讲话猝发将演进为语音和视频流的猝发，并且即时消息将包含丰富的媒体内容，例如音频、视频、文本、动画等等。

蜂窝式推压讲话(PoC)服务规格由开放移动联盟(OMA)定义。其基于第三代伙伴项目(3GPP或者3GPP2)互连网协议多媒体子系统(IMS)体系结构中的会话发起协议(SIP)。更具体地，PoC服务建立在SIP/IP核心之上，其可以满足3GPP IP多媒体子系统(IMS)[4，5]或者3GPP2 IMS[6，7]的规格。

对于通用情况的整体PoC体系结构包括多个PoC客户端，每个PoC客户端连接到其自身的参加PoC功能(在其自己的网络上)，参见由中心控制PoC功能控制的公共会话。所有PoC功能都连接到中心控制PoC功能。

请注意，控制PoC功能负责管理在给定时间谁具有讲话许可权(即谁有发送音频视频媒体或者多媒体分组的许可权)，并且负责将媒体分组从一个来源拷贝到多个目的地。参加PoC功能无法进行这些操作。

由于终端与网络的多样性，所以产生了互操作问题。例如，3GPP要求使用AMR(自适应多速率)窄带语音编解码器作为PoC服务中的默认语音编解码器。如果其上实现PoC客户端的用户装备对于语音使用16kHz采样频率，则3GPP还要求支持AMR宽带语音编解码器。在另一方面，3GPP2要求EVRC(改进可变速率编码)语音编解码器作为默认语音编解码器[3]。因此，由于不兼容，分别支持AMR与EVRC音频编解码器的3GPP与3GPP2终端将不能够一起建立PoC会话。对于包含视频和媒体的即时消息来说，同样会产生相同的不兼容性。为了解决这一问题，需要代码转换。代码转换允许在网络元件中从一种格式转换为另一种格式，以满足每个参加者的终端能力。

因为PoC服务建立在3GPP/3GPP2 IMS SIP/IP核心之上，所以媒体由MRFC/MRFP(媒体资源功能控制器/媒体资源功能处理器)控制和处理[4，8]，对于通信目的其使用H.248/MGCP(媒体网关控制协议)协议[9-11]。但是这些规格很复杂，并且开发符合这些协议的解决方案要求付出巨大努力。另外，由于H.248/MGCP复杂昂贵、并且其是不是基于SIP的唯一IMS关键系统组件，人们正在批评它并且向其提出挑战。由于这些原因，需要以更通用的框架来处理Poc应用中的代码转换问题，其不限于MRFC/MRFP以及H.248/MGCP。另外，虽然MRFC/MRFP功能与接口定义完备，但是没有定义其在PoC环境下的使用。

在PoC标准中，人们认识到需要代码转换，但是没有提供详细的解决方案。在[1]中据说可以由控制PoC功能(CPF)和/或参加PoC功能(PPF)两者进行代码转换，但是没有进一步的细节。因此重要的是开发一种代码转换体系结构，其支持各种配置与使用情况。在某些情况下，还非常希望以透明方式添加代码转换，从而其可以与已经部署的PoC装备相适合并且一起工作。

总而言之，需要一种支持PoC环境下代码转换的通用解决方案。该解决方案应该与现有的PoC体系结构和协议兼容，从而被接受和集成到标准方案中，例如3GPP、3GPP2、以及OMA。另外，该解决方案需要是灵活的，以能够适合于不同的装备部署情况和限制。

发明内容

因此，本发明的非限定性目的在于提供一种用于蜂窝式推压讲话(PoC)多媒体会话的多方实时代码转换系统和方法。

更具体地，根据本发明，提供了一种用来建立在具有非兼容媒体特性的终端之间的、具有会话描述的多用户通信会话的方法，该方法包括：邀请具有非兼容媒体特性的终端的用户参加所述通信会话；设置代码转换会话，使之能够根据关于接受了邀请的用户的终端的信息，进行所述终端的非兼容媒体特性之间的代码转换，所述信息包含该用户的终端的媒体特性；根据所述代码转换会话，建立所述会话描述；以及在所述通信会话期间，利用参加所述通信会话的其他用户的终端的媒体特性，根据所述代码转换会话，对来自一个用户的终端的媒体流进行代码转换，并且根据所述会话描述，将代码转换的媒体流发送给所述其他用户。

本发明还涉及一种用来建立在具有非兼容媒体特性的终端之间的、具有会话描述的多用户通信会话的系统，该系统包括：用来邀请具有非兼容媒体特性的终端的用户参加所述通信会话的部件；用来设置代码转换会话，使之能够根据关于接受了邀请的用户的终端的信息，进行所述终端的非兼容媒体特性之间的代码转换的部件，所述信息包含该用户的终端的媒体特性；用来根据所述代码转换会话，建立所述会话描述的部件；以及在所述通信会话期间，用来利用参加所述通信会话的其他用户的终端的媒体特性，根据所述代码转换会话，对来自一个用户的终端的媒体流进行代码转换，并且根据所述会话描述，将代码转换的媒体流发送给所述其他用户的部件。

本发明还涉及一种用来建立在具有非兼容媒体特性的终端之间的、具有会话描述的多用户通信会话的系统，该系统包括：网络元件，用来邀请具有非兼容媒体特性的终端的用户参加所述通信会话；代码转换服务器，用来设置代码转换会话，使之能够根据关于接受了邀请的用户的终端的信息，进行所述终端的非兼容媒体特性之间的代码转换，所述信息包含该用户的终端的媒体特性；其中：所述代码转换服务器根据所述代码转换会话，建立所述会话描述；以及在所述通信会话期间，所述代码转换服务器利用参加所述通信会话的其他用户的终端的媒体特性，根据所述代码转换会话，对来自一个用户的终端的媒体流进行代码转换，并且根据所述会话描述，将代码转换的媒体流发送给所述其他用户。

通过参照附图阅读对仅作为例子给出的示范实施例的以下非限定性描述，将清楚本发明的以上以及其他目的、优点以及特点。

附图说明

在附图中：

图1为显示PoC体系结构中对于语音传送的“一对多”组会话的示意图；

图2显示通用PoC体系结构；

图3显示根据本发明的第一非限定性示范实施例的具有代码转换的PoC应用的高级体系结构；

图4显示当设置会话时在SIP INVITE请求内包含的SDP会话描述；

图5A与图5B为显示在PoC应用中为保证适当通信会话的CPF的角色的示意图，其中在图5A中，CPF不支持代码转换，在图5B中，CPF支持代码转换；

图6显示在图3的体系结构中集中在CFP上的、并且其中所有媒体分组都在TS(代码转换服务器)之前到达CPF的代码转换方案的媒体流动；

图7显示集中在CFP上的、并且其中所有媒体分组都在去向CPF之前到达TS的代码转换方案的媒体流动的非限定性例子；

图8显示图7的集中在CFP上的代码转换方案的会话控制流；

图9显示在图7的集中在CFP上的代码转换方案中对于当新参加者具有讲话许可权时的情况的控制流；

图10显示对于图7的集中在CFP上的代码转换方案的信令流；

图11显示对于图7的集中在CFP上的代码转换方案的在TS(代码转换服务器)、CPF、以及用户终端之间的IP地址与端口路由设置；

图12显示根据本发明的第二非限定性示范实施例的在被邀请用户的PPF上执行的代码转换方案的体系结构；

图13显示根据本发明的第三非限定性示范实施例的集中在CFP上的透明代码转换方案的体系结构；

图14显示图13的集中在CFP上的透明代码转换方案的信令流；以及

图15显示图13的集中在CFP上的透明代码转换方案的TS、CPF、以及用户终端之间的IP地址与端口路由设置。

具体实施方式

在以下描述中，将参照附图，这些附图形成了本说明书的一部分，并且在其中显示了其中可以实现本发明的各种非限定性示范实施例。应该理解，可以利用其他实施例，并且在不脱离本发明的范围的前提下，可以进行结构与操作的变化。

在以下描述中，将在蜂窝式推压讲话(PoC)的情景下描述本发明。但是，本发明不限于PoC应用，并且可以用于其中在任意给定时间只有一个参加者具有讲话许可权的其他多方多媒体体系结构；该许可权由中心网络元件控制。该中心网络元件可以是会话的任何中心元件，包括控制PoC功能以及多点控制单元(MCU)。在更一般的情景下，该讲话许可权可以为从一或多个用户导出、并且被分发给所有用户的任何音频视频媒体流(例如从几个用户的视频流产生的视频拼图，或者几个音频流的混合)。还请注意，虽然参照了讲话猝发以及讲话许可权，但是讲话一般地指向其他参加者发送媒体流的许可权，而不管这些媒体流为音频、视频、文本、图形、还是其他类型。因此，将使用术语“讲话猝发”，但是术语“媒体猝发”也许更适当。该用法不限制本发明的范围，本发明适用于媒体的所有类型与组合。最后，在本发明的范围内，用户或者参见通信会话的一方不限于利用终端或者任何其他设备参加多媒体会话的人，而且还包括参见会议的任何自主设备，例如监控或者记录设备。

一般地，本发明的说明性实施例提供了一种系统和方法，用来使支持不同媒体特性(类型、格式、编解码器、或者属性)的终端之间能够互操作，这些终端如果没有这种系统和方法将无法建立其中在给定时间上只有一个用户具有发送媒体流(例如音频和视频)的许可权的多用户多媒体会话。虽然主要关心的是互操作性，但是为了方便，所提出的系统还进行代码转换。例如，用户终端可能支持音频，但是如果用户正在会议(其中不允许使用音频)之中则其可能希望将媒体转换为文本。此类用法被认为是在本发明的范围之内，并且被包含在本发明的的术语“非兼容性”的用法中。该系统与方法通过定制对于每个用户的会话提议、并且按照需要修改用户之间的媒体流以符合每个参加者终端的能力甚至偏好，使能互操作性。该系统与方法处理多方多媒体会话，并且可以用于PoC多媒体会话的情景。本说明书描述了几种替换实施例。选择特定实施例依赖于与部署特定服务关联的限制。在某些情况下，性能可能最重要，而在其他情况下，透明代码转换可能最重要。

本发明让人感兴趣的一种可能应用是在PoC服务中，如图1所示。该服务允许移动用户建立组会话，其中参加者可以在一对一或者一对多基础[1]上进行语音和数据通信。图1显示PoC系统100，其中具有讲话许可权的移动终端102通过发送天线102、无线网络106、以及接收天线108与110向终端112、114、116、以及118发送媒体流。无线网络106中的中心元件(未显示)负责复制与传输媒体流到目的地终端112、114、116、以及118。

在图2中显示了通用PoC体系结构200的例子。终端202与204连接到其本地参加PoC功能(PPF)206，PPF 206位于其自身本地网络208内，连接到位于中心网络212内的控制PoC功能(CPF)210。另外，终端214连接到其本地网络218内的其本地PPF 216。本地PPF 216也连接到CPF 210。因此，终端202与204通过中心网络212互连到终端214。终端202、204与214参加CPF 210控制的公共通信会话。请注意，体系结构200还可以包含包括多个PPF(例如206与216)的、连接到多个终端(例如202、204、以及214)的多个本地网络208与218。

1.PoC应用中的代码转换

1.1 在PoC应用中使能代码转换要考虑的元素

在PoC版本1.0标准[1][14][15]中，人们认识到了对代码转换的需求，但是没有给出详细的解决方案。在[1]中据说可以由控制PoC功能(CPF)和/或参加PoC功能(PPF)两者进行代码转换。因此需要一种代码转换体系结构，其支持各种配置与使用情况。总体解决方案应该涉及几个元素，例如：

1.系统级协议流，不同实体(例如客户端或者用户、代码转换服务器(TS)、PoC服务器)之间的交互，以及修改不同实体之间交换的消息。

2.代码转换服务器的处理体系结构(在TS中发生的内部处理)。

3.代码转换服务器与PoC功能之间的代码转换接口(TI)。

在图3中显示了这些元素。更具体地，图3显示了PoC应用的高级体系结构300，其基本与图2的体系结构类似，但是具有代码转换能力。N个本地网络302₁到302₂通过中心网络304相互互连。每个本地网络302_n(1≤n≤N)包括连接到PPF 308_n的用户终端306_n。中心网络304包括CPF 310，每个PPF 308_n都连接到CPF 310。不同实体之间的连接可以属于不同类型，例如无线、有线、使用电缆等等。另外，代码转换服务器312_n与314分别连接到每个本地网络302_n与中心网络304。更具体地，代码转换服务器312_n通过代码转换接口316_n连接到PPF 308_n。并且TS 314通过代码转换接口318连接到CPF 310。此类配置300允许N个用户306₁到306_N参加中心网络元件CPF 310控制的、并且其中在某时间上一个用户可以发送媒体流的公共通信会话。

另外，图3还显示了用于设置会话的不同实体之间的会话流。一旦会话有效，则媒体流动可以例如直接穿行通过TS 312_n，或者在达到TS 312_n之前，通过CPF 310和/或PPF 308_n。请注意，PoC服务器可以包括控制PoC功能(CPF)、参加PoC功能(PPF)、或者两者，即，CPF与PPF可以构成单个服务器，尽管其在逻辑上是分离的功能。

1.2 会话描述协议

如图4所示的会话描述协议(SDP)400为基于SIP(会话发起协议)多媒体会话的关键元素，并且在[13]中定义。SDP 400包括定义会话参数的多个字段。每行对应一个字段。SDP 400包含在SIP INVITE消息[14]内，当发起与其他用户的组会话时由用户发送该消息。

以下SDP参数让人特别感兴趣：

-其中要接收媒体流的IP地址用行422上的字段“c＝”描述，其中例如显示了IPV6地址1000:900:800:700:600:efdf:2edf:3ece。

-媒体特性列表用行424与432上的字段“m＝”描述，例如显示了该会话中的两个媒体：

-用相关RTCP(实时控制协议)在端口3456上接收的RTP(实时协议)上的音频在行424中显示。对于音频媒体，提供两个编解码器，并且标记为97与98。

-利用UDP(用户数据报协议)在端口2000上接收的讲话猝发控制协议(TBCP)在行432中显示。

-这两个媒体的细节在行426、428、430与434上的字段“a＝”中描述：

-对于音频媒体，两个标签97与98对应于所提议的两个不同的编解码器：AMR编解码器或者8000Hz上的EVRC编解码器，如行426与428中所示。

-在行430中提供端口5560上的RTCP。

-对于TBCP，在行434中提供几种选项。

2.对于集中在控制PoC功能上的代码转换方案的PoC信令流

PoC规格描述了可能包含几种邀请方法的几种会话，其在开放移动联盟(OMA)制定的PoC规格中描述，此处为了简洁不进行描述。本领域技术人员能够以直接的方式将本发明用于PoC标准支持的所有情况。

在本发明的第一非限定行示范实施例中，考虑代码转换方案集中在控制PoC功能上的情况

2.1 在会话流中控制PoC功能的角色

在图3所示的本发明的第一非限定行示范实施例中，除讲话许可权之外，CPF 310还管理整个代码转换处理。不管所建立的PoC组会话的类型如何，CPF 310具有两项主要责任：

1.保证用户之间的适当的会话提议以及设置：

因为PoC用户可能具有具有不兼容的格式/编解码器，所以CPF 310可能必须改变对各个用户的SDP 400(参见图4)，以包含其在组会话期间能够使用、并且对于其可以有到其他格式/编解码器的适当代码转换的格式/编解码器。例如，仅支持AMR的用户将无法与仅支持EVRC的用户建立直接会话。支持AMR-EVRC的代码转换的CPF将在会话提议中包含AMR与EVRC两者。在图5的系统500中显示，其大概显示了保证适当会话提议的CPF角色。在图5的例子A)中，通过CPF 502(其不更改邀请的会话描述)，仅支持AMR音频编解码器的终端504用会话描述(未显示)邀请仅支持EVRC音频编解码器的终端506来通信会话。然后终端506生成错误“4xx RequestFailure”，因为其无法支持所提议的AMR音频编解码器。在例子B)中，通过CPF 512(现在其更改邀请的会话描述以符合终端510的能力)，仅支持AMR音频编解码器的终端508用会话描述(未显示)邀请仅支持EVRC音频编解码器的终端510来通信会话。虽然终端508发出的邀请的会话描述仅包含AMR音频编解码器，由于CPF 512扩展了会话描述从而也包含终端510的EVRC音频编解码器，所以终端510将发出200OK响应(其中以EVRC编解码器作为选定编解码器)，从而接受邀请。CPF 512将修改对于终端508的邀请接受，以包含AMR编解码器而非EVRC编解码器，从而可以在终端508与终端510之间进行会话，并且可以在其间交换数据。

2.管理用户之间的媒体流的流动

当需要代码转换时，媒体流将必须流经代码转换服务器(TS)(在图5中未显示)，其中媒体流将被适配/代码转换，然后被发送到其目的地。这要求媒体流的流动由CPF 512管理。关于媒体流动，CPF 512必须管理两种业务：讲话猝发控制(TBC)以及通常媒体。第一种涉及讲话请求，例如请求讲话许可权，以及用户与CPF 512之间的响应。第二种涉及通常媒体流，其包含有用信息以及要传送的实际数据(例如RTP与RTCP上的AMR)。每种业务都被分配给某些特定端口号。因此，CPF 512与TS分别至少包含用于TBC业务的端口，例如TBCP(讲话猝发控制协议)端口。

2.2 控制PoC功能在媒体流动中的角色

对于媒体流动，可能有两个选项。因此，在图6的体系结构600以及图7的体系结构700中考虑并且显示了两种媒体流动方案。作为非限定性例子，图6与图7都显示了使用AMR/EVRC代码转换的体系结构。

在图6的体系结构600中显示第一种媒体流动方案，此时代码转换集中在CPF 602上，并且其中所有的媒体分组在代码转换服务器(TS)之前到达CPF 602。来自利用AMR编解码器的终端606的用户希望与来自利用EVRC编解码器的终端608的用户通信以及交换媒体流。终端606在媒体流动610中向CPF 602发送实时协议(RTP)上的AMR分组。在媒体流动612中，CPF 602发送这些RTP上的AMR分组给TS 604，以进行适配与代码转换。在媒体流动614中，TS 604将适配的RTP上的EVRC分组返回给CFP 602，然后，在媒体流动616中，CFP 602将其转发给终端608。在另一替代方案中，TS 604可以直接将适配的EVRC分组发送给终端608，而不经过CFP 602。

在CFP 602将通常媒体流转发给TS 604时，其自己处理到达其TBCP端口、来自终端606的TBC分组，并且在消息流618中，将结果返回给终端606。实际上，包含TB请求与响应的媒体流动618仅在终端608与CFP 602之间传送，而在通信路径中不涉及TS 604。

在图7的体系结构700中显示第二种媒体流动方案，此时代码转换集中在CPF 702上，并且其中所有的媒体分组在CPF 702之前(或者替代CPF 702)到达TS 704。在媒体流动708中，终端706发送RTP上的AMR分组给TS 704。TS 704将AMR分组代码转换为EVRC分组，并且在媒体流动710中，将如此适配的RTP上的EVRC分组发送给终端712。包含TB请求与响应的媒体流动714仅通过TS 704在终端706与CFP 702之间传送。更具体地，TS 704将媒体流动714的进入的分组转发给媒体流动716的外出的去向CFP 702的分组。并且TS 704将媒体流动716的来自CFP 702的进入的分组转发给媒体流动714的外出的去向终端706的分组。以同样的方式，终端712与CFP 702可以仅通过TS 704相互交换TB请求与响应。

因此，TS 704将到达其TBCP端口的TBC分组转发给CFP 702，同时其代码转换通常媒体流，并且将其发送给其目的地，例如到终端712。CFP 702管理到达其TBCP端口的TBC消息，并且将响应返回给TS 704，TS704将其转发给其目的地，或者可替换地，CFP 702直接将响应返回到其目的地。

图7的体系结构700被认为是优选媒体流动方案，这是因为其要求TS 704与CPF 702之间的分组的流动较少。

2.3 控制PoC功能管理的会话控制

除上述媒体流动之外，还必须管理/提供会话控制流。会话控制流在图8中显示，并且由CPF 802控制，其还管理会话本身。会话可能会影响媒体流动。实际上，在设置通信会话之后，当会话参数改变时，例如由于用户加入或者离开，或者当不同的用户具有讲话许可权时，CPF 802必须通知TS 804该情况，从而可以对媒体流进行适当的代码转换以及路由传送。

更具体地，图8的体系结构800显示了当设置会话时在CPF 802、TS 804、以及终端806与808之间发生的控制流。在体系结构800中，ARM与EVRC音频编解码器之间的互操作性被处理为非限定性例子。会话的设置如下：

1.在消息810中，通过发送邀请(其中会话描述包含其所支持的音频视频格式/编解码器，例如AMR编解码器)，终端806的用户邀请另一用户到会话。

2.CPF 802接收该邀请(其包含所提议的会话媒体格式/编解码器信息以及IP地址和端口号)，并且在消息812中，请求TS 804设置代码转换会话，并且提供向参加该会话的其他用户提议的可接受格式/编解码器的列表

3.TS 804设置代码转换资源，并且在消息814，将IP地址以及端口信息与格式/编解码器信息一起返回给CPF 802。在该特定例子中，将EVRC编解码器添加到列表中。

4.在消息815中，CPF 802将具有改进的媒体格式/编解码器以及IP地址与端口信息的邀请转发给被邀请的终端808。

5.在目的地为CPF 802的消息816中，终端808接受具有其自己支持的解码器(在该例子中为EVRC)的邀请。

6.当收到消息816时，在消息818中，CPF 802请求TS804根据接受了邀请的被邀请终端808提供的信息更新代码转换会话；该信息涉及已接受格式/编解码器，以及用于终端808的IP地址和端口。

7.TS 804进行所请求的操作，并且消息820中，提供更新后的会话信息给CPF 802，包括格式/编解码器以及IP地址与端口信息。

8.然后在消息820中，CPF 802通知终端806邀请已经被接受以及要用的、并且终端806支持的格式/编解码器。

9.然后终端806利用现有的PoC机制，获得讲话许可权。

10.终端806开始向TS 804发送ARM分组。然后根据图7的体系结构700，TS 804将ARM分组代码转换为EVRC分组，并且将其转发给终端808。如果替换地使用图6的体系结构600，则在TS804中被代码转换之前，分组首先到达CPF 802。

在以下描述的图10中，以详细的信令流提供了更多的细节。

现在参照图9，体系结构900当用户例如906请求讲话许可权时在CPF902、TS 904、以及用户906与908之间发生的控制流的例子。一般地，假设开始没有用户有讲话许可权。步骤如下：

1.终端906通过发出TB(讲话猝发)请求消息901，请求讲话许可权。在该例子中，假设图7的媒体流动，但是本领域技术人员可以容易地设想用于根据图6的媒体流动的适当的消息流。

2.TB请求消息901到达TS904，并且在消息912中被转发给CPF 902。

3.在消息914中，CPF 902通知TS 904用户终端906正在请求讲话许可权，从而TS 904可以适当地相应分配代码转换资源，并且实施对媒体流的适当控制。

4.在TS 904在消息916中向CPF 902确认准许该请求之后，CPF 902通过发送TB确认消息918给TS 904，通知用户终端906其讲话请求被准许，TS 904在消息920中将该TB确认消息918转发给用户终端906。

5.然后，在媒体流动922中，用户终端906可以开始发送RTP传输上的AMR分组。

6.媒体流动922到达TS 904。TS904将媒体信息从AMR代码转换为EVRC格式，然后在媒体流动924中，将代码转换的媒体发送给用户终端908。

7.然后，在媒体流动926中，对于媒体924的RTCP报告(例如终端908接收的分组的数目)被从终端908发送给TS904。

8.在媒体流动928中，对于媒体922的RTCP报告被从TS904发送给用户906。

使用AMR与EVRC编解码器仅是为了说明在体系结构900中要执行的操作，但是体系结构900不限于此。体系结构900可以支持各种格式/编解码器以及格式/编解码器的组合，包括音频视频格式/编解码器的组合，例如AMR、EVRC、H.263、MPEG-4部分2、MPEG-4部分10等等。例如，体系结构900可以支持AMR/H.263去向/来自EVRC/MPEG-4部分2的代码转换。另外，在本应用中，仅仅出于说明目的，在TS 904与CPF 902之间流动TB(请求/确认)消息。在本发明的其他修改与实施例中，对于此类操作，可以使用IP交换机，以将此类消息直接路由传送给CPF 792，而不必经过TS 904。

2.4 用于适配集中在CPF上的详细信令流

现在参照图10，描述了集中在CPF上的代码转换方案的详细信令流。可以考虑几种组会话情况及其变体。但是，这将使本说明书阅读起来非常烦琐，也没有提供任何附加好处。因此，将描述配备有对应的详细信令流的代表性使用情况。本领域技术人员可以直接方式将该信令流应用于所有其他情况。

在下文中，将描述“利用在PoC规格中描述的手动回答命令上会话的确认指示”的情况。将不描述关于SIP/IP核心的信令细节，这是因为本领域技公知，并且只会增加流动的复杂性而没有任何益处。另外，考虑所有媒体分组到达TS的情况。但是，本领域技术人员可以直接方式考虑其都到达CPF的情况。

图10显示对于代码转换方案集中在CPF上、并且其中所有媒体流都到达TS的情况的、在CPF 1002、TS 1004、用户终端1006与1008及其相应PPF1010与1012之间的详细信令流的示范性实施例1000。

0.PoC用户1006按压对应PoC终端的PoC按钮，以发起组会话。

1.通过这样做，在消息1014中，用户1006发出包含SDP信息(标记为SDP-A)的SIP INVITE方法。SIP INVITE首先到达用户1006的网络中的PPF1010(例如其归属PPF)。例如，作为非限定性例子，SDP-A可以包括：

c＝IN IP6 FF1E:03AD::7F2E:172A:1E24

m＝audio 3456 RTP/AVP97

a＝rtpmap:97 AMR

a＝rtcp:5560

m＝application 2000 udp TBCP

a＝fmtp:TCBP queuing＝1；tb_priority＝2；timestamp＝1

2.然后，在消息1016中，将SIP INVITE从PPF 1010发送给CPF 1002。CPF 1002可以在任何网络上，例如用户1006的网络、用户1008的网络、或者不同的网络。

3.然后，在消息1018中，CPF 1002联系TS 1004设置用于该会话的代码转换资源。该请求包括在SDP-A中包含的格式/编解码器以及IP地址和端口信息。编解码器信息用来得知被邀请方(例如用户1008)的格式/编解码器，并且确定可以向对其他用户的会话提议添加哪些附加的格式/编解码器。IP地址和端口信息用来确定在代码转换之后需要将来自其他用户的代码转换的结果发送到何处以到达发出邀请的客户端(在这种情况下为用户1006)。因为所有媒体分组都到达TS 1004，所以IP地址和端口信息还用来确定需要将来自CPF 1002讲话猝发(TB)响应发送给何方以达到用户1006。另外，需要CPF 1002的IP地址和端口信息，使发出邀请的客户端(用户1006)向其转发讲话猝发请求。例如，如果CPF 1002的IP地址为IP6FF1E:03AD::7F2E:172A:1E28，则如下提供使用SDP的信息(尽管接口不需要使用SDP):

c＝IN IP6FF1E:03AD::7F2E:172A:1E28

m＝application 2002 udp TBCP

另外，设置代码转换操作一般调用两个TS API(应用程序接口)方法：i)SetupTranscodingSession(SDP-A，SDP-CPF)以及ii)AddInvitee(SessionID)。

i)该第一方法发起新的代码转换会话。其建立新的会话ID上下文，并且记住用来使其所有媒体到达用户1006与CPF 1002的IP地址与端口。其还记住用户1006(即发出邀请方)支持的媒体格式/编解码器与协议。该方法返回会话ID。在图11中的点虚线1110中显示了用户1006的TS 1004内的保留处理。

ii)该第二方法向会话ID提供邀请新参加者信息。该方法返回用户ID与用户可以向其发送媒体流、并且其中CPF 1002可以通过TS1004向该用户发送TB响应的IP地址和端口。所有信息在会话ID的上下文中更新。

4.然后，TS 1004将在消息1020中向CPF 1002返回以下信息：

对于消息1018中的对于Setup TranscodingSession(SDP-A，SDP-CPF)的调用，其将返回会话ID用于将来引用。

对于对AddInvitee(Session ID)的调用，其将返回(如图11中短划线1116中所示)：用于将来引用的用户ID(例如接受了邀请的用户或者离开的用户)，在对被邀请方1008的会话提议中提供的格式/编解码器的列表(即TS 1004可以支持与用户1006所提议的格式/编解码器的代码转换的格式/编解码器的列表)，其中被邀请的用户1008可以向其他参加者发送其媒体以进行代码转换的地址/输入端口的列表，其中CPF 1002可以发送对被邀请的用户1008的讲话猝发响应给TS 1004的地址/输入端口的列表。

TS 1004可以利用如下的SDP提供信息(尽管接口不需要使用SDP)：

i)对于邀请其他参加者：

c＝IN IP6 FF1E:03AD::7F2E:172A:1E30

m＝audio 53456 RTP/AVP 97 98

a＝rtpmap:97 AMR

a＝rtpmap:98 EVRC/8000

a＝rtcp:53080

m＝application 50000 udp TBCP

a＝fmtp:TCBP queuing＝1；tb_priority＝2；timestamp＝1

以及ii)对于从CPF1002发送TB响应：

c＝IN IP6 FF1E:03AD::7F2E:172A:1E30

m＝application 53458 udp TBCP

请注意：每次CPF 1002希望要求新用户到会话时，其将必须调用AddInvitee(Session ID)。另外，如果所有媒体流都在去向TS 1004之前进入CPF 1002(另一选项)，则步骤3(利用消息1018)中的IP地址与端口不对应于SDP-A，而是对应于CPF 1002中的IP地址与端口。另外，因为在CPF 1002与TS 1004之间没有TBCP的任何流动，所以在参数中不存在具有媒体TBCP的行“m＝”。因此，TS 1004知道其不需要处理任何讲话猝发控制消息(TBCM)。

5.从TS 1004接收的信息响应由CPF 1002处理，并且生成修改后的邀请SDP-A’，然后在消息1022中，通过其PPF 1012将其发送给被邀请方1008。

6.在消息1024中，PPF 1012将收到的邀请转发给PoC用户1008。

7.在消息1026中，从用户1008向其PPF 1012发送更改(Altering)消息。该更改消息通知发出邀请的用户1006被邀请的用户1008已经收到了邀请，但是还没有接受邀请。

8.然后，在消息1028中，将更改消息从PPF 1012发送到CPF 1002。

9.然后，在消息1030中，将更改消息从CPF 1002发送到用户1006的PPF 1010。

10.最后，在消息1032中，用户1006接收PPF 1010发送的更改消息。

11.用户1008接受邀请，并且在消息1034中，向其PPF1012发送SDP-AB’中的选定媒体信息。例如，SDP-AB’可以包括：

c＝INIP6FF1E:03AD::7F2E:172A:1E34

m＝audio 5458 RTP/AVP 98

a＝rtpmap:98 EVRC/8000

a＝rtcp:5480

m＝application 4000 udp TBCP

a＝fmtp:TCBP queuing＝1；tb_priority＝2；timestamp＝1

12.在消息1036中，PPF1012将消息1034转发给CPF1002。

13.然后，在消息1038中，CPF 1002联系TS1004更新代码转换会话。该请求实际涉及以下两种TS API方法：

-Join(Session ID，User ID，SDP-AB’，SDP-CPF)(在图11中在实线1112中显示)：该方法通知TS 1004用户1008已经接受了邀请。其通过记住对应于用户ID以及CPF 1002的用来使其所有媒体数据到达用户1008的IP地址与端口，更新会话ID上下文。其还记住用户ID(即参加方1008)所支持的媒体格式/编解码器。例如，CPF 1002必须提供关于其IP地址与端口的信息，来自用户ID的TB请求可以向该IP地址与端口发送：

c＝IN IP6 FF1E:03AD::7F2E:172A:1E28

m＝application 2008 udp TBCP

在图11中在实线1112中显示了对于用户1008的TS 1004内部的保留处理。

-AcceptInvite(Session ID，SDP-AB’，SDP-CPF):该方法通知TS 1004来自用户1006的邀请已经被至少一个人接受。其通过记住对于每个输入端口希望用户1006使用哪些格式/编解码器，更新会话ID上下文。该方法返回其中用户1006可以发送媒体流的、以及CPF 1002可以沿其通过TS 1004向用户1006发送TB响应的IP地址与端口。在图11中在长划线1114中显示了对于用户1006的TS 1004内部的保留处理。

14.然后在消息1040中，TS 1004向CFP 1002返回以下信息：

在消息1038中进行的调用Join(Session ID，UserID，SDP-AB’，SDP-CPF)的请求的状态。通常，该状态报告成功地将新用户添加到会话，或者没有添加该新用户的原因。

在消息1038中进行的调用AcceptInvite(Session ID，SDP-AB’，SDP-CPF)的返回参数，包括：其中用户1006可以发送其媒体流以代码转换为其他参加者的格式的地址/输入端口的列表，要使用的格式/编解码器，其中CPF 1002可以向TS 1004发送对于用户1006的讲话猝发响应的地址/输入端口的列表。TS 1004将利用如下SDP提供信息，在图11中在长划线1114中显示(尽管接口不需要使用SDP)：

i)对于在会话期间向用户1006发送数据：

c＝IN IP6 FF1E:03 AD::7F2E:172A:1E3

m＝audio 48456 RTP/AVP 97

a＝rtpmap:97AMR

a＝rtcp:48080

m＝application 48000 udp TBCP

a＝fmtp:TCBP queuing＝1；tb_priority＝2；timestamp＝1

ii)对于发送来自CPF 1002的TB响应：

c＝IN IP6 FF1E:03AD::7F2E:172A:1E30

m＝application 48400 udp TBCP

15.来自TS 1004的信息响应由CPF 1002处理，然后在消息1042中，CPF 1002通过其PPF 1010发送对于发出邀请的一方1006的修改后的邀请SDP-AB^*。其基本包含要使用的媒体格式/编解码器，以及其中发送媒体流的IP地址与端口。

16.在消息1044中，PPF 1010将该邀请转发给PoC用户1006。

17.在消息1046中，CPF 1002通知TS 1004用户1006具有讲话许可权。这可以利用以下API方法来进行：TalkBurstInform(Session ID，User ID)。在会话ID的上下文中更新信息。

18.TS 1004通过向CPF 1002发送消息1046，确认该许可权。

19.在消息1050中，CPF 1002通过其PPF 1010发送目的地为用户1006的讲话猝发确认。

20.在消息1052中，PPF1 010发送讲话猝发确认给用户1006。

21.在通知1054中，授予用户1006讲话的权利。

22.在消息1056中，CPF 1002通过其PPF1012发送接收讲话猝发消息给用户1008。

23.在消息1060中，PPF 1012将接收讲话猝发消息转发给用户1008。

24.在通知1062中，通知用户1008已经授予用户1006讲话的权利。

25.在媒体流动1064中，媒体流从用户1006向TS 1004流动。在该示范性实施例中，发送AMR分组。容易设想媒体流穿过CPF 1002而非TS 1004的情况。会话发起处理(SIP)需要做的就是向用户提供不同的地址与端口，其将指向CPF 1002而非TS 1004，以及向TS1004提供CPF 1002的IP地址与端口作为输出目的地。

26.然后，TS 1004知道用户1006具有讲话的权利，并且在操作1066中，将媒体流从AMR代码转换为EVRC。

27.然后，在媒体流动1068中，TS 1004向用户1008发送代码转换为EVRC的分组。

28.用户释放PoC按钮。

29到41.剩余步骤为通常PoC操作，不需要进一步解释，其涉及代码转换用户终端1006发送的最后分组，以及结束媒体流传送，其由讲话猝发空闲通知指示，在用户1006释放PoC按钮之后。

但是，随后由用户1006与1008之一重新按压PoC按钮将如以上所述地处理，例如通过图10的操作1046(利用来自希望发送媒体流用户的讲话猝发通知)到1076(用于发送和代码转换媒体流)，以允许所述的一个用户将媒体流传送给(多个)其他参加者。操作1070到1094描述了当所述一个用户释放PoC按钮时在信令流中发生的情况。

图11的媒体流动体系结构1100显示了在代码转换方案集中在CPF 1102上的情况下通过CPF 1102与TS 1104的媒体流动的路由传送。用于从发出邀请的终端1106发出的媒体的TS 1102上的输入IP地址与端口、以及从CPF1102到终端1106的TBCP消息在长划线1114中显示。来自终端1106的输入IP地址与端口被映射到各种类型的媒体流动，例如编解码器、RTCP以及TBCP，如在媒体流动1114中所示。类似地，用于从被邀请的终端1108发出的媒体的TS 1102上的输入IP地址与端口、以及从CPF 1102到终端1108的TBCP消息在短划线1116中显示。来自终端1108的输入IP地址与端口被映射到各种类型的媒体流动，例如编解码器、RTCP以及TBCP，如在媒体流动1116中所示。用于要发送给发出邀请的终端1106的媒体的TS 1102上的目的地IP地址与端口、以及从终端1106到CPF 1102的TBCP消息在点划线1110中显示。终端1106上的输入IP地址与端口被映射到各种类型的媒体流动，例如编解码器、RTCP以及TBCP，如在媒体流动1110中所示。

用于要发送给被邀请的终端1108的媒体的TS 1102上的目的地IP地址与端口、以及用于来自终端1108的目的地为CPF 1102的TBCP消息的IP地址与端口在图11中在实线1112中显示。终端1108上的输入IP地址与端口被映射到各种类型的媒体流动，例如编解码器、RTCP以及TBCP，如在媒体流动1112中所示。应该注意：TS 1102具有IP地址，在该例子中，其以“1E30”结束，并且用于1114与1116中显示的所有进入的媒体流动，尽管对于每个不同的流动使用不同的端口。对于外出的流动，以“1E24”结束的IP地址目的地为终端1106，以“1E28”结束的IP地址目的地为CPF 1102，并且以“1E34”结束的IP地址目的地为终端1108。

需要注意对所述示范性事实例的某些进一步的解释以及变化：

-多个参加者的情况：在这种情况下，对于每个要邀请的参加者，CPF 1102将必须在发送SDP INVITE之前调用AddInvitee(Session ID)，并且一旦用户接受了则必须调用Join(Session ID，User ID，SDP-AB’，SDP-CPF)。当参加者离开会话时，考虑到离开会话的用户ID，CPF1102必须调用Leave(Session ID，UserID)，其更新会话ID。

-所有媒体分组到达CPF 1102的情况:该替换情况在以上参照图10讨论。会话发起处理要做的就是向用户提供不同的地址与端口，其指向CPF 1002而非TS 1004，并且向TS 1004提供CPF 1002 IP地址与端口作为输出目的地。另外，当向TS 1004提供媒体信息时，会话描述中没有TBCP媒体部分，这是因为其完全由CPF 1002管理。应该注意，这是PoC应用中假设的“安全”情况，如在[1]9.12小节中所述，其中所有的媒体流动必须经过CPF 1002(由于分组复制)。但是，另一情况(其中所有的媒体流达到TS)效率高得多、扩展性强得多，因为其将媒体处理分派给了TS 1004。在某种意义上，可以把TS 1004当作CPF 1002的扩展。

请注意：可以对上述示范性实施例进行许多变化，而不会脱离本发明的性质与范围。例如，在一种变化中，TBCP消息可以不流经TS 1004。可以将TS行为分类为严格控制的或者松散控制的。当严格控制时，TS 1004或者监控TBCP消息，以确定谁有讲话许可权，或者从CPF 1002接收特定控制消息。当松散控制时，TS 1004通过监控媒体流获得，知道谁在讲话。也可以修改CPF 1002与TS 1004之间的特定方法与API，而不会脱离本发明的范围。另外，诸如PPF 1006、CPF 1002、以及TS 1004等媒体元素被显示为不同的逻辑元素，但是在实践中，其中之一或者多个可以被组合在一起，成为单个服务器，而不会脱离本发明的范围。

3.其中代码转换方案在被邀请的参加PoC功能上的PoC信令流

该小节提供本发明的第二非限定性示范实施例，其中在被邀请方的PPF上进行代码转换。

3.1 参加与控制PoC功能的角色

在其中在被邀请PPF上进行代码转换的情况下，整个代码转换处理由PPF管理，同时讲话许可权以及将媒体流路由传送到每个目的地(包括复制媒体分组)仍然由CPF管理。不管所建立的组会话的类型如何，PPF都具有两种主要责任，其基本上与在2.1中描述的相同。首先PPF保证在用户之间的适当的会话提议以及设置。第二，PPF管理用户与CPF之间的媒体流的流动。应该注意，虽然所有的媒体流都必须穿过CPF，但是它们不需要穿过所有的PFF。但是，会话控制消息必须穿过所有的PPF与CPF。

CPF的角色为：i)控制谁有讲话许可权；以及ii)复制以及路由传送讲话用户的媒体分组到其他用户。

当前情况与其中代码转换方案集中在CPF上的情况之间的主要差异在于：

i)PPF将控制用户与CPF之间的代码转换(因此有一个用户在输入端，并且有一个用户在输出端)，而在先前情况下，CPF必须控制到所有目的地(许多用户)的代码转换。这是因为不允许PPF复制分组到各个目的地；复制只有由CPF进行。

ii)PPF不必控制谁讲话；CPF仍然控制谁讲话。因此可以两种方式进行PFF对代码转换服务器的控制：a)松散控制——一旦设置会话，代码转换服务器总是有效，并且总是准备进行代码转换，但是某些信道可能会空闲；b)严格控制——PPF将监听TBCM，并且通知代码转换服务器开始或者停止代码转换，可替换地，PPF可以分析TBCM，并且确定谁有讲话许可权。

在本发明的该第二非限定性示范实施例中，在被邀请的参加者的PPF上进行适配或者代码转换。发出邀请的终端向其他方发送邀请，该邀请包含其媒体会话描述。每个被邀请的参加者的PPF都将进行与图8中CPF所进行的相同的操作。这会导致以下情况：发出邀请一方的PPF不需要进行代码转换，这是参加会话的其他各方(例如被邀请的用户)的PPF的责任。因此，在CPF内将流动发出邀请一方所支持格式的媒体。如果参加会话的许多被邀请方支持发出邀请一方的媒体格式，则可以减少系统中代码转换所需的计算资源。

图12显示了用于在被邀请方的PPF上的代码转换的示范性体系结构1200。在情况A)中，在接收PPF进行代码转换。发出邀请的终端1202(其具有讲话许可权)以其所支持的格式(在该特定例子中为AMR)发送媒体流。此类流(为发出邀请的终端1202所支持的、并且在会话建立时同意的格式)在CPF 1204内流动。被邀请方的PPF 1214与1216接收终端1202所支持格式的媒体流，然后按照需要对其进行代码转换，以满足被邀请终端1212与1210的能力。在该例子中，对于用户1212，PPF 1214形成TS，其将收到的媒体流从ARM代码转换为EVRC，而对于用户1210，PPF 1216不必进行任何代码转换，因为用户1210的终端已经支持ARM。

应该注意，在该例子中，元素1202、1212、以及1214每个都形成融入单个服务器中的PFF与TS的组合。

另外，如图12所示，情况B)对应于其中代码转换发生在发送与接收PPF上的情况。用户1224发起组会话，并且邀请用户1232与1220参加。被邀请的用户1220具有讲话许可权。PPF 1222将媒体流动从用户1120支持的格式代码转换为发出邀请的终端1224支持、并且在会话建立期间同意的格式。例如，PPF 1222进行从EVRC到ARM到的代码转换，因为AMR为发出邀请的终端1224所支持、并且在会话建立期间同意的格式，并且由此在CPF 1226内流动。发出邀请的终端1224的PPF 1228不进行代码转换。PPF1230一般为被邀请的终端1232进行代码转换。但是，因为CPF 1226提供的媒体流动处于被邀请的终端1232所支持的格式，所以PPF 1230确定不需要进行代码转换。实际上，因为终端1232支持对于终端1224在会话建立期间同意的、并且在CPF 1226内流动的相同格式/编解码器，所以在终端1232上不需要进行去向以及来自终端1232的代码转换，而不管谁在讲话。例如，在该例子中，AMR总是在CPF 1222内流动，并且因为ARM也被终端1232支持，所以PPF 1230必须不进行代码转换。再次地，元素1222、1228、以及1230每个都形成融入单个服务器中的PFF与TS的组合。

在剩余说明书中，将被发出邀请的终端所支持、并且在会话建立期间同意(由此在CPF内流动)的格式称为“公共流格式”(CSF)。

3.2 参加PoC功能管理的业务的类型与媒体流动

对于媒体流动，与其中代码转换方案集中在CPF上的情况类似，考虑两种方案，如图6与图7所示，但是具有以下修改：替代CPF 602或者702，PPF与TS 604或者704交互。除TS与PPF而非CPF交互之外，主要区别在于到达PPF或者TS的TB请求将被转发给CPF，并且TB响应在到达PPF或者TS之前来自CPF。

3.3 参加PoC功能管理的会话控制

PPF具有非常少的会话管理责任。例如，与CPF不同，本地PPF不需要关心新用户是否假如或者离开会话，只要会话仍然在进行，并且其所服务的用户仍然在参加即可，这是因为对于给定用户，其仅管理来自以及去向CSF的代码转换。另外，其不需要管理谁有讲话许可权；在最差的情况下，其仅监控这一点。

因此，图8的会话流以及图9的控制流仍然对本情况适用，只是TBCM还被路由传送去向/来自CPF，并且TS将被被邀请方的PPF替代。

3.4 对于集中在PPF上的适配的详细的信令流

对于在PPF上进行代码转换的情况下的详细信令流非常类似于代码转换集中在CPF上的情况。图10保持相同，只是与代码转换服务器的交互将在每个被邀请方的PPF上处理。规则为每个被邀请终端的PPF必须进行来自/去向该终端的所支持的媒体格式去向/来自CSF的代码转换。这也要求被邀请方的PFF改变会话描述，以允许建立会话。这以与图10中的CPF 1002所作的相同的方式进行。对TS 1004的功能调用也类似。

4.透明PoC代码转换

该小节描述本发明的第三非限定性示范实施例，其中代码转换为透明PoC代码转换。透明PoC代码转换指PoC终端与服务器不知道正在发生代码转换，并且所做就如任何常规PoC实体在没有进行代码转换的上下文中所做的那样。代码转换服务器被作为代理插入在通信路径中。该方法的主要优点在于其不需要对现有的PoC终端与服务器进行任何改变。实际上，已经部署了PoC系统的运营商可以添加PoC代码转换，而不对已经部署的PoC终端与服务器进行任何改变。该方法已经被证明能够有效地在多媒体消息服务中顺利引入代码转换。

4.1 集中在CPF上的透明PoC代码转换

在该实施例中，将代码转换服务器(TS)置于网络的中心位置，从而其与CPF位置相同，并且可以因此利用以该特有方式相对于CPF放置这一点。在媒体路径中，将TS置于CPF之后，但是在会话控制路径中，将TS置于CPF之前。另外，所有媒体分组(通常媒体与TBCP)都穿过CPF，其在媒体流流动中位于TS之前。

图13的体系结构显示了CPF 1302上的透明代码转换的示范体系结构。处于媒体路径中的CPF 1302将复制通常的(多个)进入媒体流，并且试图将其分发给会话中的其他用户。这些输出流每个都进入TS 1304，并且将分别按照需要被代码转换，以满足目的地终端能力，并且此后将其分发给每个目的地终端1306与1308。TBCP分组也将进入TS 1304，TS 1304将其转发给其目的地。或者通过监控从CPF 1302发送的TCBP分组的内容，或者通过识别进入的通常媒体流(其是无效的，因为正在讲话的用户是对其CPF 1302没有没有传送媒体流的用户)，TS 1304可以了解谁有讲话许可权。根据这一点，TS 1304将确定对每个目的地进行的代码转换操作。例如，如果正在讲话的人使用AMR编解码器，则对于支持EVRC编解码器的用户，需要进行ARM到EVRC代码转换；但是如果正在讲话的人使用EVRC编解码器而不是AMR编解码器，则不需要代码转换。

另外，在图13中，CPF 1302对于所有的目的地用户复制从用户1310获得的AMR流。TS 1304截获那些媒体流，并且将其代码转换以适合目的地用户1306与1308的能力，并且将代码转换的媒体流发送给其目的地。由此，进入TS 1304的目的地为终端1306的AMR媒体在TS 1304的输出端变为对于终端1306的EVRC媒体，而在TS 1304的输入端上目的地为终端1308的AMR媒体在TS 1304的输出端保持为对于终端1308的AMR媒体。TS 1304还将未改变的TBCP消息转发每个目的地用户1306与1308。

要使媒体流穿过CPF 1302然后通过TS 1304，在会话建立处理期间，必须进行某些SDP修改。关于向哪里发送信息，将TS 1304的IP地址和端口信息给予CPF 1302。将CPF 1302的IP地址和端口信息给予用户，而不管向哪里发送信息。TS 1304管理这些IP地址、端口集合与不同实体希望从其接收其数据的地点之间的连接。

图14显示对于透明代码转换集中在CPF 1402上的情况的、在CPF 1402、TS 1404、以及终端1405和1406之间的详细信令流的示范实施例。没有显示终端1405和1406的PPF，以简化描述，但是不丧失一般性。在下文中，描述在重新确定媒体流的路由程序中从CPF 1402到TS 1404的会话提议变化(例如提议的格式/编解码器)。信令流如下：

1.在操作1410中，PoC用户1405按压PoC按钮，以发起组会话。

2.在消息1412中，PoC用户1405发出包含利用SDP信息的会话描述的SIP INVITE方法。SIP INVITE被TS 1404截获，TS 1404可以例如位于与CPF1402相同的网络中。例如，SDP-A可以包括：

c＝INP6FF1E:03AD::7F2E:172A:1E24

m＝audio 3456 RTP/AVP 97

a＝rtpmap:97 AMR

a＝rtcp:5560

m＝application 2000 udp TBCP

a＝fmtp:TCBP queuing＝1；tb_priority＝2；timestamp＝1

3.TS 1404改变用户1405提供的格式/编解码器以及IP地址和端口信息，从而目的地为用户1405的任何媒体流都在被传送给用户1405之前，首先到达TS1404(参见图15中的点线)。其还存储新提议的SDP与用户开始提议的SDP之间的绑定信息。另外，TS 1404通过添加其可以支持来自与去向用户1405提议的媒体格式/编解码器的代码转换的媒体格式/编解码器，来改进会话描述。然后，在消息1414中，TS 1404向CPF 1402发送具有更新的SDP会话描述的邀请。例如，TS1 404提供的SDP可以为：

c＝IN IP6 FF1E:03AD::7F2E:172A:1E30

m＝audio 18456 RTP/AVP 97 98

a＝rtpmap:97 AMR

a＝rtpmap:98 EVRC/8000

a＝rtcp:18080

m＝application 18000 udp TBCP

a＝fmtp:TCBP queuing＝1；tb_priority＝2；timestamp＝1

请注意在行“c＝”中将IP地址从用户1405替换为TS 1404，并且在行“a＝”中添加了EVRC编解码器。

4.CPF 1402接收SDP会话描述，对其进行修改从而使媒体流首先经过自己。然后，在消息1416中，CPF 1402将修改后的邀请发送给用户1406。CPF1402还知道IP地址与端口的映射，因此其可以将进入的分组转发给正确的目的地。例如，其可以如图15所示(参见短划线)：

c＝IN IP6 FF1E:03AD::7F2E:172A:1E28

m＝audio 53456 RTP/AVP97 98

a＝rtpmap:97 AMR

a＝rtpmap:98 EVRC/8000

a＝rtcp:53080

m＝application 50000 udp TBCP

a＝fmtp:TCBP queuing＝1；tb_priority＝2；timestamp＝1

5.更改消息1418被从用户1406发送给TS1404。

6.更改消息1420被从TS 1404发送给CPF1402。

7.更改消息1422被从CPF 1402发送给用户1405。

8.用户1406接受邀请，并且在消息1424中，在SDP-AB’中提供选定媒体信息。该请求由TS1404截获。例如，SDP-AB’可以包括：

c＝IN IP6 FF1E:03AD::7F2E:172A:1E34

m＝audio 5458 RTP/AVP 98

a＝rtpmap:98EVRC/8000

a＝rtcp:5480

m＝application 4000 udp TBCP

a＝fmtp:TCBP queuing＝1；tb_priority＝2；timestamp＝1

9.TS 1404保留代码转换资源与端口，并且在消息1426中，向CPF 1402提供修改后的SDP会话。例如，该SDP可以为：

c＝INIP6FF1E:03AD::7F2E:172A:1E30

m＝audio 28456 RTP/AVP 97

a＝rtpmap:97 AMR

a＝rtcp:28080

m＝application 28000 udp TBCP

a＝fmtp:TCBP queuing＝1；tb_priority＝2；timestamp＝1

10.该信息响应被CPF 1402进一步修改，以将其自己首先包括在媒体路径中。然后，在消息1428中，CPF 1402将修改后的响应发送给用户1405。

例如，该SDP可以为：

c＝INIP6FF1E:03AD::7F2E:172A:1E28

m＝audio 48456

a＝rtpmap:98 EVRC/8000

a＝rtcp:48080

m＝application 48000 udp TBCP

a＝fmtp:TCBP queuing＝1；tb_priority＝2；timestamp＝1

11.在消息1430中，CPF 1402发起对于用户1405的“讲话猝发确认”消息，该消息到达TS 1404(因为其是媒体路径中CPF 1402之后的下一个)。

12.在消息1432中，将“讲话猝发确认”消息从TS 1404发送给用户1405。

13.在通知1434中，将“讲话进行”通知发送给用户1405。

14.在通知1436中，从用户1408接收“讲话猝发”，将其从CPF 1402向用户1406发起，并且到达TS 1404，这是因为其是媒体路径中CPF 1402之后的下一个。

15.在通知1438中，从用户1405接收“讲话猝发”，将其从TS 1404发送给用户1406。

16.在通知1440中，将“讲话者ID”通知发送给用户1406。

17.在来自用户1405的流动中发送的媒体分组达到CPF 1402，这是因为其为媒体路径中的第一个(参见图15中的长划线)。

18.CPF 1402按照需要复制收到的媒体流，并且在媒体流动1444中，将复制的媒体流转发给TS 1404。

19.在操作1446中，TS 1404代码转换流。

20.在媒体流动1448中，TS 1404将适配和代码转换的媒体流转发给用户1406。

21.剩余的信令流就明白了。当用户1406讲话时，从用户1406到用户1408的媒体流动在图15中在短划线和点线中显示。

当会话中涉及多个终端时，对于每个参加终端，以类似的方式(从而CPF1402为路径中的第一个，并且TS 1404为下一个)，CPF 1402与TS 1404进行SDP修改，以修改媒体流的路径。CPF 1402与TS 1404也都知道哪些IP地址和端口属于哪个会话描述，以进行正确的代码转换和路由传送。

请注意，重要的是，虽然在媒体流动中CPF 1402在TS 1404之前，但是在会话流动中，TS 1404总是在CPF 1402之前。通过在网络中使用IP交换机从而不是来自TS 1404的、以CPF 1402为目的地的每个SIP分组被路由传送给TS 1404，可以保证这一点。实际上，以CPF 1402为目的地的每个会话控制消息首先穿过TS 1404，TS 1404可以修改其内容。

最后，图15显示在代码转换会话设置期间在CPF 1502、TS 1506、以及终端1502和1508之间的IP地址的路由传送的例子。对CPF 1502的进入的业务具有以“1E28”结束的IP地址。对TS 1506的进入的业务具有以“1E30”结束的IP地址。并且从TS 1506外出的、目的地为终端1508的业务具有以“1E24”结束的IP地址。关于从TS 1506外出的、目的地为终端1502的业务，该外出的业务使用以“1E34”结束的IP地址。

本领域技术人员在此处描述的对于体系结构以及信令流的几个可替换实现的教导下，可以设想许多修改以及本发明的其他实施例。因此，应该理解，本发明不限于所公开的特定实施例，并且所述修改与其他实施例要包含在权利要求的范围内。虽然此处采用了特定的术语，但是使用这些术语是为了说明在PoC服务范围中的实现，而不是要以任何方式限定本发明的范围。

虽然通过非限定性示范实施例上以上说明书中描述了本发明，但是在权利要求的范围内，可以对这些实施例进行修改，而不会脱离本发明的精神与实质。

参考资料

[1]开放移动联盟，＂Push to Talk Over Cellular(PoC)-Architecture.OMAAD_PoC-V1_0-20041117-D.＂

[2]3GPP TS 26.235，＂Packet switched conversational multimediaapplications；Default codecs(Release 6).＂

[3]3GPP2 S.R0100-0，＂Push to Talk Over Cellular(PoC)SystemRequirements.＂

[4]3GPP TS 23.228，＂IP Multimedia Subsys tem(IMS)；Stage2.＂

[5]3GPP TS 24.229，＂IP Multimedia Call Cont rol based on SIP and SDP；Stage 3.＂

[6]3GPP2 X.S0013.2，＂IP Multimedia Subsystem(IMS)；Stage 2.＂

[7]3GPP2 X.S0013.4，＂IP Multimedia Call Control Protocol，Based onSIP and SDP stage 3.＂

[8]3GPP TS 23.218，＂Multimedia(IM)session handling；stage 2.＂

[9]IETF RFC 3435，＂Media Gateway Control Protocol；version 1.＂

[10]IETF RFC 3525，＂Gateway Control Protocol；version 1.＂

[11]ITU Recommendation H.248，＂Gateway control protocol.＂

[12]E.Burger and Guy Redmill，＂Media Services in the IMS：Evolutionfor Innovation，＂Brooktrou thTechnology，May 2005.

[13]I ETF RFC 2327，＂SDP：Session Description Protocol.＂

[14]开放移动联盟，＂Push to Talk Over Cellular(PoC)-Control PlaneDocument.0MA-TS-PoCCont rolPlane-V1_0.＂

[15]开放移动联盟，＂Push to Talk Over Cellular(PoC)-User Plane.OMA-TS-PoC-UserPlane-V1_0.＂