在融合互联网协议消息服务中控制用于互配的会话的方法和装置及其系统
阅读：534发布：2023-01-25
专利汇可以提供在融合互联网协议消息服务中控制用于互配的会话的方法和装置及其系统专利检索，专利查询，专利分析的服务。并且公开了一种在支持订制融合互联网协议(IP)消息(CPM)服务的第一客户端和没有订制该CPM服务的第二客户端之间的CPM会话的CPM 服务器 中的会话控制方法，该会话控制方法包括：在通过CPM服务器和互配功能(IWF)在第一客户端和第二客户端之间发起该CPM会话之后，从第一客户端接收包括特定媒体的会话 修改 请求 消息；通过发起的CPM会话向IWF发送包括该特定媒体的会话修改请求消息；以及从该IWF接收响应消息，该响应消息包括对该包括特定媒体的会话修改请求消息的拒绝理由。，下面是在融合互联网协议消息服务中控制用于互配的会话的方法和装置及其系统专利的具体信息内容。
1.一种在用于支持订制融合互联网协议IP消息CPM服务的第一客户端和不订制CPM服务的第二客户端之间的CPM会话的CPM服务器中的会话控制方法，该会话控制方法包括步骤：
在通过CPM服务器和互配功能IWF在第一客户端和第二客户端之间发起该CPM会话之后，从第一客户端接收包括多个媒体的会话修改请求消息；
通过发起的CPM会话向该IWF发送包括该多个媒体的会话修改请求消息；以及从该IWF接收响应消息，该响应消息包括基于确定该多个媒体的至少一个不被IWF支持的拒绝理由。
2.如权利要求1所述的会话控制方法，还包括：向互配选择功能ISF发送对该多个媒体的至少一个的会话请求。
3.一种在用于支持订制融合互联网协议IP消息CPM服务的第一客户端和不订制CPM服务的第二客户端之间的CPM会话的互配功能IWF中的会话控制方法，该会话控制方法包括步骤：
在通过CPM服务器和该IWF在第一客户端和第二客户端之间发起该CPM会话之后，通过该CPM服务器从第一客户端接收包括多个媒体的会话修改请求消息；以及基于确定该多个媒体不被IWF支持向该CPM服务器发送响应消息，该响应消息包括指示该多个媒体不被该IWF支持的拒绝理由。
4.一种用于支持订制融合互联网协议IP消息CPM服务的第一客户端和不订制CPM服务的第二客户端之间的CPM会话的互配装置，该互配装置包括：
至少一个互配功能IWF，用于支持多个媒体，以及基于接收到对不被该IWF支持的多个媒体的至少一个的互配请求，产生作为该多个媒体的至少一个不被该IWF支持的指示的拒绝理由；和
互配选择功能ISF，用于在通过该CPM服务器和IWF在第一客户端和第二客户端之间发起CPM会话之后，当通过CPM服务器从第一客户端接收到包括多个媒体的会话修改请求消息时，从该至少一个IWF当中选择负责该多个媒体的互配的实体。
5.如权利要求4所述的互配装置，还包括控制器，用于当从IWF接收到指示该该多个媒体的至少一个不被该IWF支持的拒绝理由时，指令该ISF重新选择负责该多个媒体的至少一个的互配的实体。
6.一种在用于支持订制融合互联网协议IP消息CPM服务的第一客户端和不订制CPM服务的第二客户端之间的CPM会话的CPM服务器中的会话控制方法，该会话控制方法包括步骤：
从第一客户端接收包括多个媒体的会话发起消息；
通过互配选择功能ISF向互配功能IWF发送包括该多个媒体的会话发起消息；以及通过该ISF从该IWF接收响应消息，该响应消息包括基于确定该多个媒体的至少一个不被IWF支持的拒绝理由。
7.如权利要求6所述的会话控制方法，还包括：向该ISF重新发送包括该多个媒体的至少一个的会话发起消息。
8.一种在用于支持订制融合互联网协议IP消息CPM服务的第一客户端和不订制CPM服务的第二客户端之间的CPM会话的互配功能IWF中的会话控制方法，该会话控制方法包括步骤：
通过CPM服务器从第一客户端接收包括多个媒体的会话发起消息；以及基于确定该多个媒体不被IWF支持，向该CPM服务器发送响应消息，该响应消息包括指示该多个媒体的至少一个不被该IWF支持的拒绝理由。
9.一种用于支持订制融合互联网协议IP消息CPM服务的第一客户端和不订制CPM服务的第二客户端之间的CPM会话的互配装置，该互配装置包括：
至少一个互配功能IWF，用于支持多个媒体，以及基于接收到对不被该IWF支持的多个媒体的至少一个的互配请求，产生指示相应的媒体不被该IWF支持的拒绝理由；和互配选择功能ISF，用于当通过CPM服务器从第一客户端接收到包括多个媒体的会话发起请求消息时，从该至少一个IWF当中选择负责该多个媒体的互配的实体。
10.如权利要求9所述的互配装置，还包括控制器，用于指令该ISF重新选择负责该多个媒体的至少一个的互配的实体。
在融合互联网协议消息服务中控制用于互配的会话的方法
和装置及其系统
技术领域
[0001] 本发明涉及用于控制用于融合IP消息服务和非融合IP消息服务之间的互配的会话的方法，更具体地涉及用于以发起融合IP消息服务和非融合IP消息服务之间的会话的方式控制会话、修改已经发起的会话等等的方法。
背景技术
[0002] 在现有移动环境中，终端执行一次性的消息，诸如短消息服务(SMS)消息、多媒体消息服务(MMS)消息等等，但是用户期望便于在有线环境中通过即时信使与别人对话的消息服务。即时消息服务已经基于会话发起协议/互联网协议(SIP/IP)核心网络被引入到终端和网络中。此外，由于客户和企业对按键通话(例如步话机)的需要，已经开发了基于SIP/IP核心网络的通过蜂窝的按键通话(PoC)服务和系统。此外，包括企业和通信行业的市场的急剧变化增加了对集成和处理各种类型的接收的消息的需要。
[0003] 考虑到这一点，开放移动联盟(OMA)，一个建立移动解决方案和服务的国际开放标准的标准组织，近来已经开发了通过SIP/IP核心网络实现的融合互联网协议(IP)消息(CPM)服务的技术标准。
[0004] CPM服务是基于IP多媒体子系统(IMS)的消息服务，其将诸如SMS、MMS等之类的现有消息服务集成到单个服务中并且基于IP提供集成的单个服务。与发送/接收可能在有限的网络和终端内的现有消息服务不同，CPM服务不管终端的种类、媒体的类型、网络的种类以及服务的类型如何，都提供基于IP的融合服务。
[0005] 这样的CPM服务必须能够集成和处理所有类型的现有消息。因此，CPM服务需要SMS消息格式、MMS消息格式、即时消息服务消息格式、非CPM消息格式(例如PoC)和CPM消息格式之间的相互转换。非CPM消息格式和CPM消息格式之间的相互转换被称为“互配”。
[0006] CPM服务支持与各种类型的非CPM服务的互配。当消息的发送者和接收者属于不同的网络区域时，可以根据每个服务情形在发送者的网络或接收者的网络中执行互配。为了提供与非CPM服务的互配，CPM系统必须配置各种网络实体。将参考图1描述构成CPM系统的网络实体的功能和相互关系。
[0007] 图1示出了CPM系统的实体。CPM系统包括CPM客户端110、CPM服务器120、互配选择功能(ISF)130、互配功能(IWF)140、SIP/IP核心网络150和远程SIP/IP核心网络151。尽管非CPM客户端111和非CPM服务器160不是CPM系统的实体，但是在该图中示出了它们以便于描述CPM系统的互配。
[0008] CPM客户端110是指CPM服务用户。CPM客户端110产生融合消息以发送给CPM服务器120，并从CPM服务器120接收另一个CPM客户端或非CPM客户端111发送的消息。非CPM客户端111是订制非CPM服务的客户端，并且与相应的非CPM服务器160交换消息。
[0009] CPM服务器120处理从CPM客户端110或另一个CPM服务器接收到的消息。为此，CPM服务器120确定是否需要互配。也就是说，CPM服务器120确定对于接收的消息是否需要互配以便与非CPM服务器160通信。
[0010] 例如，如果CPM服务器120确定需要互配，则CPM服务器120向ISF130传送接收的消息。如果CPM服务器120确定不需要互配，则CPM服务器120向接收CPM客户端或接收CPM客户端所属的CPM服务器传送接收的消息。也就是说，当接收CPM客户端与CPM服务器120属于相同的网络区域时，CPM服务器120向该接收CPM客户端传送接收的消息。但是，当接收CPM客户端与CPM服务器120属于不同的网络区域时，CPM服务器120向该不同的网络区域的CPM服务器传送接收的消息。此外，CPM服务器120向与接收的消息的目的地址对应的非CPM客户端111传送从ISF 130或IWF 140接收到的用于互配的消息。
[0011] ISF 130选择能够最有效地将从CPM服务器120接收到的消息传送到接收方的非CPM服务器160，并将接收的消息传送到实际上负责与选择的非CPM服务器160互配的IWF140。
[0012] IWF 140是用于提供与非CPM服务的直接互配的功能实体，并且执行CPM和非CPM服务消息的格式之间的相互转换以然后将转换后的消息传送到非CPM服务器160。
[0013] SIP/IP核心网络150是用于将基于SIP的服务的控制信号、由客户端或其服务实体产生的消息等传送到接收者或其它实体的功能实体。为此，SIP/IP核心网络150可以与属于其它提供者区域的SIP/IP核心网络交换消息。
[0014] 远程SIP/IP核心网络151是由另一个网络提供者提供和管理的SIP/IP核心网络，并且具有与SIP/IP核心网络150相同的功能。尽管图1没有示出，但是用于提供CPM和非CPM服务的实体、设备和系统可以在远程SIP/IP核心网络151中实现。
[0015] 非CPM服务器160用来提供除了CPM服务之外的消息服务。由非CPM服务器150提供的消息服务包括SMS、MMS、即时消息服务、PoC等等。
[0016] 现在将参考图2描述互配操作。图2示出了用于CPM服务和非CPM服务之间的互配的消息发送/接收。具体地，图2示出了在发送CPM客户端110请求接收非CPM客户端111建立会话并且CPM客户端110请求的任何媒体类型能够在任何单个IWF中处理的假定之下的消息发送/接收。
[0017] 在步骤201中，CPM客户端110向CPM服务器120发送请求会话发起的INVITE消息。INVITE消息包括用于会话描述协议(SDP)形式的会话发起的必需信息。
[0018] 在步骤203中，在从CPM客户端110接收到INVITE消息时，CPM服务器120检查接收客户端是否是CPM服务用户并且是否处于可用状态，从而确定是否需要互配。当接收客户端是非CPM客户端时需要互配，以及当接收客户端是CPM客户端并且处于可用状态或者接收客户端是CPM客户端并且处于不可用状态时不需要互配。这里假定接收客户端是非CPM客户端111。因而，在步骤205中，CPM服务器120向ISF 130传送INVITE消息。但是，如果不需要互配，则执行不同的操作。也就是说，当接收客户端是CPM客户端并且处于可用状态时，将INVITE消息传送到接收CPM客户端以发起会话。此外，当接收客户端是CPM客户端并且处于不可用状态时，可以根据用户设置将INVITE消息删除、暂时存储在CPM服务器120中、或传送到ISF 130以通过非CPM服务进行消息转发。但是，图中没有示出此情形。
[0019] 考虑到接收客户端的存在和优选、INVITE消息请求的媒体类型、接收客户端订制的服务等等，ISF 130在步骤207中选择最适合于执行CPM服务和非CPM服务之间的互配的IWF 140，并在步骤209中将INVITE消息传送到选择的IWF 140。存在是指包括客户端订制的服务的类型的信息，以及优选是指用户设置，等等。
[0020] 在步骤211中，在接收到INVITE消息时，IWF 140确定它是否能够支持包括在INVITE消息中的并且为之请求会话发起的媒体类型。假定IWF 140能够支持请求的媒体类型，则在步骤211中，IWF 140基于适合于非CPM服务的格式，将接收的INVITE消息转换成非CPM消息。仅供参考，如下转换INVITE消息：当IWF 140可支持的非CPM服务是诸如SIMPLE IM、POC等等之类的基于SIP的服务时，INVITE消息中的特定报头、参数或SDP体被适配为相应的非CPM消息格式，以及当IWF 140可支持的非CPM服务是诸如SMS、MMS等等之类的基于非SIP的服务时，INVITE消息被转换为适合于相应的非CPM服务的协议的消息格式。
[0021] 如果请求的媒体类型没有一个能被IWF 140支持，则IWF 140向ISF 130发送相应的响应消息(例如，“415 Unsupported Media Type(不支持的媒体类型)”)。在接收到“415 Unsupported Media Type”消息时，ISF 130可以根据服务策略，将该消息经由CPM服务器120传送到发送CPM客户端110，或选择另一个IWF并重试互配。此外，如果请求的媒体类型中的一些能够被IWF 140支持，则在消息转换过程中忽略对不支持的媒体类型的会话请求。
[0022] 在步骤213中，IWF 140向相应的非CPM服务器160传送转换后的非CPM消息，非CPM服务器160又在步骤215中将转换后的非CPM消息传送到接收非CPM客户端111。在步骤217和219中，非CPM客户端111响应于从非CPM服务器160接收到的非CPM消息，将响应消息经由非CPM服务器160传送到IWF 140。
[0023] 在步骤221中，IWF 140将经由非CPM服务器160接收的响应消息转换成适合于CPM消息格式的消息，例如根据SIP消息格式的OK消息，然后在步骤223中将转换后的响应消息传送到ISF 130。在步骤225中，ISF 130将转换后的响应消息传送到CPM服务器120。
[0024] 在步骤227中，CPM服务器120发起与IWF 140的用于允许的媒体类型的会话，然后在步骤229中向发送CPM客户端110发送OK消息、对步骤201中的会话发起消息的响应消息。随后，在步骤231中，CPM客户端发起与CPM服务器120的用于允许的媒体类型的发送/接收的会话。
发明内容
[0025] 技术问题
[0026] 但是，传统的CPM系统中的上述互配操作具有以下问题。当CPM客户端110请求的媒体类型中仅仅一些能够被IWF 140支持时，对于不支持的媒体类型不执行互配，并因而不能向它们提供CPM服务，如步骤211所述。由于这引起CPM服务的质量的恶化，因此需要最小化这样的限制。
[0027] 技术方案
[0028] 因此，已经做出本发明以至少解决现有技术中存在的上述问题，并且本发明提供一种在CPM系统中甚至对于特定的IWF不支持的媒体类型也支持互配的方法。
[0029] 此外，本发明提供一种在CPM系统中对于特定的IWF不支持的媒体类型选择另一个IWF的方法。
[0030] 此外，本发明提供一种在CPM系统中用于根据媒体类型发起与不同的IWF的会话并且控制发起的会话的方法。
[0031] 此外，本发明提供一种在CPM系统中通过向发起的会话添加新的媒体来修改根据媒体类型发起的与不同的IWF的会话的方法。
[0032] 此外，本发明提供一种在CPM系统中通过删除包括在发起的会话中的媒体来修改根据媒体类型发起的与不同的IWF的会话的方法。
[0033] 此外，本发明提供一种在CPM系统中通过删除包括在发起的会话中的媒体并且向发起的会话添加新的媒体来修改根据媒体类型发起的与不同的IWF的会话的方法。
[0034] 根据本发明的一方面，提供一种在支持订制融合IP消息(CPM)服务的第一客户端和没有订制该CPM服务的第二客户端之间的CPM会话的CPM服务器中的会话控制方法，该会话控制方法包括：在通过CPM服务器和互配功能(IWF)在第一客户端和第二客户端之间发起该CPM会话之后，从第一客户端接收包括特定媒体的会话修改请求消息；通过发起的CPM会话向IWF发送包括该特定媒体的会话修改请求消息；以及从该IWF接收响应消息，该响应消息包括对该包括特定媒体的会话修改请求消息的拒绝理由。
[0035] 该会话控制方法还可以包括：当包括在该响应消息中的拒绝理由是该特定媒体不被该IWF支持时，向互配选择功能(ISF)发送对被拒绝的特定媒体的会话请求。
[0036] 根据本发明的另一方面，提供一种在用于支持订制CPM服务的第一客户端和没有订制CPM服务的第二客户端之间的CPM会话的IWF中的会话控制方法，该会话控制方法包括：在通过CPM服务器和IWF在第一客户端和第二客户端之间发起CPM会话之后，通过CPM服务器从第一客户端接收包括特定媒体的会话修改请求消息；以及当该特定媒体不被该IWF支持时，向CPM服务器发送响应消息，该响应消息包括拒绝理由，该拒绝理由是特定媒体不被该IWF支持的指示。
[0037] 根据本发明的另一方面，提供一种用于支持订制CPM服务的第一客户端和没有订制CPM服务的第二客户端之间的CPM会话的互配装置，该互配装置包括：至少一个IWF，用于支持至少一个媒体的每一个，以及当接收到对不被该IWF支持的媒体的互配请求时，产生拒绝理由，该拒绝理由是相应媒体不被该IWF支持的指示；和ISF，用于在通过CPM服务器和IWF在第一客户端和第二客户端之间发起CPM会话之后，当通过CPM服务器从第一客户端接收到包括特定媒体的会话修改请求消息时，从至少一个IWF当中选择负责该特定媒体的互配的实体。
[0038] 该互配装置还可以包括控制器，用于当从该IWF接收到作为该特定媒体不被该IWF支持的指示的拒绝理由时，指令该ISF重新选择负责该特定媒体的互配的实体。
[0039] 根据本发明的另一方面，提供一种在用于支持订制CPM服务的第一客户端和没有订制CPM服务的第二客户端之间的CPM会话的CPM服务器中的会话控制方法，该会话控制方法包括：从第一客户端接收包括特定媒体的会话发起消息；通过ISF向IWF发送包括该特定媒体的会话发起消息；以及通过该ISF从IWF接收响应消息，该响应消息包括该会话发起消息的拒绝理由。
[0040] 该会话控制方法还可以包括：当拒绝理由是该特定媒体不被该IWF支持时，向该ISF重新发送包括该特定媒体的会话发起消息。
[0041] 根据本发明的另一方面，提供一种在用于支持订制CPM服务的第一客户端和没有订制CPM服务的第二客户端之间的CPM会话的IWF中的会话控制方法，该会话控制方法包括步骤：通过CPM服务器从第一客户端接收包括特定媒体的会话发起消息；以及当该特定媒体不被该IWF支持时，向CPM服务器发送响应消息，该响应消息包括拒绝理由，该拒绝理由是特定媒体不被该IWF支持的指示。
[0042] 根据本发明的另一方面，提供一种用于支持订制CPM服务的第一客户端和没有订制CPM服务的第二客户端之间的CPM会话的互配装置，该互配装置包括：至少一个IWF，用于支持至少一个媒体的每一个，以及当接收到对不被该IWF支持的媒体的互配请求时，产生拒绝理由，该拒绝理由是相应媒体不被该IWF支持的指示；和ISF，用于当通过CPM服务器从第一客户端接收到包括该特定媒体的会话发起请求消息时，从至少一个IWF当中选择负责该特定媒体的互配的实体。
[0043] 该互配装置还可以包括控制器，用于当从该IWF接收到作为该特定媒体不被该IWF支持的指示的拒绝理由时，指令该ISF重新选择负责该特定媒体的互配的实体。
[0044] 有益效果
[0045] 具体地，当需要互配时，CPM服务器同时执行接收客户端订制的多个非CPM服务的互配，以使得CPM客户端能够通过一个会话交换各种媒体类型，并且同时非CPM客户端能够通过使用各种消息服务与CPM客户端交换媒体。因此，能够增加消息服务的用户的满意度。附图说明
[0046] 通过下面结合附图的详细描述，本发明的上述和其它目的、特征和优点将更加明显，其中：
[0047] 图1是示出了CPM系统的实体的图；
[0048] 图2是用于说明用于在CPM服务和非CPM服务之间互配的消息发送/接收的消息流程图；
[0049] 图3和4是用于说明根据本发明的第一实施例的在CPM系统的代理模式中发起会话的操作的消息流程图；
[0050] 图5是示出了根据本发明的第一实施例的在代理模式中IWF的操作的流程图；
[0051] 图6是示出了根据本发明的第一实施例的在代理模式中CPM服务器的操作的流程图；
[0052] 图7和8是用于说明根据本发明的第二实施例的在代理模式中向已经发起的会话添加新的媒体类型的操作的消息流程图；
[0053] 图9是用于说明根据本发明的第三实施例的在代理模式中通过从已经发起的会话中删除特定媒体类型来修改已经发起的会话的操作的消息流程图；
[0054] 图10和11是用于说明根据本发明的第四实施例的在代理模式中通过向已经发起的会话添加新的媒体类型同时从已经发起的会话中删除现有媒体类型来修改已经发起的会话的操作的消息流程图；
[0055] 图12是示出了根据本发明的第二到第四实施例的在代理模式中接收会话修改请求的CPM服务器的操作的流程图；
[0056] 图13和14是示出了根据本发明的第二到第四实施例的在代理模式中从IWF接收响应消息的CPM服务器的操作的流程图；
[0057] 图15和16是用于说明根据本发明的第五实施例的在CPM系统的B2BUA模式中发起会话的操作的消息流程图；
[0058] 图17和18是用于说明根据本发明的第六实施例的在B2BUA模式中通过改变特定媒体类型来修改已经发起的会话的操作的消息流程图；
[0059] 图19和20是用于说明根据本发明的第一实施例的当ISF工作在其中不允许修改消息体部分的代理模式中时发起会话的另一个操作的消息流程图；
[0060] 图21和22是用于说明根据本发明的第五实施例的当ISF工作在B2BUA模式中时发起会话的另一个操作的消息流程图；和
[0061] 图23和24是用于说明根据本发明的第二实施例的当IWF工作在代理模式中时向已经发起的会话添加新的媒体的操作的消息流程图。
具体实施方式
[0062] 在下文中，将参考附图描述本发明的实施例。应当注意，虽然在不同的附图中，但是相似的组件由相似的参考数字指定。此外，在下面的描述中，当对合并于此的已知功能和配置的详细描述可能混淆本发明的主题时，将略去该详细描述。此外，应当注意，将仅仅描述对理解根据本发明的操作是必要的部分，而省略除了该必要部分之外的部分的描述，以便不致混淆本发明的要点。
[0063] 在给出本发明的描述之前，将详细描述将要应用在本发明的融合IP消息(CPM)系统中的互配选择功能(ISF)和互配功能(IWF)。
[0064] 在本发明中，根据CPM系统的实施环境，ISF可以包括在CPM服务器或IWF中，或可以被实现为独立的实体。可替换地，ISF和IWF可以被实现为单个设备。
[0065] 此外，ISF可以根据CPM系统的消息处理方案工作在代理模式或背对背用户代理(B2BUA)模式中。
[0066] 在代理模式中，ISF的主要操作包括IWF选择、消息传送等等。消息传送是指将从CPM服务器接收到的消息传送到选择的IWF、将从IWF接收到的响应消息传送到CPM服务器的操作等等。此外，当传送接收的消息时，可以允许ISF修改接收的消息的特定报头字段或参数。但是，一般不允许修改消息体部分。然而，由于可能出现根据CPM系统的设计甚至在代理模式中也可以修改消息体部分的例外情况，所以本发明提出ISF将对于两种情况的每一个不同地操作。但是，在允许修改消息体部分的代理模式情况下，IWF不位于发起的会话上，因而通过发起的会话传送的媒体不经过IWF。
[0067] 在B2BUA模式中，ISF的主要操作包括IWF选择，另外包括充当用于CPM服务器的IWF或用作用于IWF的CPM服务器的用户代理(UA)。UA如下工作：当ISF从CPM服务器接收到任何消息时，UA产生与其对应的新消息，并且向CPM服务器发送产生的消息。因而，对于IWF，ISF充当CPM服务器的UA。当ISF从IWF接收到任何消息时，ISF产生与其对应的新消息，并且向CPM服务器发送产生的消息。因而，对于CPM服务器，ISF充当IWF的UA。在B2BUA模式中，ISF能够通过以这种方式用作UA来控制通过会话传送的媒体流。此外，在B2BUA模式中，ISF位于发起的会话上，因而通过发起的会话传送的媒体经过IWF。
[0068] 根据CPM系统的实施，可以为每个非CPM服务提供用于控制与一个指定的非CPM服务的互配的单独的IWF，或者一个IWF可以控制与所有非CPM服务或多个非CPM服务的互配。在说明书中，将在网络环境中为每个非CPM服务提供单独的IWF的假定之下描述本发明的实施例。
[0069] 首先，将描述根据本发明的实施例的初始会话发起。
[0070] CPM客户端向CPM服务器发送对媒体的会话请求。当需要互配时，CPM服务器向ISF传送会话请求，并且ISF选择合适的IWF并向选择的IWF传送会话请求。IWF确定是否允许会话请求并发送对会话请求的响应。当IWF拒绝会话请求时，IWF在响应中包括拒绝的细节。
[0071] 如果会话请求的拒绝理由是接收客户端给出会话请求的拒绝通知，则被拒绝的会话不需要被再次请求。这是因为即使当另一个IWF支持为之做出会话请求的媒体时，客户端方也将再次拒绝该会话请求。但是，如果会话请求的拒绝理由是IWF不能支持为之做出会话请求的媒体，则可以通过向支持该媒体的另一个IWF转发该会话请求来发起会话。
[0072] 因此，如果IWF在对会话请求的响应中包括拒绝的细节，即关于拒绝者或拒绝理由的信息，则可以根据拒绝的细节确定是否转发被拒绝的会话。当CPM客户端发送对多个媒体的会话请求并且请求的媒体中的一些被拒绝时，拒绝的细节包括关于被拒绝的媒体的信息。例如，由CPM服务器或ISF确定是否转发会话请求。
[0073] 接着，将描述根据本发明的实施例的会话修改。会话修改可以基本上被分成向会话添加新的媒体、删除包括在会话中的媒体、从会话中删除现有媒体且向会话添加新的媒体、改变现有媒体类型，等等。在此情况下，不做出会话发起请求并且做出会话修改请求。当IWF拒绝对添加新的媒体的会话请求时，IWF发送包括拒绝的细节的响应，并且CPM服务器通过考虑拒绝的细节确定如何修改会话。下面将详细描述。
[0074] 本发明可以在“代理模式”和“B2BUA模式”中实施，并且现在将基于本发明的主要构思描述本发明的实施例。
[0075] 在本发明的第一实施例中，将参考图3到6和19到20讨论在代理模式中发起对于多个媒体的初始会话的操作。
[0076] 在本发明的第二实施例中，将参考图7到8和23到24讨论在代理模式中通过向已经发起的会话添加新的媒体类型来修改已经发起的会话的操作。
[0077] 在本发明的第三实施例中，将参考图9讨论在代理模式中通过从已经发起的会话中删除特定媒体类型来修改已经发起的会话的操作。
[0078] 在本发明的第四实施例中，将参考图10到11讨论通过改变特定媒体类型来修改已经发起的会话的操作。
[0079] 在本发明的第五实施例中，将参考15到16和21到22讨论在B2BUA模式中发起对于多个媒体的初始会话的操作。
[0080] 在本发明的第六实施例中，将参考图17到18讨论在B2BUA模式中通过改变特定媒体类型来修改已经发起的会话的操作。
[0081] ISF：代理模式
[0082] A.不允许修改消息体部分的情况
[0083] 图3和4示出了根据本发明的第一实施例的当ISF工作在不允许修改消息体部分的代理模式中时发起会话的操作。图3和4中的操作假定以下条件：
[0084] (1)CPM客户端110发起包括第一和第二媒体的会话。
[0085] (2)接收客户端是非CPM客户端，并且订制第一、第二和第三非CPM服务。
[0086] (3)第一IWF 141执行与第一非CPM服务的互配，第二IWF 142执行与第二非CPM服务的互配，以及第三IWF 143执行与第三非CPM服务的互配。
[0087] (4)第一媒体被第一非CPM服务支持，但是第二媒体不被第一非CPM服务支持。这对第一IWF 141是一样的。
[0088] (5)第二媒体被第二非CPM服务支持，但是第一媒体不被第二非CPM服务支持。这对第二IWF 142是一样的。
[0089] (6)第一和第二媒体二者都不被第三非CPM服务支持。这对第三IWF143是一样的。
[0090] 在图3中，省略从每个IWF到接收非CPM客户端的会话发起请求和其响应的传送。
[0091] 在步骤301中，CPM客户端110向CPM服务器120发送会话发起请求消息(INVITE)。在步骤303中，在接收到会话发起请求消息时，CPM服务器120确定对于该会话发起是否需要互配。图3，由于接收客户端是非CPM客户端，因此需要互配。因而，在步骤305中，CPM服务器120向ISF 130发送会话发起请求消息。
[0092] 在步骤307中，ISF 130基于包括接收客户端的优选项和存在、为之做出会话发起请求的媒体类型、接收客户端订制的服务、服务策略等的信息，选择最适合于执行会话发起的IWF。假定ISF 130在步骤307中选择第三IWF143。
[0093] 在步骤309中，ISF 130向第三IWF 143传送会话发起请求消息。在步骤311中，因为第三IWF 143不支持第一和第二媒体，所以第三IWF 143产生并发送回对会话发起请求消息的拒绝响应消息。在步骤313中，ISF 130将接收的拒绝响应消息传送到CPM服务器120。拒绝响应消息包括拒绝的细节，例如关于拒绝的一个或多个理由、拒绝者和被拒绝的媒体的信息。
[0094] 特定的代号可以用来在拒绝响应消息中包括拒绝的细节。所有SIP响应消息包括可以根据处理与每个响应消息对应的SIP请求消息的结果而变化的唯一代号、错误的理由，等等。例如，当诸如会话发起请求或媒体添加请求之类的SIP请求消息被IWF拒绝时，代号“488”可以包括在相应的响应消息中，以及当SIP请求消息被接收客户端拒绝时，代号“606”可以包括在相应的响应消息中。这些代号仅仅是说明性的，并且代号可以根据系统实施而变化。但是，可能发生CPM服务器120仅仅由代号不能准确确定的情况。这是做出对支持多个媒体类型的会话的发起的请求、但是多个媒体中的一些被用户拒绝并且它们中的一些被IWF拒绝的情况。在这种情况下，响应消息必须直接或间接地澄清对于每一个被拒绝的媒体的拒绝细节。下面将在表1和3中描述澄清每一个媒体的拒绝细节的拒绝响应消息的格式。
[0095] 在步骤315中，CPM服务器120可以从拒绝响应消息的代号知道会话请求被IWF拒绝，并且检查是否允许重试发起被拒绝的会话。在图3中，假定允许重试做出会话发起请求。因而，在步骤317中，CPM服务器120向ISF 130发送会话发起请求消息以便重试会话发起。
[0096] 在步骤319中，ISF 130选择合适的IWF。当然，不选择已经发送回对先前会话请求的拒绝响应消息的IWF，即第三IWF 143。在步骤319中，假定ISF 130选择第一IWF 141。因而，在步骤321中，ISF 130向第一IWF 141传送会话发起请求消息。
[0097] 由于假定第一媒体被第一IWF 141支持并且第二媒体不被第一IWF 141支持，因此第一IWF 141可以接受对于第一媒体的会话的发起。因而，在步骤323中，第一IWF 141产生并发送回接受响应消息(200 OK)。由于第二媒体被第一IWF 141拒绝，因此根据配置对会话发起请求的部分接受响应消息的方法，第一IWF 141在响应消息中包括指示第二媒体被第一IWF 141拒绝的信息，如下所述。
[0098] 在步骤325中，ISF 130将接收的响应消息传送到CPM服务器120。在步骤327中，在CPM服务器120和第一IWF 141之间发起包括第一媒体的会话。
[0099] 在步骤329中，CPM服务器120产生对于被第一IWF 141拒绝的第二媒体的会话发起请求消息，然后在步骤331中，向ISF 130发送产生的消息。在步骤333中，ISF 130选择最适合于执行请求的会话发起的IWF。当然，ISF 130不选择已经发送回对包括第二媒体的先前会话请求的拒绝响应消息的第一IWF 141。
[0100] 在步骤333中，假定ISF 130选择第二IWF 142。因而，在步骤335中，ISF 130向第二IWF 142发送会话发起请求消息。在步骤337中，第二IWF 142产生并发送回对会话发起请求消息的接受响应消息(200 OK)。在步骤339中，ISF 130将接收的响应消息传送到CPM服务器120。随后，在步骤341中，在CPM服务器120和第二IWF 142之间发起包括第二媒体的会话。
[0101] 在步骤343中，CPM服务器120产生对在步骤301中接收的会话发起请求消息的响应消息，并且将产生的响应消息发送回CPM客户端110。此响应消息包括如下指示：包括第一媒体的会话和包括第二媒体的会话被全部接受。随后，在步骤345中，在CPM客户端110和CPM服务器120之间发起包括第一和第二媒体的会话。
[0102] 在图3和4中，ISF 130和第一到第三IWF 141、142、143可以实现为单个互配单元。这样的单个互配单元包括控制器(图中未示出)。在此设备配置情况下，ISF 130可以接收包括第一和第二媒体的会话发起请求消息(INVITE)，并且选择负责第一和第二媒体的互配的IWF。如果ISF 130选择第三IWF 143，则ISF 130向第三IWF 143发送媒体发起请求消息。如上所述，第三IWF 143不能支持第一和第二媒体。因而，第三IWF 143向控制器(未示出)传送拒绝的细节，指示第一和第二媒体由于第三IWF 143的属性而被拒绝。基于此拒绝理由，控制器指令ISF 130重新选择用于第一和第二媒体的IWF，并且ISF 130可以根据控制器的指令重新选择IWF。作为另一个示例，控制器可以被设计为基于拒绝理由重新选择IWF。
[0103] 图19和20示出了根据本发明的第一实施例的当ISF工作在不允许修改消息体部分的代理模式中时发起会话的操作。
[0104] 比较图19和20的操作与图3和4的操作，这两个操作的不同之处在于，图3和4中的CPM服务器120从第一IWF 141和第二IWF 142接收所有响应消息，然后组合接收的响应消息以向CPM客户端110发送组合后的响应消息，但是图19和20中的CPM服务器120单独地处理从各个IWF接收到的响应消息。也就是说，在图19和20中，CPM服务器120基于从主要执行互配的IWF(即第一IWF 141)接收到的响应消息，首先发起与CPM客户端110的会话。当CPM服务器120从次要执行互配的IWF(即，第二IWF142)接收到接受响应消息时，CPM服务器120将第二IWF 142另外接受的媒体添加到在CPM服务器120和CPM客户端110之间已经发起的会话。此外，图19和20的操作假定与图3和4的操作相同的条件，除了接收客户端不订制第三非CPM服务之外。因此，除上述差别之外，图19和20的操作基本上与图3和4的相同。现在将描述图19和20的操作。
[0105] 在步骤1301中，CPM客户端110向CPM服务器120发送会话发起请求消息(INVITE)。在步骤1303中，在接收到会话发起请求消息时，CPM服务器120确定对于该会话发起是否需要互配。在图19和20，由于接收客户端是非CPM客户端，因此需要互配。因而，在步骤1305中，CPM服务器120向ISF 130发送会话发起请求消息。
[0106] 在步骤1307中，ISF 130基于包括接收客户端的优选项和存在、为之做出会话发起请求的媒体类型、接收客户端订制的服务、服务策略等的信息，选择最适合于执行会话发起的IWF。假定ISF 130在步骤1307中选择第一IWF 141。
[0107] 在步骤1309中，ISF 130向第一IWF 143传送会话发起请求消息。在步骤1311中，第一IWF 141产生并发送回“200 OK”作为对会话发起请求消息的响应消息，因为第一IWF141支持第一媒体。在步骤1313中，ISF 130将接收的响应消息传送到CPM服务器120。在步骤1311中，第一IWF 141在响应消息中包括指示第一媒体被接收方用户接受并且第二媒体不被IWF支持因而被自动拒绝的细节。
[0108] 在步骤1315中，在CPM服务器120和第一IWF 141之间发起用于接受的第一媒体的会话。在步骤1317中，CPM服务器120创建对于被拒绝的第二媒体的新的会话发起请求，然后在步骤1317中，向ISF 130发送创建的请求。在步骤1315中，可以根据CPM服务器120的操作方案在步骤1317之后发起第一媒体会话。
[0109] 在步骤1321中，CPM服务器120向CPM客户端110发送“200 OK”作为对在步骤1301中接收的会话发起请求的响应消息。响应消息可以包括第一媒体被接受并且第二媒体被拒绝的简单指示。在步骤1321中响应消息被传送到CPM客户端110的实际的时间点可以根据CPM服务器120的操作方案而变化。换句话说，CPM服务器120可以等待特定时间段以接收对在步骤1319中发送的新的会话发起请求的响应消息，或者可以一从ISF 130接收到第一响应消息就向CPM客户端110发送响应消息。图19和20假定后者。在前者情况下，当在固定的时间段期间接收到对新的会话发起请求的响应消息时，CPM服务器120集成这些响应消息，然后向CPM客户端110发送最终的响应消息，如图3和4的操作中所示。如果在该固定的时间段之外接收到对新的会话发起请求的响应消息，则CPM服务器120首先向CPM客户端110发送首先接收到的响应消息以发起对于被接受的媒体的会话，然后根据随后的对新的会话发起请求的响应消息的内容修改或保持发起的会话。
[0110] 在步骤1323中，在CPM客户端110和CPM服务器120之间发起第一媒体会话。
[0111] 在步骤1325中，ISF 130选择最适合于执行接收的新的会话发起请求的IWF，并向选择的IWF发送该会话发起请求。在图20中，假定ISF 130选择第二IWF 412。在步骤1327中，ISF 130向第二IWF 142发送会话发起请求消息。在步骤1329中，第二IWF 142产生并发送回“200 OK”作为对会话发起请求消息的响应消息，因为它支持第二媒体。在步骤1331中，ISF 130将接收的响应消息传送到CPM服务器120。
[0112] 在步骤1333中，在CPM服务器120和第二IWF 142之间发起第二媒体会话。
[0113] 在步骤1335中，CPM服务器120向CPM客户端110发送会话修改请求。会话修改请求是用于向在CPM客户端110和CPM服务器120之间发起的第一媒体会话添加第二媒体会话的请求。
[0114] 在步骤1337中，CPM客户端110向CPM服务器120发送“200 OK”作为对会话修改请求的接受响应消息。在步骤1339中，以包括第一和第二媒体二者的方式修改在CPM客户端110和CPM服务器120之间发起的会话。
[0115] 图5示出了根据本发明的第一实施例的在代理模式中IWF的操作。在此操作中，IWF执行发送回对会话发起请求的响应消息的操作。
[0116] 在步骤401中，IWF检查会话发起请求是否被拒绝，并且当会话发起请求被拒绝时进行到步骤403。在步骤403中，由于会话发起请求被拒绝，因此IWF产生拒绝响应消息，并且将产生的拒绝响应消息发送回ISF。经由IWF，将发送回的响应消息发送给CPM服务器。IWF根据拒绝理由产生在[RFC(Request for Comments)3261]中定义的拒绝响应消息。如果在步骤401中会话发起请求被接受(即不被拒绝)，则IWF进行到步骤405。在步骤405中，IWF对于请求的媒体的全部或一些，检查会话是否被接受。当仅仅对于请求的媒体中的一些，该会话被接受时，IWF进行到步骤407。
[0117] 在步骤407中，IWF产生接受响应消息(200 OK)，然后将产生的接受响应消息发送回ISF。关于这一点，IWF在响应消息中包括澄清被拒绝的媒体类型是否被IWF或接收客户端拒绝的信息。下面将描述在响应消息中表达这样的信息的方式。
[0118] 当在步骤405中对于请求的媒体的全部，会话被接受时，IWF进行到步骤409，并产生接受响应消息(200 OK)，以然后将产生的接受响应消息发送回ISF。
[0119] 当在步骤407中请求的媒体中的一些被拒绝时，IWF在响应消息中包括拒绝理由。在本发明中，对于媒体的会话发起请求的拒绝理由分成两类。第一类别对应于通过从接收客户端给出的通知拒绝请求的情况，以及第二类别对应于IWF拒绝不支持的媒体的情况。
在本发明中，IWF在响应消息中包括媒体的拒绝理由，从而使得可以重试发起对于被拒绝的媒体类型的会话。
在本发明中，IWF在响应消息中包括媒体的拒绝理由，从而使得可以重试发起对于被拒绝的媒体类型的会话。
[0120] 作为在响应消息中包括关于对于媒体的会话发起为什么被拒绝或被谁拒绝的信息的方式，在本发明中提出了三种情况。
[0121] 在表1中描述情况1。
[0122] 表1
[0123]
[0124] 在情况1中，定义“rejected-by”SDP属性以表达关于对于媒体的会话发起为什么被拒绝或者被谁拒绝的信息。表示媒体级别的属性的“rejected-by”具有拒绝对于相应的媒体类型的会话发起的拒绝者的标识符值。在本发明中，“user”或“network”被示出为属性值。在实际实施中，属性值可以改变为另一个值或由另一个值替代。属性值“user”表示接收客户端拒绝对于媒体的会话发起请求的情况，以及属性值“network”表示接收客户端的IWF或非CPM服务器拒绝对于媒体的会话发起请求因为它不能支持相应的媒体的情况。
[0125] 从表1可以看出，视频无论如何都被拒绝，因为视频的媒体线中的端口号(m＝video 0 RTP/AVP 98 99)被设置为0。从属性值“rejected-by”被设置为“network”的事实，也可以看出，请求的媒体类型不被IWF支持，因而IWF拒绝会话请求。
[0126] 除了会话发起请求之外，可以由IWF以对于将新的媒体添加到已经发起的会话的请求相同的方式执行澄清关于媒体类型为什么被拒绝或者被谁拒绝的信息的上述操作。
[0127] 在表2中描述情况2。
[0128] 表2
[0129]
[0130] 在情况2中，IWF在响应消息中表达它的支持的媒体类型。为此，IWF在响应消息中包括[RFC 3840]媒体特征标签当中的它的支持的媒体的特征标签。在表2中，由于IWF支持音频和视频媒体，因此它在“Contact”报头中包括音频和视频标签。
[0131] 当根据情况2产生的响应消息包括与被拒绝了会话发起的媒体类型对应的媒体标签时，相应的媒体被认为是被接收客户端拒绝。但是，当响应消息不包括与被拒绝的媒体类型对应的媒体标签时，相应的媒体被认为是被IWF拒绝。
[0132] 在表3中描述情况3。
[0133] 表3
[0134]
[0135] 在情况3中，IWF在响应消息中包括作为SDP参数的支持的媒体信息。通过使用SDP参数来传送SIP UA能力信息的方法在[RFC 3264]中定义。由于IWF通过使用SDP参数传送关于它的支持的媒体类型的信息，因此响应消息包括两个SDP体。
[0136] SDP模式之一是用于表示会话发起请求的接受或拒绝的SDP体(SDP应答)，以及另一个是包括关于IWF支持的媒体的信息的SDP体。为了将后者与前者区分开来，在本发明中，“capability”被定义为后者的“Content-Disposition”报头值。“capability”指示相应的SDP体不表示SDP Answer，而是SIPUA的能力信息。
[0137] 在表3中，SDP体部分，其“Content-Disposition”报头值被设置为“capability”，表示IWF的能力。在表3中，与IWF的能力对应的SDP体表示视频和音频媒体被IWF支持的事实、每一个媒体可支持的编解码器信息等等。
[0138] 当在根据情况3产生的响应消息中拒绝IWF支持的媒体类型时，该媒体类型被认为是被接收客户端拒绝。但是，当不被IWF支持的媒体类型被拒绝时，该媒体类型被认为是被IWF拒绝。
[0139] 图6示出了如图3和4所述当ISF工作在根据本发明的第一实施例的不允许修改消息体部分的代理模式中时CPM服务器的操作。
[0140] 根据传统的技术，在从CPM客户端接收到会话发起请求消息时，CPM服务器确定是否需要执行互配，然后当需要执行互配时，向ISF发送会话发起请求消息。也就是说，当不需要互配时，CPM服务器向接收客户端的地址发送会话发起请求消息，以及当需要互配时，经由ISF向相应的IWF发送会话发起请求消息。
[0141] 在本发明的第一实施例中，CPM服务器用和传统的技术相同的方式工作以便处理会话发起请求消息。但是，CPM服务器和传统的技术的工作方式不同之处在于，它从ISF接收对会话发起请求消息的响应消息。也就是说，当在为其请求会话发起的媒体当中存在被IWF拒绝的媒体时，CPM服务器根据包括在响应消息中的拒绝的细节重试发起对于被拒绝的媒体的会话。
[0142] 在步骤501中，CPM服务器从ISF接收对会话发起请求消息的响应消息。在步骤503中，当响应消息是接受响应消息(200 OK)时，CPM服务器进行到步骤505，并且与ISF发起包括被接受的媒体的会话。在步骤507中，CPM确定在为其请求会话发起的媒体类型当中是否存在由于IWF的属性而被拒绝的媒体类型，即不被IWF支持的媒体类型。当存在被拒绝的媒体类型时，CPM服务器进行到步骤511，以及当不存在被拒绝的媒体类型时，进行到步骤509。
[0143] 不存在由于IWF的属性而被拒绝的媒体类型的情况与所有请求的媒体类型都被接受的情况，或一些媒体类型被接收客户端拒绝的情况对应。因而，在步骤509中，CPM服务器120产生对会话发起请求消息的响应消息，并且将产生的响应消息发送回已经发送了该会话发起请求消息的CPM客户端。
[0144] 在步骤511中，CPM服务器重新产生对于由于IWF的属性被拒绝的媒体类型的会话发起请求消息(INVITE)。在步骤513中，CPM服务器向ISF发送重新产生的会话发起请求消息，并且返回到步骤501，在步骤501中CPM服务器再次从ISF接收对会话发起请求消息的响应消息。
[0145] 如果在步骤503中不接受会话发起请求，则CPM服务器进行到步骤515，并检查会话发起请求是否被接收客户端拒绝。当会话发起请求被接收客户端拒绝时，CPM服务器进行到步骤509，以及当会话发起请求不被接收客户端拒绝时，进行到步骤517。
[0146] 在步骤517中，CPM服务器通过预定义的代号发现会话发起请求的拒绝理由，从而检查是否可以重试会话发起请求。考虑会话发起请求的拒绝理由来确定是否可以重试会话发起请求。此外，CPM服务器可以依据服务策略、是否超过受限的重试次数等等，考虑是否允许重试会话发起请求。如果允许重试会话发起请求，则CPM服务器进行到步骤513，并向ISF重新发送对于被拒绝的媒体的会话发起请求消息。但是，如果不允许重试会话发起请求，则CPM服务器进行到步骤509，并且将响应消息发送回CPM客户端。
[0147] 在通过互配在CPM客户端和CPM服务器之间发起会话之后，应CPM客户端的请求必须修改会话。在下文中，将描述根据本发明的实施例的修改已经发起的会话的操作。
[0148] 会话修改包括(1)向已经发起的会话添加新的媒体，其将被描述为图7和8中的本发明的第二实施例；(2)删除包括在已经发起的会话中的媒体，其将被描述为图9中的本发明的第三实施例；和(3)改变已经发起的会话的媒体类型，即删除现有媒体同时添加新的媒体，其将被描述为图10和11中的本发明的第四实施例。
[0149] CPM客户端通过向CPM服务器发送会话修改请求消息来请求CPM服务器修改会话。根据上述三种情形，会话修改请求消息在情况(1)下可以被格式转换为媒体添加请求消息、在情况(2)下可以被格式转换为媒体删除请求消息、以及在情况(3)下可以被格式转换为媒体改变请求消息。
[0150] 图7和8示出了根据本发明的第二实施例的当ISF工作在不允许修改消息体部分的代理模式中时向已经发起的会话添加新的媒体类型的操作。图7和8中的操作假定以下条件：
[0151] (1)在CPM客户端和CPM服务器之间发起包括第一和第二媒体的会话。
[0152] (2)为了向/从接收客户端发送/接收第一媒体，CPM服务器已经发起了与第一IWF的包括第一媒体的会话。
[0153] (3)为了向/从接收客户端发送/接收第二媒体，CPM服务器已经发起了与第二IWF的包括第二媒体的会话。
[0154] (4)第一和第二IWF不支持第三媒体。此外，第一IWF支持第四媒体。
[0155] (5)第三IWF支持第三媒体，以及执行与第三非CPM服务的互配。
[0156] (6)接收客户端订制支持第三媒体的第三非CPM服务。
[0157] 在步骤601中，CPM客户端110发送用于向在CPM客户端110和CPM服务器120之间发起的(第一媒体+第二媒体)会话添加第三和第四媒体的媒体添加请求消息。媒体添加请求消息包括用于第一、第二、第三和第四媒体的SDP参数。
[0158] 在步骤603中，与在CPM客户端10和CPM服务器120之间发起的(第一媒体+第二媒体)会话连接的媒体会话是在CPM服务器120和第一IWF141之间发起的第一媒体会话和在CPM服务器120和第二IWF 412之间发起的第二媒体会话。
[0159] 在步骤603中，CPM服务器120选择第一媒体会话和第二媒体会话中的一个。在步骤603中，假定CPM服务器120选择第一媒体会话。在步骤605中，CPM服务器120向与第一媒体会话连接的第一IWF 141发送媒体添加请求消息(Re-INVITE)。媒体添加请求消息包括用于第一、第三和第四媒体的SDP参数。
[0160] 在步骤607中，第一IWF 141接受包括在媒体添加请求消息中的第一和第四媒体，但是拒绝第三媒体，因为第一IWF 141不能支持第三媒体。因而，第一IWF 141将包括这样的细节的响应消息(200 OK)发送回CPM服务器120。对于此，响应消息的细节包括指示第三媒体由于第一IWF 141的属性而被拒绝的信息。在步骤609中，以包括第一和第四媒体的方式修改在CPM服务器120和第一IWF 141之间发起的会话。
[0161] 在步骤611中，CPM服务器120重试对由于第一IWF 141的属性而被拒绝的第三媒体的媒体添加请求。也就是说，CPM服务器120试着向任何还没有尝试媒体添加请求的第二会话添加第三媒体。为此，在步骤613中，CPM服务器120产生用于向第二会话添加第三媒体的媒体添加请求消息(Re-INVITE)，并且向第二IWF 142发送产生的媒体添加请求消息。媒体添加请求消息包括用于第二和第三媒体的SDP参数。
[0162] 在步骤615中，第二IWF 142接受包括在媒体添加请求消息中的第二媒体，因为第二媒体包括在现有会话中，但是拒绝第三媒体，因为它不能支持第三媒体。因而，在步骤617中，第二IWF 142产生并发送回包括这样的细节的响应消息(200 OK)。对于此，响应消息的细节包括指示第三媒体由于第二IWF 142的属性而被拒绝的信息。
[0163] 在步骤617中，由于不存在可以向其添加被第一和第二IWF 141、142拒绝的第三媒体的会话，因此CPM服务器120产生对于第三媒体的会话发起请求消息，并且在步骤619中确定对于产生的会话发起请求消息是否需要互配。假定需要互配，在步骤621中，CPM服务器120向ISF 130发送会话发起请求消息。
[0164] 在步骤623中，ISF 130选择最适合于处理会话发起请求消息的IWF。假定选择了第三IWF 413，则在步骤625中ISF 130向第三IWF 413发送会话发起请求消息，以及在步骤627中第三IWF 413产生并发送回接受响应消息。在步骤629中，ISF 130将响应消息传送到CPM服务器120。在步骤631中，在CPM服务器120和第三IWF 143之间发起包括第三媒体的会话。在步骤633中，CPM服务器120产生对媒体添加请求消息的响应消息，然后将产生的响应消息发送回CPM客户端110。在步骤635中，以包括第一、第二、第三和第四媒体的方式修改在CPM客户端110和CPM服务器120之间发起的现有会话。
[0165] 在图7和8中，ISF 130和第一到第三IWF 141、142、143可以被实现为单个互配单元。这样的单个互配单元包括控制器(图中未示出)。在此设备配置情况下，ISF 130可以从CPM服务器120接收用于添加第三和第四媒体的媒体添加请求消息，并且选择用于控制请求的第三和第四媒体的互配的IWF。如果ISF 130选择第一IWF 141，则它向第一IWF141发送媒体添加请求消息。如上所述，第一IWF 141不能支持第三媒体。因而，第一IWF
141向控制器(未示出)传送指示第三媒体由于第一IWF 141的属性而被拒绝的细节。基于此拒绝理由，控制器指令ISF 130重新选择用于第三媒体的IWF，并且ISF 130可以根据控制器的指令重新选择IWF。作为另一个示例，控制器可以被设计为基于拒绝理由重新选择IWF。
141向控制器(未示出)传送指示第三媒体由于第一IWF 141的属性而被拒绝的细节。基于此拒绝理由，控制器指令ISF 130重新选择用于第三媒体的IWF，并且ISF 130可以根据控制器的指令重新选择IWF。作为另一个示例，控制器可以被设计为基于拒绝理由重新选择IWF。
[0166] 在上述操作中，即使当在步骤603中CPM服务器120发起与多个IWF的媒体会话时，CPM服务器120也重复向任何一个IWF发送媒体添加请求消息。但是，根据CPM服务器120的操作方案，CPM服务器120可以向各个IWF(每个发起与CPM服务器120的媒体会话)同时发送媒体添加请求消息。但是，这可能引起对同一媒体的添加请求同时被不同的IWF接受的情况，因此CPM服务器120必须通过检查全部接收的响应消息来防止同一媒体同时被不同的IWF添加。
[0167] 因此，作为防止同一媒体的重叠添加的方式，CPM服务器120可以等到从向其发送了媒体添加请求的所有IWF接收到响应消息为止，以便防止同一媒体同时被不同的IWF添加。可替换地，CPM服务器120可以通过处理首先从一个IWF接收到的OK响应消息、当由稍后从另一个IWF接收到的OK响应消息引起同一媒体的重叠添加时产生会话终止请求消息(BYE)或媒体删除请求消息(Re-INVITE)、然后将产生的消息发送到相应的IWF，来防止同一媒体的重叠添加。
[0168] 图23和24示出了根据本发明的第二实施例的当ISF工作在不允许修改消息体部分的代理模式中时向已经发起的会话添加新的媒体类型的操作。图23和24的操作与图7和8的不同之处在于，CPM服务器试着同时向所有相关的IWF发送媒体添加请求。
[0169] 除以下条件之外，图23和24的操作与图7和8假定相同的条件：
[0170] (1)第一IWF和第二IWF不支持第三媒体。
[0171] (2)第一IWF和第二IWF支持第四媒体。
[0172] 在步骤1501中，CPM客户端110发送用于向在CPM客户端110和CPM服务器120之间发起的(第一媒体+第二媒体)会话添加第三和第四媒体的媒体添加请求消息。媒体添加请求消息包括用于第一、第二、第三和第四媒体的SDP参数。
[0173] 在步骤1503中，与在CPM客户端10和CPM服务器120之间发起的(第一媒体+第二媒体)会话连接的媒体会话是在CPM服务器120和第一IWF141之间发起的第一媒体会话和在CPM服务器120和第二IWF 412之间发起的第二媒体会话。
[0174] 在步骤1503中，CPM服务器120向与第一媒体会话连接的第一IWF 141发送媒体添加请求消息(Re-INVITE)。媒体添加请求消息包括用于第一、第三和第四媒体的SDP参数。
[0175] 在步骤1505中，CPM服务器120向与第二媒体会话连接的第二IWF 142发送媒体添加请求消息(Re-INVITE)。媒体添加请求消息包括用于第二、第三和第四媒体的SDP参数。
[0176] 在步骤1507中，第一IWF 141接受包括在媒体添加请求消息中的第一和第四媒体，但是拒绝第三媒体，因为第一IWF 141不能支持第三媒体。因而，第一IWF 141将包括这样的细节的响应消息(200 OK)发送回CPM服务器120。对于此，响应消息的细节包括指示第三媒体由于第一IWF 141的属性而被拒绝的信息。在步骤1509中，以包括第一和第四媒体的方式修改在CPM服务器120和第一IWF 141之间发起的会话。
[0177] 在步骤1511中，第二IWF 142接受包括在媒体添加请求消息中的第二和第四媒体，但是拒绝第三媒体，因为它不能支持第三媒体。因而，在步骤1513中，第二IWF 142产生并发送回包括这样的细节的响应消息(200 OK)。对于此，响应消息的细节包括指示第三媒体由于第二IWF 142的属性而被拒绝的信息。在步骤1513中，以包括第二和第四媒体的方式修改在CPM服务器120和第二IWF 142之间发起的会话。
[0178] 作为执行上述步骤的结果，同时将第三媒体添加到第一IWF 141和第二IWF 142。因而，为了防止第三媒体的重叠添加，CPM服务器120产生用于删除后来添加的第三媒体的媒体删除请求消息(Re-INVITE)，并向第二IWF142发送产生的媒体删除请求消息。
[0179] 在步骤1517中，响应于媒体删除请求消息，第二IWF 142向CPM服务器120发送接受响应消息。在步骤1519中，修改在CPM服务器120和第二IWF 142之间发起的会话以使得从该会话中删除第三媒体，并且仅仅第二媒体包括在该会话中。
[0180] 将省略后面的步骤的描述，因为已经在图7和8中描述过了它们。
[0181] 但是，如图23和24所述的CPM服务器120的操作可以根据CPM服务器120的实施稍微有变化。例如，在图23和24中，CPM服务器120从第一IWF 141和第二IWF 142接收响应消息，但是CPM服务器120可以根据服务器的实施方案或设置发送SIP UPDATE消息或SIP CANCEL消息，只要它已经从第一IWF 141接收到OK响应消息但是还没有从第二IWF142接收到响应消息。
[0182] 当要被添加的所有媒体被第一IWF 141接受时，发送SIP CANCEL消息，并且SIP CANCEL消息用来取消发送给第二IWF 142的媒体添加请求消息。
[0183] 当请求被添加到第一IWF 141的媒体中的仅仅一些被接受而其它的被拒绝时，可以使用SIP UPDATE消息，并且SIP UPDATE消息用来从发送给第二IWF 142的媒体添加请求消息中删除被第一IWF 141接受的媒体。
[0184] 图9示出了根据本发明的第三实施例的当ISF工作在不允许修改消息体部分的代理模式中时通过删除特定媒体类型来修改已经发起的会话的操作。在图9中预见的情况假定，通过图7和8的操作添加的第三和第四媒体被再次删除。
[0185] 在步骤701中，CPM客户端110向CPM服务器120发送用于从在CPM客户端110和CPM服务器120之间发起的会话中删除第三和第四媒体的媒体删除请求消息。媒体删除请求消息包括用于第一和第二媒体的SDP参数。
[0186] 在步骤703中，CPM服务器120选择对于该媒体删除请求的目标会话。也就是说，CPM服务器120选择在CPM服务器120和第三IWF 143之间发起的第三会话以便删除第三媒体，并且选择在CPM服务器120和第一IWF141之间发起的(第一媒体+第四媒体)会话以便删除第四媒体。
[0187] 在步骤705中，CPM服务器120产生用于从选择的(第一媒体+第四媒体)会话中删除第四媒体的媒体删除请求消息，然后向第一IWF 141发送产生的媒体删除请求消息。在步骤707中，CPM服务器120产生媒体删除请求消息，其请求选择的第三媒体会话删除第三媒体。但是，由于第三媒体会话除了第三媒体之外不包括其它媒体，因此CPM服务器120产生会话终止消息(BYE)，然后向第三IWF 143发送会话终止消息。
[0188] 在步骤709中，第一IWF 141产生对第四媒体删除请求消息的接受响应消息，然后将接受响应消息发送回CPM服务器120。在步骤711中，从在CPM服务器120和第一IWF 141之间发起的(第一媒体+第四媒体)会话中删除第四媒体。在步骤713中，第三IWF 143产生对在步骤707中接收到的会话终止请求的接受响应消息，然后将接受响应消息发送回CPM服务器120。在步骤715中，终止在CPM服务器120和第三IWF 143之间发起的第三媒体会话。
[0189] 在步骤717中，CPM服务器120产生对在步骤701中接收到的媒体删除请求的响应消息，然后将该响应消息发送回CPM客户端110。在步骤719中，从在CPM客户端110和CPM服务器120之间发起的(第一媒体+第二媒体+第三媒体+第四媒体)会话中删除第三和第四媒体。
[0190] 图10和11示出了根据本发明的第四实施例的当ISF工作在不允许修改消息体部分的代理模式中时通过向会话添加新的媒体同时从会话中删除现有媒体来修改已经发起的会话的操作。也就是说，图10和11的操作与改变特定媒体类型的操作对应，并且在图10和11中预见的情况假定，将第三和第四媒体添加到通过图3和4的操作发起的会话并且从该会话中删除第二媒体。
[0191] 在步骤801中，CPM客户端110向CPM服务器120发送用于向在CPM客户端110和CPM服务器120之间发起的会话添加第三和第四媒体并且从该会话中删除第二媒体的媒体修改请求消息。媒体修改请求消息包括用于第一、第三和第四媒体的SDP参数。
[0192] 在步骤803中，CPM服务器120选择对于该媒体删除请求的目标会话。也就是说，CPM服务器120选择在CPM服务器120和第二IWF 142之间发起的第二会话以便删除第二媒体。在步骤805中，CPM服务器120产生用于向选择的第二媒体会话添加第三和第四媒体并且从该会话中删除第二媒体的会话修改请求消息，并且向第二IWF 142发送会话修改请求消息。会话修改消息包括用于第三和第四媒体的SDP参数。
[0193] 在步骤807中，第二IWF 142发送回拒绝响应消息，因为第二IWF 142不能支持第三和第四媒体。在步骤809中，CPM服务器120可以再次产生第二媒体删除请求消息，并且向第二IWF 142发送第二媒体删除请求消息。但是，由于第二媒体会话除了要被删除的第二媒体之外不包括其它媒体，因此CPM服务器120向第二IWF 142发送会话终止请求消息(BYE)，而不是媒体删除请求消息。在步骤811中，第二IWF 142发送回对会话终止请求消息的接受响应消息。在步骤813中，终止在CPM服务器120和第二IWF 142之间发起的第二媒体会话。
[0194] 在步骤815中，由于因第二IWF 142的属性而拒绝向第二会话添加第三和第四媒体，因此CPM服务器120产生用于向还没有向其发送媒体添加请求的第一媒体会话添加第三和第四媒体的媒体添加请求消息，然后在步骤817中，向第一IWF 141发送产生的媒体添加请求消息。媒体添加请求消息包括用于第一、第三和第四媒体的SDP参数。
[0195] 在步骤819中，由于第一IWF 141支持第一和第四媒体，但是不支持第三媒体，因此第一IWF 141接受第一和第四媒体，但是拒绝第三媒体。因而，第一IWF 141发送回包括这样的细节的响应消息。也就是说，响应消息包括指示第三媒体由于第一IWF 141的属性而被拒绝的信息。由于第一和第四媒体被接受，因此在步骤821中，以包括第一和第四媒体的方式修改第一媒体会话。
[0196] 在步骤823中，CPM服务器120重试对由于第一或第二IWF 141、142的属性而被拒绝的第三媒体的添加请求。但是，由于CPM服务器120已经请求了向已经发起的会话的媒体添加，因此CPM服务器120产生对于第三媒体的会话发起请求消息，而不是媒体添加请求消息。随后，在步骤825中，CPM服务器120确定对于产生的会话发起请求消息是否需要互配。在图10和11中，假定需要互配。
[0197] 在步骤827中，CPM服务器120向ISF 130发送对于第三媒体的会话发起请求消息。在步骤829中，ISF 130选择最适合于会话发起的IWF。这里假定选择了第三IWF 143。在步骤831中，ISF 130向第三IWF 143发送会话发起请求消息。在步骤833中，第三IWF
143产生对会话发起请求的接受响应消息，然后将接受响应消息发送回ISF 130。在步骤
835中，ISF 130向CPM服务器120传送响应消息，然后在步骤837中，在CPM服务器120和第三IWF 143之间发起第三媒体会话。
143产生对会话发起请求的接受响应消息，然后将接受响应消息发送回ISF 130。在步骤
835中，ISF 130向CPM服务器120传送响应消息，然后在步骤837中，在CPM服务器120和第三IWF 143之间发起第三媒体会话。
[0198] 在步骤839中，CPM服务器120产生对在步骤801中接收到的会话修改请求消息(用于添加第三和第四媒体并且删除第二媒体的消息)的响应消息，然后将响应消息发送回CPM客户端110。响应消息包括指示请求的所有CPM客户端110都被接受的细节。在步骤841中，以包括第一、第三和第四媒体的方式修改在CPM客户端110和CPM服务器120之间的会话。
[0199] 现在将描述在本发明的第二到第四实施例中CPM服务器如何工作。在图12中示出的操作与CPM服务器从CPM客户端接收会话修改请求消息的情况对应，以及在图13和14中示出的操作与CPM服务器从IWF接收对会话修改请求的响应消息的情况对应。
[0200] 图12示出了当ISF工作在根据本发明的第二到第四实施例的不允许修改消息体部分的代理模式中时接收会话修改请求消息的CPM服务器的操作。
[0201] 在步骤901中，CPM服务器从CPM客户端接收会话修改消息(Re-INVITE)。会话修改请求消息包括指示要被修改的会话是在CPM服务器和CPM客户端之间发起的会话的信息。在步骤903中，CPM服务器从映射到接收客户端的会话当中选择对于该会话修改请求的目标媒体会话。当存在几个对于会话修改请求的目标媒体会话时，CPM服务器立即选择几个媒体会话。例如，如果会话修改请求是用于删除几个媒体类型的媒体或改变媒体类型的请求，并且所有请求的媒体不包括在一个媒体会话中，则可以全部选择包括请求的媒体的媒体会话。
[0202] 当CPM服务器选择媒体会话时，它可以如下工作：
[0203] 如果来自于CPM客户端的会话修改请求是媒体添加请求，则CPM服务器可以存储包括在已经在会话发起时从IWF发送回的响应消息中的细节，然后利用该细节。也就是说，当来自于IWF的响应消息包括如表2或3所示的关于相应的IWF支持的媒体类型的信息时，CPM服务器可以存储关于相应的媒体类型的信息，然后利用该信息来检查在媒体添加请求消息中请求的媒体是否被相应的IWF支持，并且选择将向其添加请求的媒体的目标媒体会话。如果会话修改请求是对特定媒体的媒体删除请求或用于将特定媒体改变为其它媒体的请求，则CPM服务器可以立即选择该媒体会话，因为它知道哪个媒体包括在当前媒体会话中。
[0204] 在步骤905中，CPM服务器产生被适配为选择的媒体会话的会话修改请求消息，并且向参与相应的媒体会话的IWF发送会话修改请求消息。当几个媒体会话被选择为要被修改的媒体会话时，CPM服务器产生对于该几个媒体会话的会话修改请求消息，并且向相应的IWF发送会话修改请求消息。
[0205] 如果会话修改请求是媒体删除请求，并且选择的媒体会话包括除了请求的媒体之外的其它媒体，则CPM服务器产生媒体删除请求消息(Re-INVITE)并且向相应的IWF发送媒体删除请求消息。但是，如果选择的媒体会话不包括除了请求的媒体之外的其它媒体，则CPM服务器产生对于选择的媒体会话的会话终止请求消息(BYE)，并且向相应的IWF发送会话终止请求消息。
[0206] 图13和14示出了根据本发明的第二到第四实施例的当ISF工作在不允许修改消息体部分的代理模式中时从IWF接收响应消息的CPM服务器的操作。图13和14假定包括在会话修改请求消息中的媒体添加请求可以被接收客户端拒绝或由于IWF的属性而被拒绝，但是媒体删除请求和媒体类型改变请求可以仅仅由接收客户端拒绝。
[0207] 在步骤1001中，CPM服务器120从ISF 130接收对会话修改请求的响应消息。在步骤1003中，当响应消息是对包括媒体添加请求的会话修改请求的响应时，CPM服务器120进行到步骤1005。包括媒体添加请求的会话修改请求是指用于仅仅添加新的媒体的请求或用于改变媒体类型的请求。在步骤1005中，当响应消息是接受响应消息(200 OK)时，CPM服务器120进行到步骤1007，并且修改相应的会话以使得向其添加请求的媒体。但是，当响应消息不是接受响应消息时，CPM服务器120进行到步骤1025。
[0208] 在步骤1009中，如果在请求的媒体当中媒体由于IWF的属性而被拒绝，则CPM服务器进行到步骤1011。否则，CPM服务器120进行到步骤1023，并且产生对来自于CPM客户端的会话修改请求的响应消息，并且将响应消息发送回CPM客户端。
[0209] 在步骤1011中，如果在连接到CPM服务器120的媒体会话当中存在还没有向其发送媒体会话修改请求的媒体会话，则CPM服务器120进行到步骤1013。在步骤1013中，CPM服务器选择还没有向其发送媒体会话修改请求的媒体会话中的任何一个，并且产生被适配为选择的媒体会话的对于被拒绝的媒体的媒体添加请求消息。在步骤1015中，CPM服务器向选择的IWF发送产生的媒体添加请求消息。随后，CPM服务器返回到步骤1001以便处理对发送的媒体添加请求消息的响应消息。
[0210] 在步骤1011中，如果不存在还没有向其发送媒体会话修改请求的媒体会话，则CPM服务器120进行到步骤1029。在步骤1029中，CPM服务器120产生对于由于IWF的属性被拒绝的媒体的会话发起请求消息(INVITE)。在步骤1031中，CPM服务器确定对于产生的会话发起请求消息是否需要互配。当需要互配时，CPM服务器进行到步骤1033，并且向ISF 130发送会话发起请求消息。当不需要互配时，CPM服务器进行到步骤1035。
[0211] 由于不需要互配意味着接收客户端是CPM客户端，因此CPM服务器向接收客户端的地址发送会话发起请求消息。当接收客户端与CPM服务器120位于同一个网络区域中时，将会话发起请求消息发送给接收CPM客户端110。但是，当接收客户端位于不同的网络区域中时，将会话发起请求消息发送给属于相应的网络区域的CPM服务器120。随后，如果CPM服务器120接收到对会话发起请求的响应消息，则CPM服务器120返回到步骤1001以便处理响应消息。
[0212] 在步骤1003中，当接收到的响应消息不是对包括媒体添加请求的会话修改请求的响应消息时，即当接收到的响应消息是对媒体删除请求的响应消息时，CPM服务器进行到步骤1017。在步骤1017中，当接收到的响应消息是接受响应消息(200 OK)时，即当会话修改请求被接受时，CPM服务器进行到步骤1019，并且修改目标媒体会话以使得被接受的细节，即媒体删除被反映在目标媒体会话中。但是，当接收到的响应消息是拒绝响应消息时，CPM服务器进行到步骤1021，并且保持现有会话。在步骤1023中，CPM服务器产生对来自于CPM客户端110的会话修改请求的响应消息，并且将响应消息发送回CPM客户端110。
[0213] 在步骤中1005，当接收到的响应消息是拒绝响应消息时，CPM服务器进行到步骤1025。在步骤1025中，由于如果拒绝响应不是由于IWF的属性而不需要重试会话修改请求，因此CPM服务器进行到步骤1021，并且保持现有会话。如果拒绝响应是由于IWF的属性，则CPM服务器进行到步骤1026。在步骤1026中，CPM服务器确定拒绝响应是否是对媒体添加请求或媒体类型改变请求的拒绝响应。在对媒体添加请求的拒绝响应的情况下，CPM服务器进行到步骤1011，并且创建媒体添加请求消息或媒体发起请求消息。
[0214] 但是，当拒绝响应是对媒体类型改变请求的拒绝响应时，同时执行步骤1011和1027。也就是说，媒体类型改变请求是用于添加新的媒体并删除先前的媒体的请求。但是，由于用于添加请求的新的媒体不被IWF支持，因此CPM服务器120必须分开做出媒体添加请求和媒体删除请求。因而，在步骤1027中，CPM服务器产生媒体删除请求消息，并且将它重新发送到相应的IWF。同时，CPM服务器120进行到步骤1011和后面的步骤，并且处理媒体添加请求。
[0215] B.允许修改消息体部分的情况
[0216] 工作在允许修改消息体部分的代理模式中的IWF以和工作在B2BUA模式中的ISF基本上相同的方式工作。但是，该过程的不同之处在于，虽然工作在B2BUA模式中的ISF在传送消息之前将媒体的目的地址和端口设置为该消息的SDP体中的IWF的目的地址和端口，但是工作在B2BUA模式中的ISF整体发送从CPM服务器接收到的SDP体，因为CPM服务器不能修改消息体。下面将描述当ISF工作在B2BUA模式中时发起和修改会话的过程。
[0217] ISF：B2BUA模式
[0218] 当IWF工作在代理模式中时，在CPM客户端和CPM服务器之间发起包括由CPM客户端请求的全部媒体的一个会话，并且可以根据IWF支持的媒体类型在CPM服务器和IWF之间发起几个媒体会话。因此，一个会话在CPM服务器处分离成几个媒体会话。
[0219] 当IWF工作在B2BUA模式中时，在CPM客户端和CPM服务器之间，以及在CPM服务器和ISF之间发起包括由CPM客户端请求的全部媒体的一个会话。但是，可以根据IWF支持的媒体类型在ISF和IWF之间发起几个媒体会话。因此，与代理模式不同，一个会话在ISF处分离成几个媒体会话。
[0220] B2BUA模式中的每个实体如下工作：
[0221] 在接收到会话发起或修改请求消息时，CPM服务器确定是否需要互配，然后当需要互配时向ISF发送会话发起或修改请求消息。此外，在从ISF接收到对会话发起或修改请求消息的响应消息时，CPM服务器向CPM客户端传送响应消息。
[0222] IWF以和在代理模式中相同的方式工作，并且ISF以和代理模式中的CPM服务器基本相同的方式工作。
[0223] 图15和16示出了根据本发明的第五实施例的当ISF工作在B2BUA模式中时发起会话的操作。
[0224] 在步骤1101中，CPM客户端110向CPM服务器120发送包括第一和第二媒体的会话发起请求消息(INVITE)。在步骤1103中，CPM服务器120确定对于会话发起是否需要互配。由于假定接收客户端是非CPM客户端，因此需要互配。因而，在步骤1105中，CPM服务器120向ISF 130发送会话发起请求消息。
[0225] 在步骤1107中，ISF 130选择适合于会话发起的IWF。图15和16假定选择了支持第一媒体的第一IWF 141。因而，在步骤1109中，ISF 130向第一IWF 141发送会话发起请求消息。在步骤1111中，第一IWF 141发送回对会话发起请求的接受响应消息(200 OK)。由于第一IWF 141支持第一媒体但是不支持第二媒体，因此接受响应消息包括指示第二媒体由于第一IWF141的属性而被拒绝，即第二媒体是不被第一IWF 141支持的特定类型的细节。在步骤1113中，在ISF 130和第一IWF 141之间发起包括第一媒体的媒体会话。
[0226] 在步骤1115中，ISF 130检查是否允许重试用于被拒绝的第二媒体的会话发起。这里假定允许重试会话发起。因而，在步骤1117中，ISF 130产生对于被拒绝的第二媒体的会话发起请求消息。在步骤1119中，ISF 130选择第二IWF 142作为向其发送会话发起请求消息的IWF，然后在步骤1121中，向选择的第二IWF 142发送会话发起请求消息。
[0227] 在步骤1123中，第二IWF 142发送回接受响应消息(200 OK)。在步骤1125中，然后在ISF 130和第二IWF 142之间发起包括第二媒体的媒体会话。在步骤1127中，ISF130产生对在步骤1105中接收的会话发起请求消息的响应消息，并且将该响应消息发送回CPM服务器120。响应消息包括指示第一和第二媒体都被接受的细节。在步骤1129中，在CPM服务器120和ISF130之间发起包括第一和第二媒体的会话。在步骤1131中，CPM服务器120产生对在步骤1131中接收的会话发起请求消息的响应消息，并且将该响应消息发送回CPM客户端110。响应消息包括指示第一和第二媒体都被接受的细节。在步骤1133中，在CPM客户端110和CPM服务器120之间发起包括第一和第二媒体的会话。
[0228] 图21和22示出了根据本发明的第五实施例的当ISF工作在B2BUA模式中时发起会话的另一个操作。在图5中，ISF 130从各个IWF接收全部响应消息，将它们组合成单个响应消息，将该单个响应消息传送到CPM服务器120，最后发起会话。相反，在图21和22中，ISF 130基于从主要执行互配的IWF(第一IWF)接收到的响应消息，首先发起与CPM服务器120的会话。随后，当从次要执行互配的IWF(第二IWF 142)接收到接受响应消息时，ISF 130将第二IWF 142另外接受的媒体添加到在ISF 130和CPM服务器120之间、以及在CPM服务器120和CPM客户端110之间已经发起的会话。因此，除这些特征之外，图21和22中的其余步骤与图5中的那些相同。
[0229] 在步骤1401中，CPM客户端110向CPM服务器120发送包括第一和第二媒体的会话发起请求消息(INVITE)。在步骤1403中，CPM服务器120确定对于会话发起是否需要互配。由于假定接收客户端是非CPM客户端，因此需要互配。因而，在步骤1405中，CPM服务器120向ISF 130发送会话发起请求消息。
[0230] 在步骤1407中，ISF 130基于包括接收客户端的优选项和存在、为之做出会话发起请求的媒体类型、接收客户端订制的服务、服务策略等的信息，选择最适合于执行会话发起的IWF。假定ISF 130在步骤1407中选择第一IWF 141。
[0231] 在步骤1409中，ISF 130向第一IWF 141发送会话发起请求消息。在步骤1411中，第一IWF 141产生并发送回“200 OK”作为对会话发起请求消息的接受响应消息，因为它支持第一媒体。在步骤1413中，在ISF 130和第一IWF 141之间发起对于被接受媒体的会话。在步骤1411中，第一IWF 141在响应消息中包括指示第一媒体被接收方用户接受并且第二媒体由于是不被第一IWF 141支持的媒体而被自动拒绝的细节。
[0232] 在步骤1415中，ISF 130将响应消息发送到CPM服务器120。在步骤1417中，在CPM服务器120和第一IWF 141之间发起第一媒体会话。ISF 130向CPM服务器120发送响应消息的时间点可以根据ISF 130的操作模式而变化。换句话说，ISF 130可以等待特定时间段以接收对在步骤1429中发送的新的会话发起请求的响应消息，或者可以一旦从第一IWF 141接收到第一响应消息就向CPM服务器120发送响应消息。图21和22假定后者。在前者情况下，当在固定时间段期间接收到对新的会话发起请求的响应消息时，ISF130集成这些响应消息，然后向CPM服务器120发送最终的响应消息，如图15和16的操作中所示。如果在该固定时间段之外接收到对新的会话发起请求的响应消息，则ISF 130首先向CPM服务器120发送首先接收到的响应消息以发起对于被接受的媒体的会话，然后根据随后的对新的会话发起请求的响应消息的内容修改或保持发起的会话。
[0233] 在步骤1419中，CPM服务器120将响应消息发送到CPM客户端110。在步骤1421中，在CPM客户端110和CPM服务器120之间发起第一媒体会话。
[0234] 在步骤1423中，ISF 130检查是否允许重试对于被第一IWF 141自动拒绝的第二媒体的会话发起请求。如果允许，则ISF 130在步骤1425中产生对于第二媒体的新的会话发起请求，并且在步骤1427中选择最适合于处理新的会话发起请求的IWF。这里假定ISF130选择支持第二媒体的第二IWF142。在步骤1429中，ISF 130向第二IWF 142发送新的会话发起请求。
[0235] 在步骤1423中，第二IWF 142向ISF 130发送“200 OK”作为接受响应消息。在步骤1433中，在ISF 130和第二IWF 142之间发起第二媒体会话。
[0236] 在步骤1435中，ISF 130向CPM服务器120发送会话修改请求。在步骤1435中的会话修改请求是用于向在CPM服务器120和IWF 130之间发起的第一媒体会话添加第二媒体的请求。
[0237] 在步骤1437中，CPM服务器120向CPM客户端110发送会话修改请求。在步骤1437中的会话修改请求是用于向在CPM客户端110和CPM服务器120之间发起的第一媒体会话添加第二媒体的请求。
[0238] 在步骤1439中，CPM客户端110向CPM服务器120发送“200 OK”作为对会话修改请求的响应消息。在步骤1441中，以包括第一和第二媒体的方式修改CPM客户端110和CPM服务器120之间的会话。此外，在步骤1443中，CPM服务器120向ISF 130发送″200 OK″。然后，在步骤1445中，以包括第一和第二媒体的方式修改CPM服务器120和ISF 130之间的会话。
[0239] 图15和16的根据本发明的第五实施例的ISF处理会话发起请求的操作与图6中描述的CPM服务器的操作相同。但是，在B2BUA模式中，图6的操作由ISF执行，因而图6中的步骤513和509必须被如下修正。也就是说，步骤509必须被修订为“产生对会话发起请求的响应消息，并将它发送回CPM服务器”，以及步骤513必须被修订为“选择最适合于处理在步骤511中产生的会话发起请求消息的IWF，并将会话发起请求消息发送到选择的IWF”。
[0240] 图17和18示出了根据本发明的第六实施例的当ISF工作在B2BUA模式中时通过改变特定媒体类型来修改已经发起的会话的操作。也就是说，图17和18预见的情况假定，将新的媒体，即第三和第四媒体添加到已经在图15和16中发起的包括第一和第二媒体的会话，同时从该会话中删除第二媒体。
[0241] 在步骤1201中，CPM客户端110向CPM服务器120发送用于向已经发起的会话添加第三和第四媒体并且从该会话中删除第二媒体的会话修改请求消息。
[0242] 在步骤1201中的会话修改请求消息包括用于第一、第三和第四会话的SDP参数。在步骤1203中，CPM服务器120将接收的会话修改请求消息传送到ISF 130。
[0243] 在步骤1205中，ISF 130选择第二媒体会话作为对于该会话修改请求的目标会话。在步骤1207中，ISF 130产生被适配为第二媒体会话的会话修改请求消息，并且向第二IWF 142发送该会话修改请求消息。在步骤1207中的会话修改请求消息包括用于第三和第四会话的SDP参数。在步骤1209中，第二IWF 142发送回拒绝响应消息，因为第二IWF142不支持第三和第四媒体。
[0244] 在步骤1211中，ISF 130将用于从第二媒体会话中删除第二媒体的请求重新发送到第二IWF 142。由于第二媒体会话除了第二媒体之外当前不包括其它媒体，因此ISF 130向第二IWF 142发送对于第二媒体会话的会话终止请求消息(BYE)。
[0245] 在步骤1213中，第二IWF 142发送回对会话终止请求消息的接受响应消息。在步骤1215中，终止ISF 130和第二IWF 142之间的第二会话。
[0246] 在步骤1217中，ISF 130产生用于向还没有为其做出媒体添加请求的第一媒体会话添加被拒绝的第三和第四媒体的媒体添加请求消息，然后在步骤1219中，向第一IWF141发送产生的媒体添加请求消息。媒体添加请求消息包括用于第一、第三和第四媒体的SDP参数。
[0247] 由于第一IWF 141支持第一和第四媒体，但是第一IWF 141不支持第三媒体，因此第一IWF 141接受第一和第四媒体而拒绝第三媒体。因而，在步骤1221中，第一IWF 141发送回包括这样的细节的响应消息。也就是说，响应消息包括指示第三媒体由于第一IWF 141的属性而被拒绝的信息。在步骤1223中，由于第一和第四媒体被接受，因此以包括第一和第四媒体的方式修改第一媒体会话。
[0248] 在步骤1225中，ISF 130再次产生对于被拒绝的第三媒体的会话发起请求消息。为了产生的会话发起请求消息的互配，ISF 130在步骤1227中选择第三IWF 143，并且将在步骤1225中产生的会话发起请求消息传送到第三IWF 143。在步骤1231中，第三IWF 143产生并发送回对会话发起请求的接受响应消息。在步骤1233中，在ISF 130和第三IWF 143之间发起第三媒体会话。
[0249] 在步骤1235中，ISF 130产生对在步骤1203中接收到的会话修改请求的接受响应消息，然后将接受响应消息发送回CPM服务器120。步骤1235中的响应消息包括指示请求的所有CPM服务器120都被接受的细节。随后，在步骤1237中，以包括第一、第三和第四媒体的方式修改CPM服务器120和ISF 130之间的会话。
[0250] 在步骤1239中，CPM服务器120产生对在步骤1201中接收到的会话修改请求的接受响应消息，然后将接受响应消息发送回CPM客户端110。步骤1239中的响应消息包括指示请求的所有CPM客户端110都被接受的细节。在步骤1241中，以包括第一、第三和第四媒体的方式修改在CPM客户端110和CPM服务器120之间的会话。
[0251] 在图17和18的操作中，可以根据ISF 130的实施方式修正步骤1207到1217。换句话说，ISF 130可以向支持相应的媒体的IWF发送对于第二媒体的媒体删除请求(Re-INVITE)或对于第二媒体会话的会话终止请求(BYE)，并且同时发送对于第三和第四媒体的会话发起请求(INVITE)。这是可以的，因为ISF 130已经知道每个IWF支持哪些媒体类型。
[0252] 根据本发明的第六实施例的ISF处理会话修改请求的操作与图13和14中描述的CPM服务器的操作相同。但是，步骤1031被如下修正。在图13和14中的代理模式的情况下，CPM服务器根据是否需要互配而进行到步骤1033或1035，并且向ISF或接收客户端的地址发送会话发起请求消息。但是，由于在B2BUA模式中是否需要互配是由CPM服务器确定的，因此B2BUA模式中的步骤1031必须被修订为“选择最适合于执行在步骤1029中产生的会话发起请求消息的IWF，并且将会话发起请求消息发送到选择的IWF”。此外，省略不必要的步骤1033和1035，并且随后ISF返回到步骤501以便处理对会话发起请求消息的响应消息。
[0253] 尽管已经参考本发明的特定示范性实施例对本发明进行了图示和描述，但是本领域技术人员应当理解，在不脱离由所附权利要求书所定义的本发明的精神和范围的情况下，可以对本发明做出形式和细节上的各种修改。
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
修改热门专利
QQ群二维码
意见反馈
意见反馈