多媒体呼叫控制机制和使用该机制的通信设备

摘要

一种控制至少两个通信设备(1，2)之间的多媒体呼叫建立的方法、相应的系统和相应的通信设备，包括建立承载连接，导致至少两个通信设备之间的数据传输信道的创建。在创建所述数据传输信道后，在所述至少两个通信设备之间传输数据流，以保持所述数据传输信道的同步。在所述数据流中引入预定信息元素，其中所述预定信息元素指示用于所述多媒体呼叫的本地协议设置。从所述数据流中识别出预定信息元素，以及基于所述预定信息元素来调节用于所述多媒体呼叫的应用协议的参数。

说明书

技术领域

本发明涉及一种用于控制至少两个通信设备之间的多媒体呼叫的建立的方法、相应的系统和相应的通信设备。特别地，本发明涉及通过其可改进用于视频电话呼叫的建立时间的方法、系统和通信设备。

为了在下面描述本发明的目的，应该注意到：

-通信设备可以例如是用户可以通过其接入通信网络的任意设备；这意味着移动以及非移动设备和网络，独立于它们所基于的技术平台；仅作为例子，注意到根据由第3代合作伙伴计划3GPP所标准化的原理操作并且例如称为UMTS终端的通信设备特别适于结合本发明来使用；

-尽管这里之前参考了视频电话，但这仅示例了内容的特定例子；在本发明中所使用的内容旨在指音频数据、视频数据、图像数据、文本数据和元数据(其用于描述音频、视频、图像和/或文本数据的属性)中至少一项的多媒体数据，它们的任意组合，或者可选或附加地，甚至是例如将要访问/下载的应用程序的程序代码之类的其他数据；

-可能被实施为软件代码部分并且使用处理器在实体之一处运行的方法步骤是软件代码无关的并且可以使用任意已知的或未来开发的编程语言来指定；

-可能被实施为在实体之一处的硬件组件的方法步骤和/或设备是硬件无关的并且可以使用任意已知或未来开发的硬件技术或这些的任意混合来实施，例如MOS、CMOS、BiCMOS、ECL、TTL等，例如使用ASIC组件或DSP组件；

-通常，在不改变本发明的思想下，任意的方法步骤适于实施为软件或由硬件来实施；

-设备或装置可以被实施为单独的设备或装置，但这不排除它们以分布式的方式在整个系统内实施，只要保持设备的功能性。

背景技术

在过去的几年，通信网络的持续扩展在全球发生，该通信网络例如是：基于有线的通信网络，例如综合服务数字网络(ISDN)；或无线通信网络，例如cdma2000(码分多址)系统、像通用移动通信系统(UMTS)的蜂窝第3代(3G)通信网络、像全球移动通信系统的蜂窝第2代(2G)通信网络、通用分组无线系统(GPRS)、全球演进的增强数据速率(EDGE)或其他无线通信系统例如无线局域网(WLAN)。各种组织，例如第3代合作伙伴计划(3GPP)、国际电信联盟(ITU)、第3代合作伙伴计划2(3GPP2)、互联网工程任务组(IETF)和类似组织正在致力于用于通信网络和多种接入环境的标准。

一般地，通信网络的系统结构是使得一方(例如，订户的通信设备，例如移动台、移动电话、固定电话、个人计算机(PC)、膝上型计算机、个人数字助理(PDA)等)经由收发器或接口(例如空中接口、有线接口等)连接到接入网络子系统。接入网络子系统控制来往于通信设备的通信连接，并且经由接口连接到相应的核心网络或骨干网络子系统。核心(或骨干)网络子系统将经由通信连接传输的数据交换到目的地方，例如另一通信设备、服务提供商(服务器/代理)，或另一通信网络。将注意到核心网络子系统可以连接到多个接入网络子系统。如本领域技术人员已知以及在各规范(例如对于UMTS、GSM等等)中所定义，根据所使用的通信网络，实际网络结构可以变化。

一般地，为了正确地建立和处理网元(例如通信设备和另一通信设备或终端、数据库、服务器等)之间的通信连接，涉及一个或多个中间网元(例如控制网元、支持节点或服务节点)。

其重要性对于当前和未来通信系统都增加的一个应用是多媒体通信服务，并且特别是会话视频电话(VT)服务。一般地，视频通信涉及具有移动图片的通信，但在某种程度上也涉及文本和语音，特别结合用于多媒体通信或呼叫。多媒体呼叫是这样一种例如声音(话音)、文本和图片被同时使用的通信。视频电话(也称为视频话机(videophone))被定义为经由终端的远程通信，其能够基本上实时地在发送方和接收方之间交互地传送移动图片和音频。由于此类的会话VT服务是延迟敏感型应用(因为VT呼叫传输期间的延迟是妨碍并且对用户不便的)，所以需要为VT呼叫选择适当的信令路径和过程以便确保此类连接的质量对于用户来说是足够的。另外，由于VT呼叫需要并行地传输若干不同类型的数据(视频、音频等)，并且这些数据将由不同类型的通信设备或网元来发送和接收，所以需要协商多种通信协议并且调节用于通信的合适参数。

例如，在3G网络中，3GPP要求使用确保3G带宽的电路交换承载。另外，作为将要用于此类多媒体通信的标准，将使用3G-324M系统。3G-324M系统表示ITU-T H.324协议的派生，其进而需要使用若干另外的组件或协议，例如用于复用的ITU-T H.223协议和用于对不同多媒体系统之间的多媒体通信进行呼叫控制的ITU-T H.245协议。本领域技术人员已知用于建立多媒体通信的一般过程，从而在这里省略对其详细的描述。

一般地，当将要建立例如VT呼叫的多媒体呼叫时，例如在使用上述提到的3G-324M系统的3G网络中，执行下面的过程(简略描述)。这些过程的进一步细节例如可在3GPP规范TS 26.112 V1.1.0、TS 24.008 V3.16.0，和TR 26.911 V3.4.0中找到。

用于VT呼叫的参数的协商在下面的阶段中执行：

-A：在第一信令阶段，交换BCIE(承载能力信息元素)和LCIE(低层兼容信息元素)参数。这是在例如话音和数据呼叫中执行的常规移动呼叫建立过程。BCIE和LCIE参数向另一实体(即，另一通信设备)通知对等端(即，(主叫)通信设备)的承载能力并且主要用于建立承载链路(即，物理层连接)。一旦建立物理链路，承载协议开始发送填充信息到刚创建的比特管道。一旦视频应用协议被初始化，由其将实际的视频协议数据提供给比特管道。

-B：在应用协议协商阶段，应用协议被初始化并且启动与对等实体的应用协议“握手”过程。该阶段通常将比阶段A更长。注意到在物理比特管道创建之前，应用协议参数的握手将不可能。

在此类的常规视频呼叫建立中，建立时间可能持续相对较长的时间。如上所述，原因在于此类的视频呼叫建立需要若干级的协议协商以便就对等实体(即，参与视频呼叫的通信设备)之间的视频应用参数进行交换并达成一致。然而，在视频呼叫实际可开始前长的等待时间是不期望的并且降低了视频电话服务对用户的吸引力。

当前，提出了若干种用于加速视频呼叫建立的专用解决方案。然而，这些解决方案涉及加速视频协议协商。例如，使用卖方ID信息来选择用于所提议的逻辑信道的参数。

发明内容

因此，本发明的一个目的是提供一种机制，用于控制至少两个通信设备之间的多媒体呼叫的建立，通过该机制，呼叫建立时间可以被缩短。

该目的可通过在所附权利要求书中所定义的措施来实现。

特别地，根据所提出的解决方案的一个方面，提供一种例如控制至少两个通信设备之间的多媒体呼叫的建立的方法，该方法包括步骤：建立承载连接，导致至少两个通信设备之间的数据传输信道的创建；在创建数据传输信道后在至少两个通信设备之间传输数据流以保持数据传输信道的同步；在数据流中引入预定信息元素，其中预定信息元素指示用于多媒体呼叫的本地协议设置；接收数据流并且从数据流中识别出预定信息元素；以及，基于预定信息元素来调节用于多媒体呼叫的应用协议的参数。

另外，根据提出的解决方案的一个方面，提供例如一种可用于控制至少两个通信设备之间的多媒体呼叫的建立的系统，该系统包括至少两个通信设备，以及用于在至少两个网元之间传输数据的通信网络，其中该系统可操作性地连接以及配置成：建立承载连接，导致至少两个通信设备之间的数据传输信道的创建；在创建数据传输信道后，在至少两个通信设备之间传输数据流，以保持数据传输信道的同步；将预定信息元素引入到数据流中，其中预定信息元素指示用于多媒体呼叫的本地协议设置；接收数据流并且从数据流中识别出预定信息元素；以及，基于预定信息元素来调节用于多媒体呼叫的应用协议的参数。

类似地，根据提出的解决方案的一个方面，提供例如一种系统，可用于控制在至少两个通信设备之间建立多媒体呼叫，该系统包括至少两个通信设备，以及用于在至少两个网元之间传输数据的通信网络，其中系统另外包括：处理装置，该处理装置包括本地承载部分，用于建立承载连接，导致至少两个通信设备之间的数据传输信道的创建；传输装置，用于在创建数据传输信道后，在至少两个通信设备之间传输数据流，以保持数据传输信道的同步，其中该处理装置另外包括用于将预定信息元素引入到数据流中的装置，其中该预定信息元素指示用于多媒体呼叫的本地协议设置；用于接收数据流的接收装置；用于从数据流中识别出预定信息元素的装置；以及，基于预定信息元素来调节用于多媒体呼叫的应用协议的参数的应用部分。

另外，根据提出的解决方案的一个方面，提供例如一种可用于控制通往至少一个其他通信设备的多媒体呼叫的建立的通信设备，该通信设备可操作性地连接以及配置成：建立承载连接，导致到至少一个其他通信设备的数据传输信道的创建，在创建数据传输信道后，向/从该至少一个其他通信设备发送和接收数据流，以保持数据传输信道的同步；将预定信息元素引入到发送到至少一个其他通信设备的数据流中，其中预定信息元素指示用于多媒体呼叫的本地协议设置；从自至少一个其他通信设备接收到的数据流中识别出预定信息元素；以及，基于接收到的预定信息元素来调节用于多媒体呼叫的应用协议的参数。

类似地，根据提出的解决方案的一个方面，提供例如一种通信设备，可用于控制通往至少一个其他通信设备的多媒体呼叫的建立，该通信设备包括：处理装置，该处理装置包括本地承载部分，用于建立承载连接，导致到至少一个其他通信设备的数据传输信道的创建；以及传输和接收装置，用于在创建数据传输信道后，向/从该至少一个其他通信设备发送和接收数据流，以保持数据传输信道的同步，其中该处理装置另外包括用于将预定信息元素引入到发送到至少一个其他通信设备的数据流中的装置，其中该预定信息元素指示用于多媒体呼叫的本地协议设置；用于从自至少一个其他通信设备接收到的数据流中识别出预定信息元素的装置；以及基于从所述至少一个其他通信设备中接收的预定信息元素来调节用于多媒体呼叫的应用协议的参数的应用部分。

另外，根据提出的解决方案的一个方面，提供例如一种可用于控制到至少一个其他通信设备的多媒体呼叫的建立的通信设备，该通信设备可操作性地连接以及配置成：建立承载连接，导致到至少一个其他通信设备的数据传输信道的创建；在创建数据传输信道后，发送数据流到至少一个其他通信设备，以保持数据传输信道的同步；以及将预定信息元素引入到发送到至少一个其他通信设备的数据流中，其中预定信息元素指示用于多媒体呼叫的本地协议设置。

另外，根据提出的解决方案的一个方面，提供例如一种可用于控制到至少一个其他通信设备的多媒体呼叫的建立的通信设备，该通信设备可操作性地连接以及配置成：建立承载连接，导致到至少一个其他通信设备的数据传输信道的创建；在创建数据传输信道后，从至少一个其他通信设备接收数据流，以保持数据传输信道的同步；从自至少一个其他通信设备接收到的数据流中识别出预定信息元素，该预定信息元素指示用于多媒体呼叫的至少一个其他通信设备的本地协议设置；以及基于接收到的预定信息元素来调节用于多媒体呼叫的应用协议的参数。

另外，根据提出的解决方案的一个方面，提供例如一种可用于控制到至少一个其他通信设备的多媒体呼叫的建立的通信设备的处理设备，该处理设备可操作性地连接以及配置成：控制建立承载连接，导致到至少一个其他通信设备的数据传输信道的创建；在创建数据传输信道后，控制向/从至少一个其他通信设备发送和接收数据流，以保持数据传输信道的同步；控制将预定信息元素引入到发送到至少一个其他通信设备的数据流中，其中预定信息元素指示用于多媒体呼叫的本地协议设置；控制从自至少一个其他通信设备接收到的数据流中识别出预定信息元素；以及，控制基于接收到的预定信息元素来调节用于多媒体呼叫的应用协议的参数。

另外，根据所提出的解决方案的一个方面，提供例如一种用于计算机的计算机程序产品，包括软件代码部分，用于当所述产品运行在计算机上时，使所述计算机用作通信设备并且可用于控制到至少一个其他通信设备的多媒体呼叫的建立，计算机程序产品被配置成：建立承载连接，导致到至少一个其他通信设备的数据传输信道的创建；在创建数据传输信道后，向/从至少一个其他通信设备发送和接收数据流，以保持数据传输信道的同步；将预定信息元素引入到发送到至少一个其他通信设备的数据流中，其中预定信息元素指示用于多媒体呼叫的本地协议设置；从自至少一个其他通信设备接收到的数据流中识别预定信息元素；以及，基于接收到的预定信息元素来调节用于多媒体呼叫的应用协议的参数。

另外，根据提出的解决方案的一个方面，提供例如一种可实施在通信设备中并且可用于控制到至少一个其他通信设备的多媒体呼叫的建立的芯片组，该芯片组包括芯片部分，该芯片部分可操作性地连接以及配置成：建立承载连接，导致到至少一个其他通信设备的数据传输信道的创建；在创建数据传输信道后，控制向/从至少一个其他通信设备发送和接收数据流，以保持数据传输信道的同步；将预定信息元素引入到发送到至少一个其他通信设备的数据流中，其中预定信息元素指示用于多媒体呼叫的本地协议设置；从自至少一个其他通信设备接收到的数据流中识别出预定信息元素；以及，基于接收到的预定信息元素来调节用于多媒体呼叫的应用协议的参数。

根据进一步的改进，提出的解决方案可包括一个或多个下面的特征：

-在数据流中识别出的预定信息元素可以被传送到通信设备中的应用部分以执行多媒体协议参数的调节。可以通过通信设备中的本地承载部分和应用部分之间的消息接口来执行将预定信息元素传送到应用部分；

-传输包括预定信息元素的数据流可被重复预定的次数；

-应用协议握手过程可以并行于或在将预定信息元素引入进在通信设备之间传输的数据流中后初始化。当在预定时间过去后没有在数据流中识别出预定信息元素时可以执行应用协议握手过程的初始化。另外，当在已经初始化应用协议握手过程后在数据流中识别出预定信息元素时，应用协议握手过程可以被中断并且在数据流中识别出的预定信息元素可以用于调节应用协议的参数；

-预定信息元素可以被格式化成适于对传输的预定信息元素执行检错处理的格式；

-预定信息元素可以包括可以由接收侧通信设备用于确定在发送侧的通信设备类型的信息；

-在至少两个通信设备之间的数据传输信道的创建可以是在至少两个通信设备之间的同步透明比特管道的创建；

-多媒体呼叫的建立可以包括电路交换通信连接的建立；

-多媒体呼叫的建立可以包括视频电话呼叫的建立。

根据提议的解决方案，可以实现下面的优势：

-通过使用在常规空闲时间阶段期间传输的特别信息元素，可以加速多媒体呼叫建立阶段。因此，对等实体能够在创建了用户终端之间的比特管道后立即检测用于视频应用协议参数的参数设置。由于可以在启动应用协议握手过程前传输参数，所以常规所需的应用层协商阶段(上述的阶段B)可以被绕开。因此，用于VT呼叫建立的时间可以被显著地缩短。例如，在建立业务或承载信道后，可以在标准端对端H.245带内协商中节省时间。换句话说，根据本发明，相比较于常规的H.324情形，例如可以更早地执行握手过程，从而加速呼叫建立。

通过用于保持比特管道的同步的数据流，根据本发明的参数的传输可以在任意情形下执行。这意味着提出的机制可以普遍地应用于通信系统中并且不存在这样的问题：即可能在所涉及的用户终端之间的任何阶段不传输数据。通过重复地传输参数信息，可以进一步提高数据传输的安全性，从而可以在另外的周期内完整接收在经由透明信道/比特管道的传输期间所丢失的信息。另外，数据可以被格式化，使得可能的错误可以被检测，例如，通过使用冗余数据。

-所提出的机制也易于实现。不存在预期中的互操作性问题，例如当一个通信设备使用提出的方案，而另一个通信设备没有做相应的准备时。换句话说，无论在何处创建VT呼叫，所提出的机制不会干扰现有的实现和工作。例如，在其中一个通信设备接收指示用于VT呼叫的参数的预定信息元素但不能同样地对它们进行解译时，这些数据将被解译为常规填充信息或垃圾。这样，可在没有以不适当的方式干扰呼叫建立的情况下执行常规应用协议握手过程。

在参考描述和附图后，本发明的上述和另外的目的、特征和优势将变得更为明显。

附图说明

图1示出了其中本发明可应用的通信网络环境的简化结构的示图；

图2示出了图示根据本发明的一个实施方式的通信设备的组件的电路框图；

图3和图4示出了图示根据本发明的一个实施方式执行的信令的信令图；以及

图5示出了根据本发明的一个实施方式的呼叫建立控制过程的流程图。

具体实施方式

在下文中，将参考附图来描述本发明的实施方式。为了说明本发明，将在3G网络环境中描述优选的实施方式，该3G网络环境根据3GPP规范包括移动接入网络子系统和核心网络子系统组件。然而，应该注意到本发明不限于此类网络环境中的应用，而也可应用于其他网络类型。在图1中，示出了(移动)通信网络的基本网络环境的示意性框图。应该注意到根据图1的结构仅代表可用于本发明的通信网络环境的架构的简化例子。正如本领域技术人员所知，提供了用于通信连接的若干附加网元和信令链路。然而，为了简化，仅描述对于描述本发明所必需的那些元件。

另外，这里所描述的网元和它们的功能要以由软件来实现，例如通过用于计算机的计算机程序产品来实现，或由硬件来实现。在任何的情况下，为了执行它们相应的功能，相应使用的设备，例如通信设备UE、核心网络控制元件(例如移动交换中心MSC)、接入网络子系统元件(例如基站子系统BSS元件或无线接入网络RAN元件等)，包括控制、处理和通信/信令功能性所需的若干装置和组件(未示出)。此类的装置可包括例如处理器单元，用于执行指令、程序和用于处理数据；存储装置，用于存储指令、程序和数据，用于用作处理器的工作区等(例如ROM、RAM、EEPROM等)；输入装置，用于由软件输入数据和指令(例如，软盘、CD-ROM、EEPROM等)；用户接口装置，用于向用户提供监视和操纵可能性(例如屏幕、键盘等)；接口装置，用于在处理器单元的控制下建立链路和/或连接(例如，有线和无线接口装置、天线等)等等。

根据图1，参考标记1和2表示通信设备，例如移动电话、PDA等，其能够建立类似于VT呼叫的多媒体呼叫。应该注意到通信设备也可以是固定终端、例如个人计算机PC 21、ISDN终端22等，只要相应的通信设备能够执行VT呼叫即可。参考标记3和6表示接入网络子系统，例如BSS或RAN，其中为了简化在图1中省略了其各个组件(基站、基站控制器等)。参考标记4和5表示MSC作为用于将待建立的呼叫切换到定义的目的地的核心网络控制元件。参考标记7表示使用作为用于呼叫的转移网络的通信网络，例如公共交换电话网络PSTN、固定网络等。根据本发明，可以注意到通信网络7可以是任意类型的网络，特别是数字网络类型。

在图1中还示出了CE1和CE2之间的通信链路，其代表将要建立的多媒体呼叫连接。在该连接中，应该注意到本发明的呼叫连接和相应的控制功能基本上不限于两个单独的终端之间的连接的情形。例如，呼叫连接可以建立在多于两个通信设备之间，例如在多方实现的情形中(多方也可以包括这样的情形，其中在两个端点之间的连接中，一个端点可以用作若干个呼叫的节点并且递送或分发这些呼叫之间的数据)。另外，参与呼叫的通信设备也可以驻留于通信网络的相同“侧”，例如在由MSC 4所控制的相同小区区域内。接着，可以不同于图1中所示出的方式来引导连接链路。

在下文中，当应用本发明的网络环境是根据图1所示时，用于多媒体呼叫的呼叫建立控制机制，特别是根据本发明的视频电话呼叫将参考图3到图5来描述。

在图5中，根据本发明的一个实施方式，示出了图示用于多媒体呼叫的呼叫建立控制过程，特别是视频电话(VT)呼叫的流程图。

当开始该过程时，在步骤S110，执行参与呼叫的通信设备之间的第一信令阶段。例如，也在通常的话音或数据呼叫中执行的常规移动呼叫建立过程可以在该阶段使用。在例如如图1所示的3G网络环境的情形下，这例如包括通信设备CE1和CE2之间的承载连接的建立和数据传输信道的创建。呼叫的建立可以基于经由相应的BSS/RAN 3、6、MSC 4、5和通信网络7所连接的电路交换通信，并且数据传输信道例如可以是同步透明比特管道。在此类的情形下，在呼叫建立的初始阶段，为了建立承载链路(物理层)，在CE1和2之间交换承载能力信息元素BCIE和低层兼容性信息元素LCIE，以便向彼此通知终端和网络的更低层特性。这意味着BCIE和LCIE向相应的其他通信设备通知关于对等端的承载能力。本领域技术人员已知用于建立承载连接的该过程的细节，从而省略其详细的描述。

一旦建立CE1和CE2之间的物理层(即，比特管道)，承载协议开始经由刚创建的比特管道来发送数据流。这对于保持同步透明数据传输信道的同步是必要的，为此需要传输充分的和持久的数据量。

常规地，用于保持同步的数据流仅包括填充数据，例如以“0xFF0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF...”形式的数据。

根据本发明，预定信息元素被包括在该数据流中并且发送到相应的其他通信设备(步骤S120)。例如，替代于上述的填充数据，在创建了比特管道后，现在将在数据流中以“0xFF 0xaa 0xbb0xcc..0xFF 0xFF 0xaa 0xbb 0xcc..0xFF 0xFF..”形式来传输数据，其中0xaa、0xbb 0xcc代表预定信息元素。该预定信息元素用于定义例如视频应用参数的本地协议设置。换句话说，通过包括在数据流中的特定信息元素，发送通信设备向作为对等实体的另一(接收)通信设备通知关于将要例如用于VT呼叫的期望应用协议特征。

这些设置或参数可以是预设的并且存储在通信设备中，以便标识出特定的通信设备类型(即，视频终端的类型)以及其参数，即，在与具有相应类型的视频终端的相应通信设备进行VT呼叫的情形下被设置用于视频应用的参数。换句话说，预定信息元素包括数据，这些数据是预先达成一致的并且分配到相应的通信设备。

预定信息元素被引入进数据流中，例如，从数据流传输的开始。另外，优选的是将其传输重复至少预定的次数，从而确保接收侧(即，作为对等端的另一通信设备)能够正确地接收和识别出信息元素。此外，包括通信设备1和2之间的数据流中的特定信息元素的消息可以被格式化，使得可以例如通过包括某些冗余数据来检测经由透明比特管道的传输期间可能发生的错误。

当通信设备2、1从另一通信设备1、2接收数据流时，确定经由承载连接接收到的数据流是否包括特定的信息元素(步骤S130)。应该注意到两个通信设备1、2在一旦创建比特管道并且数据流将被传输时将它们的预定信息元素发送到相应的另一通信设备。如果数据流包括特定的信息元素，则通信设备从其提取信息元素并且将信息元素从承载层传送到应用协议，即，上述情形中的视频应用协议(步骤S140)。应该注意到可选地，替代于这样将信息元素传送到应用协议，还可以确定由接收到的信息元素所代表或包含的相应值并且将以不同于接收到的信息元素的适宜形式将该值(或信息)转发到应用协议。例如可通过本地承载和视频应用实体之间的消息接口来执行信息的传送。

当信息元素(即用于VT呼叫的参数设置的有关信息)被传输到应用协议实体时，基于提取的信息元素来调节应用的参数(步骤S150)。这例如可以通过从存储器等提取相应的参数集来实现，该参数集可以分配给接收到的预定信息元素。可选地，信息元素本身或包含在其中的相应值也可以被用作参数设置。当本地协议设置被完成和/或可接受时，优选地可将确认从相应的实体发送到网络和/或其他实体，并且反之亦然，从而确认成功地进行了设置(未示出)。

关于确认过程，应该注意到这可以是可选的问题。另一方面，当实现此类的确认过程时，可以实现更为可靠的信令。

作为例子，可以下面的方式来执行确认过程。一旦对等终端(例如通信设备)检测到另一端应用协议配置并且识别出值是可同意的，则相应的对等终端将相应的指示传送到另一端。指示例如可以是预先达成同意的字符串，例如“0xFF，0xBB，0xBB，0xBB，0xBB，0xFF”。该指示(例如上述的串)可以被重复预定的次数。对等端执行类似的过程，即，其检查接收到的协议配置并且一旦其识别出协议配置是可以同意的，则对等端以相同的方式来回复。因此，两端知道进入的VT呼叫配置。

确认的交换(也称为协商)在高层上执行，这是因为应用协议参数的详细知识在此时尚未“启动”的应用协议端中。然而，常规地，VT呼叫参数彼此很接近，从而在多数情形下，可以获得用于确认过程的正面结果。当参数的协商方向(上行链路或下行链路)被正确地考虑时(其通常在协议协商中执行)，可以进一步改进确认过程。通过此，相应的通信设备能够确定提出的参数是否是可接受的，例如通过将它们与自身的配置进行比较。应该注意到还可以在蜂窝协议层中加入更多的应用协议认识(awareness)。该确认过程不会影响呼叫建立时间，因为最慢部分是应用协议栈的启动，这意味着在没有延长建立时间的情况下可以在规定的时间内完成确认过程。

作为进一步的选项，在其中参数是不可接受的情况下(例如，如果协商仅在很高的层内执行时)，相应的通信设备可以被配置成将不同于在参数是可接受的情形下的(如上所述)另一预先达成同意的指示发送到另一端。该指示可具有例如类似于“0xFF 0xCC 0xCC0xCC 0xCC 0xFF”字符串的形式，其可以被重复预定的次数。通信设备也可以被配置成当检测到相应的另一端的答复时，停止发送指示(即，发送涉及可接受参数的指示或涉及不可接受参数的指示，如上所述)。在这种答复指示参数是不可接受的情形下，两个终端(即，通信设备)可以被配置成使得建议的协议配置被改变，并且接着过程从开始启动，或该过程被停止，其中以常规的方式来执行应用层协商。

另外，如果在一端或两端(通信设备)没有检测到否定或肯定确认，那么一旦应用层协议准备启动标准协商，则可以停止“早前”的协商过程。

应该注意到在常规的VT呼叫设置过程中，在建立承载连接后(参见步骤S110)，视频应用协议也启动初始化过程。这意味着当通过启动与对等实体过程的应用协议“握手”过程而初始化应用协议的时候，启动应用协议协商阶段，其中两个应用协议端向对等端通知其能力，其中基于此选择用于将要建立的视频会话的正确协议设置。该步骤通常将比执行承载连接建立的步骤占用更长的时间。应该注意到在已经创建物理比特管道前不可能进行应用协议参数的握手。

根据本实施方式，应用协议握手过程也可以被启动。例如，应用协议握手过程可以在第一数据流被接收并且没有在数据流中识别出预定信息元素后启动(步骤S160)。可选地，应用协议握手过程的启动可以被延迟预定的时间以等待是否接收到预定信息元素。作为进一步的选择，应用协议握手过程可以在当预定信息元素被引入到数据流中时同时启动，例如，当创建了CE1，2之间的比特管道时。

在启动了应用协议握手过程后，如步骤170中所示，将仍然就预定信息元素来监视数据流。执行此以便确保识别出来自于另一通信设备的预定信息元素的延迟的或干扰的传输。

如果在步骤S160中启动了应用协议握手过程后，在步骤S170中接收和识别预定信息元素，则应用协议握手过程可以被中断并且信息元素可以被处理，类似于其中在开始处(即，在步骤S140中)接收它们的情形。这由图5中从块S170到S140的虚线箭头来说明。否则，如果没有识别出预定信息元素，则完成应用协议握手过程，如常规VT呼叫建立的情形一样。

当完成视频应用的参数设置时(并且例如，交换针对本地协议设置的确认时)，建立VT呼叫连接并且可在CE1，2之间启动视频应用数据流(步骤S180)。此后，结束呼叫建立控制过程。

在图3和图4中，示出用于图示在根据图1的环境中，在图5中示出的过程的实现的信令图。

在步骤S11中，当移动发起(MO)通信设备(UE)视频应用初始化呼叫建立时，例如由于来自用户的相应指令，将VT呼叫请求传输到MO CE调制解调器。在步骤S12中，调制解调器将相应的呼叫请求发送到MSC(例如，经由图1中的BSS/RAN 3的MSC 4)。调制解调器通常在到MSC的呼叫请求中包括承载能力BC信息。在S13中，MSC经由转移网络(例如图1中的通信网络7)转发呼叫请求到接收侧的第二MSC(例如MSC 5)。接收侧MSC将呼叫请求经由相应的子网络(例如BSS/RAN 6)发送到移动终结(MT)CE调制解调器(步骤S14)。呼叫请求的该传输可以或可以不包括BC，将在下面对其进行更为详细地描述。在S15中，MT CE调制解调器接着向MT CE视频应用提供VT呼叫请求。

在步骤S16中，MT CE视频应用通过相应的呼叫应答来应答呼叫请求，其中该应答被传输到MT CE调制解调器。在步骤S17中，MT CE调制解调器发送呼叫应答(包括类似于步骤S12的BC参数)到MSC(例如MSC 5)。在步骤S18中，MSC经由转移网络(通信网络7)将呼叫应答转发到第一MSC(MSC 4)，该第一MSC在可用的时候将包括BC参数的呼叫应答传送到MO CE调制解调器(步骤S19)。在步骤S20中，MO CE调制解调器向MO CE视频应用通知关于该呼叫应答的信息。接着，如S21所指示，视频承载建立完成并且物理链路(例如比特管道)被创建。

应用注意到步骤S11到S20对应于图5中的步骤S110并且可代表类似语音或数据呼叫中的常规呼叫建立。

在根据图4的步骤S21中，经由创建的比特管道在通信设备之间交换预定信息元素。步骤S21因此可包括根据图5中的步骤S120的措施，即数据流的传输和其中预定信息元素的引入。

在步骤S22a、S22b中，相应的MO和MT CE调制解调器提取从另一CE调制解调器所发送的信息元素并且将它们传送到MO或MT CE视频应用。这对应于图5中的步骤S130和S140。接着根据接收到的信息元素可以设置相应的CE视频应用并且初始化视频应用(步骤S23a、S23b)(参见图5中的步骤S150)。此外，可以交换关于本地协议设置的确认(未示出)。此后，如步骤S24中所示，执行视频应用数据流。

在图2中，示出通信设备的简化结构，其适于执行上述的过程。应该注意到仅示出了对于理解关于本发明的通信设备的功能所必需的那些元件，而对于此类通信设备的常规或可选部分的那些元件和本领域技术人员来说已知的那些元件被省略。另外，如上所指示，由下面所描述的元件所提供的功能可以由硬件和/或软件来实施，并且元件可以被包括在一个实体中或分布到若干个实体中。

根据图2，CE 2包括作为用户接口的输入/输出(I/O)装置21，例如键盘和显示器，用于输入来自用户的指令并且将信息输出给用户。参考标记22表示处理装置，其用于实施根据本发明的呼叫建立。应该注意到处理装置22可以被实施为例如具有适于执行相应的处理的相应芯片部分的芯片组或芯片组的一部分。参考标记23表示另外的I/O装置，用于与外部网络通信，即，例如与另一UE进行通信，并且包括接口和/或收发器装置。经由I/O装置23，例如建立同步透明比特管道。

处理装置22包括控制部分，例如CPU等，用于根据本发明来控制处理装置的整体处理和步骤的执行。控制部分24连接到I/O装置21。参考标记25表示连接到控制装置的存储装置，用于存储处理软件和数据，用于涉及预定信息元素的应用协议设置的参数集，涉及该CE 2的预定信息元素集，等等。

参考标记26表示用于生成数据流的数据流发生器，该数据流用于保持比特管道的同步并且用于发送存储在存储装置25中的预定信息元素。例如可通过控制装置24来控制数据流的生成和预定信息元素的引入。数据流发生器与承载部分29连接，该承载部分29也连接到控制装置24。在VT呼叫建立的开始，由承载部分29在控制部分24的控制下执行承载连接(即，物理链路)的建立。

当建立承载连接时，如上所述，经由I/O装置23将预定信息元素发送到另一CE，而在另一侧，经由I/O装置在承载部分处接收来自另一UE的相应预定信息元素。为此，承载部分也与信息元素识别部分30连接，该信息元素识别部分针对预定信息元素的存在监视到达CE 2处的数据流。信息元素识别部分30也可连接到存储装置25，以将接收到的数据与存储的预定信息元素集进行比较，从而对它们进行识别。

由信息元素识别部分30在数据流中识别出预定信息元素时，这些信息元素将被传送到应用部分28，该应用部分28被提供在处理装置中以便提供例如视频应用。为了将信息元素(或对应其的数据)从承载部分29传送到应用部分28，所以在其间提供消息接口27。通过该消息接口27，可在CE 2中将预定信息元素从承载层传送到应用层，从而可以基于直接从承载信令接收到的信息来本地地调节用于VT呼叫的应用协议设置。

还可以预想到除上述以外的其他方式以加速视频呼叫建立。例如，可以预想使用上述的BCIE和LCIE参数来传输用于应用协议的设置信息。例如，可以在那些参数的子字段中描述所有所需的应用协议信息。然而，应该注意到这些BCIE和LCIE参数不总是携带在两个MSC之间的链路上。例如如果转接网络包括模拟部分，则该承载能力信息丢失。这在图3中结合步骤S14和S19并通过“如果可用”来指示。因此，仅依赖于BCIE参数信息的机制将不会总起作用。另外，BCIE和LCIE参数的内容需要被仔细地标准化。因此，这些参数中的任意改变将需要对移动台和网元二者的更新，这将造成大的工作量和成本。

如上所指出，根据本发明，可以改进呼叫建立时间，特别是例如视频电话呼叫的多媒体呼叫的呼叫建立时间。基本上，当要建立例如VT呼叫时，在应用协议活跃之前，协议软件等将填充数据发送到对等实体。通过使用填充数据内的特定信息，对等实体能够立即检测到远程终端例如是一种类型的VT终端。该信息接着被传送到应用协议，其可以马上正确地调节协议参数。换句话说，呼叫建立过程中通常是某种“空闲时间”的阶段被用于传输应用协议参数。因此，可以通过在刚创建的透明比特管道上的承载建立后立即通过传送对等实体参数来绕过应用协议协商的常规阶段。这意味着以常规方式来执行承载建立，并且当比特管道被创建时，向对等实体通知期望应用协议特征的有关信息，即，本地视频协议设置。该信息接着被传送到应用协议栈以加速初始化过程并使得可以绕过应用协议握手。因此，在不需要额外的应用握手过程的情况下，可在相应的通信设备自身内本地地执行应用层协商。应该注意到在大多数情况下，MO和MT终端的视频协议参数彼此接近，并且因此通过知晓最早的可能状态中的对等端设置，可以绕过标准的和耗时的握手过程。

由于提出的方法对于现有的功能没有影响，所以本发明易于实施。例如，在其中一个CE不能检测到预定信息元素的存在或不能应用提出的机制时，VT呼叫建立例如可通过常规应用协议握手过程来以常规方式来继续。

另外，通过使用根据上述实施方式的机制，不像使用BCIE和LCIE参数的过程，例如，可以总是执行应用协议设置的协商。由于在此处描述的方法中，一旦承载比特管道存在，则进行协商，因此其总是发挥作用。

该过程也不会创建任意类型的互操作性(IOP)问题，因为其可以不考虑对等实体而使用。如果对等端不知道该方法，则其将进入的帧解译为垃圾。在使用BCIE信息的情况下，例如，虽然BCIE参数和视频应用协议协商二者在其可被使用前需要被很好地达成同意并且经IOP检测，但较老的移动/网络版本仍存在问题。然而，本实施方式中所描述的机制不会涉及此类的问题。

尽管上述的实施方式针对于两个通信设备的连接，但应该理解，本发明也可应用于其中多媒体呼叫中涉及多于两个的通信设备的情形。在此类的情形中，可在所涉及的通信设备的每个之间执行上述的步骤或一个通信设备可以被设置为中央服务器，该服务器与其他通信设备顺序地或并行地执行根据本发明的步骤。

如上所述，一种用于控制至少两个通信设备之间的多媒体呼叫建立的方法、一种相应的系统以及一种相应的通信设备，包括承载连接的建立，导致至少两个通信设备之间的数据传输信道的创建。

在创建数据传输信道后，在至少两个通信设备之间传送数据流，以保持数据传输信道的同步。预定信息元素被引入进数据流中，其中该预定信息元素指示用于多媒体呼叫的本地协议设置。从数据流中识别出预定信息元素，并且基于预定信息元素来调节用于多媒体呼叫的应用协议的参数。

应该理解，上述的描述和附图仅旨在通过例子来说明本发明。本发明的优选实施方式可因此在所附权利要求书的范围内变化。