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

专利名称：用于多媒体会话的多用户实时代码转换系统与方法
技术领域：
一般地，本发明涉及用来建立多用户通信会话的系统与方法。更具体地 而不是排他地，本发明涉及用于蜂窝式多i某体会话上的推压讲话(push to talk) 的多方实时代码转换系统与方法。
背景技术：
蜂窝式推压讲话(PoC)服务允许移动用户建立组会话，其中参加者可以 在一对一或者一对多基础上进行语音与数据通信[l]。语音通信类似于步话机 服务，其中终端具有专用的"讲话，，按钮。在给定时间，只有一个人可以讲 话，并且每次讲话猝发都相对较短，例如，其持续几秒钟。用户也可以交换 即时消息。不久讲话猝发将演进为语音和视频流的猝发，并且即时消息将包 含丰富的4某体内容，例如音频、视频、文本、动画等等。
蜂窝式推压讲话(PoC)服务规格由开放移动联盟(OMA)定义。其基于 第三代伙伴项目(3GPP或者3GPP2 )互连网协议多4某体子系统(IMS )体系 结构中的会话发起协议(SIP )。更具体地，PoC服务建立在SIP/IP核心之上， 其可以满足3GPPIP多媒体子系统(IMS) [4, 5]或者3GPP2IMS[6, 7]的规 格。
对于通用情况的整体PoC体系结构包括多个PoC客户端，每个PoC客户 端连接到其自身的参加PoC功能(在其自己的网络上)，参见由中心控制PoC 功能控制的公共会话。所有PoC功能都连接到中心控制PoC功能。
请注意，控制PoC功能负责管理在给定时间谁具有讲话许可权(即谁有 发送音频视频媒体或者多i某体分组的许可权)，并且负责将^ 某体分组从一个来
源拷贝到多个目的地。参加PoC功能无法进行这些操作。
由于终端与网络的多样性，所以产生了互操作问题。例如，3GPP要求使 用AMR (自适应多速率)窄带语音编解码器作为PoC服务中的默认语音编 解码器。如果其上实现PoC客户端的用户装备对于语音使用16 kHz采样频率， 则3GPP还要求支持AMR宽带语音编解码器。在另 一方面，3GPP2要求EVRC (改进可变速率编码)语音编解码器作为默认语音编解码器[3]。因此，由于 不兼容，分别支持AMR与EVRC音频编解码器的3GPP与3GPP2终端将不 能够一起建立PoC会话。对于包含视频和媒体的即时消息来说，同样会产生 相同的不兼容性。为了解决这一问题，需要代码转换。代码转换允许在网络 元件中从一种格式转换为另一种格式，以满足每个参加者的终端能力。
因为PoC服务建立在3GPP/3GPP2 IMS SIP/IP核心之上，所以媒体由 MRFC/MRFP (媒体资源功能控制器/媒体资源功能处理器)控制和处理[4, 8],对于通信目的其使用H.248/MGCP0某体网关控制协议)协议[9-11]。但是 这些规格很复杂，并且开发符合这些协议的解决方案要求付出巨大努力。另 外，由于H.248/MGCP复杂昂贵、并且其是不是基于SIP的唯一 IMS关键系 统组件，人们正在批评它并且向其提出挑战。由于这些原因，需要以更通用 的框架来处理Poc应用中的代码转换问题，其不限于MRFC/MRFP以及 H,248/MGCP。另外，虽然MRFC/MRFP功能与接口定义完备，但是没有定 义其在PoC环境下的使用。
在PoC标准中，人们认识到需要代码转换，但是没有提供详细的解决方 案。在[l]中据说可以由控制PoC功能(CPF)和/或参加PoC功能(PPF)两 者进行代码转换，但是没有进一步的细节。因此重要的是开发一种代码转换 体系结构，其支持各种配置与使用情况。在某些情况下，还非常希望以透明 方式添加代码转换，从而其可以与已经部署的PoC装备相适合并且一起工作。
总而言之，需要一种支持PoC环境下代码转换的通用解决方案。该解决 方案应该与现有的PoC体系结构和协议兼容，从而被接受和集成到标准方案 中，例如3GPP、 3GPP2、以及OMA。另外，该解决方案需要是灵活的，以 能够适合于不同的装备部署情况和限制。

发明内容
因此，本发明的非限定性目的在于提供一种用于蜂窝式推压讲话(PoC)
多媒体会话的多方实时代码转换系统和方法。
更具体地，根据本发明，提供了一种用来建立在具有非兼容媒体特性的
终端之间的、具有会话描述的多用户通信会话的方法，该方法包括邀请具 有非兼容媒体特性的终端的用户参加所述通信会话；设置代码转换会话，使 之能够根据关于接受了邀请的用户的终端的信息，进行所述终端的非兼容媒 体特性之间的代码转换，所述信息包含该用户的终端的媒体特性；根据所述 代码转换会话，建立所述会话描述；以及在所述通信会话期间，利用参加所 述通信会话的其他用户的终端的媒体特性，根据所述代码转换会话，对来自 一个用户的终端的々某体流进行代码转换，并且才艮据所述会话描述，将代码转 换的媒体流发送给所述其他用户。
本发明还涉及一种用来建立在具有非兼容媒体特性的终端之间的、具有 会话描述的多用户通信会话的系统，该系统包括用来邀请具有非兼容媒体 特性的终端的用户参加所述通信会话的部件；用来设置代码转换会话，使之 能够根据关于接受了邀请的用户的终端的信息，进行所述终端的非兼容媒体 特性之间的代码转换的部件，所述信息包含该用户的终端的媒体特性；用来 根据所述代码转换会话，建立所述会话描述的部件；以及在所述通信会话期 间，用来利用参加所述通信会话的其他用户的终端的媒体特性，根据所述代 码转换会话，对来自一个用户的终端的媒体流进行代码转换，并且根据所述 会话描述，将代码转换的々某体流发送给所述其他用户的部件。
本发明还涉及一种用来建立在具有非兼容々某体特性的终端之间的、具有 会话描述的多用户通信会话的系统，该系统包括网络元件，用来邀请具有 非兼容i某体特性的终端的用户参加所述通信会话；代码转换服务器，用来设 置代码转换会话，使之能够根据关于接受了邀请的用户的终端的信息，进行
所述终端的非兼容^某体特性之间的代码转换，所述信息包含该用户的终端的 媒体特性；其中所述代码转换服务器根据所述代码转换会话，建立所述会 话描述；以及在所述通信会话期间，所述代码转换服务器利用参加所述通信 会话的其他用户的终端的々某体特性，根据所述代码转换会话，对来自一个用 户的终端的媒体流进行代码转换，并且根据所述会话描述，将代码转换的媒 体流发送给所述其他用户。
述，将清楚本发明的以上以及其他目的、优点以及特点。


在附图中
图1为显示PoC体系结构中对于语音传送的"一对多"组会话的示意图； 图2显示通用PoC体系结构；
图3显示根据本发明的第一非限定性示范实施例的具有代码转换的PoC
应用的高级体系结构；
图4显示当设置会话时在SIP INVITE请求内包含的SDP会话描述；
图5A与图5B为显示在PoC应用中为保证适当通信会话的CPF的角色的
示意图，其中在图5A中，CPF不支持代码转换，在图5B中，CPF支持代码转
换；
图6显示在图3的体系结构中集中在CFP上的、并且其中所有i某体分组 都在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所示。该服 务允许移动用户建立组会话，其中参加者可以在一对一或者一对多基础[l]上
进行语音和数据通信。图1显示PoC系统100，其中具有讲话许可权的移动
终端102通过发送天线102、无线网络106、以及"l妄收天线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。
l.PoC应用中的代码转换
1.1在PoC应用中使能代码转换要考虑的元素
在PoC版本1.0标准[1][14][15]中，人们认识到了对代码转换的需求，但 是没有给出详细的解决方案。在[l]中据说可以由控制PoC功能(CPF)和/ 或参加PoC功能(PPF)两者进行代码转换。因此需要一种代码转换体系结 构，其支持各种配置与使用情况。总体解决方案应该涉及几个元素，例如
1. 系统级协议流，不同实体(例如客户端或者用户、代码转换服务器 (TS)、 PoC服务器)之间的交互，以及修改不同实体之间交换的消息。
2. 代码转换服务器的处理体系结构(在TS中发生的内部处理)。
3. 代码转换服务器与PoC功能之间的代码转换接口 (TI)。 在图3中显示了这些元素。更具体地，图3显示了 PoC应用的高级体系
结构300，其基本与图2的体系结构类似，但是具有代码转换能力。N个本 地网络302,到3022通过中心网络304相互互连。每个本地网络302n ( 1《n 《N)包括连接到PPF 308 n的用户终端306n。中心网络304包括CPF 310, 每个PPF 308n都连接到CPF 310。不同实体之间的连接可以属于不同类型， 例如无线、有线、使用电缆等等。另外，代码转换服务器312n与314分别连 接到每个本地网络302n与中心网络304。更具体地，代码转换服务器312n通 过代码转换接口 316 连接到PPF 308n。并且TS 314通过代码转换接口 318
连接到CPF310。此类配置300允许N个用户306i到306n参加中心网絡元件 CPF 310控制的、并且其中在某时间上一个用户可以发送i某体流的公共通信 会话。
另外，图3还显示了用于设置会话的不同实体之间的会话流。 一旦会话 有效，则々某体流动可以例如直接穿行通过TS312n,或者在达到TS312n之前， 通过CPF 310和/或PPF 308 n。请注意，PoC服务器可以包括控制PoC功能 (CPF)、参力卩PoC功能(PPF)、或者两者，即，CPF与PPF可以构成单个 服务器，尽管其在逻辑上是分离的功能。
1.2会话描述协议
如图4所示的会话描述协议(SDP ) 400为基于SIP (会话发起协议)多 媒体会话的关键元素，并且在[13]中定义。SDP400包括定义会话参数的多个 字段。每行对应一个字段。SDP 400包含在SIP INVITE消息[14]内，当发起 与其他用户的组会话时由用户发送该消息。
以下SDP参数让人特别感兴趣
-其中要接收媒体流的IP地址用行422上的字段"c=，，描述，其中例如 显示了 IPV6i也址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=，，中描述
-对于音频4某体，两个标签97与98对应于所^是议的两个不同的编 解码器AMR编解码器或者8000Hz上的EVRC编解码器，如行426与"8 中所示。
-在行430中提供端口 5560上的RTCP。
隱对于TBCP，在行434中提供几种选项。 2.对于集中在控制PoC功能上的代码转换方案的PoC信令流 PoC规格描述了可能包含几种邀请方法的几种会话，其在开放移动联盟(OMA)制定的PoC规格中描述，此处为了简洁不进行描述。本领域技术人 员能够以直接的方式将本发明用于PoC标准支持的所有情况。
在本发明的第一非限定行示范实施例中，考虑代码转换方案集中在控制 PoC功能上的情况
2.1在会话流中控制PoC功能的角色
在图3所示的本发明的第一非限定行示范实施例中，除讲话许可权之外， CPF 310还管理整个代码转换处理。不管所建立的PoC组会话的类型如何， CPF 310具有两项主要责任
1. 保证用户之间的适当的会话提议以及设置
因为PoC用户可能具有具有不兼容的格式/编解码器，所以CPF310可能 必须改变对各个用户的SDP 400 (参见图4 ),以包含其在组会话期间能够使
器。例如，仅支持AMR的用户将无法与仅支持EVRC的用户建立直接会话。 支持AMR-EVRC的代码转换的CPF将在会话提议中包含AMR与EVRC两 者。在图5的系统500中显示，其大概显示了保证适当会话提议的CPF角色。 在图5的例子A)中，通过CPF 502 (其不更改邀请的会话描述)，仅支持 AMR音频编解码器的终端504用会话描述(未显示)邀请仅支持EVRC音频 编解码器的终端506来通信会话。然后终端506生成错误"4xx Request Failure",因为其无法支持所提议的AMR音频编解码器。在例子B)中，通 过CPF 512 (现在其更 文邀请的会话描述以符合终端510的能力)，仅支持 AMR音频编解码器的终端508用会话描述(未显示)邀请仅支持EVRC音频 编解码器的终端510来通信会话。虽然终端508发出的邀请的会话描述仅包 含AMR音频编解码器，由于CPF 512扩展了会话描述从而也包含终端510 的EVRC音频编解码器，所以终端510将发出200 OK响应(其中以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中显示第一种Jf某体流动方案，此时代码转换集中 在CPF 602上，并且其中所有的媒体分组在代码转换服务器(TS )之前到达 CPF 602。来自利用AMR编解码器的终端606的用户希望与来自利用EVRC 编解码器的终端608的用户通信以及交换+某体流。终端606在i某体流动610 中向CPF 602发送实时协议(RTP)上的AMR分组。在媒体流动612中， CPF 602发送这些RTP上的AMR分组给TS 604，以进行适配与代码转换。 在i某体流动614中，TS 604将适配的RTP上的EVRC分组返回给CFP 602, 然后，在i某体流动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分组，并且在i某体流动710中，将如 此适配的RTP上的EVRC分组发送给终端712。包含TB请求与响应的媒体 流动714仅通过TS 704在终端706与CFP 702之间传送。更具体地，TS 704 将i某体流动714的进入的分组转发给^ 某体流动716的外出的去向CFP 702的 分组。并且TS 704将媒体流动716的来自CFP 702的进入的分组转发给4某体 流动714的外出的去向终端706的分组。以同样的方式，终端712与CFP702
可以^又通过TS 704相互交换TB请求与响应。
因此，TS 704将到达其TBCP端口的TBC分组转发给CFP 702,同时其 代码转换通常媒体流，并且将其发送给其目的地，例如到终端712。 CFP702 管理到达其TBCP端口的TBC消息，并且将响应返回给TS 704, TS 704将 其转发给其目的地，或者可替换地，CFP 702直接将响应返回到其目的地。
图7的体系结构700被认为是优选媒体流动方案，这是因为其要求TS704 与CPF 702之间的分组的流动4交少。
2.3控制PoC功能管理的会话控制
除上述i某体流动之外，还必须管理/提供会话控制流。会话控制流在图8 中显示，并且由CPF 802控制，其还管理会话本身。会话可能会影响媒体流 动。实际上，在设置通信会话之后，当会话参数改变时，例如由于用户加入 或者离开，或者当不同的用户具有讲话许可权时，CPF 802必须通知TS 804 该情况，从而可以对i某体流进行适当的代码转换以及路由传送。
更具体地，图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地址以及端口信息 与格式/编解码器信息一起返回给CPF802。在该特定例子中，将EVRC编解 码器添加到列表中。
4. 在消息815中，CPF 802将具有改进的媒体格式/编解码器以及IP地址 与端口信息的邀请转发给一皮邀请的终端808。
5. 在目的地为CPF 802的消息816中，终端808接受具有其自己支持的 解码器(在该例子中为EVRC)的邀请。
6. 当收到消息816时，在消息818中，CPF 802请求TS 804根据4妄受了 邀请的被邀请终端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,则在TS 804中被代码转换之前，分组 首先到达CPF 802。
在以下描述的图10中，以详细的信令流提供了更多的细节。 现在参照图9,体系结构900当用户例如906请求讲话许可斥又时在CPF
902、 TS904、以及用户906与908之间发生的控制流的例子。 一般地，假设
开始没有用户有讲话许可权。步骤如下
1. 终端906通过发出TB (讲话猝发)请求消息901，请求讲话许可权。 在该例子中，假设图7的媒体流动，但是本领域技术人员可以容易地设想用 于根据图6的媒体流动的适当的消息流。
2. TB请求消息901到达TS 904,并且在消息912中被转发给CPF 902。
3. 在消息914中，CPF 902通知TS 904用户终端906正在请求讲话许可 权，从而TS904可以适当地相应分配代码转换资源，并且实施对々某体流的适 当控制。
4. 在TS 904在消息916中向CPF 902确认准许该请求之后，CPF 902通 过发送TB确认消息918给TS 904 ，通知用户终端906其讲话请求被准许， TS卯4在消息920中将该TB确认消息918转发给用户终端906。
5. 然后，在^ 某体流动922中，用户终端906可以开始发送RTP传输上的 AMR分组。
6. 媒体流动922到达TS 904。 TS 904将媒体信息/人AMR代码转换为 EVRC格式，然后在媒体流动924中，将代码转换的媒体发送给用户终端908。
7. 然后，在媒体流动926中，对于媒体924的RTCP报告(例如终端908 接收的分组的数目)祐:/人终端908发送给TS卯4。
8. 在媒体流动928中，对于媒体922的RTCP报告被从TS 904发送给用
户906。
使用AMR与EVRC编解码器仅是为了说明在体系结构900中要执行的 操作，但是体系结构900不限于此。体系结构900可以支持各种格式/编解码 器以及格式/编解码器的组合，包括音频视频格式/编解码器的组合，例如 AMR、 EVRC、 H.263、 MPEG-4部分2、 MPEG-4部分10等等。例如，体系
另外，在本应用中，仅仅出于说明目的，在TS 904与CPF 902之间流动TB (请求/确认)消息。在本发明的其他修改与实施例中，对于此类操作，可以 使用IP交换机，以将此类消息直接路由传送给CPF792,而不必经过TS904。 2.4用于适配集中在CPF上的详细信令流
现在参照图10,描述了集中在CPF上的代码转换方案的详细信令流。可 以考虑几种组会话情况及其变体。但是，这将使本说明书阅读起来非常烦瑣， 也没有提供任何附加好处。因此，将描述配备有对应的详细信令流的代表性 使用情况。本领域技术人员可以直接方式将该信令流应用于所有其他情况。
在下文中，将描述"利用在PoC规格中描述的手动回答命令上会话的确 认指示，，的情况。将不描述关于SIP/IP核心的信令细节，这是因为本领域技 公知，并且只会增加流动的复杂性而没有任何益处。另外，考虑所有i某体分 组到达TS的情况。但是，本领域技术人员可以直接方式考虑其都到达CPF 的情况。
图10显示对于代码转换方案集中在CPF上、并且其中所有媒体流都到 达TS的情况的、在CPF 1002、 TS 1004、用户终端1006与1008及其相应PPF 1010与1012之间的详细信令流的示范性实施例1000。
0. PoC用户1006按压对应PoC终端的PoC按钮，以发起组会话。
1. 通过这样做，在消息1014中，用户1006发出包含SDP信息(标记为 SDP-A )的SIP INVITE方法。SIP INVITE首先到达用户1006的网络中的PPF 1010 (例如其归属PPF )。例如，作为非限定性例子，SDP-A可以包括
c=IN IP6 FF1E:03AD::7F2E:172A:1E24 m= audio 3456 RTP/AVP 97 a= rtpmap: 97 AMR a= rtcp:5560
m= application 2000 udp TBCP
19
a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
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地址为IP6 FF1E:03AD::7F2E:172A:1E28，则如下提供使用SDP的信息(尽管4妄口不需 要使用SDP ):
c =IN IP6 FF1E:03AD::7F2E:172A:1E28 m= application 2002 udp TBCP
另外，设置代码转换操作一般调用两个TSAPI (应用程序接口 )方法 i) SetupTranscodingSession(SDP-A, SDP-CPF)以及 ii) AddInvitee(Session ID)。
i) 该第一方法发起新的代码转换会话。其建立新的会话ID上下文，并且 记住用来^f吏其所有i某体到达用户1006与CPF 1002的IP地址与端口 。其还记 住用户1006 (即发出邀请方)支持的媒体格式/编解码器与协议。该方法返回 会话ID。在图11中的点虚线1110中显示了用户1006的TS 1004内的^f呆留处 理。
ii) 该第二方法向会话ID提供邀请新参加者信息。该方法返回用户ID与 用户可以向其发送i某体流、并且其中CPF 1002可以通过TS 1004向该用户发 送TB响应的IP地址和端口 。所有信息在会话ID的上下文中更新。
4. 然后，TS 1004将在消息1020中向CPF 1002返回以下信息 对于消息1018中的对于SetupTranscodingSession(SDP-A, SDP-CPF)的调
用，其将返回会话ID用于将来引用。
对于对AddInvitee(SessionID)的调用，其将返回(如图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/訓0
a= rtcp:53080
m= application 50000 udp TBCP a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l 以及ii)对于从CPF 1002发送TB响应 c =IN IP6 FF 1E:03AD::7F2E: 172A: 1E30 m=application 53458 udp TBCP 请注意每次CPF 1002希望要求新用户到会话时，其将必须调用 Addlnvitee(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中，向其PPF 1012发送 SDP-AB，中的选定媒体信息。例如，SDP-AB，可以包括
c= INIP6FF 1E:03 AD: :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=l; tb_priority=2; timestamp=l
12. 在消息1036中，PPF 1012将消息1034转发给CPF 1002。
13. 然后，在消息1038中，CPF 1002联系TS 1004更新代码转换会话。 该请求实际涉及以下两种TS API方法
陽Join(SessionID，UserID, 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, User ID， SDP-AB，， SDP-CPF) 的请求的状态。通常，该状态报告成功地将新用户添加到会话，或者没有添 加该新用户的原因。
在消息1038中进行的调用Acceptlnvite(Session ID， SDP-AB，， SDP-CPF) 的返回参数，包括其中用户1006可以发送其々某体流以代码转换为其他参加 者的格式的地址/输入端口的列表，要使用的格式/编解码器，其中CPF 1002 可以向TS 1004发送对于用户1006的讲话猝发响应的地址/输入端口的列表。 TS 1004将利用如下SDP提供信息，在图11中在长划线1114中显示(尽管 接口不需要使用SDP):
i) 对于在会话期间向用户1006发送数据 c=IN IP6 FF1E:03AD::7F2E:172A:1E3 m= audio 48456 RTP/AVP 97
a= rtpmap: 97 AMR a= rtcp: 48080
m= application 48000 udp TBCP
a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
ii) 对于发送来自CPF 1002的TB响应 c=IN IP6 FF1 E:03AD::7F2E: 172A: 1E30 m= application 48400 udp TBCP
15. 来自TS 1004的信息响应由CPF 1002处理，然后在消息1042中， CPF 1002通过其PPF 1010发送对于发出邀请的一方1006的修改后的邀请 SDP-AB*。其基本包含要使用的媒体格式/编解码器，以及其中发送媒体流的 IPJ也址与端口。
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，确iU亥许可斗又。
19. 在消息1050中，CPF 1002通过其PPF 1010发送目的地为用户1006 的讲话猝发确认。
20. 在消息1052中，PPF IOIO发送讲话猝发确认给用户1006。
21. 在通知1054中，授予用户1006讲话的权利。
22. 在消息1056中，CPF 1002通过其PPF 1012发送接收讲话猝发消息 给用户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,以及向TS 1004提供CPF 1002的IP地址 与端口作为输出目的地。
26. 然后，TS 1004知道用户1006具有讲话的权利，并且在操:作1066 中，将々某体流/人AMR代码转换为EVRC。
27. 然后，在i某体流动1068中，TS 1004向用户1008发送代码转换为 EVRC的分组。
28. 用户释》文PoC4姿钮。
29到41.剩余步骤为通常PoC操作，不需要进一步解释，其涉及代码转 换用户终端1006发送的最后分组，以及结束i某体流传送，其由讲话猝发空闲 通知指示，在用户1006释放PoC按钮之后。
但是，随后由用户1006与1008之一重新按压PoC按钮将如以上所述地 处理，例如通过图10的操作1046 (利用来自希望发送媒体流用户的讲话猝 发通知)到1076 (用于发送和代码转换々某体流)，以允许所述的一个用户将 媒体流传送给(多个)其他参加者。操作1070到1094描述了当所述一个用 户释放PoC按钮时在信令流中发生的情况。
图11的々某体流动体系结构IIOO显示了在代码转换方案集中在CPF 1102 上的情况下通过CPF 1102与TS 1104的媒体流动的路由传送。用于从发出邀 请的终端1106发出的+某体的TS 1102上的输入IP地址与端口 、以及从CPF 1102到终端1106的TBCP消息在长划线1114中显示。来自终端1106的输入 IP地址与端口被映射到各种类型的媒体流动，例如编解码器、RTCP以及
TBCP，如在i某体流动1114中所示。类似地，用于从被邀请的终端1108发出 的i某体的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地 址与端口在图ii中在实线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之前调用Addlnvitee(Session ID),并且一旦用户接 受了则必须调用Join(Session ID, User ID， SDP-AB，， SDP-CPF)。当参加者离开 会话时，考虑到离开会话的用户ID, CPF 1102必须调用Leave(Session ID， User ID)，其更新会话ID。
-所有媒体分组到达CPF 1102的情况该替换情况在以上参照图IO讨论。 会话发起处理要做的就是向用户提供不同的地址与端口 ，其指向CPF 1002而 非TS 1004，并且向TS 1004提供CPF 1002 IP地址与端口作为输出目的地。 另外，当向TS 1004提供媒体信息时，会话描述中没有TBCP媒体部分，这 是因为其完全由CPF 1002管理。应该注意，这是PoC应用中假设的"安全" 情况，如在[1]9.12小节中所述，其中所有的i某体流动必须经过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 上进行代码转换。
参加与控制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 (其
此类流(为发出邀请的终端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不进行代码转换。PPF 1230—般为被邀请的终端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所示，但是具有以下^f务改替代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上的适配的详细的4言令流
对于在PPF上进行代码转换的情况下的详细信令流非常类似于代码转换 集中在CPF上的情况。图IO保持相同，只是与代码转换服务器的交互将在 每个被邀请方的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的AMRJ某体在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,以简化描述，但是不丧失一4殳性。在下文中，描 述在重新确定力某体流的路由程序中从CPF 1402到TS 1404的会话提议变化 (例如提议的格式/编解码器)。信令流如下
1. 在操作1410中，PoC用户1405按压PoC按钮，以发起组会话。
2. 在消息1412中，PoC用户1405发出包含利用SDP信息的会话描述的 SIP INVITE方法。SIP INVITE被TS 1404截获，TS 1404可以例如位于与CPF 1402相同的网络中。例如，SDP-A可以包括
c = INP6 FF1E: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=l; tb_priority=2; timestamp=l
3. TS 1404改变用户1405提供的格式/编解码器以及IP地址和端口信息， 从而目的地为用户1405的任何々某体流都在被传送给用户1405之前，首先到 达TS 1404 (参见图15中的点线)。其还存储新提议的SDP与用户开始提议 的SDP之间的绑定信息。另外，TS 1404通过添加其可以支持来自与去向用 户1405提议的媒体格式/编解码器的代码转换的媒体格式/编解码器，来改进 会话描述。然后，在消息1414中，TS 1404向CPF 1402发送具有更新的SDP 会话描述的邀请。例如，TS 1404提供的SDP可以为
c=IN IP6 FF1E:03AD::7F2E:172A:1E30 m= audio 18456 RTP/AVP 97 98a=rtpmap: 97 A歐
a= rtpmap: 98 EVRC/8000
a=rtcp: 18080
m= application 18000 udp TBCP a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l 请注意在行"c-"中将IP地址从用户1405替换为TS 1404，并且在行"a-" 中添加了 EVRC编解码器。
4. CPF 1402接收SDP会话描述，对其进行修改从而使媒体流首先经过自 己。然后，在消息1416中，CPF 1402将修改后的邀请发送给用户1406。 CPF 1402还知道IP地址与端口的映射，因此其可以将进入的分组转发给正确的目 的地。例如，其可以如图15所示(参见短划线)
c =IN IP6 FF1E:03AD::7F2E:172A:1E28 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=l; tb_priority=2; timestamp=l
5. 更改消息1418被从用户1406发送给TS 1404。
6. 更改消息1420 ^皮/人TS 1404发送给CPF 1402。
7. 更改消息1422被从CPF 1402发送给用户1405。
8. 用户1406接受邀请，并且在消息1424中，在SDP-AB，中提供选定媒 体信息。该请求由TS 1404截获。例如，SDP-AB，可以包括
c=IN IP6 FF1E: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=l; tb_priority=2; timestamp=l
9. TS 1404保留代码转换资源与端口 ，并且在消息1426中，向CPF 1402 提供修改后的SDP会话。例如，该SDP可以为c=IN IP6 FF1E: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=l; tb_priority=2; timestamp=l
10. 该信息响应被CPF 1402进一步修改，以将其自己首先包括在媒体路 径中。然后，在消息1428中，CPF 1402将修改后的响应发送给用户1405。 例如，该SDP可以为
c=INIP6 FF1E:03AD::7F2E:172A:1E28
m=audio 48456
a= rtpmap: 98 EVRC/8000
a= rtcp:48080
m= application 48000 udp TBCP
a= fmtp:TCBP queuing=l; tb_priority=2; timestamp=l
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"通知发送i合用户1406。
17. 在来自用户1405的流动中发送的i某体分组达到CPF 1402,这是因为 其为々某体路径中的第一个(参见图15中的长划线)。
18. CPF 1402按照需要复制收到的媒体流，并且在媒体流动1444中，将 复制的媒体流转发给TS 1404。
19. 在操作1446中，TS 1404代码转换流。
20. 在媒体流动1448中，TS 1404将适配和代码转换的媒体流转发给用
户1406。
21.剩余的信令流就明白了。当用户1406讲话时，从用户1406到用户 1408的i某体流动在图15中在短划线和点线中显示。
当会话中涉及多个终端时，对于每个参加终端，以类似的方式(从而CPF 1402为路径中的第一个，并且TS 1404为下一个)，CPF 1402与TS 1404进 行SDP》务改，以^修改i某体流的3各径。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服务范围中的实现，而不是要以任何方式限定本发明的范围。
虽然通过非限定性示范实施例上以上说明书中描述了本发明，但是在权 利要求的范围内，可以对这些实施例进行修改，而不会脱离本发明的精神与 实质。 参考资料 开》文移动联盟，"Push to Talk Over Cellular (PoC) - Architecture. OMAAD-PoC-VI —0-20041117-D."3GPP TS 26.235， "Packet switched conversational multimedia applications; Default codecs (Release 6)."3GPP2 S.R0100—0， "Push to Talk Over Cellular (PoC) System Requirements."3GPP TS 23.228， "IP Multimedia Subsystem (IMS); Stage 2."3GPP TS 24. 229， "IP Multimedia Call Control based on SIP and SDP; Stage 3."3GPP2 X. S0013. 2， "IP Multimedia Subsystem (IMS); Stage 2."3GPP2 X. S0013.4， "IP Multimedia Call Control Protocol, Based on SIP and SDP stage 3." 3GPP TS 23, 218， "Multimedia (IM) session handling; stage 2." IETF RFC 3435， "Media Gateway Control Protocol; version 1." IETF RFC 3525， "Gateway Control Protocol; version 1." ITU Recommendation H.248， "Gateway control protocol." E. Burger and Guy Redmill, "Media Services in the IMS: Evolution for Innovation, " "rooKrowt力rec力/ o/c^/， May 2005. IETF RFC 2327， "SDP: Session Description Protocol."开力文移动联盟，"Push to Talk Over Cellular (PoC) - Control Plane Document. 0MA-TS-PoCControlPlane-V1 — 0."开i丈移动联盟，"Push to Talk Over Cellular (PoC) — User Plane. OMA-TS—PoC—UserPlane-Vl_0."
权利要求
1. 一种用来建立在具有非兼容媒体特性的终端之间的、具有会话描述的多用户通信会话的方法，该方法包括邀请具有非兼容媒体特性的终端的用户参加所述通信会话；设置代码转换会话，使之能够根据关于接受了邀请的用户的终端的信息，进行所述终端的非兼容媒体特性之间的代码转换，所述信息包含该用户的终端的媒体特性；根据所述代码转换会话，建立所述会话描述；以及在所述通信会话期间，利用参加所述通信会话的其他用户的终端的媒体特性，根据所述代码转换会话，对来自一个用户的终端的媒体流进行代码转换，并且根据所述会话描述，将代码转换的媒体流发送给所述其他用户。
2. 如权利要求l所述的方法，其中所述邀请具有非兼容媒体特性的终端 的用户参加通信会话包括从第 一用户向中心网络元件发送具有所述会话描 述的邀请请求。
3. 如权利要求2所述的方法，其中所述会话描述包括对第一用户的终端所支持的至少 一 个々某体特性的描述。
4. 如权利要求3所述的方法，其中所描述的所支持的々某体特性为特定编 解码器。
5. 如权利要求2所述的方法，其中所述设置代码转换会话包括从所述 中心网络元件接收通过代码转换服务器设置所述代码转换会话的请求。
6. 如权利要求5所述的方法，其中所述设置代码转换会话进一步包括 建立代码转换资源以及经过所述代码转换服务器的々某体流流动。
7. 如权利要求6所述的方法，其中所述建立代码转换资源包括提供包含 以下元素中的至少一个元素的代码转换会话信息会话标识、所述代码转换 服务器支持代码转换的格式与编解码器的列表、以及允许媒体流流经所述代 码转换服务器的IP地址与端口的列表。
8. 如权利要求7所述的方法，其中所述设置代码转换会话使之能够根据 接受了邀请的用户提供的信息进行非兼容媒体特性之间的代码转换进一步包 括利用接受了邀请的用户的终端的会话标识、IP地址与端口、以及格式与 编解码器，更新所述代码转换会话信息。
9. 如权利要求8所述的方法，其中所述更新代码转换会话信息进一步包 括根据每个接受了邀请的用户提供的信息，更新所述代码转换资源以及所 述经过所述代码转换服务器的媒体流流动。
10. 如权利要求9所述的方法，其中所述更新代码转换资源以及媒体流 流动包括确定要执行的代码转换操作以及代码转换的々某体流要送往的端口 和IPi也址。
11. 如权利要求8所述的方法，其中所述建立会话描述包括根据更新 的代码转换会话信息，更新所述会话描述。
12. 如权利要求6所述的方法，其中所述建立媒体流流动包括建立讲 话猝发分组与々某体分组流动。
13. 如权利要求12的方法，其中所述讲话猝发分组包括所述用户与中 心网络元件之间的讲话请求与响应。
14. 如权利要求13的方法，包括向所述代码转换服务器提供所有媒体 流流动。
15. 如权利要求14的方法，其中所述媒体分组在所述代码转换服务器上 进行代码转换，并且所述讲话猝发分组被转发给所述中心网络元件。
16. 如权利要求14的方法，进一步包括向所述中心网络元件提供所有 媒体流流动。
17. 如权利要求16的方法，其中只有所述媒体分组被转发给所述代码转 换服务器进行代码转换。
18. 如权利要求6的方法，进一步包括通过所述中心网络元件，管理 所述纟某体流流动、通信会话流动、以及代码转换程序。
19. 如权利要求18的方法，其中所述代码转换程序进一步由用户终端所 在的本地网络管理，并且讲话许可权由所述中心网络元件管理。
20. —种用来建立在具有非兼容々某体特性的终端之间的、具有会话描述 的多用户通信会话的系统，该系统包括用来邀请具有非兼容媒体特性的终端的用户参加所述通信会话的部件； 用来设置代码转换会话，使之能够根据关于接受了邀请的用户的终端的信息，进行所述终端的非兼容媒体特性之间的代码转换的部件，所述信息包含该用户的终端的i某体特性；用来根据所述代码转换会话，建立所述会话描述的部件；以及 在所述通信会话期间，用来利用参加所述通信会话的其他用户的终端的 媒体特性，根据所述代码转换会话，对来自一个用户的终端的媒体流进行代 码转换，并且根据所述会话描述，将代码转换的媒体流发送给所述其他用户 的部件。
21. —种用来建立在具有非兼容媒体特性的终端之间的、具有会话描述 的多用户通信会话的系统，该系统包括网络元件，用来邀请具有非兼容々某体特性的终端的用户参加所述通信会话；代码转换服务器，用来设置代码转换会话，使之能够根据关于接受了邀 请的用户的终端的信息，进行所述终端的非兼容媒体特性之间的代码转换，所述信息包含所述用户的终端的々某体特性； 其中所述代码转换服务器根据所述代码转换会话，建立所述会话描述；以及 在所述通信会话期间，所述代码转换服务器利用参加所述通信会话的其 他用户的终端的媒体特性，根据所述代码转换会话，对来自一个用户的终端 的媒体流进行代码转换，并且根据所述会话描述，将代码转换的媒体流发送 给所述其他用户。
22. 如权利要求21所述的系统，其中所述网络元件为中心网络元件。
23. 如权利要求22所述的系统，其中所述中心网络元件管理媒体流以及 通信会话流动。
24. 如权利要求22所述的系统，其中所述中心网络元件从第一用户接收 邀请请求。
25. 如权利要求24所述的系统，其中所述会话描述包括第一用户所支持 的至少一个媒体特性。
26. 如权利要求25所述的系统，其中所支持的媒体特性为特定编解码器。
27. 如权利要求22所述的系统，其中所述代码转换服务器从所述中心网 络元件接收设置所述代码转换会话的请求。
28. 如权利要求27所述的系统，其中所述代码转换服务器进一步建立代 码转换资源以及经过所述代码转换服务器的媒体流流动。
29. 如权利要求28所述的系统，其中所述代码转换服务器进一步提供代 码转换会话信息。
30. 如权利要求29所述的系统，其中所述代码转换会话信息包含以下元 素中的至少一个元素会话标识、所述代码转换服务器支持代码转换的格式 与编解码器的列表、以及允许媒体流流经所述代码转换服务器的IP地址与端 口的列表。
31. 如权利要求30所述的系统，其中所述代码转换服务器进一步利用关 于接受了邀请的用户提供的关于该接受了邀请的用户的终端的信息，更新所 述代码转换会话信息。
32. 如权利要求31所述的系统，其中所述代码转换服务器进一步根据接 受了邀请的用户提供的信息，更新所述代码转换资源与媒体流流动。
33. 如权利要求32所述的系统，其中在所述代码转换会话期间，所述代 码转换服务器确定要执行的代码转换操作以及代码转换的媒体流要送往的端 口和IP地址。
34. 如权利要求32所述的系统，其中所述代码转换服务器根据所述代码 转换会话信息，更新所述会话描述。
35. 如权利要求21所述的系统，其中所述网络元件包括每个参加所述多 用户通信会话的用户的本地网络元件。
36. 如权利要求35所述的系统，其中所述代码转换服务器包括多个代码 转换服务器，其中每个代码转换服务器连接到参加所述通信会话的相关用户 的相应本地网络元件。
37. 如权利要求36所述的系统，其中所述每个参加通信会话的用户的本 地网络元件管理与其相关的代码转换服务器。
38. 如权利要求37所述的系统，包括管理讲话许可权与i某体流动的中 心网络元件。
39. 如权利要求35所述的系统，包括用来将来自第一用户的邀请请求 提供给该第一用户的本地网络元件的部件。
40. 如权利要求39所述的系统，其中所述会话描述包括第一用户支持的 至少一个媒体特性。
41. 如权利要求40所述的系统，其中所支持的々某体特性为特定编解码器。
42. 如权利要求35所述的系统，其中所述代码转换服务器从第一用户的 本地网络元件接收设置所述代码转换会话的请求。
43. 如权利要求42所述的系统，其中所述代码转换服务器进一步建立代 码转换资源以及经过所述代码转换服务器的々某体流流动。
44. 如权利要求43所述的系统，其中所述代码转换服务器进一步提供代 码转换会话信息。
45. 如权利要求44所述的系统，其中所述代码转换会话信息包含以下元 素中的至少一个元素会话标识、所述代码转换服务器支持代码转换的格式 与编解码器的列表、以及允许媒体流流经所述代码转换服务器的IP地址与端 口的列表。
46. 如权利要求45所述的系统，其中所述代码转换服务器进一步利用接受了邀请的用户提供的关于所述接受了邀请的用户的终端的信息，更新所述 代码转换会话信息。
47. 如权利要求46所述的系统，其中所述代码转换服务器进一步根据接 受了邀请的用户提供的信息，更新所述代码转换资源以及々某体流流动。
48. 如权利要求47所述的系统，其中在所述代码转换会话期间，所述代 码转换服务器确定要执行的代码转换操作以及代码转换的媒体流要送往的端 口和IPi也址。
49. 如权利要求24所述的系统，其中所述代码转换服务器截获从第一用 户到所述中心网络元件的邀请请求。
50. 如权利要求49所述的系统，其中所述代码转换服务器进一步作为在 所述中心网络元件与第 一用户之间的通信路径中的代理服务器。
51. 如权利要求50所述的系统，其中所述代码转换服务器独立于所述中 心网络元件以及第 一用户的本地网络元件。
52. 如权利要求49所述的系统，其中所述代码转换服务器进一步建立代 码转换资源以及流经所述代码转换服务器的媒体流流动。
53. 如权利要求52所述的系统，其中所述代码转换服务器进一步提供代 码转换会话信息。
54. 如权利要求53所述的系统，其中所述代码转换会话信息包含以下元 素中的至少一个元素会话标识、所述代码转换服务器支持代码转换的格式 与编解码器的列表、以及允许々某体流流经所述代码转换服务器的IP地址与端 口的列表。
55. 如权利要求54所述的系统，其中所述代码转换服务器进一步利用接 受了参加所述通信会话的邀请的用户提供的信息，更新所述代码转换会话信
56. 如权利要求55所述的系统，其中所述代码转换服务器进一步根据接受了参加所述通信会话的邀请的用户提供的信息，更新所述代码转换资源与媒体流流动。
57. 如权利要求56所述的系统，其中在所述代码转换会话期间，所述代码转换服务器确定要执行的代码转换操作以及代码转换的媒体流要送往的端口和IP地址。
58. 如权利要求49所述的系统，其中所述代码转换服务器使用IP交换机来截获来自所述中心网络元件的消息。
59. 如权利要求28所述的系统，其中所述媒体流包括讲话猝发分组与媒体分组。
60. 如权利要求59所述的系统，其中所述讲话摔发分组包括在所述用户与网络元件之间交换的讲话请求与响应。
61. 如权利要求59所述的系统，包括用来向所述代码转换服务器提供所有媒体流的部件。
62. 如权利要求61所述的系统，其中所述代码转换服务器对所述媒体分组进行代码转换，并且将所述讲话猝发分组转发给所述网络元件。
63. 如权利要求61所述的系统，包括用来向所述中心网络元件提供所有媒体流的部件。
64. 如权利要求63所述的系统，包括用来仅将媒体分组转发给所述代码转换服务器进行代码转换的部件。
65. 如权利要求62所述的系统，其中所述中心网络元件通知所述代码转换服务器哪个参加的用户具有讲话许可权。
66. 如权利要求62所述的系统，其中所述代码转换服务器通过查看所述讲话猝发分组，来导出哪个参加的用户具有讲话许可权。
全文摘要
一种用来建立在具有非兼容媒体特性的终端之间的、具有会话描述的多用户通信会话的方法与系统，其中邀请具有非兼容媒体特性的终端的用户参加通信会话。设置代码转换会话，使之能够根据关于接受了邀请的用户的终端的信息，进行终端的非兼容媒体特性之间的代码转换，信息包含该用户的终端的媒体特性。根据代码转换会话，建立会话描述；以及在通信会话期间，利用参加通信会话的其他用户的终端的媒体特性，根据代码转换会话，对来自一个用户的终端的媒体流进行代码转换，并且根据会话描述，将代码转换的媒体流发送给其他用户。
文档编号H04W88/18GK101390415SQ200680053567
公开日2009年3月18日 申请日期2006年12月27日 优先权日2005年12月28日
发明者斯蒂法妮·库隆比 申请人:梵提克斯公司