资源预留设置协议RSVP环境中提供带宽预留的系统和方法

摘要

一种通信系统包括协调和监管端点之间的通信的呼叫代理。呼叫代理分配用于呼叫中涉及的每个端点的QoS代理。为了向呼叫提供有保证的带宽量和确立的QoS，QoS代理生成用于呼叫的预留。每个端点或与端点相关的位置具有预留策略，该策略确定获得或未获得预留时以及呼叫过程中丢失或得到预留时怎样处理呼叫。通信系统能在如挂起、呼叫转移、呼叫转发、电话会议和共享线路服务之类的各种情况中，处理预留或预留缺失。

权利要求

1.一种用于在资源预留设立协议RSVP环境中提供带宽预留的方法，包括：对于使用第一服务质量QoS代理和第二QoS代理的呼叫，促进第一位置和第二位置之间的通信，其中所述第一位置与所述第一QoS代理相关，所述第二位置与所述第二QoS代理相关；

根据预留处理策略，为第一端点和第二端点之间的呼叫的音频部分和视频部分中的每一个建立带宽预留，其中所述第一端点与所述第一QoS代理和所述第一位置相关，所述第二端点与所述第二QoS代理和所述第二位置相关，所述预留指定用于所述呼叫的带宽；

响应于用于所述呼叫的音频部分和视频部分的预留未被建立，根据所述预留处理策略，在预定的时间间隔期间，在所述第一端点和所述第二端点之间重试所述预留的建立，判断呼叫过程中，第一端点和第二端点之间是否发生失败，所述呼叫的音频部分和视频部分中的每一个具有相关的已建立预留；

响应于所述第一端点和所述第二端点之间发生的失败，确定呼叫中策略，用于所述呼叫中策略的预留失败选项包括通过公共交换电话网重新路由所述呼叫；

响应于所述第一端点和所述第二端点之间发生的失败，依据音频部分和视频部分中哪一个经历了其相应预留的呼叫中失败，来分别对所述音频部分和所述视频部分应用所述呼叫中策略，其中所述呼叫中策略与所述预留处理策略中的每一个对于呼叫的音频部分和视频部分包括无预留策略、强制性策略或可选策略。

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

在RSVP环境中在所述第一和第二端点之间提供QoS信令；

将所述QoS信令与和所述呼叫相关的信令相同步，其中所述QoS信令独立于所述呼叫信令；

使用所述QoS信令在所述第一和第二端点之间获得所述预留。

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

判断所述第一位置和所述第二位置之间的通信过程中，是否已经由所述第一端点实施了一个触发带宽保留的特征；

根据所述特征已被实施的判断，在所述第一端点和所述第二端点之间保留所述预留。

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

判断所述呼叫过程中，是否发生能力改变；

响应于所述呼叫过程中发生的所述能力改变，调整与所述呼叫相关的所述预留。

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

判断所述呼叫的初始设立过程中或者呼叫本身的过程中是否已经发生预留错误；

响应于所述预留错误，重试所述预留的建立。

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

响应于音频或视频预留各自的失败，重试音频或视频预留的建立。

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

响应于所述视频预留中的失败，使用只有音频的服务维持所述呼叫。

8.一种用于在资源预留设立协议RSVP环境中重试预留的系统，包括：第一服务质量QoS代理和第二QoS代理，所述第一QoS代理和第二QoS代理可用于促进呼叫过程中第一位置和第二位置之间的通信，其中所述第一位置与所述第一QoS代理相关，所述第二位置与所述第二QoS代理相关；所述第一QoS代理可用于根据预留处理策略，为第一端点和第二端点之间的呼叫的音频部分和视频部分中的每一个建立预留，其中所述第一端点与所述第一QoS代理和所述第一位置相关，所述第二端点与所述第二QoS代理和所述第二位置相关，所述预留指定用于所述呼叫的带宽；所述第一QoS代理可用于响应于用于所述呼叫的音频部分和视频部分的预留未被建立，根据所述预留处理策略，在预定的时间间隔期间，在所述第一端点和所述第二端点之间重试所述预留的建立；

耦合到所述第一QoS代理和所述第二QoS代理的呼叫代理，所述呼叫代理可用于管理所述第一QoS代理和所述第二QoS代理，其中：所述呼叫代理可用于判断呼叫过程中，第一端点和第二端点之间是否发生失败，所述呼叫的音频部分和视频部分中的每一个具有相关的已建立预留；响应于所述失败，所述呼叫代理可用于确定呼叫中策略，用于所述呼叫中策略的预留失败选项包括通过公共交换电话网重新路由所述呼叫；所述呼叫代理可用于响应于所述失败，依据音频部分和视频部分中哪一个经历了其相应预留的呼叫中失败，来分别对所述音频部分和所述视频部分应用所述呼叫中策略，其中所述呼叫中策略与所述预留处理策略中的每一个对于呼叫的音频部分和视频部分包括无预留策略、强制性策略或可选策略。

9.如权利要求8所述的系统，其中：

所述第一和第二QoS代理可用于在所述第一和第二端点之间提供QoS信令；所述第一和第二QoS代理可用于将所述QoS信令与和所述呼叫相关的信令相同步，其中所述QoS信令独立于所述呼叫信令；所述第一QoS代理可用于使用所述QoS信令，在所述第一和第二端点之间获得所述预留。

10.如权利要求8所述的系统，其中：

所述呼叫代理可用于判断所述第一位置和所述第二位置之间的通信过程中，是否已经由所述第一端点实施了一个触发带宽保留的特征；所述呼叫代理可用于根据所述特征已被实施的判断，在所述第一端点和所述第二端点之间保留所述预留。

11.如权利要求8所述的系统，其中：

所述呼叫代理可用于监视所述第一端点和所述第二端点之间的呼叫；所述呼叫代理可用于判断所述呼叫过程中，是否发生能力改变；

所述第一QoS代理和所述第二QoS代理可用于响应于所述呼叫过程中发生的所述能力改变，调整与所述呼叫相关的所述预留。

12.如权利要求8所述的系统，其中：

所述呼叫代理可用于判断所述呼叫的初始设立过程中或者呼叫本身的过程中是否已经发生预留错误；所述呼叫代理可用于响应于所述预留错误，重试所述预留的建立。

13.如权利要求8所述的系统，其中：

所述呼叫代理可用于响应于音频或视频预留各自的失败，重试音频或视频预留的建立。

14.如权利要求8所述的系统，其中：

所述呼叫代理可用于响应于所述视频预留中的失败，使用只有音频的服务维持所述呼叫。

说明书

资源预留设置协议RSVP环境中提供带宽预留的系统和方

法

技术领域

[0001] 本发明一般地涉及电信领域。更具体地，本发明涉及在RSVP环境中实施呼叫中(mid-call)策略的系统和方法。

背景技术

[0002] 当今社会通信领域变得越来越重要。具体而言，通过任何适当通信媒体与个人进行快速而有效的交互的能力给组件制造商、系统设计师和网络操作员造成重大障碍。由于当前市场中存在的不同通信技术过剩，使这一障碍更难于应付。因为这许多的通信技术，所以很多组件彼此之间无法交互。随着新的通信平台可被消费者享用，需要开发新的协议来优化这些新兴技术。

发明内容

[0003] 根据本发明，可以减少或消除与用于在通信系统中的资源预留协议(Resource Reservation Protocol，RSVP)环境中实施呼叫中策略的现有技术相关的缺点和问题。

[0004] 根据本发明的一个实施例提供一种用于在资源预留设立协议RSVP环境中提供带宽预留的方法，包括：对于使用第一服务质量QoS代理和第二QoS代理的呼叫，促进第一位置和第二位置之间的通信，其中所述第一位置与所述第一QoS代理相关，所述第二位置与所述第二QoS代理相关；根据预留处理策略，为第一端点和第二端点之间的呼叫的音频部分和视频部分中的每一个建立带宽预留，其中所述第一端点与所述第一QoS代理和所述第一位置相关，所述第二端点与所述第二QoS代理和所述第二位置相关，所述预留指定用于所述呼叫的带宽；响应于用于所述呼叫的音频部分和视频部分的预留未被建立，根据所述预留处理策略，在预定的时间间隔期间，在所述第一端点和所述第二端点之间重试所述预留的建立，以及判断呼叫过程中，第一端点和第二端点之间是否发生失败，所述呼叫的音频部分和视频部分中的每一个具有相关的已建立预留；响应于所述第一端点和所述第二端点之间发生的失败，确定呼叫中策略，所述呼叫中策略包括重新路由所述呼叫；响应于所述第一端点和所述第二端点之间发生的失败，依据音频部分和视频部分中哪一个经历了其相应预留的呼叫中失败，来分别对所述音频部分和所述视频部分应用所述呼叫中策略，其中所述呼叫中策略与所述预留处理策略中的每一个对于呼叫的音频部分和视频部分包括无预留策略、强制性策略或可选策略。

[0005] 根据本发明的一个实施例提供通信系统，其包括在两个或多个端点之间控制呼叫的设立的呼叫代理。为保证用于呼叫的一定量带宽，呼叫代理与在端点之间建立预留的服务质量(quality of service，QoS)代理相互作用。QoS代理为呼叫代理提供有关端点之间获得的或失败的预留的信息，以便呼叫代理能在端点之间建立用于呼叫的适当连接。呼叫代理实施不同的呼叫前(pre-call)和呼叫中资源预留策略，并在失败后启动获得用于呼叫的预留的过程。

[0006] 本发明的某些实施例可提供一个或多个技术优势。一个实施例的技术优势是不需要接触每个端点即可在系统中使用RSVP。端点支持不同的协议，并在同样的系统中与RSVP交互。另外，支持RSVP的端点可与不支持RSVP的端点进行通信。另一个实施例的另一个技术优势是若初始的尝试未获得RSVP预留，呼叫不会失败。允许呼叫在没有RSVP预留时继续使得避免了呼叫完全失败。实施例的又一个技术优势是进行呼叫的过程中呼叫可获得预留，这改善了QoS；或者可重建呼叫中失败的预留，这也改善了呼叫的QoS。

[0007] 对于上面的技术优势，本发明的某些实施例可不包括、包括一些或包括全部。通过此处包含的附图、说明和权利要求，一个或多个其他技术优势对本领域技术人员是清楚的。

附图说明

[0008] 为了更完整地理解本发明及其特征和优点，现在对下面的说明连同附图进行参考，其中相似的参考标号代表相似的部分，其中：

[0009] 图1是说明可以实施预留特征的通信系统的简化框图；

[0010] 图2A～2C表示说明通信系统中用于获得预留的方法的实施例的流程图和消息流；

[0011] 图3A、3Ba和3Bb是表示通信系统中用于重试预留的方法的实施例的流程图和消息流；

[0012] 图4是说明通信系统中用于实现呼叫中策略的方法的实施例的流程图；

[0013] 图5A～5B表示通信系统中用于获得音频和视频流两者的方法的另一实施例的流程图和消息流；

[0014] 图6A～6B表示说明挂起(on hold)状态中用于保留带宽的方法的实施例的流程图和消息流；

[0015] 图7A～7B表示说明呼叫转移情况中用于保留带宽的方法的另一实施例的流程图和消息流；

[0016] 图8是说明电话会议情况中用于保留带宽的方法的另一实施例的流程图；

[0017] 图9是说明呼叫转发情况中用于保留带宽的方法的另一实施例的流程图；

[0018] 图10A～10B表示说明共享线路情况的消息流；

[0019] 图11是说明用于在已连接的呼叫期间激活视频媒体的实施例的流程图。

具体实施方式

[0020] 图1是用于实施资源预留协议(Resource Reservation Protocol，RSVP)内的预留特征的通信系统10的简化框图，所述预留特征可以在任何适当环境中优化通信。通信系统10包括管理在一个或多个位置102的呼叫的呼叫代理100。呼叫代理100允许位置102在适当时间使用预留特征在内部以及与其他位置102进行通信。诸如位置102a或102b之类的位置102的内部，可以存在多个接收和发起媒体流的端点106。如所示，位置102a具有端点106a、106b和106c。位置102b具有端点106d、106e和106f。每个位置102a和102b包括控制RSVP的实施的QoS代理104a和104b。

[0021] 呼叫代理100是控制位置102a和102b之间以及位置102a和102b内部的单个端点106之间的媒体交换的中央实体。呼叫代理100还负责RSVP信令。结果，呼叫代理100位于信令路径之内。呼叫代理100可配置为反映预留处理策略。呼叫代理100可包括接收配置信息的用户接口。例如，用户可在呼叫代理100处配置位置102a和102b的预留处理策略。

[0022] 位置102a和102b是通信系统10内端点的逻辑分组，并且未必是基于地理位置的。每个位置102代表用于接收和发送通过通信系统10传播的信息分组的互连通信路径的一系列点或节点。位置102可彼此之间或与其他设备和适当位置进行通信。每个位置102可向端点或端点组提供某个服务和能力。位置102还可连接到一个或多个附加网络单元。例如，位置102可连接到服务供应商网络。位置102还可包括呼叫代理100的功能。
位置102可以是任何适当结构，如局域网(local area network，LAN)、企业网、虚拟专用网(virtual private network，VPN)、城域网(metropolitian area network，MAN)或广域网(wide area network，WAN)，或任何其他方便通信的合适结构或系统。

[0023] 端点106经由位置102在通信系统10中建立隧道、链接或会话(session)。端点106可配置为在尝试获得预留时实施特定的预留处理策略。端点106可包括瘦客户控制协议(Skinny Client Control Protocol，SCCP)电话、会话发起协议(Session Initiation Protocol，SIP)电话、计算机、个人数字处理、膝上计算机、视频会议设备、网关，或任何其他适当的端点。端点106可通过任意协议实现，如SCCP、SIP、H.232、媒体网关控制协议(Media Gateway Control Protocol，MGCP)，或任何其他适当的协议。在所示出的实施例中，位置端点106a可以是因特网协议电话，端点106b可以是计算机，端点106c可以是网关。对于位置102b，端点106d可以是SIP电话，端点106e可以是网关，端点106f可以是视频会议设备。

[0024] QoS代理104a和104b分别耦合到相关的呼叫代理100和相关的端点106。正如呼叫代理100所确定，QoS代理104代表端点106、为端点106预留带宽，并在端点106之间的信令和媒体交换中被涉及。QoS代理104通过确定可用带宽并为端点106做出预留来控制RSVP的实施。呼叫线路(call leg)和信令路径可由任意一个QoS代理104创建。QoS代理104可以是交换机、网关、网桥、语音邮件服务器、路由器和负载平衡器。使用QoS代理104，RSVP支持被扩展到由任意合适协议建立的呼叫，所述协议例如是实时协议(real-time protocol，RTP)、用户数据报协议(userdatagram protocol，UDP)、SCCP、SIP、H.323，或任何其他合适类型的协议或技术。QoS代理104还可容纳音频和视频媒体流、音频和视频会议，并执行适当的代码转换操作。

[0025] QoS代理104可提供媒体流中的每个分组的区分服务代码点(Differentiated Services Code Point，DSCP)标记。DSCP标记指定用于每个分组服务的类别。DSCP标记基于预留功能的结果而更新。呼叫代理100允许特殊的DSCP标记，其为呼叫过程中未能获得预留或丢失预留的呼叫指示不同级别的服务。这样，通过使用不同的DSCP值，即使呼叫被网络抢占，呼叫代理100也可以避免呼叫失败。

[0026] QoS代 理 104还 可 支 持 多 级 优 先 和 抢 占 (Multilevel Precedence andPreemption，MLPP)，其中带有较高优先级指定的呼叫可抢占带有较低优先级指定的呼叫。呼叫代理100将呼叫优先级别用QoS消息传递到QoS代理104。这允许路由器基于优先级别来抢占流。QoS代理104将预留失败作为抢占的结果通知呼叫代理100。如果呼叫要被抢占，则呼叫代理100按照配置的策略处理抢占并通知端点106。

[0027] RSVP是在使用预留的不可靠的基于因特网协议(Intemet Protocol，IP)的网络中用于预留资源的传输级信令协议。RSVP在呼叫代理100内提供替代的呼叫接纳控制机制。当今电信环境中客户尝试脱离用于视频会议和视频电话应用的中心和分支(hub and spoke)网络拓扑。RSVP的使用有助于实现这一目标。RSVP的重要特征包括为特定会话预留带宽，该会话是具有特定目的地址、目的端口和协议标识的流。RSVP消息以非定向方式沿着与媒体流相同的路径传播。这样，所述流只在一个方向预留，并且每个会话被当作一个独立单元看待。RSVP消息流透明地穿过非RSVP路由器和交换机。RSVP支持单播(unicast)和多播(multicast)环境，并且由于流的接收者请求预留因此是面向接收者的。由于有了预留，呼叫可以使用预留的带宽并获得提高的QoS。

[0028] 简要概括一下呼叫操作，主叫端点106a尝试联系被叫端点106d。若呼叫代理策略在建立给定呼叫时提供RSVP，则呼叫代理100为呼叫和被叫双方分配QoS代理104的资源。呼叫代理100指示QoS代理104a和104b代表端点106a和106d尝试RSVP预留。QoS代理
104a启动包含期望的业务流的描述或公告的路径(PATH)消息。PATH消息沿着与媒体流的路径相同的路径从QoS代理104a传播到QoS代理104b。沿路的任何支持RSVP的网络设备将从PATH消息中收集合适信息，并将其存储为路径状态。QoS代理104b收到PATH消息后，可通过发送RESV(预留)消息来请求用于PATH消息中描述的媒体流的资源。RESV消息沿着与PATH消息和媒体流的路径相反的路径传送。沿相反路径的每个支持RSVP的设备接收RESV消息，并决定接受还是拒绝该请求。若接受该请求，则存储必要的状态并沿相反路径向下转发RESV消息。若拒绝该请求，则生成并沿原来的路径发送RESVERR(预留错误)消息，并且不再转发RESV消息。QoS代理104a响应于其PATH消息而收到RESV消息后，成功完成单向RSVP预留的建立。获得预留后，呼叫代理100向被叫端点106d振铃(ring)。于是主叫端点106a和被叫端点106d可以交换媒体。

[0029] 给定的呼叫是否要求预留取决于为位置或端点配置的预留处理策略。默认情况下相同位置内的呼叫可以不要求预留。当不为特定呼叫实施RSVP时，可使用任何类型的呼叫接纳控制(Call Admission Control，CAC)。用于所述位置或端点的预留处理策略可由用户配置。一个位置或端点的预留处理策略可以是下述之一：无预留(无)、音频/视频预留强制(音频/视频强制)、音频预留强制且视频可选(视频可选)，或者音频预留可选且视频可选(音频可选)。尽管为了讨论的目的只提到四种预留处理策略，但是同样可实施其他预留处理策略，例如视频强制且音频可选预留处理策略。无预留策略意味着不需要预留来连接呼叫。该呼叫可通过另一个呼叫接纳控制机制来连接。实施例中，这可能是用于同样位置内的端点的默认方式。对于音频/视频强制策略，发送的每个媒体流收到RSVP预留之前，呼叫不能被连接。若用于任何一个媒体流的预留不成功，则释放该呼叫。例如，若音频流收到预留但视频流未收到预留，则释放该呼叫。视频可选策略下，RSVP预留成功之前，不会连接呼叫的音频流。该呼叫可仅与音频连接，并且若用于视频流的预留成功，该呼叫可加入视频。音频可选策略不要求呼叫进行之前为音频流建立预留。可对于获得RSVP预留进行尝试，但无论预留成功与否呼叫都将进行。呼叫可能不具有高QoS，但将以“尽力而为”(best effort)的质量来进行。音频可选策略中的视频流只有在用于视频流的RSVP预留成功时才可用。表I提供了下面将更详细讨论的不同预留处理策略过程的总结。

[0030] 表I

[0031]

[0032]

[0033]

[0034] 用于呼叫的QoS可通过RSVP和任何其他类型的呼叫接纳控制机制的混合来管理。RSVP功能在整个通信系统10中可操作也许不可能。因此，通信系统10的一些位置中，有的设备将具有QoS代理配置，而其他设备则没有。举例来说，当从具有RSVP能力的位置到不支持RSVP的另一位置启动呼叫时，呼叫代理100将使用两种机制管理用于呼叫的QoS。从支持RSVP的位置到支持RSVP的中心或中央站点的呼叫的第一部分将通过RSVP机制进行。
将通过另一个呼叫接纳控制类型管理从中心或中央站点到不支持RSVP的位置的呼叫的第二部分。若任一机制无法分配合适带宽，则呼叫失败。由于其他呼叫接纳控制类型可能不具有任何可选策略，因此若没有足够位置带宽，则呼叫将被拒绝。不存在如RSVP机制下可用的尽力而为呼叫。因此，若用于呼叫的QoS由另外的呼叫接纳控制机制和RSVP机制两者管理，则预留处理策略只影响由RSVP管理的呼叫部分。对于由另一个呼叫接纳控制管理的呼叫部分，只支持强制性策略行为，并且呼叫或成功或失败，不会有用于呼叫的降级的尽力而为服务。

[0035] 不脱离本发明的范围的前提下，可对本系统做出修改、添加或省略。例如位置102可以修改、变更、重设或重新配置来取得它们预期操作，只要其适合预留功能。实施例中，呼叫代理100的功能可分布到多于一个分散了呼叫代理100的功能的呼叫代理100上。例如，单独的呼叫代理100可与每个位置102相关。位置102a和102b之间，可出现多件网络设备，包括路由器、交换机、广域网链路，或任何其他适当的网络设备。

[0036] 软件、硬件或二者的结合可驻留于QoS代理104中，以获得预留功能和与预留功能相关的许多特征。QoS代理104可存在于呼叫代理100中、媒体流的媒体路径中、远程位置中，或要求预留功能的任何适当位置中。另一个实施例中，QoS代理104可包含于端点106中，其中端点106用作QoS代理104。这些单元可以配备或包括任何适当组件、设备、专用集成电路(application specific integrated circuit，ASIC)、处理器、微处理器、算法、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、可擦除可编程ROM(erasableprogrammable ROM，EPROM)、电可擦除可编程ROM(electricallyerasable programmable ROM，EEPROM)、现场可编程门阵列(field-programmable gate array，FPGA)，或者能够方便所述单元的操作的任何其他适当的可操作单元或对象。另外，包括软件、硬件、其他逻辑或其任何适当组合在内的任何适当的逻辑可执行通信系统10的功能。

[0037] 图2A是说明通信系统10中用于获得预留的方法的一个实施例的流程图20。块200处确定端点106的位置102的预留处理策略。确定位置102a的预留处理策略允许呼叫代理100确定呼叫是否需要预留。在判断块202处，若该预留处理策略确定为无预留策略，则端点106开始在块204处交换媒体。若该预留处理策略不是无预留策略，则呼叫代理
100在判断块206处确定该预留处理策略是否为强制性预留处理策略。确定该预留处理策略不是强制性预留处理策略(意味着该预留处理策略是可选预留处理策略)后，呼叫代理
100在块208处同时指示QoS代理104尝试获得预留并向被叫端点106d振铃。判断块210确定是否对于可选预留处理策略已经获得了预留。若获得了预留，则端点以高QoS交换媒体，并且方法在块220处继续进行。若未获得预留，则呼叫代理100到图3A中的“A”处继续进行。呼叫在块212处以较低QoS连接，并且端点106交换媒体。

[0038] 判断块206处，若预留处理策略被确定为强制性预留处理策略，则呼叫代理100在块214处指示QoS代理104尝试获得预留。块216处若未获得预留，则呼叫代理100在块218处行使预留失败选项。用于强制性预留处理策略呼叫的预留失败选项包括通过公共交换电话网(Public SwitchedTelephone Network，PSTN)重新路由呼叫、释放呼叫，或其他任何适当的预留失败选项。预留失败选项可包括以降级的服务连接该呼叫。为了避免由于预留缺失造成的呼叫失败，该呼叫可分配为不同类别的呼叫，并以降级的服务级别分配到两个端点106之间的路由器中的低优先级队列。若QoS代理104获得预留，则在块220处连接端点之间的呼叫，并开始媒体的交换。呼叫代理100在获得预留后向合适的QoS代理104发送预留命令。获得预留后，呼叫代理100警告被叫端点106d并连接主叫端点106a和被叫端点106d之间的呼叫。

[0039] 从块220处，呼叫代理100在块222处确定已连接的呼叫是否经历过失败事件。失败事件包括呼叫被另一个具有较高优先级的呼叫抢占、呼叫没有足够带宽来继续，或任何适当的失败事件。呼叫以降级的服务继续，而不是由于失败事件的发生，该呼叫被释放。例如，降级的服务涉及使用较低的DSCP标记值，降低呼叫的QoS。为了以降级的服务继续该呼叫并支持另一个呼叫，原来支持该呼叫的带宽根据QoS的可用性被重新分配。

[0040] 在所示的实施例中，通信系统10允许较高优先级的呼叫抢占较低优先级的呼叫。抢占较低优先级的呼叫允许较高优先级的呼叫使用曾经由较低优先级的呼叫获得的预留。
实施例中，通信系统10可不支持MLPP并且不允许抢占。若呼叫还没被抢占，则以较高QoS在端点106之间继续媒体的交换。若呼叫已经被抢占，则端点106在块224处使用较低DSCP标记值继续交换媒体，意味着媒体交换具有较低的优先级并可能未收到最好的QoS。块226处，媒体交换继续时，在呼叫过程中尝试获得较高的DSCP标记值。在呼叫过程中获得较高的DSCP标记值改善了呼叫的QoS。从块226，该方法可继续到图3中的“A”。呼叫终止于块
228，接着该方法结束。

[0041] 图2B说明用于音频流的预留为强制性时，端点106a和106d、QoS代理104a和104b以及呼叫代理100中的示例消息流。样本呼叫流涉及到端点106a和106d二者都为SCCP电话的情形。下面的讨论中将指出呼叫流的变化，该呼叫流中端点106a和106d中的一个或两者为SIP端点。

[0042] 呼叫代理100收到来自端点106a的呼入请求时，呼叫代理100在将该呼叫延伸到端点106d之前，首先检查用于端点106a和106d之间的呼叫的预留处理策略。若对于该呼叫，预留处理策略是音频/视频强制的或视频可选的，则呼叫代理100为端点106a分配QoS代理104a，为端点106d分配QoS代理104b。呼叫代理100向QoS代理104a和104b二者发送RTPPortReq(RTP端口请求)消息来为双向音频流打开RTP接收端口。呼叫代理100指示QoS代理104a和104b监听接收端口。

[0043] 对于从端点106a到106d的预留，呼叫代理100向QoS代理104a发送QoSPath(QoS路径)消息来指示QoS代理104a启动去往QoS代理104b的PATH消息。收到PATH消息后，QoS代理104b向QoS代理104a发送RESV消息。RESV消息沿着与PATH消息和业务流的路径相反的路径传送。QoS代理104a收到RESV消息后，它通过发送QoSRESVNotify(QoS预留通知)消息来通知呼叫代理100关于预留的状态。相似的消息流请求从端点106d到端点106a的预留。对于与端点106a和106d之间的呼叫相关的任何视频或数据流都会出现相似的消息流。

[0044] 两个音频流的预留都成功后，呼叫代理100向端点106d振铃并向端点106a回铃(ring back)。端点106d摘机(offhook)后，呼叫代理100在端点106a和106d之间连接音频媒体。端点106a和106d之一挂机(onhook)并终止呼叫后，呼叫代理100指示QoS代理104a和104b通过沿方向参数发送QoSTearDown(QoS拆除)消息来拆除RSVP预留。对于发送方向，适当的QoS代理启动PATHTear(路径拆除)消息。对于接收方向，适当的QoS代理启动RESVTear(预留拆除)消息。由于RSVP预留仍需要保留时，媒体可能停止流动，因此RSVP预留拆除独立于媒体停止流动。这在发生挂起/继续(hold/resume)的情况时会需要，该情况中为了继续该呼叫，端点被挂起并预留被保留。对于伴随任何音频流的视频或数据流，会出现相似的拆除消息转移。

[0045] 呼叫代理100能够支持端点106a和106d处的非上述SCCP电话的不同类型的设备。例如，端点106可使用SIP设备。SCCP设备中存在的初始摘机和拨号消息被替换为INVITE消息。SCCP设备的使用中存在的振铃、回铃和摘机消息被替换为呼叫代理100提供给QoS代理104b的INVITE(邀请)消息、QoS代理104b提供给呼叫代理100的RINGING(振铃)消息、从QoS代理104b到呼叫代理100的200OK消息、从呼叫代理100到QoS代理104b的ACK消息、从呼叫代理100到QoS代理104a的200OK消息，以及从QoS代理104a到呼叫代理100的ACK消息。这样，媒体在端点106a和106d之间流动。挂机消息(假设以端点106d先挂机为例)替换为从QoS代理104b到呼叫代理100的BYE(再见)消息、从呼叫代理100到QoS代理104b的200OK消息、从呼叫代理100到QoS代理104a的BYE消息，以及从QoS代理104a到呼叫代理100的200OK消息。

[0046] 对于使用H323设备的端点106，初始摘机和拨号消息被替换为H225Setup(H225建立)消息。SCCP设备的使用中存在的振铃、回铃和摘机消息被替换为呼叫代理100提供给QoS代理104b的H225Setup消息、QoS代理104b提供给呼叫代理100的H225Alert(H225警告)消息、呼叫代理100提供给QoS代理104a的H225Alert消息、从QoS代理104b到呼叫代理100的H225Alert消息，以及从呼叫代理100到QoS代理104a的H225Alert消息。呼叫代理100还能够支持其他类型的端点106，并且还支持端点106a具有与端点106d不同类型的设备的实施方式。

[0047] 对于音频/视频强制预留处理策略，在从端点106a到端点106d的方向上用于音频流和视频/数据流两者的预留的获取失败，导致呼叫代理100拒绝来自呼叫端点106a的呼叫建立请求。对于视频可选预留处理策略，若未获得用于从端点106a到端点106d的音频流的预留，则呼叫代理100拒绝呼叫建立。若未获得用于从端点106d到端点106a的音频流的预留，将采用同样的拒绝。端点106a具有的预留处理策略可以与端点106d具有的预留处理策略不同。呼叫代理100将拒绝任何其要求的预留未获得的呼叫建立。

[0048] 图2C示出每个音频流的预留成功后呼叫代理100连接媒体时的消息流。获得用于每个流的预留后，呼叫代理100在连接媒体之前并不知道为呼叫使用的确切带宽。此时，呼叫代理100在QoSPath消息中提供估计的带宽信息。对于音频呼叫，呼叫代理100可使用以任何方式确定的端点106a和106d之间的任何估计的带宽。对于视频呼叫，呼叫代理100可使用希望的最小值默认视频带宽。连接媒体后，呼叫代理100指示QoS代理104a和
104b通过QoSModifyTSpec消息调整用于呼叫的RSVP带宽预留。每个单向媒体流建立后，若带宽规格不同于QoSPath和QoSResv(QoS预留)消息中所使用的带宽规格，呼叫代理100可以指示QoS代理104a和104b调整带宽规格。

[0049] 图3A是说明通信系统10中用于重试预留的方法的实施例的流程图30。流程图30中的块可位于图2A的流程图20之内。块300处，呼叫代理100确定媒体交换过程中是否已发生预留错误。预留错误可包括呼叫中失败或初始呼叫建立未能获得预留。例如，预留错误可发生在呼叫被抢占时、呼叫过程中路由器变得不可操作时，或可能导致预留失败的任何其他错误发生时。若端点106在呼叫过程中丢失已建立的预留，或者若具有可选策略的端点106在初始呼叫建立的过程中无法获得预留，则也可能发生预留错误。对于可选预留处理策略呼叫，若开始时或呼叫过程中未获得预留，则可能发生重试预留；对于呼叫中失败的强制性预留处理策略呼叫，可能发生重试预留；或者对于在呼叫过程中的任何时间失败的任何适当策略呼叫，可能发生重试预留。若呼叫代理100未识别出错误，则端点106继续交换媒体并检查预留错误。通过这种重试机制，原先不带预留和QoS优先级而启动的呼叫在有可用资源和带宽时能够在呼叫过程中获得预留和改善的QoS。

[0050] 若检测到预留错误，则呼叫代理100在块302处启动内部重试计时器。呼叫代理100包括设置在什么样的时间间隔重试获取预留的计时器。或者，呼叫代理100可设置计数值，确定尝试的重试的总次数。块304处，QoS代理104尝试在重试计时器设立的时间间隔获得预留。判断块306处，确定是否在该时间间隔获得了预留。若获得预留，则呼叫继续并且端点106在块308处交换媒体。呼叫在块310处终止，然后本方法结束。若由于链路/节点或其他失败，造成预留在呼叫过程中丢失，则失败情况可在少量时间内自行更正。重试计时器或计数避免收到失败指示后呼叫立刻拆除，并且允许呼叫代理100在呼叫失败之前保持用于呼叫的连接并在很短的时间段内重试获取丢失的预留。

[0051] 若判断块306处未获得预留，则在块312处确定是否超过时间间隔或达到最大计数。若不是，则更新该时间间隔或计数，并且QoS代理104重试获取预留。若是，则本方法继续到图4中的“B”。若块314处尚未发生N次重试，则该方法继续重试获取预留。

[0052] 图3Ba～3Bb示出用于音频流的预留可选时的端点106a和106d、QoS代理104a和104b，以及呼叫代理100之间的示例消息流。该消息流还涵盖了不需要预留来连接端点106以及端点106开始交换媒体后预留丢失或得到时的重试情形。不需要预留来将端点
106a连接到端点106d时，呼叫代理100向端点106d发送RING消息，同时开始并行获取预留。不论端点106d摘机之前是否获得预留，端点106a和106b之间都将建立连接。示例中，呼叫代理100在QoSPath和QoSListen(QoS监听)消息中向QoS代理104a和104b传递retry＝true(重试为真)状态和retryTimer(重试计时器)值。QoS代理104a和104b收到QoSListen消息后，ListenTimer(监听计时器)启动。若ListenTimer到期前QoS代理104a或104b没收到PATH消息，则QoSErrorNotify(QoS错误通知)消息被发往呼叫代理100。此时，若媒体流的预留处理策略为强制性的，则呼叫代理100将拒绝来自呼叫端点的呼叫建立请求。可选的情况下，呼叫代理100仅将该错误记入日志。若QoS代理104a或
104b收到PathError(路径错误)，则路径重试计时器启动，并且该计时器到期时PATH消息被发送。为避免向呼叫代理100重复发送错误信息，QoS代理104a和104b只需要在发生从错误状态到非错误状态的状态转变及相反转变时通知呼叫代理100。

[0053] 图4是说明通信系统10中用于实现呼叫中策略的方法的实施例的流程图40。流程图40中包含的块可在任何适当位置位于图3A的流程图30之内。呼叫中策略可在获取预留的尝试被重复时，用来确定呼叫怎样继续，或在呼叫中失败发生时使用。呼叫中失败可发生在路由器在呼叫过程中变得不可操作或因为任何原因预留丢失的情况中。块400处，确定端点106的位置102的呼叫中策略。呼叫代理100采用呼叫中策略，且呼叫中策略可配置为任何适当的策略。例如，呼叫中策略可以是无预留策略、强制性策略，或可选策略。呼叫中策略可以与用于所涉及端点的原来的预留处理策略相同或独立。这样，呼叫在最初建立时可具有强制性预留处理策略，但响应于任何呼叫中失败，可具有稍弱的策略。这会避免端点106之间媒体交换过程中呼叫失败的发生。

[0054] 若在判断块402处确定呼叫中策略是无预留策略，则端点106在块404处交换媒体，且呼叫最后终止于块418。但若呼叫中策略不是无预留呼叫中策略，则在块406处确定呼叫中策略是否为强制性呼叫中策略。若呼叫中策略不是强制性呼叫中策略(意味着呼叫中策略为可选呼叫中策略)，则呼叫在块408处“尽力而为”地继续并最后终止于块418。“尽力而为”地继续允许呼叫以最好的可用服务来继续，即使该服务不是最高质量的。重试过程发生于块409，来获得用于该呼叫的预留。若块410处未获得预留，则重试的努力继续。
若块410处获得预留，则块411处利用获得的预留交换媒体。

[0055] 对于强制性呼叫中策略，呼叫代理100在块412处确定强制性呼叫中策略的呼叫中处理。若呼叫中处理在判断块413处不是“尽力而为”的，则在块414处行使预留失败选项。用于呼叫中策略的预留失败选项包括通过PSTN重新路由呼叫、释放呼叫，或任何其他适当的预留失败选项。预留失败选项还可包括终止端点之间的连接之前获得用于呼叫的预留的尝试中的一次预留重试。若呼叫中处理是“尽力而为”的，则呼叫在块416处以最好的可用服务来继续，并重试RSVP预留。呼叫终止于块418，然后本方法结束。

[0056] 保留了两个端点106之间的资源并且媒体在两个端点106之间流动后，可能出现预留丢失的情况。图3Ba～3Bb所示的示例情况中，QoS代理104a收到RESVError(预留错误)消息，该消息指示为端点106a从端点106d接收媒体而建立的预留已丢失。QoS代理104a将发送QosErrorNotify消息，来将丢失的预留通知呼叫代理100。为了将DSCP标记改变为较低级别的服务，呼叫代理100向QoS代理104b发送UpdateDSCP(更新DSCP)消息。QoS代理104a启动ResvRetryTimer(预留重试计时器)，然后检查有效的PATH状态。若存在有效的PATH状态，则为了恢复预留，QoS代理104a发送RESV消息。若PATH状态仍无效，则QoS代理104a重置ResvRetryTimer。收到RESV消息后，QoS代理104b通过发送QoSResvNotify(QoS预留通知)消息来通知呼叫代理100。为了将DSCP标记重置到较高级别的服务，呼叫代理100向QoS代理104b发送UpdateDSCP消息。

[0057] 此处参考图2A、图2B、图3A、图3Ba、图3Bb和图4讨论的特征也可应用于交换音频和视频流两者的呼叫。这些特征独立地应用到每个媒体流。例如，若呼叫过程中视频流失败，则呼叫代理100和QoS代理104可重试获取用于视频流的预留，同时端点106继续交换音频流。

[0058] 图5A是扩展图2A和2B的概念、说明通信系统10中用于获得视频和音频流两者的预留的方法的另一个实施例的流程图50。图5B是示出用于音频伴视频(audio with video)呼叫的示例消息流。块500处，确定该位置的预留处理策略。若判断块502处确定的预留处理策略不是强制性预留处理策略(意味着预留处理策略为可选预留处理策略)，则在块504处为每个媒体流尝试获取预留：用于音频流的预留和用于视频流的预留。呼叫代理100还在块504处向端点106d振铃，并且方法继续到块508。若预留处理策略为强制性预留处理策略，则在块506处尝试为每个媒体流——音频流和视频流——获取预留。实施例中，呼叫代理100可在确定预留处理策略是强制性的还是可选的之前，确定预留处理策略是否为无预留策略。块508处，判断是否已获得用于音频流的预留。若音频流尚未获得预留，则在块510处行使用于音频流的预留失败选项。用于音频流的预留失败选项可包括释放呼叫、通过PSTN重新路由呼叫，或任何其他用于音频流的适当的预留失败选项。

[0059] 块508处获得用于音频流的预留使得本方法继续到块512，其中呼叫代理100连接呼叫，并且端点106开始交换数据。判断块514处，确定视频流是否已获得预留。若视频流尚未获得预留，则在块516处行使用于视频流的预留失败选项。用于视频流的预留失败选项包括释放视频流，或任何其他用于视频流的适当的预留失败选项。若视频流已获得预留，则端点106在块518处交换视频并且继续呼叫过程中的音频交换。端点106之间的呼叫终止于块520，然后该方法结束。

[0060] 若块508处未获得预留，则对于音频可选预留处理策略，呼叫在块522处以较低QoS连接。对视频流预留的检查在块514处进行。若未得到视频流预留，则最可能的情况是，由于未获得音频流预留，因此块524处继续在端点106之间交换音频。此时如果需要的话，可以在块524处以较低QoS提供视频。每当未获得音频或视频预留，必要时上面讨论的重试过程也可结合进本流程图。

[0061] 带宽可在RSVP环境中保留。端点106之间的媒体交换过程中实施特征时，保留带宽被启动。特征包括将端点106挂起、媒体交换过程中调用补充服务业务、三方会议，或任何其他触发带宽保留的适当特征。补充业务使得呼叫过程中的各方改变。

[0062] 图6A是说明端点106挂起时用于保留带宽的方法的实施例的流程图。图6B是用于挂起状态的示例消息流。端点106a和106d在块600中使用按上述建立的RSVP预留来交换媒体。判断块602处，确定端点106d是否被端点106a挂起。若端点106d未被挂起，则端点106a和106d之间使用RSVP预留的媒体交换继续。若端点106d被端点106a挂起，则在块604处保留端点106a和106d使用的预留。保留预留保留了端点106a和106d用来交换媒体的带宽。

[0063] 音乐挂起(Music-On-Hold，MOH)服务器在挂起状态中使用。块605处，确定MOH服务器和挂起端点106d之间是否需要RSVP预留。若不需要，则当端点106a挂起端点106d时，MOH服务器在块607处向挂起端点106d发送媒体。若需要RSVP预留，则在块607处交换媒体之前，在块606处获得预留。MOH服务器可能位于QoS代理104a、104b的路径上，或者可以位于远程。若MOH服务器与端点106d和QoS代理104b位于同一处，则保留的RSVP预留被保持，并且不在MOH服务器和挂起端点106d之间使用。若MOH服务器与挂起端点106d的端点106a位于同一处，则保留的RSVP预留重新用来将MOH服务器与挂起端点106d相连接，并在端点106a对端点106d解挂(off hold)时再次使用。若MOH服务器在离端点
106a和端点106d远程的位置，则需要在挂起的端点106d和MOH服务器之间建立新的RSVP预留。判断块608确定挂起的端点106d是否被端点106a解挂。若挂起的端点106d仍然挂起，则MOH服务器继续向挂起端点106d发送媒体。若挂起的端点106d在判断块608处被解挂，则挂起端点106d和端点106a之间的媒体交换在块610处使用保留的RSVP预留继续。因此，挂起状态结束后，使挂(holding)端点106a和挂起(holder)端点106d之间可重新使用原来的RSVP预留。端点106d挂起时，若MOH服务器与端点106a和QoS代理104a位于同一处，也可使用原来的RSVP预留。呼叫最后终止于块612，然后该方法结束。若无法获得挂起端点106d和MOH服务器之间的预留，则对挂起端点106d应用挂起音(tone on hold)。

[0064] 图7A是说明呼叫转移到新端点106时，用于保留带宽的方法的另一个实施例的流程图70。图7B是用于呼叫转移情况的示例消息流。端点106a和106d在块700中使用按上述建立的RSVP预留来交换媒体。媒体交换过程中可调用补充业务。补充业务可包括在端点106之间转移呼叫、将呼叫转发到另一个端点106，和任何增强媒体交换的适当的补充业务。在所示的实施例的判断块702处，确定呼叫是否转移到另一个端点106c。若呼叫未转移，则端点106a和106d之间的媒体交换使用RSVP预留继续。若端点106a在转移呼叫，则端点106a和106d之间使用的预留在块704处被保留。通过保留预留，保留了端点106a和106d用来交换媒体的带宽。端点106a发起转移后，端点106d可按上述被挂起。

[0065] 判断块706处，确定被转移端点106d与接收被转移呼叫的端点106c是否位于同一位置。若被转移端点106d和接收端点106c位于同一位置，则被转移端点106d和接收端点106c或者使用块707处确定的新预留、或者根本不使用预留，在块708处交换媒体，并且释放保留的RSVP预留。呼叫最后终止于块712。若块709处，接收端点位于与端点106a和106b都不相同的位置，则该过程也流向块707。若接收端点106c与端点106a位于同一位置，则被转移端点106d和端点106a之间来自原来的媒体交换的保留的RSVP预留可重新使用。块710处，非同一位置端点106交换媒体。呼叫最后终止于块712，然后该方法结束。

[0066] 调用任何适当补充业务时，可应用本方法。例如，若会议桥(conference bridge)与开始电话会议的端点位于同一位置，则电话会议可重新使用保留的预留。另外，只要不脱离本发明的范围，可以任何适当顺序执行这些步骤。

[0067] 图8是说明电话会议建立后，用于保留带宽的方法的另一个实施例的流程图80。端点106a在块800处建立与端点106d的媒体交换。假设获得了用于端点106a和106d之间的媒体交换的预留，当端点106a尝试在端点106d和另一个端点106f之间启动电话会议时，这些预留将被保留。电话会议在块802处启动后，端点106a和106d之间的媒体交换在块804处断开，且预留被保留。这一事件实质上将端点106d置于挂起状态，该状态的建立前面已经讨论过。然后如有需要，端点106a在块806处按上述使用预留来建立与端点106f的连接。由于端点106f与端点106d位于同一位置，因此可以重新使用用于端点106a和
106d之间的连接的被保留的预留。

[0068] 建立与端点106f的连接后，端点106a启动会议能力，以便每个端点106a、106d和106f能够互相交换媒体。端点106d将脱离挂起状态。启动电话会议后，每个端点106a、
106d和106f在块808处重新定向到会议桥以便媒体交换能够发生。端点106a和106f之间的预留在块810处被保留。呼叫代理100通过QoS代理104a和104b利用会议桥，单独为每个端点106a、106d和106f执行RSVP预留。若会议桥与QoS代理104a或104b位于同一位置，则可重新使用保留的预留。若端点106d在块812处离开电话会议，则呼叫代理100可在块814处将端点106a和106d重新定向离开会议桥，并重建端点106a和106f之间用于媒体的直接交换的保留的预留。块816处每个预留被一个端点106终止后，呼叫代理100将释放端点106a与106d以及端点106a与106f之间的预留。

[0069] 图9是说明用于为呼叫转发的实施而保留带宽的方法的另一个实施例的流程图90。呼叫代理100可以支持至少三种类型的呼叫转发——呼叫转发全部(call forward all)，呼叫转发无应答(call forward no answer)，以及呼叫转发忙(call forward busy)。示例性转发情况为端点106a在块900处呼叫端点106d，然后端点106d在块902处可能将其呼叫转发到端点106f。若呼叫转发未使能，那么块904处媒体在端点106a和
106d之间交换。对于呼叫转发全部操作，从端点106a到端点106d的呼叫将立即延伸到端点106f。呼叫代理100只需在块908处建立QoS代理104a和104b之间的RSVP预留，用于块910处端点106a和106f之间的媒体交换。对于呼叫转发无应答操作，呼叫代理100在块912处建立端点106a和106d之间的预留。若块914处端点106d不应答，则启动计时器，并且计时器到期后将呼叫延伸到端点106f。将呼叫转发到端点106f之前，呼叫代理释放与端点106d相关的预留，并建立与端点106a和106f相关的预留。若端点106d和106f位于同一位置，则呼叫代理100可将与端点106d相关的预留重新用于端点106f。对于呼叫转发忙操作，块916处确定端点106d摘机后，不使用计时器且转发将立刻开始。若端点
106d应答，那么块916处媒体在端点106a和106d之间交换。呼叫最后终止于块918。

[0070] 图10A是说明共享线路的实施的消息流。该情形中，端点106d和106f共享同一号薄号码(directory number)。端点106a想要通过该号薄号码建立连接时，端点106a与端点106d和106f之间都建立RSVP预留。若端点106d和106f位于同一位置，则在建立被端点106d和106f共享的RSVP预留时使用单个QoS代理104b。若端点106d和106f位于不同位置，则通过QoS代理104b为端点106d、通过另外的QoS代理为端点106f建立分别的预留。端点106a与端点106d和106f之间的预留建立后或建立的同时，振铃信号提供给端点106d和106f两者。示出的示例中，端点106d先摘机，且媒体在端点106a和106d之间交换。然后拆除建立的有关端点106d的任何预留。

[0071] 图10B是说明共享线路实施中挂起事件的消息流。该情形中，端点106a按前面讨论的那样使端点106b挂起，并且预留被保留。但是作为共享线路，端点106f继续与端点106a的呼叫。若端点106f与端点106d位于同一位置，则所保留的预留可重新用于端点106a到端点106f的连接。若端点106f位于与端点106d不同的位置，那么所保留的预留被释放，并以前面描述的方式建立用于端点106a到端点106f的连接的新预留。呼叫代理
100为端点106f分配新的QoS代理，并且与端点106d的连接被拆除。

[0072] 图11是说明用于在已连接的呼叫过程中激活视频媒体的实施例的流程图1100。端点106在块1101中互相交换媒体。呼叫代理100在判断块1102处动态确定是否已激活视频。若视频未激活，则主叫端点106a和被叫端点106d继续交换音频媒体。若音频已激活，则呼叫代理100在块1104处确定被叫端点106d的视频能力。判断块1106确定被叫端点106d是否支持视频。若被叫端点106d不具备视频能力，则呼叫代理100不向媒体流添加视频媒体，并且主叫端点106a和被叫端点106d之间的音频媒体交换继续。若被叫端点
106d支持视频，则在块1110处向呼叫添加带有RSVP预留的视频媒体。现在端点106可在块1112处交换音频和视频媒体。交换音频媒体、视频媒体或二者都交换时，呼叫终止于块
1114，然后该方法结束。

[0073] 另一个实施例中，除了音频媒体之外，端点106可交换视频媒体。该实施例中，若接收端点106c不支持视频，则从呼叫中使视频媒体无效。例如，被叫端点106d可将呼叫从主叫端点106a转移到接收端点106c。在主叫端点106a和被叫端点106d交换视频媒体时，接收端点106c可不具备视频能力。呼叫代理100动态检测接收端点106c的视频能力，指示QoS代理104释放用于视频媒体的预留资源，并启动RSVP预留的释放。

[0074] 如上所述，强制情况下，为了在适当时候推迟或暂停对被叫方的振铃警告直到预留成功，RSVP机制被与呼叫信令同步。呼叫代理100还具备预留失败时，视情况不执行或重新路由呼叫的能力，包括向终端用户提供适当通知。例如，强制情况下，呼叫代理100向终端用户提供至少与其他呼叫接纳控制类型相同的关于预留失败的通知。对于IP电话，呼叫代理100可显示“带宽不足”并向终端用户提供快速繁忙音。快速繁忙音可替换为指示失败状态的语音提示。可选情况下，即使呼叫建立过程中RSVP失败，呼叫仍可继续。然后呼叫可能以较差语音质量开始。但是该较差质量状态是暂时的，呼叫过程中自动预留重试能力可成功提供足够带宽。呼叫代理100初始时可通知终端用户，对于该呼叫，可能要体验削弱的语音。一旦获得预留，呼叫代理100通知终端用户已取得正常网络状态并已恢复良好的语音质量。

[0075] QoS代理104在实现RSVP机制时为呼叫代理100充当代理。QoS代理104独立于端点106工作并向呼叫代理100提供合适的RSVP控制消息。这种方式中，端点106可以是实现上述不同协议的各种类型的设备。QoS代理104与呼叫代理100合作来将RSVP信令与呼叫信令同步。QoS代理的功能可包含在单一实体中或分布于整个网络。QoS代理功能可全部或部分置于呼叫代理100或位置102中。通过QoS代理104的使用，RSVP机制可从端点106之间的媒体路径中分开并脱离。

[0076] 不脱离本方面的范围的前提下，可对上述任何流程图或消息流进行修改、添加或省略。另外，步骤可按任何适当顺序执行，只要不脱离本方面的范围。

[0077] 本方面的某些实施例可提供一个或多个技术优势。一个实施例的技术优势为RSVP可以不用接触每个端点而在系统中使用。端点可支持不同协议并在同一系统内与RSVP交互。另外，支持RSVP的端点可与不支持RSVP的端点通信。另一个实施例的另一个技术优势为若初始尝试时未获得RSVP预留，呼叫也不会失败。允许呼叫在没有RSVP预留时继续避免了呼叫完全失败。实施例的又一个技术优势是进行呼叫的过程中呼叫可获得预留，这改善了QoS；或者可重建呼叫中失败的预留，这也改善呼叫的QoS。

[0078] 虽然根据某些实施例和一般相关方法描述了本公开内容，但是对实施例和方法的改造和变更对本领域技术人员显而易见。因此，上面对实施例的描述不限制本公开内容。不脱离本公开内容的精神和范围的前提下，也可以有其他修改、替代和变更。