CN1732665A

CN1732665A - 多媒体会话控制器

Info

Publication number: CN1732665A
Application number: CNA2003801080588A
Authority: CN
Inventors: 迈克尔·P·莱波雷; 斯蒂夫·R·奎特诺; 保罗·H·基兹瓦特; 丹尼尔·L·肖尔
Original assignee: Cisco Technology Inc
Current assignee: Cisco Technology Inc
Priority date: 2002-12-30
Filing date: 2003-11-26
Publication date: 2006-02-08
Anticipated expiration: 2023-11-26
Also published as: US20040125756A1; DE60331355D1; EP1579654A1; AU2003296016B2; CN100574316C; ATE458342T1; AU2003296016A1; US7532628B2; EP1579654B1; WO2004062229A1; CA2510624A1

Abstract

一种用于管理多媒体会话的方法，包括接收对发起包括第一媒体和第二媒体的多媒体会话的请求。该方法还包括建立与第一设备的第一委托会话以传递第一媒体，并且将第一委托会话与多媒体会话相关联。

Description

多媒体会话控制器

技术领域

本发明一般地涉及电信系统，更具体地说，涉及用于多媒体会话的复合控制器。

背景技术

例如会话发起协议(SIP)之类的分散式通信协议允许不需要集中呼叫控制的通信会话。这些通信协议允许设备彼此直接交换媒体，而不是通过例如呼叫管理器之类的中间媒介来进行交换。每个设备与其对等体之间建立独立的控制和媒体流。

发明内容

根据本发明，与用于分散式通信协议的用户代理有关的缺点和问题被显著减少或消除。具体地说，本发明的某些实施例提供了处理涉及与一个或多个用户设备的委托(delegated)媒体会话的多媒体会话的复合控制器。这提供了允许多个媒体设备参与一个多媒体会话的方法。

根据本发明的一个实施例，提供了一种用于管理多媒体会话的方法，其包括接收对发起多媒体会话的请求，所述多媒体会话包括第一媒体和第二媒体。该方法还包括建立与第一设备的第一委托会话以传递所述第一媒体，以及将所述第一委托会话与所述多媒体会话相关联。

根据本发明的另一实施例，提供了一种复合控制器，其包括第一接口、第二接口和处理器。所述第一接口接收对发起具有第一和第二媒体的多媒体会话的请求。所述第二接口建立与委托用户代理的委托会话，以与所述委托用户代理交换所述第一媒体。所述处理器将所述第一委托会话与所述多媒体会话相关联。

本发明的某些实施例重要技术优点包括增加了媒体和可用于分布式通信协议的专用特定设备的多样性。对复合控制器的使用允许多个设备的通信能力被合并入同一通信会话中，而无需每种设备建立单独的通信连接。这提高了整体效率，并降低了建立和控制多媒体连接的复杂度。

根据下面的附图、描述和权利要求，本发明的其它技术优点将对本领域的技术人员变得非常明显。而且，虽然上面已列举了具体的优点，但是各种实施例可包括所列优点中的全部、一些或一个优点也不包括。

附图说明

参照下面的描述并结合附图，可获得对本发明及其优点的更全面理解，在附图中：

图1示出了根据本发明的一个实施例的通信系统；

图2示出了图1的系统中的复合控制器；

图3示出了可由图2的复合控制器存储的会话信息表的示例；

图4是示出了在用户代理处，响应于请求而发起多媒体会话的方法的一个示例的流程图；

图5是示出了用于在复合控制器处发起多媒体会话的方法的示例的流程图；

图6是示出了用于在坞接(dock)到复合控制器的设备处发起多媒体会话的方法的示例的流程图；

图7是用于在复合控制器处接收对于多媒体会话的SIP请求的呼叫流示意图；

图8是在复合控制器处使用SIP来发起多媒体会话的呼叫流示意图；以及

图9是用于在坞接到运行SIP的复合控制器的设备处发起多媒体会话的呼叫流示意图。

具体实施方式

图1所示的通信系统100包括复合控制器(CC)102a和102b(统称为“CC 102”)，用于管理与端点104的通信会话。复合控制器102建立与一个或多个其它用户代理的主多媒体会话，其中所述其它用户代理可以是复合型的，也可以不是复合型的。CC 102在端点104之间建立委托媒体会话，并将其与主多媒体会话相关联，以使每个单独的端点104处理适当类型的媒体，同时对每个会话的控制由复合控制器102处理。于是，复合控制器102允许由CC 102所控制的单个多媒体会话中的不同媒体类型终止于不同的端点104。其媒体会话被CC 102管理的端点104被称为“坞接端点”。坞接端点104可以较持久的方式坞接，从而坞接端点104的所有通信可由CC 102管理。或者，端点104可以根据需要从与CC 102相关联的端点集合中有选择地被坞接，以使特定的端点104从事自管理式媒体会话，除非端点104被CC 102坞接。这样的端点104被称为“可用端点”。

术语“多媒体会话”泛指多种媒体类型的任何交换，并包括媒体的交换和用于管理每个媒体交换的控制或信令信息的任何有关交换。媒体类型可包括语音、视频、数据或任何其它合适形式的信息。信息的交换可根据允许端点104建立与其它端点104的独立媒体会话的任何合适的协议而发生。协议可包括会话发起协议(SIP)和任何其它对等、分布式或其它合适的通信协议。在多媒体会话中，CC 102处理用于坞接端点104和其它设备之间的媒体交换的信令和/或控制信息。因为媒体交换是由CC 102控制的，所以它们被称为委托媒体会话。CC 102还可以使用本地应用(称为“本地媒体会话”)来处理特定类型的媒体。

复合控制器(CC)102是指建立主多媒体会话的任何硬件和/或软件。在主多媒体会话中，CC 102管理多个媒体会话，并将多媒体会话中的各种媒体交换指定到一个或多个委托会话。CC 102维护关于耦合到CC 102的可用端点104的信息，从而当CC 102接收到多媒体请求时，它可以确定多个可被委托以会话的可用端点104。CC 102还可包括处理多媒体会话中的一种或多种媒体类型的合适的硬件、软件或其它组件或应用。例如，CC102可以将语音和视频委托给合适的端点104，而直接处理例如即时消息应用之类的数据交换。在管理单个媒体会话时，CC 102可与单个的端点104或管理对应的端点104集合的媒体会话的远程CC 102交换信令和/或控制信息。

端点104是指用于与其它端点104交换一种或多种媒体的任何设备、应用、硬件和/或软件。例如，端点104可包括模拟、数字或因特网协议(IP)电话、个人计算机、视频会议装备、无线通信设备、个人数字助理(PDA)、软件应用，或任何其它合适的设备或应用。在特定实施例中，端点104被装备为使用SIP来与其它设备协商通信会话。

应用服务器106代表任何服务器、处理器、计算机，或其它用于管理CC 102的合适组件。应用服务器106提供用于CC 102的用户接口，其允许用户发起多媒体会话、执行CC 102的任何合适的配置或任何合适的控制或管理任务。应用服务器106可包括任何合适的输入或输出设备，例如键盘、鼠标、图形用户接口(GUI)。通过提供用于CC 102的控制接口，应用服务器106的某些实施例允许用户管理多个媒体设备，就像它们是一个多媒体设备一样。

在操作中，CC 102接收对涉及一种或多种媒体类型的通信会话的请求。CC 102识别通信请求中的媒体类型，并且基于所述媒体类型，CC 102识别能够处理每种媒体的可用端点104。CC 102还可在本地媒体会话中直接处理特定的媒体类型。当CC 102尝试发起与所选择的端点104的委托媒体会话时，CC 102可以回复通信请求的发送者，向其表明：CC 102正在尝试建立会话。为了建立委托媒体会话，CC 102建立与端点104的控制连接，使得CC 102可以控制通过端点104的媒体交换。一旦建立了与端点104的委托媒体会话，CC 102就建立与通信请求的发送者的主多媒体会话。然后，端点104在CC 102所管理的委托会话中交换媒体，而CC 102在本地媒体会话中交换媒体。

CC 102也可以发起多媒体会话。CC 102的用户发起对多媒体通信的请求。响应于该请求，CC 102通过参考所存储的信息或通过询问可用端点104以确定它们的能力，来确定哪些媒体类型可用于委托或本地媒体会话。一旦可用媒体类型已被探知，则CC 102就将包括对每个所选媒体类型的请求的多媒体会话请求传递给所选择的一个或多个目的地。如果通信请求被接受，则CC 102建立任何委托会话和本地会话，从而端点104和/或CC 102可开始与目的地交换媒体。

在多媒体会话期间，CC 102也可以添加或删除特定的媒体类型。例如，如果端点104的用户希望交换视频，则用户之一可传递视频请求。CC102接收对添加媒体类型的请求，确定该媒体是否能在委托或本地媒体会话中处理，并且建立合适类型的会话。类似地，CC 102可以通过终止用于某媒体类型的委托会话，而从多媒体会话中删除该媒体类型。

CC 102还可接收来自端点104的对发起多媒体通信或添加媒体的请求。当请求是对多媒体会话的请求时，CC 102接收该请求、认识到该请求来自端点104，并且(可能和任何其它合适的媒体请求一起)中继该通信请求。例如，如果CC 102具有额外的即时消息能力，则CC 102可与语音通信请求一起请求即时消息会话。如果该通信请求被接受，则CC 102建立与请求端点104的委托媒体会话以及任何其它合适的本地或委托会话，这些会话都与主多媒体会话相关联。

图2更详细地示出了CC 102的具体实施例。CC 102包括处理器202、存储器204，以及接口。接口包括网络接口206、设备接口208，以及应用编程接口212。虽然接口被示为单独的部件，但是应当理解多个接口的功能可共享同一硬件和/或软件。

处理器202代表用于处理信息和执行与CC 102的功能有关的任何合适的任务的任意硬件和/或软件。处理器202可包括微处理器、微控制器、数字信号处理器(DSP)，或任何其它合适的硬件和/或软件。存储器204代表任何易失性或非易失性信息存储介质，包括磁介质、光介质、本地组件、远程组件、可清除介质、CD-ROM、DVD-ROM，或任何其它合适形式的信息存储设备。

接口代表任何真实或虚拟的端口或连接，包括允许CC 102与系统100的其它组件交换信息的任何合适的硬件和/或软件。网络接口206与其它CC 102或未坞接到CC 102的端点104交换信息，该信息可以包括媒体和/或信令或控制信息。设备接口208与坞接到CC 102的端点104交换信息。设备接口208包括端口210，每个端口210都对应于到坞接端点104之一的真实或虚拟连接。CC 102可通过端口210来识别所接收的信息的源，其中所述信息是从端口210处接收的。应用编程接口(API)212代表允许应用服务器106控制CC 102的操作的连接。

存储器204存储CC 102用来建立并管理主多媒体会话、委托媒体会话和本地媒体会话的信息。代码214代表被包含在计算机可读介质中的指令，所述指令被处理器202执行以执行各种任务。介质类型216表明可被CC 102及其相关联的端点104处理的各种媒体。设备标识符218唯一地标识了可用于坞接的端点104。媒体类型216和设备标识符218可在表或映射中相互关连，所述表或映射将每种媒体类型与一个或多个处理该媒体类型的设备相关联。本地媒体接口220代表用于处理CC 102本地的特定类型的媒体会话的指令。会话信息222维护活动的主多媒体会话、委托媒体会话和本地媒体会话的记录，还维护本地和委托会话与它们各自的主会话之间的关联。

在操作中，CC 102建立并管理主多媒体会话和相关联的委托和本地媒体会话。在接收到来自网络接口206的对多媒体会话的请求后，CC 102首先通过将该请求与存储在存储器204中的媒体类型216进行比较，来识别所请求的媒体类型。如果在媒体类型216中未发现特定媒体类型，则CC102可使用网络接口206，将错误消息返回到呼叫者。对于在存储器204中发现的媒体类型，CC 102建立用于每种媒体类型的媒体会话。

为了建立媒体会话，CC 102首先咨询设备标识符218和本地媒体接口220，以确定用于处理每种媒体的可用资源。CC 102对由本地媒体接口220所支持的媒体类型建立本地媒体会话，并通过在会话信息222中存储适当的信息来标识这些会话。CC 102使用设备接口208来接触端点104，以请求与能够处理剩余媒体类型的端点104进行会话。如果请求成功，则CC 102建立与所选择的端点104的委托媒体会话，并更新会话信息222以反映新的委托会话。一旦所有的媒体类型都被分配给委托或本地会话，CC102就建立与多媒体通信请求的发送者的主多媒体会话，并更新会话信息222，从而使委托和本地媒体会话与主会话相关联。CC 102还可从API 212接收各种命令，包括对发起与其它CC 102或端点104的多媒体会话的请求。

图3示出了CC 102可用来组织关于端点104、媒体类型216和会话信息222的信息的表300。表300对被组织为4列的信息进行关联。列302列出了用于处理媒体会话的可用设备，如用任意合适的标识符所标识的那样。在所描述的实施例中，设备由因特网协议(IP)地址标识。端点IP地址310标识对应于特定端点310的目的地址。本地地址302代表用于CC102自身的IP地址。

媒体类型304表明每个特定媒体类型304所关联的设备地址。例如，如果即时消息应用由CC 102处理，则特定媒体类型304“即时消息”与本地地址302相关联。每种媒体类型可与多个设备相关联，从而CC 102可根据需要或希望而建立与任何或所有可用媒体设备的媒体会话。类似地，特定的设备可处理多种媒体。CC 102可使用媒体类型列304和设备地址列302中的信息来确定用于处理多媒体通信请求中每种媒体类型的特定设备。

活动会话标识符306可根据任何合适的排列(例如发起会话的顺序)而被分配。当新的会话被建立和现存的会话被终止时，CC 102更新活动会话列306以反映这些变化。不具有活动媒体会话的设备可被分配以0值或被列为不活动。

主会话标识符308代表用于与每个活动媒体会话306相关联的主多媒体会话的标识符。例如，在涉及语音和视频二者的媒体会话中，两者的媒体会话标识符306可与同一主会话标识符308相关联。同样，当相关联的媒体会话被发起或终止时，CC 102更新列308以反映新的相关联的媒体会话。

虽然已经描述了表300的具体实施例，但是应当理解，CC 102可使用额外的或不同的信息来建立和管理媒体会话，而且可以任何合适的格式来实现上述组织。例如，信息可被组织在有关的数据库或其它信息格式中。CC 102可在接收到来自API 212或坞接端点104的新通信请求时，才发现可用的通信资源，而不是保持对设备能力的持续记录，因此允许信息在将设备添加到CC 102或从CC 102删除设备时被保存。用于设备和媒体会话的特定标识符也可变化。这种变化并不干扰CC 102的基本操作。

图4是示出了响应于通信请求，使用CC 102来发起多媒体会话的方法的一个示例的流程图400。在步骤402，CC 102接收来自发送者的对发起多媒体通信会话的请求。在步骤404，CC 102识别该多媒体请求的媒体类型。在步骤406，CC 102选择所述媒体类型之一，并在步骤408确定该媒体类型是否被支持。如果所选媒体类型不被支持，则CC 102可在步骤410向通信请求的发送者返回错误消息。如果所选媒体类型被支持，则CC102继续建立用于该媒体类型的媒体会话。

为了建立媒体会话，CC 102在步骤412确定支持该媒体类型的设备。该设备可以是可用端点104或在CC 102自身上运行的本地媒体处置器(handler)。然后在步骤414，CC 102请求将由CC 102控制的委托会话。在本地媒体会话情形下，CC 102可在步骤414启动该应用。然后在步骤416，CC 102确定对委托会话的请求是否被接受。如果请求被接受，则CC 102在步骤418建立与该设备的委托会话。如果请求被驳回(由于通信设备中的错误或故障或任何其它原因)，CC 102在步骤420尝试定位到支持该媒体类型的另一设备。如果定位到了另一设备，则在步骤414，CC102尝试建立与该设备的媒体会话。否则，CC 102确定该媒体类型不被支持，并且在步骤410发送错误消息。

当用于所选媒体类型的媒体会话被建立后，在步骤422，CC 102确定是否存在未被分配到媒体会话的剩余媒体类型。如果存在剩余媒体类型，则CC 102从步骤406开始，继续建立用于所述媒体类型的媒体会话。否则，CC 102建立与目的地的主多媒体会话。

在步骤424，CC 102传递对多媒体通信请求的接受信息。该接受信息可包括错误消息或其它表明特定媒体类型不被支持的指示。在步骤426，CC 102发起用于委托会话的控制信息交换，并且在步骤428，基于所述控制信息来发起设备之间的媒体交换。

图5是示出了由用户发起的、用于使CC 102建立与目的地的多媒体会话的请求的流程图500。在步骤502，CC 102接收对发起多媒体会话的命令。该请求可以是通过API 212或端点104而由用户发起的，例如当呼叫者拿起电话的话筒并拨号时。或者，该请求可由CC 102的子例程、应用服务器106上的应用或任何其它合适的控制器自动发起。用户或通信请求的发起者可指定具体的媒体类型，或允许根据默认值、根据CC 102能够处理的媒体类型或根据任何其它合适的方法来选择媒体类型。对发起通信的请求还包括通信连接的目的地。

在一个实施例中，CC 102通过在步骤504请求端点104的能力来确定可用媒体类型。在步骤506，CC 102接收任意坞接设备的能力。在可替换实施例中，对多媒体会话的请求的发起者可指定媒体类型，该媒体类型可根据默认值而被选择，或通过与目的地通信来确定通信另一端所支持的媒体类型而被确定。一般地，CC 102可使用任何适当的方法来选择媒体类型。

一旦CC 102通过任意一种上述方法确定了可用的媒体类型，则在步骤510，CC 102将对多媒体会话的请求传递到所请求的目的地。如果CC102在步骤512接收到接受信息，则在步骤516，CC 102建立由CC 102控制的委托或本地媒体会话。CC 102继续建立媒体会话(由从判断步骤518出发的流代表)，直到所有媒体类型都分别与媒体会话相关联。一旦媒体会话被建立，则CC 102在步骤520向目的地确认多媒体会话，并在步骤522向各个设备确认它们各自的委托会话。然后，设备可以开始在由CC102控制的本地和委托媒体会话中交换媒体。

图6是示出了用于从坞接到CC 102的设备发起多媒体会话和用于向现存多媒体会话添加新的媒体类型的方法的一个示例的流程图600。在步骤602，CC 102接收来自坞接端点104的、对发起与目的地的通信连接的请求。在步骤604，CC 102确定什么额外媒体对通信可用。或者，坞接端点104的用户可指定某些媒体类型作为通信请求的一部分。一旦媒体类型被确定，则在步骤606，CC 102将多媒体会话请求传递到所选目的地。然后在步骤608，CC 102接收来自目的地的接受信息。

然后，对于每种所请求的媒体类型，CC 102建立委托或本地媒体会话。在步骤610，CC 102选择媒体类型。在步骤612，CC 102建立委托或本地媒体会话。判断步骤614继续建立媒体会话的循环，直到多媒体会话的所有媒体类型都与媒体会话相关联。当所有媒体会话都被建立时，在步骤616，CC 102建立与目的地的主多媒体会话。

在多媒体会话期间，CC 102可向多媒体会话添加一种或多种媒体。对媒体类型的添加或减少的请求可例如经由API 222而直接从用户处接收到，或经由网络接口206而从远程设备接收到。下面的描述给出了从CC102的用户接收添加请求的示例，但是一般地，添加或减少请求可以任何合适的方式被接收。在步骤618，CC 102从API 212接收添加媒体的请求。在步骤620，CC 102识别本地或坞接设备来处理该媒体类型。然后在步骤622-626，CC 102建立与该设备的媒体会话。

在步骤622，CC 102请求与所选设备的新委托会话。CC 102在步骤624接收来自所选设备的接受信息，并在步骤626建立与该设备的委托会话。然后在步骤628，CC 102使用多媒体会话的通信连接发送对添加新媒体的请求。在步骤630，CC 102接收来自目的地的接受信息，并在步骤632将新媒体会话与主多媒体会话相关联。如果来自API 212的添加请求包括多个媒体类型，则CC 102可以对每种额外的媒体类型重复步骤620到632。

在某些情形下，目的地设备或坞接设备可能由于故障、不支持所选媒体或其它适当理由而拒绝对通信连接的请求。在此情形下，CC 102可发送错误消息到尝试向现存多媒体会话添加媒体的一方，不论该方是CC 102的用户还是目的地CC 102或端点104的用户。

图7-9是示出了在SIP环境下，CC 102的操作示例的呼叫流示意图，具体地说，示出了CC 102与其它设备交换的SIP消息。SIP术语“用户代理”是指处理特定媒体类型的端点104。图7示出了到使用SIP的CC102的特定实施例的传入多媒体呼叫的呼叫流700的示例。呼叫流700涉及源用户代理(源UA)702，其发送多媒体请求到具有两个坞接设备(语音委托用户代理(语音委托UA)706和视频委托用户代理(视频委托UA)708)的复合控制器(CC)704。源UA 702代表CC 704与之通信的另一端点104或CC 102。“源”是指这样的事实，即UA 702是对发起多媒体会话的请求的发出者；当UA 702接收来自CC 704的对发起多媒体会话的请求时，它也可以被称为“目的地UA”704。

CC 704从源UA 702接收用于涉及语音、视频和即时消息这3种媒体类型的多媒体会话的邀请消息710。当CC 704尝试建立用于语音和视频的适当的委托会话时，它作出临时的“尝试”响应711。在所示实施例中，CC 102在本地处理即时消息媒体。

为了建立委托语音会话，CC 704发送邀请消息712到语音委托UA706。语音委托UA 706响应以接受信息(OK)714，CC 704返回确认(ACK)716，表明已接收到OK 714。一旦该接受信息被确认，就认为委托语音会话已建立。为了建立委托视频会话，CC 704发送邀请718到视频委托UA 708，接收OK 720响应，并用ACK 722来确认OK 720。这就建立了委托视频会话。

一旦委托会话被建立，CC 704就通过向源UA 702发送用于多媒体会话的OK 724来更新它的临时响应。源UA返回ACK 726，从而在源UA702和CC 704之间建立多媒体会话。然后，源UA 702与适当的目的地UA交换媒体。语音媒体流728被传递给语音委托UA 706，而CC 704处理与语音媒体流728相关联的相关信令和/或控制信息。视频媒体流730被类似地传递到视频委托UA 708。即时消息媒体流732被CC 704在本地处理，因此即时消息媒体流732终止于CC 704。

图8示出了响应于从API 212接收的命令或接收命令的其他合适的方法，由CC 704发起的多媒体呼叫的呼叫流800的示例。响应于接收发起多媒体会话的命令，CC 704通过传递用于请求核实能力的“无媒体要约(no media offer)”消息802和810来确定设备的可用性。语音委托UA706响应以语音OK 804，表明它支持语音媒体，而视频委托UA 708响应以视频OK 812。CC 102用ACK消息806和814来向每个设备对语音OK804和视频OK 812进行确认。ACK消息806和814还包括保持请求，表明UA 706和708应当在待机模式中等待媒体会话的建立。

在CC 704探知坞接UA 706和708的能力后，CC 704传递邀请消息816到目的地UA 702(称为“目的地UA”是因为它接收对发起多媒体会话的请求)。该邀请消息可以包括对应于先前确定的媒体能力的任意媒体类型以及CC 704所支持的任意媒体类型，例如所示实施例中的即时消息。对于该请求中的所有媒体类型，目的地UA对该请求响应以OK 818，如上面结合图7所述。响应于OK 818，CC 704发送邀请消息820到语音委托UA 706，发送邀请消息824到视频委托UA 708，以建立与这些设备的媒体会话。语音委托UA 706响应以语音OK 824，而视频委托UA 708响应以视频OK 826。CC 704可进行检查以确定语音OK 824和视频OK826与能力检查中的语音OK 804和视频OK 812相匹配。如果它们不匹配，则CC 704可确定CC 704的实际能力不匹配到目的地UA 702的邀请消息816中所表明的能力，在此情形下，必须放弃所尝试的多媒体连接的部分或全部，或者采取其它补救动作。

假设媒体会话都恰好匹配，则CC 704通过传递ACK消息828来向目的地UA确认多媒体会话。CC 704还通过传递ACK消息830和832来向语音委托UA 706和视频委托UA 708确认委托媒体会话。一旦所有适当的多媒体和委托会话都被接受和确认，则即时消息媒体流834、语音媒体流836和视频媒体流838就在目的地UA 702和处理每种媒体类型的各个设备之间被建立。

图9是由坞接设备发起的多媒体会话的呼叫流900的示例，其包括在呼叫期间添加媒体。在所示实施例中，语音委托用户代理706将想要发送给目的地UA 702的语音邀请消息902发送到CC 704。CC 704识别出邀请消息902是针对目的地UA 702的，并且还确定了该呼叫可能希望的任意额外媒体。CC 704可基于邀请消息902本身或基于对它自身能力和/或坞接设备能力的内部确定而作出此确定。在所示实施例中，CC 704确定即时消息(CC 704所支持的一种媒体类型)将被添加到语音邀请消息902中。

一旦多媒体请求的媒体已被确定，CC 704就传递多媒体邀请904到目的地UA 702。目的地UA 702响应以多媒体OK消息906，然后CC 704对多媒体OK消息906响应以ACK消息908。CC 704还使用语音OK 910来接受来自语音委托UA 706的原始语音邀请消息902，从而建立与语音委托UA 706的委托语音会话。语音委托UA 706以ACK消息912来确认委托语音会话。然后，即时消息媒体流916和语音媒体流918被建立在用于这些媒体类型的各个设备之间。

在多媒体呼叫期间，CC 704从API 212接收对添加视频的请求918。响应于请求918，CC 704发送“无媒体要约”消息920到视频委托UA708，以核实其视频能力。视频委托UA响应以视频OK 922，CC 704用ACK消息924来确认视频OK 922，在向多媒体会话添加视频时，该消息将视频委托UA 708置于保持状态。

一旦视频委托会话被建立，CC 704就向目的地UA 702传递邀请请求926，该请求包括来自原始多媒体会话的语音和即时消息，还包括视频。目的地UA 702返回多媒体OK 928，其指定了将在多媒体会话中使用的媒体类型。有时，例如当目的地UA 702在语音通信中支持一种语音媒体，而在视频会议中支持不同类型的语音媒体时，目的地UA 702可在响应中请求不同的媒体类型。如方框930所示，然后，CC 704可重新邀请语音委托UA进入支持新的语音类型的语音会话，如果新的语音类型不被支持，则CC 704可能放弃对添加视频的尝试。

假设多媒体OK 928中的所有媒体都被支持，则CC 704可添加视频到多媒体会话。CC 704发送视频邀请消息932到视频委托UA 708，视频委托UA 708响应以视频OK 934。如果视频OK 934不匹配视频OK 922，则CC 702可确定多媒体邀请926中传递的视频类型不被支持，并且可能放弃对添加视频的尝试，如方框936所示。否则，CC 702用ACK消息940向视频委托UA 708确认委托视频会话，并用ACK消息938向目的地UA702确认新的多媒体会话，包括视频。然后，目的地UA 702使用视频媒体流942来与视频委托UA 708交换视频。

虽然利用几个实施例描述了本发明，但是本领域的技术人员可对其作出多种改变、变化、替换、变型以及修改，本发明将包括这些改变、变化、替换、变型以及修改，它们都落在所附权利要求的范围内。

Claims

1.一种用于管理多媒体会话的方法，包括：

接收请求以发起多媒体会话，所述多媒体会话具有第一媒体和第二媒体；

建立与第一设备的第一委托会话以传递所述第一媒体；以及

将所述第一委托会话与所述多媒体会话相关联。

2.如权利要求1所述的方法，其中：

所述第一媒体是语音；并且

所述第二媒体是即时消息。

3.如权利要求1所述的方法，还包括：

建立与第二设备的第二委托会话以传递所述第二媒体；以及

将所述第二委托会话与所述多媒体会话相关联。

4.如权利要求3所述的方法，其中关联所述第一委托会话的步骤包括：

建立与远程设备的多媒体会话；以及

将所述第一委托会话与所述多媒体会话相关联。

5.如权利要求4所述的方法，其中所述远程设备与所述第一设备传递第一媒体，与所述第二设备传递第二媒体。

6.如权利要求5所述的方法，其中所述远程设备进行以下操作：

建立到第三设备的第三委托会话，以与所述第一设备传递第一媒体；以及

建立到第四设备的第四委托会话，以与所述第二设备传递第二媒体。

7.如权利要求1所述的方法，其中：

所述方法的步骤由复合控制器执行；并且

所述方法还包括通过执行所述复合控制器的应用来向用户输出所述第二媒体。

8.如权利要求1所述的方法，其中所述请求接收自应用编程接口。

9.一种用于管理多媒体会话的方法，包括：

接收第一邀请命令，以发起具有第一媒体和第二媒体的多媒体会话；

传递第二邀请命令，以建立与第一设备的第一委托会话，从而传递第一媒体；以及

将所述第一委托会话与所述多媒体会话相关联。

10.如权利要求9所述的方法，其中：

所述第一媒体是语音；并且

所述第二媒体是数据。

11.如权利要求9所述的方法，还包括：

传递第三邀请命令，以建立与第二设备的第二委托会话，从而传递第二媒体；以及

将所述第二委托会话与所述多媒体会话相关联。

12.如权利要求9所述的方法，其中关联所述第一委托会话的步骤包括：

建立与远程设备的主会话；以及

将所述第一委托会话与所述主会话相关联。

13.如权利要求9所述的方法，其中所述远程设备与所述第一设备传递第一媒体，与第二设备传递第二媒体。

14.如权利要求9所述的方法，其中所述远程设备进行以下操作：

15.如权利要求9所述的方法，其中所述请求接收自应用编程接口。

16.如权利要求9所述的方法，其中：

所述邀请消息具有由通信协议指定的格式；以及

所述通信协议包括允许一个或多个通信设备彼此建立通信会话的对等协议。

17.一种复合控制器，包括：

第一接口，其可操作来接收请求，以发起具有第一和第二媒体的多媒体会话；

第二接口，其可操作来建立与第一委托用户代理的第一委托会话，以与所述第一委托用户代理交换所述第一媒体；以及

处理器，其可操作来将所述第一委托会话与所述多媒体会话相关联。

18.如权利要求17所述的复合控制器，其中：

所述第一媒体是语音；并且

所述第二媒体是数据。

19.如权利要求18所述的复合控制器，其中：

所述第二接口还可操作来建立与第二委托用户代理的第二委托会话以传递所述第二媒体；以及

所述处理器还可操作来将所述第二委托会话与所述多媒体会话相关联。

20.如权利要求17所述的复合控制器，其中所述处理器还可操作来建立与远程设备的主会话。

21.如权利要求17所述的复合控制器，还包括可操作来向用户传递所述第二媒体的用户接口。

22.如权利要求17所述的复合控制器，其中：

所述第一接口包括应用编程接口；并且

所述请求接收自应用。

23.包含在计算机可读介质中的逻辑，该逻辑可操作来：

建立与第一设备的第一委托会话以传递所述第一媒体；以及

将所述第一委托会话与所述多媒体会话相关联。

24.如权利要求23所述的逻辑，其中关联所述第一委托会话的步骤包括：

建立与远程设备的主会话；以及

将所述第一委托会话与所述主会话相关联。

25.如权利要求23所述的逻辑，其中所述逻辑还可操作来：

建立与第二设备的第二委托会话，以传递所述第二媒体；以及

将所述第二委托会话与所述多媒体会话相关联。

26.一种复合控制器，包括：

用于接收请求以发起主多媒体会话的装置，所述主多媒体会话具有第一媒体和第二媒体；

用于建立与第一设备的第一委托会话以传递所述第一媒体的装置；以及

用于将所述第一委托会话与所述多媒体会话相关联的装置。

27.如权利要求26所述的系统，还包括：

用于建立与第二设备的第二委托会话以传递所述第二媒体的装置；以及

用于将所述第二委托会话与所述多媒体会话相关联的装置。

28.一种系统，包括：

第一复合控制器；

第二复合控制器，其可操作来建立包括至少两种媒体类型的、与所述第一复合控制器的主多媒体会话；

耦合到所述第一复合控制器的第一通信设备，其可操作来在对应于所述媒体类型之一的第一媒体会话中交换媒体，其中所述第一媒体会话与所述主多媒体会话相关联，所述第一媒体会话由所述复合控制器控制；

耦合到所述第二复合控制器的第二通信设备，其可操作来在对应于所述媒体类型之一的第二媒体会话中交换媒体，其中所述第二媒体会话与所述主多媒体会话相关联，所述第二媒体会话由所述第二复合控制器控制；以及

第三通信设备，其可操作来在对应于所述媒体类型之一的第三媒体会话中交换媒体，其中所述第三媒体会话与所述主多媒体会话相关联，并且所述第三媒体会话由所述复合控制器之一控制。

29.如权利要求28所述的系统，其中：

所述第一和第二复合控制器都包括可操作来输出第一媒体类型的用户接口；

所述第一和第二通信设备可操作来输出第二媒体类型；并且

所述主多媒体会话中的所述至少两种媒体类型包括所述第一和第二媒体类型。

30.如权利要求28所述的系统，其中所述第三通信设备包括所述第一复合控制器的输出设备。

31.如权利要求28所述的系统，其中：

所述第三通信设备耦合到所述第一复合控制器；并且

所述第三通信设备所交换的媒体类型不同于所述第一通信设备所交换的媒体类型。

32.一种用于管理多媒体会话的方法，包括：

提供运行会话发起协议的复合控制器以及坞接到所述复合控制器的通信设备；

在所述复合控制器与一个或多个远程设备之间交换第一会话发起协议消息，以建立包括至少两种媒体类型的、与所述远程设备的主多媒体会话；

与所述通信设备交换第二会话发起协议消息，以建立包括从所述至少两种媒体类型中选出的至少一种媒体类型的委托媒体会话；以及

将所述委托媒体会话与所述主多媒体会话相关联。

33.如权利要求32所述的方法，其中交换所述第一会话发起协议消息的步骤包括：

向所述通信设备传递用于所述委托媒体会话的会话发起协议邀请消息；

从所述通信设备接收用于所述委托媒体会话的会话发起协议OK消息；以及

向所述通信设备传递对所述OK消息的确认。

34.如权利要求32所述的方法，其中交换所述第二会话发起协议消息的步骤包括：

传递用于所述主多媒体会话的会话发起协议邀请消息；以及

接收用于所述主多媒体会话的会话发起协议OK消息。

35.如权利要求32所述的方法，其中：

交换所述第一会话发起协议消息的步骤包括：

从所述通信设备接收用于所述委托媒体会话的第一会话发起协议邀请消息；以及

传递第一会话发起协议OK消息；并且

交换所述第二会话发起协议消息的步骤包括：

响应于接收到所述第一会话发起协议邀请消息，选择用于所述主多媒体会话的一种或多种额外的媒体类型；

向所述一个或多个远程设备传递用于所述主多媒体会话的第二会话发起协议邀请消息；以及

接收响应于所述第二会话发起协议邀请消息的第二会话发起协议OK消息，其中所述第一会话发起协议OK消息是响应于接收到所述第二会话发起协议OK消息而被传递的。