改进的编解码器协商的制作方法

专利名称：改进的编解码器协商的制作方法
技术领域：
本发明涉及电信中的改进。本发明在使cs (电路交换)视频呼叫 向使用IP多媒体协议的视频呼叫交互工作的方式中有着特定的应用。
背景技术：
本说明书中使用了各种缩写。这些缩写在说明书结尾处列出并解释。
参照图1，今天的3G视频电话支持两个移动客户端之间以及3G 移动终端1与IP客户端2之间的呼叫情形。支持的视频电话服务包括 交互式呼叫、流传送门户、碎见频邮件及多方呼叫。
使用的通信协议是3G-324M标准，这是ITU-T H.324标准(用于 低比特率多媒体通信的终端)的修改，以使得在电路交换(CS)网络的 现有基础设施上能够实现3G对话多媒体服务。3G-324M架构由3GPP 在3GTS 26.111标准中定义。
该架构定义支持的音频和视频编解码器及用于建立多々某体通信的 控制信令协议(H.245)。控制信令通过使用H,223复用协议与音频和视 频》某体复用在一起。
CS与IP域之间的交互工作功能由CS-IP网关3处理。CS-IP网关 3可使用H.248架构来实现，其中，控制信令由々某体网关控制功能 (MGCF) 4处理，并且媒体由媒体网关(MG) 5处理。CS端点1经RAN 6与CS-IP网关3通信。
IP域中使用的控制信令可以是SIP、 H,323或RTSP,并且媒体可 使用RTP协议来传输。
已理解的是，3G视频电话服务可由于H.245呼叫建立过程导致诸如1和2等端点之间的相当大的信令的事实而遭遇长的呼叫建立时间。
ITU-T H.324标准的最近更新是引入附件K，其描述名为 MONA"定向媒体协商加速过程"的可选过程，包括用于在H.324呼叫 建立中大大降低延迟的三个补充方法(或协议)。这些方法是
快速信道建立机制MPC"媒体预配置信道"。此机制不等待能力 交换(即，端点不相互交换有关其能力的信息)，而是在此信 息可用时如果初始媒体传输尝试不符合远端的能力，则要求回 退。
灵活加速信道建立方法SPC"信令预配置信道"，其取决于优选 的初始交换和公共推理算法的执行。
在其它两种方法不适用的情况下，作为一种简单、合理的快速 技术的加速H.245建立方法ACP"加速的H.245过程"。
附件K定义了以下MONA终端类以指示特定终端实现支持三种 方法中的哪种方法
类I: SPC+MPC+ACP
类II: MPC+ACP
类m: SPC+ACP
图2示出包括MONA功能性的3G-324M标准的特征。 由于希望缩短用于CS-IP多々某体呼叫的呼叫建立时间，并且还希 望作为具MONA能力的终端之间交换的消息数量降低的结果而将 MGCF 4与MG 5之间的信令降到最低，因此，已考虑在CS-IP交互 工作网关3 (MGCF 4和MG 5 )中引入MONA支持。
本发明的主要焦点是在CS侧上使用任何MONA机制MPC、 SPC 或ACP (即，如果端点1是MONA类I、 II或III终端)时的CS-IP 交互工作。下面提供如附件K中指定的MONA过程的概述。在ITU-T更详细的描述，其通过引用结合于本文中。
如果终端支持MPC机制，则此机制可在CS侧上使用。根据MPC 机制， 一旦CS承载已建立，则CS终端开始发送包括每方向MPC编 解码器优选的优选消息。CS终端也可在接收远程终端的MPC能力的 任何信息之前在任何预配置的MPC信道上开始发送i某体。如果远程 终端支持MPC和CS终端优选的编解码器，则信道成功建立。
如果终端支持SPC机制，则此机制可在CS侧上使用。根据此机 制， 一旦CS承载已建立，CS终端将使用SPC发送其MOS (定向媒 体建立)请求(参见图3) 。 MOS请求传输将重复进行，直到检测到 MOS请求确认(requestAck)或满足回退条件之一。
当MOS请求已检测到并从MOS SPC成功解码时，终端通过开始 媒体数据的传输和处理来接受它。MOS请求确认将在接收每个MOS 请求时发送。
如图3所示，如果MOS成功完成，则打开的逻辑信道立即操作。 MONA回退在附件K的K.7.2中指定。下面另外的条件也将从 MOS启动回退
MOS过程完成后带有空genericControlCapability、包含 MOS OID的常规H.245 TerminalCapabilitySet消息。
在多个网络往返延迟(RTD)期间内，例如，在三个RTD 内，终端未^r测到有效的MOS请求，或者不接受ICM。
由于本领域的技术人员熟悉此方面，因此，此处未提供ACP机制
的概述。
支持MONA的CS-IP交互工作功能3的一个主要目的是促进端点 1、 2之间的端对端编解码器协商以便实现最佳的可能媒体质量。支持 端对端编解码器协商也将最少地利用交互工作网关3中昂贵的译码资 源。
已理解的是,.MONA与IP端点(即，SIP、 H.323或RTSP端点) 之间经CS-IP网关的呼叫信令交互工作对于使用MPC和SPC的CS
10终端发起的呼叫是有问题的。由于一旦在支持的预配置信道上收到媒
体便立即打开々某体信道，因此，在MPC情况下出现问题。由于SPC 过程具有严格的时序约束，因此，在SPC情况下出现问题。
现在将更详细地解释在SPC情况下遇到的问题。如H.324附件K 中所述， 一旦CS承载建立，具SPC能力的端点便将发送其MOS请 求。如果端对端编解码器协商要发生，这对于CS->IP呼叫尤其有挑 战性。
图4和6示出两个CS-〉IP的呼叫序列，示出根据现有技术能如何 在MONA SPC端点(例如1 )和SIP端点(例如2 )之间建立呼叫的 两个备选信令交互工作示例，并且图5(类似于图4)示出一个CS-〉IP 的呼叫序列，其示出根据现有技术能如何在MONAMPC端点(例如 1)和SIP端点(例如2)之间建立呼叫的信令交互工作示例。
在图4和5的CS到IP的呼叫建立示例序列中，完成MONA SPC 协商和MONA MPC协商而不需知道SIP端点的编解码器能力，即， SIP端点的编解码器能力在MONA SPC或MPC协商期间不被考虑， 其完全在CS侧发生(图4中的步骤4到7;图5中的步骤4和5)。
如果SIP端点不支持此编解码器，则将要求CS-IP网关译码。
由于SIP协商在CS承载建立前启动，因此，图6所示的信令交 互工作示例包括某一形式的端对端编解码器协商。随后，SIP端点优 选的编解码器(在图6的步骤9中传递)用作MONA MPC/SPC协商 (步骤4到7 )的步骤4中的优选。如果MONA端点不接受IP侧上 的选定编解码器，则SIP重新协商必须启动(步骤8a和9a)，可能 导致必须部署CS-IP网关内的译码资源。图6中仅示出SPC协商，即， 此示例的交互工作网关充当MONA类III终端。本领域的技术人员将 明白如何为MPC协商的目的修改此示例
发明内容
发明人认识到图4到6中所示的与现有4支术有关的上述缺陷。本 发明的产生是为了解决上述问题。本发明的至少优选实施例的目的是 提供一种机制以实现CS MONA端点与IP端点之间具有最少CS和IP 信令的端对端编解码器协商。
又一此类目的是^是供CS-IP交互工作功能方法以用于在MONA端 点与IP端点之间的CS到IP呼叫中实现端对端编解码器协商。在 MONA类I/III端点(使用SPC)的情况下，解决方案涉及在启动IP 编解码器协商前等待SPCMOS请求。更一般地说，无论MONA端点 的类型是什么，解决方案涉及在启动IP编解码器协商前等待CS侧编 解码器能力的指示。
提供一种将CS (电路交换)视频呼叫与使用IP多媒体协议的视 频呼叫交互工作的方法。才艮据该方法，作为MONA (定向Jf某体协商加 速)协商的部分，.交互工作功能接收包括CS视频呼叫中涉及的CS 终端的编解码器能力的指示的信令。此后，启动IP编解码器协商。并 且此后继续和/或完成MONA协商。因此，在和IP端点的IP编解码 器协商期间，能将CS终端的编解码器能力和/或优选考虑在内。
交互工作功能可包括相互合作的几个实体(如MGCF和MG)。
提供将CS (电路交换)视频呼叫与使用IP多媒体协议的视频呼 叫交互工作的另一方法，该方法包括端对端编解码器协商。端对端编 解码器协商涉及在交互工作功能，作为MONA协商的部分，接收包 括CS视频呼叫中涉及的CS终端的编解码器能力的指示的信令。此后， 启动IP编解码器.协商。同样地，由于此技术涉及端对端编解码器协商， 因此，在IP编解码器协商期间可将CS终端的编解码器能力考虑在内。
在端点之间实现端对端编解码器协商可有利于协商和使用具有最 高4某体质量的共同编解码器(例如，AMR-WB和H.264 )。它还可将 CS-IP交互工作网关中对昂贵的译码资源的利用降到最低。
设想信令包括所述CS终端的编解码器优选的指示。IP编解码器 协商包括交互工作功能与IP端点协商应该为特定呼叫使用哪些编解码器。作为此协商的部分，能将编解码器能力和/或在可用的情况下将 CS终端的编解码器优选考虑在内。
设想在收到信令之前建立CS承载。优选的是方法容忍IP编解码 器协商造成的延迟。
信令可包括SPC MOS请求，并且MONA协商可包括SPC协商。 优选的是，接收SPC MOS请求的确认使得SPC协商被视为是正
在进行中。此外，接收SPC MOS请求的确认可使得到非SPC的过程
的回退被禁止或推迟。
信令可包括MONA PM (优选消息)。
信令可包括MPC供应(offer),并且MONA协商可包括MPC 协商。优选的是，接收MPC供应的确认使得MPC协商被视为是在进 行中。优选的是，接收MPC供应的确认使得到非MPC的过程的回 退被禁止或推迟。
方法还可包括在交互工作功能接收MPC供应时，向CS终端发送 TDM空闲模式。它还可包括从信令检测CS终端充当的MONA终端 的类型。
方法可包括促^f吏到ACP的回退。这可包括交互工作功能向CS终 端发送MONA PM供应。此MONA PM可指示SPC支持而无任何MPC 编解码器供应。备选地，MONA PM可包括MPC编解码器供应而不 指示对SPC的支持。为促使到ACP的回退而由交互工作功能向CS 终端发送的MONA PM包括MPC编解码器供应，该供应是信令中包 括的MPC供应的反向副本。
设想仅在作为IP编解码器协商的部分、交互工作功能收到IP终 端的编解码器能力的指示后，它才向CS终端发送要用于特定呼叫的 编解码器的指示。
还提供一种用于使得CS (电路交换)视频呼叫能够与使用IP多 媒体协议的视频呼叫交互工作的设备。该设备布置成作为MONA协 商的部分,接收包括CS视频呼叫中涉及的CS终端的编解码器能力的
13指示的信令。此后，设备启动IP编解码器协商。并且此后，它继续和
/或完成MONA协商。
提供一种用于使得CS (电路交换)视频呼叫能够与使用IP多媒 体协议的视频呼叫交互工作的另 一设备。该设备布置成支持端对端编 解码器协商。为此，它布置成作为MONA协商的部分，接收包括所 述CS视频呼叫中涉及的CS终端的编解码器能力的指示的信令，以及 此后它启动IP编解码器协商。该i殳备例如可包括交互工作功能。
该设备可包括用于延迟向CS终端发送要用于特定呼叫的编解码 器的指示的部件。优选的是，延迟部件布置成仅当作为IP编解码器协 商的部分、它已接收IP终端的编解码器能力的指示后，才向CS终端 发送要用于特定呼叫的编解码器的指示。
还提供一种用于在电信系统中使用的终端。该终端能够支持 MONASPC。它包括用于在指定条件下、至少对于第一时间期间防止、 延迟或禁止到非SPC的呼叫建立机制的回退的部件，其中回退将在缺 少此类部件时不受防止、延迟或禁止。换而言之，回退一般将在一些 情况下发生，但由于终端中包括的该部件，并且仅仅是由于终端中包 括的该部件，只要满足指定条件，则至少对于第一时间期间防止、延 迟或禁止回退。
提供用于在电信系统中使用的另 一终端，该终端能够支持MONA SPC。当一个或多个第一条件满足时，终端布置成促使、启动或执行 到非SPC的呼叫建立机制的回退。然而，该终端包括用于当一个或多 个第二条件满足时、即使一个或多个第一条件满足、也至少对于第一 时间期间防止、延迟或禁止此类回退的部件。
例如，才是供一种用于在电信系统中使用的终端，该终端能够支持 MONASPC。该终端布置成在一个或多个条件满足时启动到非SPC的 呼叫建立机制的回退。然而，终端布置成在它已接收有效MOS请求 确认消息时至少对于第一时间期间不启动该回退。该终端布置成在它 已接收有效MOS请求确认消息时，即使一个或多个其它回退条件满足，也不启动该回退。
提供用于在电信系统中使用的另 一终端，该终端能够支持MONA SPC。终端布置成延迟MONA优选消息的确认的发送以便至少对于第 一时间期间防止、延迟或禁止到非SPC的呼叫建立机制的回退。
提供用于在电信系统中使用的另 一终端，该终端能够支持MONA SPC。终端布置成发送指示SPC协商已建立/启动和第一 MONA供应 未决的事实的信令。
提供用于在电信系统中使用的另 一终端，该终端能够支持MONA SPC。终端布置成接收指示SPC协商已建立/启动和第一 MONA供应 未决的事实的信令。在收到此类信令时，终端布置成至少对于第一时 间期间防止、延迟或禁止到非SPC的呼叫建立机制的回退。
还提供一种操作用于在电信系统中使用的终端的方法。终端能够 支持MONASPC。作为方法的部分，在一个或多个第一条件满足时， 终端促使、启动或执行到非SPC的呼叫建立机制的回退。然而，终端 在一个或多个第二条件满足时，即使一个或多个第一条件满足，也至 少对于第 一时间期间防止、延迟或禁止此类回退。
还提供操作用于在电信系统中使用的终端的另 一方法。终端能够 支持MONASPC。作为方法的部分，在一个或多个条件满足时，终端 布置成启动到非SPC的呼叫建立机制的回退。然而，终端在它已接收 有效MOS请求石角认消息时至少对于第一时间期间不启动回退。终端 在它已接收有效MOS请求确认消息时，即使一个或多个其它回退条 件满足，也不启动回退。
还提供操作用于在电信系统中使用的终端的另 一方法。终端能够 支持MONASPC。作为方法的部分，终端延迟MONA优选消息的确 认的发送以便至少对于第一时间期间防止、延迟或禁止到非SPC的呼 叫建立机制的回退。
还提供操作用于在电信系统中使用的终端的另 一 方法。终端能够 支持MONASPC。作为方法的部分，终端发送指示SPC协商已建立/启动和第一MONA供应未决的事实的信令。
还提供操作用于在电信系统中使用的终端的另 一方法。终端能够 支持MONASPC。作为方法的部分，终端接收指示SPC协商已建立/ 启动和第一 MONA供应未决的事实的信令。在收到此类信令时，终 端至少对于第一时间期间防止、延迟或禁止到非SPC的呼叫建立机制 的回退。
还提供操作用于在电信系统中使用的终端的另 一方法。终端能够 支持MONA SPC。作为方法的部分,基于在收到MONA优选消息(PM) 确认前它所花费的时间，定义往返延迟。


现在将通过^L为示例的方式并参照附图来描述本发明的 一些优选 实施例，其中
图1示出CS-IP视频电话交互工作中涉及的各种节点。
图2示出3GPPTS 26.111的标准范围，包括MONA如何集成到 TS 26.111的3GPP视频框架中。
图3示出根据H.324的MOS呼叫流程。
图4示出根据现有技术、使用MONA SPC的CS到IP呼叫建立 示例序列。
图5示出根据现有技术、使用MONA MPC的CS到IP呼叫建立 示例序列。
图6示出根据现有技术、使用MONA SPC的另一 CS到IP呼叫 建立示例序列。
图7示出根据本发明的一个实施例、使用MONA SPC的CS到IP 呼叫建立示例序列。
图8示出根据本发明的一个实施例、使用MONA MPC的CS到 IP呼叫建立示例序列。
图9示出根据本发明的一个实施例、使用MONA ACP的CS到IP呼叫建立示例序列。
图10示出根据本发明的一个实施例的技术的步骤的序列。
图11示出根据本发明的一个实施例、使用MONASPC的技术的 步骤的序列。
具体实施例方式
此处描述三个不同的实施例，这些实施例旨在实现使用MONA 的CS到IP呼叫中的端对端编解码器协商。关于应使用哪个实施例的 决定可取决于实现的选择和/或MONA端点和交互工作节点(或交互 工作网关或交互工作功能)充当的MONA终端的类型。
实施例1 (使用MONASPC):
参照图7，图的左侧示出CS端点1与交互工作节点3之间的信令， 即CS侧上的信令。图7的右侧示出IP端点2与交互工作网关3之间 的信令，即，IP侧上的信令。
序列开始于l，其中CS端点将IAM发送到交互工作节点。交互 工作节点以ANM响应CS终端(2.)。接着，使用MONA和SPC建立 H.223承载(3.)。交互工作节点随后等待来自CS端点的SPC MOS请 求，即，在未先收到SPCMOS请求前，它不继续IP协商。当交互工 作节点收到SPC MOS请求(其包括CS端点的编解码器能力的指示) 时(4.)，它通过向CS端点发送SPC MOS请求确认来确认请求(5.)。 交互工作节点随后也通过将SIP INVITE消息发送到IP终端(6.),开始 在IP侧上的协商。此SIP INVITE消息包括SDP供应，其包括CS端 点的编解码器优选。这样，在交互工作节点与IP端点之间的协商期间， 能将CS端点的编解码器优选(和能力)考虑在内。交互工作节点也 可在SDP供应中包括它对其具有译码能力的任何另外的编解码器。随 后，IP端点将SIP 200 OK消息(即,SDP回答)发送(7.)到交互工作 节点。结果，选择对CS和IP侧均适合的、即符合CS终端和IP终端的能力的编解码器(如果存在此类共同编解码器)。也就是说，如果存在CS和IP终端均支持的共同编解码器，则交互工作节点将选择此共同编解码器。如果可在几个共同编解码器之间选择，则它将选择提供最佳质量的编解码器。如果不存在此类共同编解码器，则交互工作节点将选择它对其具有译码能力的编解码器。
交互工作节点随后将SPC MOS请求发送(8.)到CS终端。此SPCMOS请求指定在CS侧上要使用哪个编解码器(按媒体类型)。
CS终端随后将SPC MOS请求确认发送到交互工作节点(9.)。呼叫因而处于活动状态中。交互工作节点的活动译码资源只在端对端编解码器失配的情况下使用。
因此，能够看到上述技术旨在提供端点之间的端对端编解码器协商。这通过交互工作节点在启动IP端点信令之前等待接收来自CS端点的SPC MOS请求而实现。结果，能在IP端点协商中使用CS端点的编解码器能力。
现在参照图10，此流程图示出根据本发明的实施例、由交互工作过节点3执行的步骤。如在10所示，作为MONA协商的一部分，交互工作节点接收CS侧MONA终端的编解码器能力的指示。此后，如在20所示，交互工作节点启动IP编解码器协商。在此之后，在30，交互工作节点继续和/或完成MONA协商。
图11示出图10所示的步骤如何特别应用于MONA协商是SPC协商的情况。
如在40所示，交互工作节点接收SPCMOS请求。此后，如在50所示，交互工作节点启动IP编解码器协商。在此之后，在60,交互工作节点继续和/或完成SPC协商。
参照图7和图11,在一些情况下，IP端点协商可能要占用一段时间，根据当前使用的协议，这可能由于满足的SPC回退条件而导致SPC协商的失败。如附件K中的K.8.2中所述的，此处所指的回退条件是在多个网络往返延迟(RTD)期间(例如，三个RTD)内未收到有效MOS请求的终端将认为SPC协商已失败，并启动到另一个呼叫建立才几制的回退。
存在解决上述潜在问题的几个解决方案。下面概述了发明人识别的三个解决方案。这些解决方案的一个共同特征是以下实际情况它们能通过更新附件K规范而实现，并且所有解决方案具有相同的目
第一解决方案涉及更新如附件K的部分K.82中指定的SPC回退条件以简化CS-IP交互工作。提议的更新是有效的MOS请求确认的接收将被理解为指示SPC协商正在进行中，并且应禁止回退到另一过程-至少在某个时期内，例如，在所述特定视频呼叫的持续时间内。才是议了对第二回退条件的以下更改(以粗体显示)
"在多个网络往返延迟(RTD)期间内，终端未4企测到有效的MOS请求或有效的MOS请求确认，或者不接受ICM。 一ife情况下，釆用三个RTD。，，
根据是第一解决方案的变型的第二解决方案，也可能引入新的"SPC协商在进行中"MOS消息(类似于SIP中的"180振铃")。在图7中，此消息将在5发送而不是SPC MOS请求确认。此类"SPC协商在进行中"MOS消息的接收将再次禁止到另一过程的回退。[Q:我觉得我们应对此多描述一些，特别是何时将发送此"SPC协商在进行中"消息。它是否通过步骤5从交互工作节点发送到CS端点？]
第三解决方案涉及更新附件K以指出具MONA SPC能力的终端将基于MONA优选消息(PM)确认往返时间来测量往返延迟。
MONAPM有效负载能力信息包括两个ACK比特，其中，MONA终端能确认来自远程终端的优选消息的接收。笫三解决方案是基于以下想法CS-IP交互工作功能有意延迟PM确认以使MONASPC协商容忍IP端点协商期间引入的延迟。换而言之，如果往i4i4迟是基于在收到MONA优选消息(PM)确认前花费的时间，并且MONA优选消息(PM)确认的发送被延迟，则RTD自动被延长。结果，回退被禁止/延迟。
为第三解决方案而提议的对附件K的文本如下
"在K.8.2中SPC回退条件内使用的RTD值应等于在接收带有ACK值"01"的PM与接收带有ACK值"10"的PM之间的时间。"
这些解决方案的任何一个能用于确保MONA SPC协商维持它完成IP会话建立所花费的时间。
实施例2 (使用MONAMPC):
图8示出使用MONA MPC的端对端编解码器协商的示例。序列开始于l，其中CS端点将IAM发送到交互工作节点。交互工作节点以ANM响应CS终端(2.)。接着，建立CS承载(3.)。交互工作节点随后等待来自CS端点的远程MONAPM消息，即，不立即继续IP协商。在交互工作节点等待远程MONAPM消息的同时，它继续将空闲^t式发送到TDM电路上的CS端点(4.)。当交互工作节点收到(5.) MONAPM消息(在此情况下是MPC供应)、该消息包括CS端点的编解码器能力的指示时，交互工作节点通过将SIP INVITE消息发送(6.)到IP终端而在IP侧启动协商。此SIP INVITE消息包括SDP供应，该供应包括CS端点的编解码器优选。这样，在交互工作节点与IP端点之间的协商期间，能将CS端点的编解码器优选(和能力)考虑在内。随后，IP端点将SIP 200 OK (即,SDP回答)发送(7.)到交互工作节点。结果，选择对CS和IP側均适合的、即符合CS终端和IP终端的能力的编解码器(如果存在此类共同的编解码器)。
交互工作节点随后将MONA PM消息(即，MPC供应)发送(9.)到CS终端。如果存在对CS端点和IP端点共同的编解码器，则将此编解码器选捧为优选。
CS终端随后将音频和视频媒体发送(10.)到交互工作节点。交互工作节点的活动译码资源只在端对端编解码器失配的情况下^f吏用(8.)。因此，能够看到第二实施例旨在提供端点之间的端对端编解码器协商。这通过有意地延迟H.223/MONA协商，直至CS和IP端点的编解码器能力和优选均已知来实现。 一旦此信息可用，则交互工作节点便能做出MPC供应，带有产生最高可能的々某体质量的最佳共同编解码器。
在上述技术中，交互工作节点通过在它发现MONA和IP端点的能力所花费的时间期间在TDM电路上发送空闲模式，模拟媒体不活动的CS承载。
作为上述第二实施例的备选，根据第 一 实施例的技术也能在MONAMPC的情况下用作在启动与IP端点的协商前等待远程端点显露其能力的一种机制。本领域的技术人员将明白，在考虑本说明书时将需要如何修改第一实施例的技术以便适合用于MONA MPC。
如果从远程CS端点(在5.)收到的初始数据指示传统信令，则执行到传统的回退。
实施例3 (使用MONAACP):
此实施例可用作实施例1或2的备选，特别是在由于任何原因而不能使用根据实施例1和2的技术时。
根据第三实施例，交互工作节点确保ACP一皮用作建立CS信道的过程。交互工作节点通过触发要由远程MONA终端4企测的回退条件而实现此方面。根据此实施例，到ACP的回退条件取决于远程MONA终端充当的MONA终端类型。交互工作节点能够根据远程终端类型进行适应和做出反应。
参照图9, MONA和H.223的GW启动被延迟以便如在第二实施例(1到4)中一样4果测CS端点的终端类型及可选地:探测其编解码器优选。如在5所示，CS端点随后发送MONA PM。交互工作节点随后发送(6.) MONA PM供应，其有意地导致到ACP的回退。
交互工作节点发送的MONA PM供应的性质取决于如交互工作节点基于CS端点发送到交互工作节点的MONA PM而4金测到的CS端点的MONA终端的类型。
如果远程MONA终端是类型II(即，它支持MPC而不支持SPC ),则交互工作节点通过在6发送指示SPC支持而无任何MPC编解码器供应(即，MPC-RX/TX比特设为值0)的PM消息来才莫拟类型III终端。另外，交互工作节点可发送MOS请求以便符合标准。
如果远程终端是类型III的(即，支持SPC, ^旦不支持MPC)，则交互工作节点通过发送MPC编解码器供应、并且还有指示无SPC支持的PM消息来^t拟类型II终端。
如果远程MONA终端是类型I的(即，支持MPC和SPC),则交互工作节点将通过做出MPC供应来模拟类型II终端，该供应可以是从远程MONA终端收到的MPC供应的反向副本，或者在其它方面不符合(例如，使得CS端点支持的编解码器不受交互工作节点支持)。
交互工作节点随后等待从远程CS端点接收TCS以探测CS端点的编解码器能力/优选。
一旦TCS从远程MONA终端收到(7.), IP编解码器协商便开始。在IP编解码器协商中，交互工作节点通过将CS端点的编解码器优选作为SDP供应中的优选来发送(8.),从而将MONA终端的编解码器优选用作向IP终端的优选。IP终端通过发送SDP回答^t文出响应(9.),该回答包括IP终端的编解码器能力和/或优选的指示。
交互工作节点的活动译码资源只在端对端编解码器失配的情况下使用(IO.)。
在IP终端的编解码器能力已知的情况下，交互工作节点将TCS编解码器供应发送(ll.)到MONA终端。此TCS编解码器供应包括两个端点(MONA和IP终端)共同具有的带有最高i某体质量的最佳可能的编解码器(如果此类共同编解码器存在)。如果不存在此类共同编解码器，则该供应将包括交互工作节点对其具有译码能力的编解码器。
远程MONA终端随后发送(12.) OLC。因此，将理解，在第三实施例中，MONA供应是基于收到的远程 MONA供应/远程MONA终端的终端类型而动态修改的。此外，在第 三实施例中，作为在CS到IP呼叫中实现端对端编解码器协商的方式， 远程终端纟皮有意强迫回退到ACP。
总之，在第二和第三实施例中，发送TDM空闲模式直到已接收 远程供应使得在启动MONA协商之前能够探测远程MONA CS终端 能力(以及可能还探测IP终端能力)。
从上面的描述中，可理解，本发明的优选实施例可将CS和IP侧 上以及MGCF4和MG5之间的呼叫信令降到最低。此外，CS-IP交互 工作呼叫的呼叫建立时间可减少。
缩写列表
ACK确认
ACP加速的呼叫过程
AMR自适应多速率
AMR-NB自适应多速率-窄带
AMR-WB自适应多速率-宽带
A丽回答消息
CCSRL控制信道分段和重新装配层
CS电路交换
3GPP第三代合作伙伴项目
IAM初始地址消息
ICM推断的共同模式
IMSIP多媒体子系统
IP因特网协议
ITU国际电信联盟
LAPM调制解调器链踏-接入过程
MG媒体网关MGCF4某体网关控制功能
MONA定向媒体协商加速
MOS定向媒体建立
MPC媒体预配置信道
MPEG运动图像专家组
MSD主从确定
NSRP编号的简单重新传输协议
OLC开放逻辑信道(ACP和H.245消息的名称)
PM优选消息
RAN无线电接入网络
RTD往返延迟
RTP实时传输协议
RTSP实时流传送协议
SDP会话描述协议
SIP会话启动协议
SPC信令预配置信道
TCS终端能力集
TS技术规范
WNSRP窗口的NSRP
虽然本发明已根据上述优选实施例进行描述，但应理解，这些实 施例只是说明性的，并且权利要求不限于那些实施例。本领域的技术 人员将能够鉴于公开内容进行修改和替代，这些修改和替代视为在随 附权利要求的范围内。本说明书中公开或示出的每个特征可单独或以
发明中
权利要求
1.一种将CS(电路交换)视频呼叫与使用IP多媒体协议的视频呼叫交互工作的方法，包括在交互工作功能，作为MONA(定向媒体协商加速)协商的部分，接收包括所述CS视频呼叫中涉及的CS终端的编解码器能力的指示的信令；此后，启动IP编解码器协商；以及此后，继续和/或完成所述MONA协商。
2. —种将CS (电路交换)视频呼叫与使用IP多媒体协议的视频 呼叫交互工作的方法，所述方法包括端对端编解码器协商，其中所述 端对端编解码器协商包括在交互工作功能，作为MONA协商的部分，接收包括所述CS 视频呼叫中涉及的CS终端的编解码器能力的指示的信令；以及 此后，启动IP编解码器协商。
3. 如权利要求1或2所述的方法，其中所述信令包括所述CS终 端的编解码器优选的指示。
4. 如前面^=又利要求任一项所述的方法，其中所述IP编解码器协 商包括所述交互工作功能与IP端点协商应该为特定呼叫使用哪些编 解码器。
5. 如权利要求4所述的方法，其中所述交互工作功能与所述IP 端点协商应该使用哪些编解码器包括将所述编解码器能力和/或在可 用的情况下将所述CS终端的编解码器优选考虑在内。
6. 如前面权利要求任一项所述的方法，还包括在接收所述信令前 建立CS承载。
7. 如前面权利要求任一项所述的方法，其中所述方法容忍所述 IP编解码器协商造成的延迟。
8. 如前面权利要求任一项所述的方法，其中所述信令包括SPCMOS请求，并且所述MONA协商包括SPC协商。
9. 如权利要求8所述的方法，其中接收所述SPCMOS请求的确 认使得所述SPC协商被视为是在进行中。
10. 如权利要求8或9所述的方法，其中接收所述SPC MOS请 求的确认使得到非SPC的过程的回退被禁止或推迟。
11. 如权利要求1到7中任一项所述的方法，其中所述信令包括 MONAPM (优选消息)。
12. 如权利要求1到7中任一项或11所述的方法，其中所述信令 包括MPC供应，并且所述MONA协商包括MPC协商。
13. 如权利要求12所述的方法，其中接收所述MPC供应的确认 使得所述MPC协商被视为是在进行中。
14. 如权利要求12或13所述的方法，其中接收所述MPC供应 的确认使得到非MPC的过程的回退被禁止或推迟。
15. 如权利要求12所述的方法，还包括在所述交互工作功能接收 所述MPC供应时，向所述CS终端发送TDM空闲模式。
16. 如权利要求1到7中任一项或11所述的方法，还包括从所述 信令检测所述CS终端充当的MONA终端的类型。
17. 如权利要求1到7中任一项或11或16所述的方法，还包括 促使到ACP的回退。
18. 如权利要求17所述的方法，其中促使到ACP的所述回退包 括所述交互工作功能向所述CS终端发送MONA PM供应。
19. 如权利要求18所述的方法，其中为了促使到ACP的所述回 退而由所述交互工作功能向所述CS终端发送的所述MONA PM指示 SPC支持而无任何MPC编解码器供应。
20. 如权利要求18所述的方法，其中为了促使到ACP的所述回 退而由所述交互工作功能向所述CS终端发送的所述MONAPM包括 MPC编解码器供应而不指示对SPC的支持。
21. 如权利要求18所述的方法，其中为了促使到ACP的所述回退而由所述交互工作功能向所述CS终端发送的所述MONA PM包括 MPC编解码器供应，所述MPC编解码器供应是所述信令中包括的 MPC供应的反向副本。
22. 如权利要求1到21中任一项所述的方法，其中仅在作为所述 IP编解码器协商的部分、所述交互工作功能已接收所述IP终端的编 解码器能力的指示后，它才向所述CS终端发送要用于特定呼叫的编 解码器的指示。
23. —种用于使得CS (电路交换)视频呼叫能够与使用IP多媒 体协议的视频呼叫交互工作的设备，其中所述设备布置成作为MONA协商的部分，接收包括所述CS视频呼叫中涉及的 CS终端的编解码器能力的指示的信令； 此后，启动IP编解码器协商；以及 此后，继续和/或完成所述MONA协商。
24. —种用于使得CS (电路交换)视频呼叫能够与使用IP多媒 体协议的视频呼叫交互工作的设备，所述设备布置成支持端对端编解 码器协商，其中所述设备布置成作为MONA协商的部分，接收包括所述CS视频呼叫中涉及的 CS终端的编解码器能力的指示的信令；以及 此后，启动IP编解码器协商。
25. 如权利要求23或24所述的设备，其中所述设备包括交互工 作功能。
26. 如权利要求23到25中任一项所述的设备，其中所述设备包 括用于延迟向所述CS终端发送要用于特定呼叫的编解码器的指示的 部件。
27. 如权利要求26所述的设备，其中所述延迟部件布置成仅在作 为所述IP编解码器协商的部分、它已^f妄收所述IP终端的编解码器能 力的指示后，才向所述CS终端发送要用于所述特定呼叫的编解码器 的指示。
28. —种用于在电信系统中使用的终端，所述终端能够支持 MONASPC，其中所述终端包括用于在指定条件下、至少对于第一时 间期间防止、延迟或禁止到非SPC的呼叫建立机制的回退的部件，其 中所述回退将在缺少所述部件时不受防止、延迟或禁止。
29. —种用于在电信系统中使用的终端，所述终端能够支持 MONASPC,其中所述终端布置成当一个或多个第一条件满足时，促 使、启动或执行到非SPC的呼叫建立机制的回退，其中所述终端包括 用于当 一个或多个第二条件满足时、即使所述一个或多个第 一条件满 足、至少对于第一时间期间防止、延迟或禁止所述回退的部件。
30. —种用于在电信系统中使用的终端，所述终端能够支持 MONASPC,其中当一个或多个条件满足时，所述终端布置成启动到 非SPC的呼叫建立机制的回退，其中所述终端布置成当它已接收有效 MOS请求确认消息时至少对于第一时间期间不启动所述回退。
31. 如权利要求30所述的终端，其中所述终端布置成当它已接收 有效MOS请求确认消息时，即使一个或多个其它回退条件满足，也 不启动所述回退。
32. —种用于在电信系统中使用的终端，所述终端能够支持 MONA SPC，其中所述终端布置成延迟MONA优选消息的确认的发 送以便至少对于第一时间期间防止、延迟或禁止到非SPC的呼叫建立 才几制的回退。
33. —种用于在电信系统中使用的终端，所述终端能够支持 MONA SPC，其中所述终端布置成发送指示SPC协商已建立/启动和 第一 MONA供应未决的事实的信令。
34. —种用于在电信系统中使用的终端，所述终端能够支持 MONA SPC，其中所述终端布置成接收指示SPC协商已建立/启动和 第一 MONA供应未决的事实的信令，其中在接收到此类信令时，所 述终端布置成至少对于第一时间期间防止、延迟或禁止到非SPC的呼 叫建立机制的回退。
35. —种操作用于在电信系统中使用的终端的方法，所述终端能 够支持MONASPC,其中所述方法包括当一个或多个第一条件满足时，所述终端促使、启动或执行到非 SPC的呼叫建立机制的回退，以及当一个或多个第二条件满足时，即4吏所述一个或多个第一条件满 足，所述终端至少对于第一时间期间防止、延迟或禁止所述回退。
36. —种操作用于在电信系统中使用的终端的方法，所述终端能 够支持MONASPC,其中当一个或多个条件满足时，所述终端布置成 启动到非SPC的呼叫建立机制的回退，其中所述方法包括所述终端在它已接收有效MOS请求确认消息时至少对于第一时 间期间不启动所述回退。
37. 如权利要求36所述的方法，其中所述终端在它已接收有效 MOS请求确认消息时，即使一个或多个其它回退条件满足，也不启动 所述回退。
38. —种操作用于在电信系统中使用的终端的方法，所述终端能 够支持MONASPC,其中所述方法包括所述终端延迟MONA优选消息的确认的发送以便至少对于第一 时间期间防止、延迟或禁止到非SPC的呼叫建立机制的回退。
39. —种操作用于在电信系统中使用的终端的方法，所述终端能 够支持MONASPC,其中所述方法包括所述终端发送指示SPC协商已建立/启动和第一 MONA供应未决 的事实的信令。
40. —种操作用于在电信系统中使用的终端的方法，所述终端能 够支持MONASPC,其中所述方法包括所述终端接收指示SPC协商已建立/启动和第一MONA供应未决 的事实的信令，其中在接收到此类信令时，所述终端至少对于第一时 间期间防止、延迟或禁止到非SPC的呼叫建立机制的回退。
41. 一种操作用于在电信系统中使用的终端的方法，所述终端能够支持MONASPC,其中所述方法包括基于在接收到MONA优选消息(PM)确认前它所花费的时间，定 义往返延迟。
全文摘要
提供一种将CS(电路交换)视频呼叫与使用IP多媒体协议的视频呼叫交互工作的方法。根据该方法，作为MONA(定向媒体协商加速)协商的部分，交互工作功能接收包括CS视频呼叫中涉及的CS终端的编解码器能力的指示的信令。此后，启动IP编解码器协商。并且此后继续和/或完成MONA协商。因此，在和IP端点的IP编解码器协商期间，能将CS终端的编解码器能力和/或优选考虑在内。
文档编号H04L29/06GK101682642SQ200880021262
公开日2010年3月24日 申请日期2008年4月28日 优先权日2007年4月26日
发明者A·威特泽尔, J·E·林德奎斯特, M·N·O·林德斯特伦 申请人:艾利森电话股份有限公司