CN115801741A - 由电话api调用的呼叫管理 - Google Patents

Abstract

由电话API调用的呼叫管理。提供了一种管理在受管理端点和多个目的地端点之间的会话的方法。该方法包括向受管理端点发送（S122）第一会话发起协议SIP INVITE，其中第一SIP INVITE包括第一呼叫标识符和多个目的地端点中的第一目的地端点的媒体地址。该方法进一步包括向受管理端点发送（S180）第二SIP INVITE，其中第二SIP INVITE包括第一呼叫标识符和多个目的地端点中的第二目的地端点的媒体地址，其中第二目的地端点不同于第一目的地端点。

Description

由电话API调用的呼叫管理

用于管理受管理端点和多个目的地端点之间的会话的方法、服务器和计算机软件。

技术领域

本申请涉及使用会话发起协议SIP管理端点之间的会话。特别地，本申请涉及由与端点分离的呼叫管理服务器发起和管理会话的SIP流。本申请进一步涉及基于网络的应用编程接口API，其可以用于调用使用SIP实现的呼叫管理能力。

背景技术

呼叫管理方法允许用户在其管理的设备和目的地设备之间发起会话。还存在执行诸如保持、转移等之类的呼叫中功能的方法。当第一会话正在进行时，用户可以在其管理的用户设备和不同的目的地设备之间发起另一会话。然而，这些方法相当不灵活，并且提供有限的管理操作，所述有限的管理操作可以通过API经由呼叫管理应用来访问。

发明内容

提供了一种管理在受管理端点和多个目的地端点之间的会话的方法。该方法包括：

x）向受管理端点发送（S122）第一会话发起协议SIP INVITE，其中第一SIP INVITE包括第一呼叫标识符和多个目的地端点中的第一目的地端点的媒体地址；和

y）向受管理端点发送（S180）第二SIP INVITE，其中第二SIP INVITE包括第一呼叫标识符和多个目的地端点中的第二目的地端点的媒体地址，其中第二目的地端点不同于第一目的地端点。

该方法可以进一步包括以下步骤：

a）接收（S110）在受管理端点和第一目的地端点之间建立会话的指令；

b）向受管理端点发送（S112）SIP INVITE，其中SIP INVITE包括第一呼叫标识符；

c）从受管理端点接收（S114）OK消息，其中该OK消息包括第一呼叫标识符和受管理端点的媒体地址；

e）向第一目的地端点发送（S118）SIP INVITE，其中SIP INVITE包括受管理端点的媒体地址；

f）从第一目的地端点接收（S120）OK消息，其中该OK消息包括第一目的地端点的媒体地址；

j）接收（S162）在受管理端点和第二目的地端点之间建立会话的指令；

q）向第二目的地端点发送（S176）SIP INVITE；

r）从第二目的地端点接收（S178）OK消息，其中该OK消息包括第二目的地端点的媒体地址；

t）向第二目的地端点发送（S184）确认ACK，其中ACK包括受管理端点的媒体地址。

步骤a）至e）和f）可以在步骤x）之前执行。步骤j）、n）、q）和r）可以在步骤x）之后和步骤y）之前执行。步骤t）可以在步骤y）之后执行。

该方法可以包括上述所有步骤，或可以仅包括这些步骤的子集。

步骤e）中发送的SIP INVITE（S118）可以进一步包括第二呼叫标识符。

在步骤f）中接收的OK消息（S120）可以进一步包括第二呼叫标识符。

该方法可以进一步包括：

n）向第一目的地端点发送（S170）SIP INVITE，其中SIP INVITE包括第二呼叫标识符和第一目的地端点已经被置于HOLD（保持）的指示。

步骤q）中发送的SIP INVITE（S176）可以包括第三呼叫标识符。

在步骤r）中接收的OK消息（S178）可以进一步包括第三呼叫标识符。

步骤t）中发送的ACK（S184）可以进一步包括第三呼叫标识符。

可以在步骤b）中在受管理端点处建立与第一呼叫标识符相关联的信令信道。可以在步骤x）使用信令信道来建立（S130）受管理端点和第一目的地端点之间的第一媒体会话。可以在步骤y）使用信令信道来建立（S190）受管理端点和第二目的地端点之间的第二媒体会话。换言之，相同的信令信道可以用于建立不同的媒体信道。

媒体会话可以是语音呼叫或视频呼叫。

步骤a）处的指令和/或步骤j）处的指令可以是来自用户应用的基于IP的请求。

步骤a）处的指令和/或步骤j）处的指令可以是来自用户应用的超文本传输协议HTTP请求。

步骤a）处的指令和/或步骤j）处的指令可以使用适合用于电话API中的任何类型的协议进行通信。例如，可以使用计算机支持的电信应用CSTA来传送指令。

该方法可以进一步包括以下步骤中的一项或二者：

d）向受管理端点发送（S116）确认ACK，其中ACK包括第一呼叫标识符和公告服务的媒体地址；

k）向受管理端点发送（S164）SIP INVITE，其中该SIP INVITE包括第一呼叫标识符和公告服务的媒体地址。

步骤d）可以在步骤x）之前执行。步骤k）可以在步骤x）之后和步骤y）之前执行。

步骤k）中的公告服务可以不同于步骤d）中的公告服务（换言之，它们可以分别是第一和第二公告服务）。在这种情况下，公告服务的媒体地址将是不同的。替代地，公告可以由相同的公告服务提供，并且在这些步骤中提供的媒体地址因此可以是相同的。

在步骤n）中发送到第一目的地端点的SIP INVITE可以进一步包括保持公告服务的媒体地址。

保持公告服务可以不同于上述第一和第二公告服务。

该方法可以进一步包括：

g）从受管理端点接收（S124）OK消息，其中该OK消息包括第一呼叫标识符；

h）向第一目的地端点发送（S126）ACK；

i）向受管理端点发送（S128）ACK，其中ACK包括第一呼叫标识符；

l）从受管理端点接收（S166）OK消息，其中该OK消息包括第一呼叫标识符；

m）向受管理端点发送（S168）ACK，其中ACK包括第一呼叫标识符；

o）从第一目的地端点接收（S172）OK消息；

p）向第一目的地端点发送（S174）ACK；

s）从受管理端点接收（S182）OK消息，其中该OK消息包括第一呼叫标识符；和

u）向受管理端点发送（S186）ACK，其中ACK包括第一呼叫标识符。

步骤g）、l）和o）可以在步骤x）之后和步骤y）之前执行。步骤s）和u）可以在步骤y）之后执行。

在步骤g）中接收的OK消息（S124）可以进一步包括受管理端点的媒体地址。

步骤h）中发送的ACK（S126）可以包括第二呼叫标识符。

在步骤l）中接收的OK消息（S166）可以进一步包括受管理端点的媒体地址。

在步骤p）中发送的ACK（S174）可以包括第二呼叫标识符。

在步骤o）中接收的OK消息（S172）可以包括第二呼叫标识符。在步骤o）中接收的OK消息（S172）可以进一步包括第一目的地端点的媒体地址。

就媒体连接的IP和端口（SDPB）而言，第一目的地端点在步骤o）（S172）中发送的媒体信息可以与步骤f）（S120）中发送的媒体信息相同。在步骤f）和o）中发送的媒体信息之间的一个差异可以是在步骤o）中指示属性“recvonly ”，而在步骤f）中可以指示属性“sendrecv”。这可能是因为在步骤n）中接收的INVITE可能包含属性“sendonly”，可能需要该属性“sendonly”来指示呼叫处于保持。

“recvonly”可以指示设备被配置为接收媒体但不发送媒体。

“sendonly”可以指示设备被配置为发送媒体但不接收媒体。

“sendrecv”可以指示设备被配置为发送和接收媒体。

在步骤s）中接收的OK消息（S182）可以进一步包括受管理端点的媒体地址。

步骤x）处的第一SIP INVITE可以进一步包括第一目的地端点的信令地址。

步骤y）处的第二SIP INVITE可以进一步包括第二目的地端点的信令地址。

如果受管理端点支持SIP“from-change”特征，则可以为SIP对话提供更新的信令地址，以及为媒体会话提供更新的媒体地址。

可以使用会话描述协议SDP提供第一目的地端点的媒体地址和/或第二目的地端点的媒体地址。第一目的地端点的媒体地址可以是SDP媒体地址。第二目的地端点的媒体地址可以是SDP媒体地址。

该方法可以进一步包括以下各项中的一项或二者：

使用所提供的SDP媒体地址（第一目的地端点的媒体地址）在受管理端点和第一目的地端点之间交换媒体；

使用所提供的SDP媒体地址（第二目的地端点的媒体地址）在受管理端点和第二目的地端点之间交换媒体。

响应于在步骤x）处接收到第一SIP INVITE，可以在受管理端点和第一目的地端点之间建立媒体连接信道。

响应于在步骤y）处接收到第二SIP INVITE，可以在受管理端点和第二目的地端点之间建立媒体连接信道。

可以作为包括媒体地址的SIP邀请的直接结果，建立媒体信道。

可以使用适合用于实时传送媒体的协议交换媒体。

可以使用例如实时传输协议RTP交换媒体。

多个目的地端点中的每一个可以具有不同的媒体地址。多个目的地端点中的每一个可以具有不同的信令地址。换言之，在步骤y）处用于提供第二受管理端点的媒体地址的RE-INVITE可以是用于具有不同信令地址以及不同媒体地址的完全不同的目的地端点的媒体地址。

受管理端点可以是用户设备UE。换言之，受管理端点可以是3G+设备。

还提供了一种配置为执行上述方法的服务器。

还提供了包括指令的计算机软件，所述指令当由计算机的处理器执行时，使得计算机执行上述方法。

某些步骤中的消息可以是对其他消息的响应，或者可以由其他消息触发。例如：

可以响应于步骤b）中发送的INVITE（S112）来接收步骤c）中的OK（S114）；

可以响应于步骤c）中的OK（S114）来发送步骤d）中的ACK（S116）；

可以响应于步骤e）中发送的INVITE（S118）来接收步骤f）中的OK（S120）；

可以响应于步骤f）中的OK（S120）来发送步骤h）中的ACK（S126）；

可以响应于步骤x）中发送的INVITE（S122）来接收步骤g）中的OK（S124）；

可以响应于步骤g）中的OK（S124）来发送步骤i）中的ACK（S128）；

可以响应于步骤k）中发送的INVITE（S164）来接收步骤l）中的OK（S166）；

可以响应于步骤l）中的OK（S166）来发送步骤m）中的ACK（S168）；

可以响应于在步骤n）中发送的INVITE（S170）来接收步骤o）中的OK（S172）；

可以响应于步骤o）中的OK（S172）来发送步骤p）中的ACK（S174）；

可以响应于步骤q）中发送的INVITE（S176）来接收步骤r）中的OK（S178）；

可以响应于步骤r）中的OK（S178）来发送步骤t）中的ACK（S184）；

可以响应于步骤y）中的INVITE（S180）来发送步骤s）中的OK（S182）；

可以响应于步骤s）中的OK（S182）来发送步骤u）中的ACK（S186）。

可以按特定次序执行步骤。可以准许对一些步骤进行重新排序。例如：

步骤a）可以在步骤b）之前执行；和/或

步骤b）可以在步骤c）之前执行；和/或

步骤c）可以在步骤d）之前执行；和/或

步骤d）可以在步骤e）之前执行；或者

步骤e）可以在步骤d）之前执行；或者

步骤d）可以与步骤e）同时进行；和/或

步骤e）可以在步骤f）之前执行；和/或

步骤f）可以在步骤x）之前执行；和/或

步骤x）可以在步骤g）之前执行；和/或

步骤g）可以在步骤h）之前执行；和/或

步骤h）可以在步骤i）之前执行；和/或

步骤i）可以在步骤j）之前执行；和/或

步骤j）可以在步骤k）之前执行；和/或

步骤k）可以在步骤l）之前执行；和/或

步骤l）可以在步骤m）之前执行；和/或

步骤m）可以在步骤n）之前执行；或者

步骤n）可以在步骤m）之前执行；或者

步骤m）可以与步骤n）同时执行；和/或

步骤n）可以在步骤o）之前执行；和/或

步骤o）可以在步骤p）之前执行；和/或

步骤p）可以在步骤q）之前执行；或者

步骤q）可以在步骤p）之前执行；或者

步骤p）可以与步骤q）同时执行；和/或

步骤q）可以在步骤r）之前执行；和/或

步骤r）可以在步骤y）之前执行；和/或

步骤y）可以在步骤s）之前执行；和/或

步骤s）可以在步骤t）之前执行；和/或

步骤t）可以在步骤u）之前执行；或者

步骤u）可以在步骤t）之前执行；或者

步骤t）可以与步骤u）同时进行。

根据另一方面，提供了一种管理在受管理端点和多个目的地端点之间的会话的方法。该方法包括向受管理端点发送第一会话发起协议SIP INVITE，其中第一SIP INVITE包括第一呼叫标识符。该方法进一步包括向受管理端点发送第二SIP INVITE，其中第二SIP邀请包括相同的第一呼叫标识符。

第一SIP INVITE可以用于建立与第一目的地端点的连接。第二SIP INVITE可以用于建立与第二目的地端点的连接。换言之，该方法可以包括对具有相同呼叫标识符的受管理端点的两个INVITE，其中第一INVITE的目的是要建立与第一目的地端点的媒体连接信道，并且第二INVITE的目的是要建立与第二目的地端点的媒体连接信道。

第二目的地端点可以不同于第一目的地端点。

用于与第二目的地端点的连接的媒体信息可以不同于用于与第一目的地端点的连接的媒体信息。

有利的是，信令信道相同，因为使用了相同的第一呼叫标识符。媒体信道是不同的，因为目的地端点不同。

上述提出的方法可以改进用户使用第三方呼叫控制应用来管理呼叫的客户体验。使用提出的方法，可能的是经由管理传统设备的呼叫的第三方呼叫控制应用来建立多于2个呼叫。

附图说明

图1图示了用于在受管理端点和目的地端点之间发起会话的信令。

图2图示了用于在受管理端点和第一目的地端点之间发起第一会话以及在受管理端点和第二目的地端点之间发起第二会话的方法的信令。

图3图示了根据特定示例用于在受管理端点和第一目的地端点之间发起第一会话以及在受管理端点和第二目的地端点之间建立第二会话的新方法的信令。

图4图示了根据特定示例用于在受管理端点和第一目的地端点之间发起第一会话以及在受管理端点和第二目的地端点之间建立第二会话的新方法的信令。

图5图示了根据特定示例用于执行信令的服务器。

具体实施方式

提供了一种呼叫管理的新方法。该方法包括在呼叫管理服务器处接收请求（例如，经由API）以及由呼叫管理服务器响应于该请求而执行的SIP信令。呼叫管理服务器公开了电话API，使得开发者可以提供他们自己的应用来管理会话（诸如呼叫）。服务器发起并维护会话，以响应于通过API做出的请求。作为示例，用户可以请求服务器发起对B的呼叫。然后，服务器将呼叫A，等待应答，呼叫B，等待应答，并且然后将A和B连接在一起。

目的是提供一种用于通过呼叫管理服务器（诸如“OneNet”（RTM）服务器）管理会话的改进并且简单的方法。会话管理可以借助于电话API来实现，第三方可以经由外部开发的应用来利用该电话API。例如，这些应用可以用于管理语音呼叫。API可以允许访问由呼叫管理服务器实现的不同服务。这可以允许第三方开发和维护适合他们自己需求的网络应用。这允许具有用于呼叫管理的更多选项的更灵活的系统。这样，用户或用户组可以以更灵活的方式实现呼叫管理应用。这可以通过提供实现API的呼叫管理服务器来实现，该API公开了呼叫管理功能并且可被第三方呼叫管理应用外部访问，该第三方呼叫管理应用可以被单独开发以满足用户的需求。

在一些示例中，API可以是：

·网络友好；和

o基于面向网络的语言和协议。

·开发者友好。

o对开发者理解和使用更简单。

呼叫管理服务器100公开了电话API，以允许作为第三方呼叫控制的应用来管理端点之间的会话。

在一个示例用例中，用户经由网络应用200请求发起呼叫，以将他们的电话、端点A300（移动电话、软电话、移动电话等）与目的地端点B 400连接。一旦建立了呼叫，也是从应用，用户就可以请求将呼叫置于保持，将其转移到不同的目的地（诸如端点C 500），将其加入到与另一目的地（诸如端点C 500）的会议中，等等。

一些呼叫管理服务器通过API接受呼叫管理命令。然而，它们不使用面向网络的语言，而是使用其他不太用户友好的协议。用于管理通过API的呼叫的现有方法受限于现有API的限制。

当用户从呼叫管理应用程序200请求向端点B 400做出呼叫时，网络上承载的信令流在图1中图示并且在下面描述：

·S110：“MAKE CALL TO B”

o用户A从应用程序200向呼叫管理服务器100发送请求，以请求与目的地端点B400的呼叫。例如，该请求可以是使用由服务器实现的API做出的基于网络的请求。

·S112：“INVITE callid1”

o呼叫管理服务器100将具有第一呼叫标识符“callid1”的SIP INVITE发送到受管理端点A 300（朝向用户A将参加呼叫的设备）。

·S114：“200OK callid1/SDPA”

o当用户A应答呼叫时，受管理端点A 300向呼叫管理服务器100发送OK消息，该OK消息包括受管理端点A 300的媒体地址“SDPA”。

·S116：“ACK callid1/SDP公告”

o呼叫管理服务器100向受管理端点A 300发送确认ACK，该确认ACK包括公告服务“SDP公告”的媒体地址。然后，用户A与公告连接，并且听到诸如“请稍候，我们将连接您的呼叫”之类的消息。

·S118：“INVITE callid2/SDPA”

o呼叫管理服务器100使用第二呼叫标识符“callid2”向目的地端点B 400发送SIPINVITE（例如，对应于在S110的请求中指定的号码）。SIP INVITE可以包括受管理端点A 300的媒体地址“SDPA”。替代地，受管理端点A 300的媒体地址可以在后续消息中被发送到目的地端点B 400（未示出）。

·S120：“200OK callid2/SDPB”

o当目的地端点B 400应答呼叫时，包括目的地端点B 400的媒体地址“SDPB”的OK消息被发送到呼叫管理服务器100。

·S122：“RE-INVITE callid1/SDPB”

o呼叫管理服务器100通过使用第一呼叫标识符向受管理端点A 300发送RE-INVITE消息，向受管理端点A 300提供目的地端点B 400的媒体地址。

·S124：“200OK callid1/SDPA”

o受管理端点A 300利用OK消息来响应RE-INVITE。OK消息可以包括用于受管理端点A 300的媒体地址。为简单起见，受管理端点A 300的媒体地址“SDPA”每次都示出为相同。然而，媒体地址可以取决于其他端点（诸如目的地端点B 400）或公告服务的能力。

·S130：“A-B CONNECTED”

o一旦受管理端点A 300和目的地端点B 400已经交换了媒体地址（诸如分别是 “SDPA”和“SDPB”），会话就被发起，并且可以发生媒体交换。在呼叫的情况下，呼叫被连接，并且用户能够交换音频（和/或视频）。

如果在从应用程序建立呼叫之后，用户A想要呼叫新号码C（可能之后将呼叫从B转移到C），则用于此的信令在图2中示出，该信令通过添加以下步骤基于图1中描述的信令构建：

·S132：“MAKE CALL TO C”

o用户A从应用程序200向呼叫管理服务器100发送新请求，以请求与不同目的地端点C 500的呼叫。如前所述，该请求可以是使用由服务器实现的API做出的基于网络的请求。

·S134：“INVITE callid3”

o呼叫管理服务器100向受管理端点A 300（朝向用户A将参加呼叫的设备）发送具有新呼叫标识符“callid3”的新SIP INVITE。这将引起用户的设备振铃，并且用户将需要应答呼叫以连接到C。

·S136：“RE-INVITE callid1 onHOLD”

o当用户A在他们的设备（受管理端点A 300）处应答呼叫时，与目的地端点B 400的先前呼叫被自动保持。这是通过受管理端点A 300向呼叫管理服务器100发送具有第一呼叫标识符（诸如“callid1”）和呼叫正被置于保持的指示的RE-INVITE消息来完成的。

·S140：“RE-INVITE callid2 onHOLD”

o当呼叫管理服务器100从受管理端点A 300接收到“RE-INVITE callid1 onHOLD”消息时，服务器向目的地端点B 400发送具有第二呼叫标识符“callid2”的RE-INVITE消息，以将呼叫者置于保持。

·S142：“200OK callid2”

o目的地端点B 400向呼叫管理服务器100发送OK消息，以指示受管理端点A 300和目的地端点B 400之间的呼叫处于保持。

·S143：“200OK callid1”

o呼叫管理服务器100向受管理端点A 300发送OK消息，以指示受管理端点A 300和目的地端点B 400之间的呼叫处于保持。

·S144：“200OK callid3/SDPA2”

o一旦对目的地端点B 400的呼叫被成功置于保持，受管理端点A 300就利用OK消息来响应用于与目的地端点C 500的呼叫的新INVITE，并提供媒体地址（诸如“SDPA2”）。

·S145：“ACK callid3/SDP公告”

o在步骤S144，呼叫管理服务器100响应于200 OK消息向受管理端点A 300发送ACK，并且提供公告服务的媒体地址，使得用户A听到公告。

·S146：“INVITE callid4/SDPA2”

o呼叫管理服务器100向目的地端点C 500发送新的SIP INVITE。

·S148：“200OK callid4/SDPC”

o当目的地端点C 500应答呼叫时，包括目的地端点C 500的媒体地址“SDPC”的OK消息被从目的地端点C 500发送到呼叫管理服务器100。

·S150：“RE-INVITE callid3/SDPC”

o呼叫管理服务器100通过使用新的呼叫标识符“callid3”向受管理端点A 300发送RE-INVITE消息，向受管理端点A 300提供目的地端点C 500的媒体地址。

·S152：“200OK callid3/SDPA2”

o受管理端点A 300利用OK消息来响应RE-INVITE。

·S190：“A-C CONNECTED”

o一旦受管理端点A 300和目的地端点C 500已经交换了媒体地址（“SDPA2” “SDPC”），会话就被发起，并且可以发生媒体交换。在呼叫的情况下，呼叫被连接，并且用户能够交换音频（和/或视频）。

在该场景中，这种管理呼叫的方式具有缺点，包括：

·A正在应答呼叫的设备需要接收用于C呼叫的第二个呼叫。

·如果A的设备是移动电话，则最多仅2个呼叫将能够被同时应答，一个连接并且另一个保持。

因此，提出了一种改进用户体验和增加可以从呼叫管理应用同时参加的呼叫数量的方式。该API将具有宽范围的用例。参考上面描述的用例，描述了提议的具体示例。

当用于应答呼叫的端点（也称为“终端”）是移动电话时，可以改变信令，使得当从应用程序请求新呼叫（并且呼叫已连接到A的设备）时，呼叫管理服务器100不向A的设备发送具有新呼叫标识符的INVITE。取而代之的是，呼叫管理服务器100使用已经与A建立的“信道”（将A与B连接）来代替使用RE-INVITE将A与C连接。发送到A的RE-INVITE具有与发送到A的已在INVITE中使用的相同的呼叫标识符“callid1 ”，以建立A和B之间的信道（在步骤S112中）。示例信令在图3中图示并且在下面解释：

·S110–S130与上面描述的相同。

·S162：“MAKE CALL TO C”

o用户A从应用程序200向呼叫管理服务器100发送新请求，以请求与不同目的地端点C 500的呼叫。如前所述，该请求可以是使用由服务器实现的API做出的基于网络的请求。该请求可以包括应该重新使用现有“信道”来建立与目的地端点C 500的连接的指示。换言之，用于将受管理端点A 300与目的地端点C 500连接的INVITE应该是与S112中的INVITE具有相同呼叫标识符的RE-INVITE。

·S164：“RE-INVITE callid1/SDP公告”

o呼叫管理服务器100向端点A 300（朝向用户A将参加呼叫的设备）发送SIP RE-INVITE。RE-INVITE具有与已经在受管理端点A 300上建立的呼叫相同的呼叫标识符“callid1”。因此，该RE-INVITE将不引起用户的设备（受管理端点A 300）振铃，并且将不要求用户为了连接到目的地端点C 500而应答呼叫。RE-INVITE可以包括公告服务的媒体地址。

·S166：“200OK callid1/SDPA”

o呼叫管理服务器100从受管理端点A 300接收“200OK callid1/SPDA”消息，从而确认受管理端点A 300已经将它们的媒体连接重新定向离开目的地端点B 400。取而代之的是，受管理端点A 300连接到公告服务“SDP公告”。

·S170：“RE-INVITE callid2 onHOLD”

o呼叫管理服务器100通过向目的地端点B 400发送具有第二呼叫标识符“callid2”和呼叫正被置于保持的指示的RE-INVITE消息，将与目的地端点B 400的先前呼叫置于保持。一旦到受管理端点A 300的媒体已经被RE-INVITE重新定向，这就可能发生。

·S172：“200OK callid2”

o目的地端点B 400向呼叫管理服务器100发送OK消息，以指示受管理端点A 300和目的地端点B 400之间的呼叫处于保持。该呼叫场景对于目的地端点B 400来说可能看起来与上述场景相同。

·S176：“200OK callid2”

o呼叫管理服务器100朝向目的地端点C 500发送新的SIP INVITE。

·S178：“200OK callid3/SDPC”

o当目的地端点C 500应答呼叫时，包括目的地端点C 500的媒体地址“SDPC”的OK消息被从目的地端点C 500发送到呼叫管理服务器100。

·S180：“RE-INVITE callid1/SDPC”

o当发起对B“callid1”的呼叫时，呼叫管理服务器100使用在步骤S112中使用的呼叫标识符，通过向受管理端点A 300发送RE-INVITE消息来向受管理端点A 300提供目的地端点C 500的媒体地址。

·S182：“200OK callid1/SDPA”

o受管理端点A 300在步骤S180中利用OK消息来响应RE-INVITE。OK消息可以包括受管理端点A 300的媒体地址“SDPA”。

·S190：“A-C CONNECTED”

o一旦受管理端点A 300和目的地端点C 500交换了媒体地址（“SDPA”“SDPC”），会话就被发起，并且媒体交换可以发生。在呼叫的情况下，呼叫被连接，并且用户能够交换音频（和/或视频）。

如上面可以看到的，当用户C应答呼叫时，使用SIP RE-INVITE，使用目的地端点C500提供的媒体地址，受管理端点A 300与目的地端点C 500连接。目的地端点B也可以随后与SIP RE-INVITE（未示出）连接。

公告服务

如上所述，可以在以下步骤中向受管理端点A 300提供公告服务的媒体地址：

·S116：“ACK callid1/SDP公告”

o呼叫管理服务器100向受管理端点A 300发送确认ACK，该确认ACK包括公告服务“SDP公告”的媒体地址。然后，用户A与公告连接，并且听到诸如“请稍候，我们将连接您的呼叫”之类的消息。

·S164：“RE-INVITE callid1/SDP公告”

o呼叫管理服务器100向受管理端点A 300发送SIP RE-INVITE（朝向用户A将参加呼叫的设备）。RE-INVITE具有与已经在受管理端点A上建立的呼叫相同的呼叫标识符“callid1”。因此，这将不引起用户的设备振铃，并且将不需要用户为了连接到目的地端点C500而应答呼叫。RE-INVITE可以包括公告服务的媒体地址。

·S166：“200OK callid1/SDPA”

o呼叫管理服务器100从受管理端点A 300接收“200OK callid1/SPDA”消息，确认受管理端点A 300已经将它们的媒体连接重新定向离开目的地端点B 400。取而代之的是，受管理端点A 300连接到公告服务“SDP公告”。

也可以为目的地端点提供公告服务的媒体地址。在S170中发送的RE-INVITE可以进一步包括保持公告服务的媒体地址：

·S170：“RE-INVITE callid2/SDP公告onHOLD”。

为了促进onHOLD公告服务，端点B可以在步骤S172中发送的200 OK响应中进一步提供媒体地址：

·S172：“200OK callid2/SDPB”。

步骤S170中播放的公告可以不同于步骤S116中播放的公告和步骤S164中播放的公告。媒体资源功能MRF的媒体地址在每个情况下可以不同（在网络中可以提供多于一个MRF）。

确认

当接收到进行第二次呼叫的指令时，不是向受管理端点A 300发送新呼叫（具有不同呼叫标识符的INVITE ），这要求A的用户采取手动动作来应答呼叫，而是提出的方法使用已经建立的信道。该方法可以包括以下步骤：

·将第一目的地端点置于保持（步骤S170）

·将受管理端点与MRF连接，听到第二目的地被警告的公告（步骤S164）

·第二目的地端点接收新呼叫（步骤S176）。

与步骤S146中发送至C的INVITE不同，步骤S176中发送至C的INVITE可能不包括端点A的媒体地址。步骤S176中发送至第二目的地的SIP INVITE不包含用于受管理端点的媒体地址（例如“SDPA”），因为此时受管理端点与公告服务连接。当服务从第二目的地接收到对于第三呼叫标识符的呼叫的应答时，向受管理端点A 300发送具有第二目的地的媒体信息的RE-INVITE（并且公告停止）。该RE-INVITE用于改变媒体信息，并且由于呼叫标识符是相同的（第一呼叫标识符），所以它由受管理端点A 300的设备自动应答，而无需任何手动动作。该应答包含第二目的地端点500必须向其发送媒体分组的受管理端点媒体信息。因此，受管理端点A 300的媒体地址（“SDPA”）在ACK（在步骤S178中发送到呼叫管理服务器100的200 OK的确认）中被发送到第二目的地端点C 500。从那时起，在步骤S190中，可以在受管理端点和第二目的地端点之间交换媒体分组。这在图4中进行了说明，旁边还有一些其他的ACK消息，为了简洁起见，先前省略了一些其他的ACK消息。这些其他ACK消息可能不包含SDP（媒体）信息。信令在下面解释：

·如上所述的S110–S124

·S126：“ACK callid2”

·S128：“ACK callid1”

·如上所述的S162–S166

·S168：“ACK callid1”

·如上所述的S170–172

·S174：“ACK callid2”

·如上所述的S176–S182

·S184：“ACK callid3/SDPA”

o在步骤S182中，受管理端点A 300的媒体地址被提供给呼叫管理服务器100，并且可以在步骤S184中被提供给目的地端点C 500，这是对在步骤S178中发送的OK的确认。

·S186：“ACK callid1”

·如上所述的S190。

在步骤S114中的200 OK消息中和在步骤S124中的200 OK消息中，将受管理端点A300的媒体地址提供给呼叫管理服务器100。每当存在新的媒体提议被发送到受管理端点A300（诸如使用具有新的目的地媒体地址的相同呼叫标识符的新的RE-INVITE）时，作为响应，可以发送200 OK/SDP，即使该SDP（受管理端点A 300的媒体地址）没有改变。换言之，目的地媒体地址在公告服务、目的地端点B 400和目的地端点C 500之间改变，但是受管理端点A 300的媒体地址可以保持不改变。然而，在步骤S124中，受管理端点A 300可以在200 OK消息中发送未改变的媒体地址，以遵守协议。类似地，在步骤S166和步骤S182中发送的200OK消息也包括受管理端点A 300的媒体地址，其可以保持不改变。

受管理端点的媒体地址（依据媒体信道的IP和端口）可以保持不改变，除非呼叫被转移。然而，取决于其他端点的能力，其他属性可以改变。例如，所选的编解码器可以改变。受管理端点A 300在步骤S124的OK中发送的媒体信息是对在步骤S122中接收的INVITE的应答，其包括目的地端点B 400的媒体信息。因此，在步骤S124中发送的媒体信息中的一些属性（诸如编解码器等）可以不同于在步骤S114中发送的媒体信息（这是在提供了目的地端点的任何媒体信息之前响应于初始INVITE而发送的OK）。

步骤S166的200 OK是对步骤S164中接收的INVITE的应答。因此，受管理端点A 300的媒体信息可以是在步骤S114和S124中提供的媒体信息的相同IP地址和端口。然而，一些属性值可能不同。例如，指示的编解码器可以是从步骤S164的INVITE中提供的编解码器中选择的一个。

可以在S126的ACK中将受管理端点A 300的媒体地址发送到目的地端点B 400。如果在S118的INVITE不包含任何媒体信息，则这可以向目的地端点B提供SDP媒体地址SDPA。

硬件

图5图示了根据特定示例的呼叫管理服务器100。呼叫管理服务器100被配置为执行本申请中描述的呼叫管理方法。呼叫管理服务器100可以包括网络接口。呼叫管理服务器100可以被配置为经由网络接口发送和接收SIP消息。呼叫管理服务器100可以包括应用编程接口。呼叫管理服务器100可以被配置为经由API从一个或多个第三方应用接收呼叫管理请求。

会话与对话

当设立与端点C的会话时，呼叫管理服务器100发送与被发送的用于设立与B的早期会话的INVITE具有相同呼叫标识符的RE-INVITE。换言之，RE-INVITE是与原始INVITE相同的对话的部分。这样，对于媒体来说，使用的是同一个“信道”（至少从A的角度来看）。结果，当呼叫管理服务器100将A连接到C时，端点A不需要应答新的呼叫。已经在端点A为与端点B的会话设立的信道被用于新的呼叫（例如，到端点C）。这允许用户以简单的方式（经由应用）管理多个呼叫。

在先前的呼叫管理方法中，可以为至单独目的地端点（例如，B 400和C 500）的每个呼叫建立新会话（具有新呼叫标识符）。在端点A是移动电话的情况下，呼叫管理操作可以被限制为不多于2个呼叫。这是因为一些移动电话仅能够维持两个同时呼叫（一个活动，并且一个保持）。相比之下，提出的呼叫管理方法提出在受管理端点A处使用一个活动呼叫来连接到不同的目的地端点（例如，B 400和C 500）。如上所述，这可以通过使用与用于设立活动呼叫的INVITE具有相同呼叫标识符的RE-INVITE消息来实现。

从受管理端点A 300的角度来看，始终将存在最大1个呼叫。同时，提出的呼叫管理方法改进了用户体验，因为用户不需要应答第二个呼叫。不仅当受管理端点A 300是移动电话时如此，而且在所有情况下都是如此。信令改变可以应用于所有场景，以改进用户体验。

如上所述，提出的方法使用修改的信令方法。结果，当基于网络的应用程序200向呼叫平台100发送请求以设立从呼叫者用户设备UE 300到第二和后续UE 500的第二或后续呼叫时，呼叫平台使用已经为从呼叫者UE 300到第一UE 400的呼叫建立的呼叫标识符（例如，“callid1”）。这是借助于RE-INVITE来实现的。换言之，一旦在呼叫者UE 300和第一UE400之间建立了呼叫标识符，相同的呼叫标识符就被用于第二和潜在的后续连接。

当受管理端点连接到多于一个的其他目的地端点时，提出的信令方法可以通过避免对于向受管理端点（例如，呼叫者UE）发送用于新的单独会话（例如，具有不同的呼叫标识符）的多于一个的SIP INVITE的需要，来提供增强的效率。

提出的信令方法可以使得受管理端点（例如，诸如移动电话的UE）使用基于网络的应用程序设立多于两个的同时呼叫（即，与多于两个的其他目的地端点，诸如UE）。这可以通过对于两个不同的会话使用相同的呼叫标识符（从A的角度来看）来实现：

1.A和B之间的会话；和

2.A和C之间的会话。

如上所述，SIP消息在呼叫管理服务器100和端点300、400和500之间交换，而不是直接在端点之间交换。这使得呼叫管理服务器100可以执行管理功能（诸如转移呼叫、呼叫置于保持、发起会议呼叫等）。

呼叫管理服务器100维持与多个端点的对话。因此，每个对话具有不同的标识符。与受管理端点A的对话可以被标识为“callid1”，如在各图中图示的示例中所示。SIP用于在端点A和B之间设立会话。然而，在呼叫管理服务器100和目的地端点B 400之间的对话中使用的标识符（在示例中的“callid2”）可以不同于在呼叫管理服务器100和受管理端点A 300之间的对话中使用的标识符（在示例中是“callid1”）。这是因为呼叫管理服务器100可以使用标识符来在与受管理端点A 300的对话和与目的地端点B 400的对话之间进行区分。

如上所述，在先前的呼叫管理方法中，可以发起呼叫管理服务器100和受管理端点A 300之间的新对话。这将要求A应答新的呼叫。相比之下，提出的方法仅要求呼叫管理服务器100和受管理端点A 300之间的一次对话（“callid1”）。

遍及信令过程，从呼叫管理服务器100向受管理端点A 300发送多个SIP邀请（例如，图1至图4中图示的步骤S112、S122、S134、S150、S164和S180）。在步骤S112处的INVITE发起与受管理设备A的新对话。该对话用于通过在步骤S122中的INVITE中提供目的地端点B400的媒体地址来建立A和B之间的会话。在诸如图2中图示的方法之类的先前方法中，在步骤S134，向受管理端点A发送INVITE，以建立与目的地端点C的会话。重要的是，使用与步骤S112和S122中的标识符不同的标识符，并且发起新的对话。因此，受管理端点A 300必须应答新的呼叫以连接到会话。相比之下，要求保护的发明在步骤S164和S180使用INVITE消息中的现有对话的标识符（来自步骤S112和S122）。在步骤S180，目的地端点C的媒体地址被提供给受管理端点A 300，以建立与目的地端点C 500的会话。该新会话是使用现有对话建立的，并且因此受管理端点A 300不需要应答新呼叫。

为了理解提出的方法与先前方法之间的差异，在步骤S134、S150、S164和S180中发送的INVITE特别重要。在步骤S134中，发起与受管理端点A 300的新对话，并且A的用户需要应答新呼叫。相比之下，提出的方法在S164中使用用于现有对话的标识符。步骤S150和S180向受管理设备A 300提供媒体地址，以建立与C“SDPC”的会话（这可以是SDP有效载荷的形式）。在先前方法中的S150中发送的INVITE使用新对话的标识符。相比之下，在提出的方法中作为步骤S180发送的INVITE使用与步骤S112、S122和S164中的INVITE相同的呼叫标识符。在提出的方法中不需要与A的新对话，并且A不需要应答单独的呼叫来与C连接。

如上所述，呼叫管理方法可以应用于第三方呼叫控制场景中，其中应用200可以管理用于受管理订户300的会话。应用200可以运行在PC、移动设备、网络浏览器中，并且可以控制针对特定号码（对应于受管理端点A）的呼叫，该特定号码（对应于受管理端点A）参与终端中的呼叫。该号码接收呼叫的终端可以是智能电话（无VOLTE）、VOLTE智能电话、模拟设备、SIP电话等。因此，应用200可以通过建立与API服务的通信来控制针对号码（A）的所有呼叫。此外，应用200可以管理终端（A）中已建立的呼叫（保持、恢复、转移、会议、转向呼叫等）并且应用200也可以发起新的呼叫。

SIP“To”和“From”字段

对于由应用发起的新呼叫（诸如在A和B之间建立呼叫），SIP信令由呼叫管理服务器100（其可以是应用服务器）发起，这不像当直接与A的终端进行呼叫时，其中信令由终端发起。如上面讨论的，由呼叫管理服务器100执行的方法参照图1中图示的信令流进行描述：

·S112：A终端接收到没有任何媒体信息的传入SIP INVITE（callid1），其中“From”和“To”是A的地址。在这种情况下，“From”不是B的地址，因为B没有发起呼叫。相反，是用户A使用应用200发起呼叫。

·S114：当终端A应答该呼叫时（发送“200 OK/SDP”，其具有其用于连接的媒体信息——“SDPA”），它与公告连接。

·S116：终端A接收具有媒体资源功能MRF的媒体信息的ACK/SDP——“SDP公告”。

·S118：一旦A与公告连接，呼叫管理服务器100就向B发送第二SIP INVITE（callid2），其具有将与A连接的媒体信息。在这种情况下，From=A，To=B。

·S120： B应答呼叫并发送200OK

·S122：呼叫管理服务器100将A与B连接，从而在RE-INVITE中向A发送包括将与B连接的媒体信息的消息。

一旦A已经应答了第一个呼叫，在受管理端点A 300处就存在活动的呼叫。如果用户A想要对C进行新的呼叫，则在先前的方法中（例如，在图2中图示的），呼叫管理服务器100向A发送新的SIP INVITE（具有标识符“callid3 ”，并且其中From/To=A，如上面解释的），并且A必须应答另一个呼叫。这是因为，从网络的角度来看，这是新的呼叫。在那之后，INVITE被发送到C（callid4）。

如果A已经具有与B建立的呼叫（由应用发起或未由应用发起），并从应用请求新的呼叫，则将优选的是A终端不需要应答新的呼叫。因此，提出的方法寻求使用与已经建立的A终端的信令信道。这样，A应该不必应答新的呼叫，但是呼叫管理服务器100应该能够使用A和B之间已经“建立”的呼叫来连接A和C之间的媒体信道。换言之，使用A终端中已经建立的呼叫的相同callid。

在诸如图2中图示的方法之类的先前方法中：

·受管理端点A 300（“A终端”）具有连接的2个不同的呼叫，其中From/To=A。

·应用200经由呼叫管理服务器100管理2个不同的呼叫：

o用From=A和To=B呼叫1，并且

o用From=A和To=C呼叫2。

根据提出的改变：

·受管理端点A 300具有连接的1个呼叫，其中From/To=A

·应用200经由呼叫管理服务器100管理2个不同的呼叫：

o用From=A和To=B呼叫1，并且

o用From=A和To=C呼叫2。

此外，在提出的方法中，受管理端点A 300可以与多于2个的目的地端点连接，对于所有目的地端点和不同的媒体信道使用相同的唯一SIP对话。相比之下，在先前的方法中，如果受管理端点A 300是智能电话，则它仅可以与2个目的地连接，因为智能电话不能同时管理多于2个的呼叫。

在一些SIP信令场景中，发起对话的INVITE中的“from”字段遍及对话中是恒定的。然而，在一些场景中，“from”字段遍及对话中可以改变。为了让这种情况发生，对话方二者（例如，终端A和呼叫管理服务器100）应该支持SIP“from改变”特征。

对于由应用发起的新呼叫，其中受管理端点A 300还不具有建立的呼叫，在步骤S122的RE-INVITE中，呼叫管理服务器100提供修改的媒体信息（诸如“SDPB”）。在这种情况下，如果受管理端点A支持“from改变”特征，则呼叫管理服务器100还可以修改在步骤S122中发送的RE-INVITE中的目的地的地址（或身份）。“To”字段中的目的地地址将被修改为B，使得受管理端点A 300具有连接的1个呼叫，其中From=A，并且To=B。

对于由应用发起的第二个呼叫，在步骤S180中的re-INVITE中，在A（受管理号码）已具有建立的呼叫的情况下，呼叫管理服务器100修改媒体信息（诸如“SDPC”）。如果受管理端点A支持“from改变”特征，则呼叫管理服务器100还可以在步骤S180中发送的RE-INVITE中将目的地的地址修改到C。在该修改之后：

·受管理端点A 300具有连接的1个呼叫，其中From=A，并且To=C

·应用200经由呼叫管理服务器100管理2个不同的呼叫：

o用From=A和To=B呼叫1，并且

o用From=A和To=C呼叫2。

替代方案

虽然上面的示例描述了向负责处理SIP信令的呼叫管理服务器发送请求，但当受管理端点和第一目的地端点之间的第一会话不是由应用发起时，本申请中描述的SIP信令方法也可以适用。例如，受管理端点和第一目的地端点之间的第一会话可以由终端（或者“受管理端点”、“用户设备”等）直接发起。此外，第一会话可以是在别处发起并由受管理端点接收的会话。

如果一个端点直接向另一个端点发起呼叫，则可以在那些端点之间建立SIP对话，无需呼叫管理服务器充当中介。在这种情况下，可以在端点之间交换具有公共Call-ID的SIP消息。为了在两个端点之间交换SIP消息，两个端点之间可能需要网络元件（诸如代理、背靠背用户代理B2BUA等）。这些元件可以负责将呼叫路由到目的地并应用呼叫控制。

方法中的消息和步骤列表不全面，并且可以在所述方法步骤之间交换附加的步骤或消息。例如，SIP客户端可以在接收到“INVITE”之后但是在发送“200 OK”之前发送“100正在尝试”和/或“180正在振铃”消息。这可以指示请求正在被处理或者用户设备正在振铃。

术语“端点”用于指代信令和媒体目的地。这些可以替代地称为“终端”。它们也可以被描述为可以具有“地址”、“号码”或“标识符”的设备或“订户”。

“地址”可以包括SIP信令地址（例如，SIP消息中的“from”字段）。替代地，“地址”可以是“媒体地址”。“媒体地址”指代一旦建立了会话，会话媒体就被发送到的地址（例如，端点的SDP媒体地址）。

在SIP协议中，与唯一SIP对话的所有消息相关的标识符可以在“Call-ID”报头中指示。例如，有时，该报头可以替换地被称为“call-id”或“Call-Id”。在本申请中，诸如“callid1”、“callid2”等之类的Call-ID用于说明单独的SIP对话。

虽然上面的具体示例指代“呼叫”，但提出的信令方法可以用于在端点之间建立不同类型的会话。这些可以包括：

·语音呼叫；

·非语音呼叫；

·视频呼叫；

·视频和语音呼叫；

·消息传递；

·游戏；

·等等。

虽然服务器100被称为“呼叫管理服务器”，但服务器可以用于管理上述任何不同的会话类型。因此，该服务器可以被称为“管理服务器”或“会话管理服务器”。

受管理端点（设备A 300）可以是3GPP+网络中的UE。如上所述，它可以是移动电话，诸如智能电话。然而，这不是必需的。SIP信令用于建立连接，但是实际的端点设备A 300可以是连接到“普通旧式电话服务”的传统设备，例如POTS。同样，目的地端点（B 400和C 500）可以是UE，诸如智能电话。然而，它们也可以是POTS上的传统设备。

之所以称为“受管理”端点，是因为用户能够经由应用200发起和管理对该端点的呼叫。应用200的用户也可以是受管理端点300的用户。换言之，用户可以使用应用200来控制对他们自己的电话的呼叫。这样，应用200可以在UE上运行（例如，作为智能电话应用程序）。

应用200与受管理端点300运行在同一设备上不是必需的。用户可以通过桌面应用程序管理他们的呼叫。在这种情况下，受管理端点可以是他们的移动电话、桌面电话或在计算机上运行的软电话。术语“受管理端点”指示这是用户通过API管理的设备。

上面的示例中的B和C被描述为“目的地端点”。这是因为这些是对其进行呼叫的端点。术语“受管理”和“目的地”用于区分端点在所描述的呼叫场景中被如何使用。然而，这不应当被理解为意指关于终点存在任何根本的不同。当描述由B管理的呼叫场景时，端点B的用户也可以具有呼叫管理应用，并且端点B可以被描述为“受管理端点”。同样，他们可以发起到端点A的呼叫，并且端点A在该场景中将是“目的地端点”。

Claims (15)

1.一种管理在受管理端点和多个目的地端点之间的会话的方法，所述方法包括：

x）向受管理端点发送（S122）第一会话发起协议SIP INVITE，其中第一SIP INVITE包括第一呼叫标识符和所述多个目的地端点中的第一目的地端点的媒体地址；和

y）向受管理端点发送（S180）第二SIP INVITE，其中第二SIP INVITE包括第一呼叫标识符和所述多个目的地端点中的第二目的地端点的媒体地址，其中第二目的地端点不同于第一目的地端点。

2.根据权利要求1所述的方法，其中所述方法进一步包括：

a）接收（S110）在受管理端点和第一目的地端点之间建立会话的指令；

b）向受管理端点发送（S112）SIP INVITE，其中SIP INVITE包括第一呼叫标识符；

c）从受管理端点接收（S114）OK消息，其中OK消息包括第一呼叫标识符和受管理端点的媒体地址；

e）向第一目的地端点发送（S118）SIP INVITE，其中SIP INVITE包括第二呼叫标识符和受管理端点的媒体地址；

f）从第一目的地端点接收（S120）OK消息，其中OK消息包括第二呼叫标识符和第一目的地端点的媒体地址；

其中步骤a）至e）和f）在步骤x）之前执行，其中所述方法进一步包括：

j）接收（S162）在受管理端点和第二目的地端点之间建立会话的指令；

n）向第一目的地端点发送（S170）SIP INVITE，其中SIP INVITE包括第二呼叫标识符和第一目的地端点已经被置于保持的指示；

q）向第二目的地端点发送（S176）SIP INVITE，其中SIP INVITE包括第三呼叫标识符；

r）从第二目的地端点接收（S178）OK消息，其中OK消息包括第三呼叫标识符和第二目的地端点的媒体地址；

其中步骤j）、n）、q）和r）在步骤x）之后和步骤y）之前执行，并且其中所述方法进一步包括：

t）向第二目的地端点发送（S184）确认ACK，其中ACK包括第三呼叫标识符和受管理端点的媒体地址；

其中步骤t）在步骤y）之后执行。

3.根据权利要求2所述的方法，其中，在步骤b）中，在受管理端点处建立与第一呼叫标识符相关联的信令信道；

其中在步骤x）处使用信令信道来建立（S130）受管理端点和第一目的地端点之间的第一媒体会话；和/或

其中在步骤y）处使用信令信道来建立（S190）受管理端点和第二目的地端点之间的第二媒体会话。

4.根据权利要求3所述的方法，其中，所述媒体会话是语音呼叫或视频呼叫。

5.根据任一前述权利要求所述的方法，其中在步骤n）中发送到第一目的地端点的SIPINVITE进一步包括保持公告服务的媒体地址。

6.根据权利要求2至5中任一项所述的方法，其中所述方法进一步包括：

d）向受管理端点发送（S116）确认ACK，其中ACK包括第一呼叫标识符和公告服务的媒体地址；

其中步骤d）在步骤x）之前执行，并且其中所述方法进一步包括：

k）向受管理端点发送（S164）SIP INVITE，其中SIP INVITE包括第一呼叫标识符和公告服务的媒体地址；

其中步骤k）在步骤x）之后和步骤y）之前执行。

7.根据权利要求6所述的方法，其中所述方法进一步包括：

g）从受管理端点接收（S124）OK消息，其中OK消息包括第一呼叫标识符和受管理端点的媒体地址；

h）向第一目的地端点发送（S126）ACK，其中ACK包括第二呼叫标识符；

i）向受管理端点发送（S128）ACK，其中ACK包括第一呼叫标识符；

l）从受管理端点接收（S166）OK消息，其中OK消息包括第一呼叫标识符和受管理端点的媒体地址；

m）向受管理端点发送（S168）ACK，其中ACK包括第一呼叫标识符；

o）从第一目的地端点接收（S172）OK消息，其中OK消息包括第二呼叫标识符；

p）向第一目的地端点发送（S174）ACK，其中ACK包括第二呼叫标识符；

其中步骤g）、l）和o）在步骤x）之后和步骤y）之前执行，并且其中所述方法进一步包括：

s）从受管理端点接收（S182）OK消息，其中OK消息包括第一呼叫标识符和受管理端点的媒体地址；和

u）向受管理端点发送（S186）ACK，其中ACK包括第一呼叫标识符，

其中步骤s）和u）在步骤y）之后执行。

8.根据任一前述权利要求所述的方法，其中：

步骤x）处的第一SIP INVITE进一步包括第一目的地端点的信令地址；和/或

步骤y）处的第二SIP INVITE进一步包括第二目的地端点的信令地址。

9.根据任一前述权利要求所述的方法，其中，使用会话描述协议SDP来提供第一目的地端点的媒体地址和/或第二目的地端点的媒体地址。

10.根据权利要求9所述的方法，进一步包括：

使用所提供的SDP媒体地址在受管理端点和第一目的地端点之间交换媒体；和/或

使用所提供的SDP媒体地址在受管理端点和第二目的地端点之间交换媒体。

11.根据任一前述权利要求所述的方法，其中：

响应于接收到第一SIP INVITE，在受管理端点和第一目的地端点之间建立媒体连接信道；和/或

响应于接收到第二SIP INVITE，在受管理端点和第二目的地端点之间建立媒体连接信道。

12.根据任一前述权利要求所述的方法，其中所述多个目的地端点中的每一个具有不同的媒体地址和信令地址。

13.根据任一前述权利要求所述的方法，其中，所述受管理端点是用户设备UE。

14.一种服务器，被配置为执行任一前述权利要求的方法。

15.一种包括指令的计算机软件，所述指令当由计算机的处理器执行时，使得计算机执行权利要求1至13中任一项的方法。

Images