本发明给出了一种设备，通过它来定义和交换UE和GGSN的 RSVP能力。本发明提供了一种机制，通过指示符和响应来协商使用 会话发起协议(SIP)的操作的优选RSVP模式。UE和GGSN之间的 消息交换通信可使用下面的技术：时分双工码分多址(TDDCDMA)、 时分一同步码分多址(TD-SCDMA)、频分双工CDMA(FDDCDMA) 和CDMA 2000。
SIP用来指明：UE的RSVP能力；基于RSVP的那个媒体流(那 些媒体流)；操作的优选模式，亦即基于UE的RSVP信令或基于GGSN 代理的RSVP信令；从策略控制功能(PCF)发送到UE的用于RSVP 的最终设置模式通信。
根据本发明，在会话设置过程中，发起UE向归属网的代理呼叫 状态控制功能(P-CSCF)发送SIP消息，提供一个所有媒体类型、能 力和工作优选模式的列表。包含策略控制功能(PCF)的P-CSCF最 终负责开展要进行会话所需的资源的分配。SIP信息用来对RSVP操 作作出最终决定。P-CSCF(PCF)可能请求GGSN的RSVP能力，这 些能力可能存储在合适的地方，根据UE和GGSN的能力信息，就可 作出最终的设置决定。如果UE和GGSN都具备RSVP能力，PCSCF (PCF)可确定提供RSVP信令的实体。另一方面，如果GGSN不具 备RSVP能力或者不想支持RSVP代理操作，就可把发起RSVP信令 的决定传给UE。如果P-CSCF确定GGSN将提供RSVP代理，P-CSCF 建议发起UE使用SIP来停止RSVP信令。然后，用通用开放策略服 务器(COPS)协议把决定传到GGSN来开始RSVP操作。
根据本发明，SIP还用来提供一个准入过程，应用通信实体的QoS 能力来确定呼叫/会话建立过程成功结果的可能性。发起UE/网络指明 呼叫建立过程中预期的QoS协议。此外，当被叫UE/网络响应时，他 们将通过SIP指出它是否具有支持特定QoS协议的能力。当不具备这 种能力时，将用一个明确的原因指示来拒绝呼叫，这有助于减少呼叫 建立的花费、网络中用于QoS信令的消息的数量并消除对不能提供服 务的不正确计费。
通过在呼叫建立过程阶段交换所有可用的QoS能力从而消除这 样一种情况，即在具备RSVP能力的UE/网络和不具备RSVP能力的 网络(包括从那以后由于缺少从不具备RSVP能力的被叫方来的对 RSVP信令消息的响应而过期的UE)之间成功建立呼叫(会话)，可 更有效地利用呼叫(会话)过程。
通过使用被叫方的策略控制功能(PCF)来对呼叫建立过程中在 GSSN上的RSVP发送者/接收者代理功能作出初步决定从而获得更快 的呼叫(会话)建立时间。只在呼叫建立阶段成功完成之后并且尤其 在正在发起的会话的被叫方的RSVP信令阶段才对GGSN上使用RSVP 代理功能作出决定。即使没有完全消除，本发明也进一步减小了通过 网络和空中接口的不必要的RSVP信令，从而提高整个系统的性能和 容量，并减少了这些情况的发生，即用户为由于成功会话建立而分配 的资源付费但实际上在服务在没有执行时会话就被叫了。
附图简述
考察下面的这些附图可更好的理解本发明及其目标和优点，在这 些图中同样的数字代表同样的元素，其中：
图1是简化的示意图，它给出了网络体系结构和应用SIP的基本 会话建立过程；
图2给出了用于图1中给出的发起UMTS体系结构类型的消息 交换会话建立过程，在这里给出的过程更为详细；
图3给出了当前使用的会话发起协议(SIP)邀请消息格式；
图4给出了会话描述协议(SDP)，它结合了UE能力、由UE 派生的代理配置以及根据本发明提供的由P-CSCF(PCF)设置的配置 选择；
图5给出了依照本发明的从UE发送到P-CSCF的包括预留协议 和优选配置指示的会话发起协议(SIP)邀请消息格式；
图6给出了依照本发明的从被叫UE发送到被叫网络P-CSCF的 包括预留协议和优选配置指示的会话发起协议(SIP)183消息格式；
图7给出了依照本发明的从发起网络P-CSCF发送到发起网络用 户设备UE的包括预留协议和优选配置指示的会话发起协议(SIP)183 消息格式；
图8是一个会话建立过程，它描述了依照当前标准在发起会话建 立过程中执行的媒体协商过程；
图9给出了依照本发明的一个会话建立过程，它和图8中的过程 类似并结合了使用SIP的呼叫/会话建立能力。
图10给出了依照本发明的具有预留协议能力以及优选配置请求 和选择的会话描述协议(SDP)；
图11给出了依照本发明的如图8中所示的从UE(A)到P-CSCF (A)的具有预留协议能力和优选配置的SIP邀请消息格式；
图12给出了依照本发明的如图8中所示的从P-CSCF(A)到S- CSCF(A)的具有建议QoS预留协议的SIP邀请消息格式；
图13给出了依照本发明的如图8中所示的从被叫UE(B)到被 叫P-CSCF(B)响应发起UE(A)邀请的SIP 183消息格式，其中UE (A)具备RSVP能力；
图14给出了如图8中所示的从被叫P-CSCF(B)到被叫S-CSCF (B)的SIP 183消息格式，其中UE(B)具备RSVP功能；
图15给出了如图8中所示的从被叫UE(B)到被叫P-CSCF(B) 的SIP 183消息格式，其中UE(B)不具备RSVP能力并且请求RSVP 代理功能；
图16给出了依照本发明如图8中所示的从被叫P-CSCF(B)到 被叫S-CSCF(B)向发起UE(A)方向的SIP 183消息格式，其中UE (B)不具备RSVP能力并且网络充当RSVP代理；
图17描述了依照本发明如图8中所示的从被叫P-CSCF(B)到 被叫S-CSCF(B)向发起UE(A)方向的SIP 183消息格式，其中UE 和网络都不具备RSVP能力；
图18是依照本发明如图8中所示的从发起P-CSCF(A)到发起 UE(A)的SIP 183消息格式，其中请求会话的双方都支持RSVP并 且安装了GGSN代理；并且
图19给出了依照本发明的从发起P-CSCF(A)到发起UE(A) 的SIP 183消息格式，其中双方都不支持RSVP并且接受DiffServ协 议。
优选实施例
图1给出了UMTS网络体系结构中会话流的简化示意图。该网 络包括UE(A)和UE(B)。UE(A)位于包含GGSN(A)和P-CSCF (A)的网络A中，网络A可以是UE(A)的归属网也可以是UE(A) 漫游到的网。
UE(B)位于包含P-CSCF(B)和GGSN(B)的网络B中。网 络B可以是UE(B)的归属网也可是UE(B)漫游到的网。在网络 A和B之间可存在一个或多个其它网络/CSCF。
UMTS呼叫/会话建立过程操作如下：
步骤S1.UE(A)启动一个包括SDP建议的UE(B)的会话发起 过程。
步骤2到4是可选的，它们取决于终端的实现和/或终端的预先 配置设置。因此，它们以虚线的方式显示。
步骤S2.预警UE(B)的用户。
步骤S3.向UE(A)发送预警指示。
步骤S4.然后UE(B)的用户交互并表达他/她对实际会话的期 望。
步骤S5.UE(B)根据终端设置、终端预配置情况以及可选的用 户期望生成可接受的SDP。
步骤S6.在可靠SIP响应的净荷中把接受的SDP转发给UE(A)。
步骤S7.执行初始集合信道(bearer)创建过程。在集合信道创建 步骤中，UE(A)和UE(B)的接入网络中的资源和PDP上下文过 程一起预留。此时，也有可能预留外部网络中的集合信道资源。
步骤8到10也是可选的，可跳过它们，它们也以虚线的形式显 示。
步骤S8.UE(B)的终端开始振铃。
步骤S9.向UE(A)发送警告指示。
步骤S10.UE(B)的用户交互并表达他/她对实际会话的期望。
步骤S11.在此时，如果在步骤7中预留的初始集合信道和UE(B) 用户的期望不同，则UE(A)和UE(B)可以执行集合信道修改过 程。在集合信道修改步骤中，可通过修改PDP上下文来修改UE(A) 和UE(B)的接入网络中的资源，并且也可以修改在外部网络中的预 留资源。
步骤S12.会话发起过程得到确认。
图2给出了按照现有标准在包含UE、P-CSCF和S-CSCF的UMTS 归属网体系结构中的会话消息交换流。
在步骤S1中，UE向归属网的P-CSCF发送一个SIP邀请，该邀 请包含会话描述协议(SDP)。在步骤S2中，P-CSCF检查邀请消息 并将它转发给S-CSCF。在步骤S3，归属网的S-CSCF检查邀请消息， 施行服务控制，获知对被叫UE服务的网络运营商，然后向被叫UE 的被叫网络或者向归属网和被叫网之间的网络发送该邀请消息。
归属网的S-CSCF在步骤S5中从被叫网络一接收到会话描述协 议，就在步骤S6中将它中继给归属网P-CSCF。P-CSCF在步骤7中 批准QoS资源，然后在步骤S8中将SDP中继给归属网UE。
在步骤S9中，归属网UE生成提出会话的最终SDP消息、ID、 版本、会话创建者、目的地址、实时协议(RTP)净荷类型、RTP格 式、时钟速率以及端口，它们被发送给归属网P-CSCF，该归属网P-CSCF 在步骤S10中将该最终SDP中继给归属网S-CSCF，归属网S-CSCF 在步骤S11中反过来又将最终SDP中继给被叫网络或者传输给归属网 和被叫网之间的网络。
UE在步骤S12中创建资源预留，这(此处需要更多信息)导致 在步骤S13中从UE到归属网P-CSCF的成功消息的中继，在步骤S14 中从归属网P-CSCF到归属网S-CSCF的消息的中继，以及在步骤S15 中从归属网S-CSCF到被叫网或者中间网的消息的中继。建立资源预 留之后，在步骤S16中随后就把来自被叫UE的振铃发送给归属网S- CSCF，在步骤S17中从S-CSCF发送给归属网的P-CSCF，在步骤S18 中从归属网的P-CSCF发送给归属网的UE。
归属网UE响应振铃指示，在步骤S19中生成回铃，这向发起UE 说明被叫方正在振铃。
被叫网络除了将振铃指示最终中继到归属网UE之外，还在步骤 S20中生成一个到归属网S-CSCF的200 OK指示，在步骤S21中它执 行会话建立结束需要的服务控制，并在步骤S22中将200 OK消息中 继给归属网的P-CSCF，它在步骤S23中认可服务质量(QoS)承诺并 在步骤S24中将200 OK消息中继给归属网UE。
在步骤S25中，归属  UE发起媒体流，在步骤S26中向归属网 的P-CSCF发送一个确认(ACK)，在步骤S27中P-CSCF将确认信 号中继给归属网S-CSCF，归属网的S-CSCF反过来又在步骤S28中 把确认(ACK)发送到被叫网或者中间网。
图3给出了根据现有标准定义的SIP消息格式，我们将详细谈到， 它缺少预留协议和优选配置的指示。图3中显示的SIP消息包括一个 请求和一个响应(第一行)，一个消息头(接下来的14行)以及一 个消息体(剩余的15到38行)。
图4显示了本发明提供的对现有SIP消息的补充。提出的格式包 括位于10的UE能力和代理配置、位于12的UE能力，位于14的UE 所需的代理配置和位于16的由P-CSCF(PCF)根据配置设置作出的 选择。这些格式的使用使得UE可以告诉P-CSCF(PCF)它是否具备 如14所示的RSVP能力，以及它工作的最优模式，也就是GGSN的 RSVP发送器/接收器代理是否是首选的，如16所示。图4中显示的 新消息格式进一步使得归属网P-CSCF(PCF)通过直接的选择告诉UE 最终的设置，也就是为UE提供一个消息来将指示GGSN具备RSVP 代理功能的RSVP信令终止，或者让指示没有代理可用的RSVP信令 继续。图4中显示的新消息格式还使得UE说明哪个数据流正使用和 在18显示的差分服务(DiffServ)协议相对的RSVP。
图5给出了一个SIP邀请消息，它具有本发明的所有补充性能， 其中UE(A)说明它具备RSVP能力，如19所示，并且代理操作是 优选的，如20所示。UE进一步说明用于三种不同媒体流I、II、III 的服务质量(QoS)将用RSVP协议运送，分别在22、24和26显示， 而最后一个媒体流IV中的QoS通过差分服务(DiffServ)运送，如28 所示。
图6显示了一个SIP 183消息，它是来自被叫UE的SDP消息， 如图2中所示的步骤5，其中被叫UE(图中未显示)回应图2中来自 发起UE的邀请，告诉P-CSCF它具备RSVP能力，如30所示，并且 RSVP代理操作不是优选的，如32所示。被叫UE还指明RSVP协议 也将用于媒体流支持，如34所示。在SIP中提供的这些能力仅仅是 用于正在服务的网络配置使用的，对体系结构中的其它实体没有影 响。在向下一跳也就是该消息要通过的下一个路由器转发消息之前， P-CSCF可删除如30和32所示的SIP消息的(PC＝)部分的代理配置。
图7显示了归属网P-CSCF转发到发起UE的SIP183消息，它告 诉UE GGSN的RSVP代理功能请求得到允许并且发起UE应停止RSVP 信令，如36所示。这个消息也可用于在其它实体间的其它SIP消息， 比如SIP 200 OK消息。图7中的SIP 183消息还确认媒体流将用RSVP 协议运送，如38所示。
如上所述，本发明还具有使得发起UE/网络可在呼叫建立过程中 指明QoS协议的功能。该技术还要求确定UE/网络在响应中说明它是 否能够支持特定的QoS协议。在被叫网络不能支持提出的QoS协议 的情况下，用一个明确的原因指示拒绝呼叫，从而：降低了呼叫建立 的花费，减少了网络中用于QoS信令的消息的数量，消除了对不能提 供的服务错误计费的可能。
通过提供一种现有UMTS呼叫(会话)建立机制，也就是SIP， 发起UE能够告诉被叫UE想要的QoS协议类型，比如RSVP。UMTS 呼叫(会话)机制还使得被叫UE可告诉发起UE和支持(服务)网 络它是否支持发起UE提出的用于QoS的协议类型，比如RSVP，同 时也能告诉发起用户和服务网络被叫用户对提出的媒体类型可支持的 QoS协议类型。
通过UMTS呼叫(会话)建立机制，也就是SIP，被叫网络也就 是P-CSCF/PCF能根据被叫用户(UE)和GGSN RSVP代理功能支持 的网络所返回的能力来判定呼叫(会话)建立能否继续。UMTS呼叫 (会话)建立机制，也就是SIP，使得被叫网的P-CSCF/PCF可告诉 被叫网络和用户该网络是否支持基于QoS的RSVP。UMTS呼叫(会 话)建立机制，也就是SIP，使得P-CSCF/PCF更新被叫UE说明支持 的QoS协议，也就是恢复发起UE利用RSVP功能起初提出的协议。 UMTS呼叫(会话)建立机制，也就是SIP，使得GGSN RSVP发送 器/接收器代理功能在呼叫建立期间而不是QoS预留阶段被实现。
UMTS呼叫(会话)建立机制，也就是SIP，使得发起网络的P- CSCF/PCF能告诉发起用户：被叫网络能否支持RSVP QoS；RSVP代 理功能在GGSN还是在基于媒体流的RSVP处实现，也就是UE是应 该停止还是应该继续发送RSVP信令消息。UMTS呼叫(会话)建立 机制，也就是SIP，使得发起UE根据接收到的关于被叫网络支持QoS 协议能力的响应终止多媒体呼叫/会话建立过程。UMTS呼叫(会话) 建立机制，也就是SIP，根据接收到的有关被叫用户能力的响应，通 过调整为支持特定媒体的想要的/建议的QoS协议，还使得发起UE能 继续多媒体呼叫/会话建立过程。
图8显示了一个通信系统，其中UE#1位于包括P-CSCF#1和S- CSCF#1的网络中，该网络可能是UE的归属网也可能是UE#1漫游到 的网；UE#2位于包括CSCF#2和P-CSCF#2的网络中，该网络可能是 UE#2的归属网也可能是UE#2漫游到的网。在图2显示的实施例中， 假设发起和被叫UE都在归属网中，为了简化其中的描述，认为除了 通过额外的中间网络的消息的最终传输之外该系统基本相同。
在给出的实例中，UE#1在步骤S1中确定UE#1正在请求的会话 中支持的编解码器的全集。UE#1构建包括带宽需求和每种媒体特征 的会话描述协议(SDP)，并为每种可能的媒体流分配本地端口号。 可建议多媒体流，并且对于每种媒体流(M＝line和SDP)可有多种编 解码器选择。在步骤S2中，UE#1把初始的INVITE消息发送到包含 UE#1构建的SDP的P-CSCF#1。P-CSCF#1在步骤S3中检查媒体参 数并去除那些网络运营商根据本地策略决定在网络上不支持的那些选 择，并在步骤S4中把INVITE消息转发给S-CSCF#1。在步骤S5中， S-CSCF#1检查媒体参数并去除那些客户无权请求也就是说客户还没 有请求的并对提供给客户的这部分服务付费的那些选择。在步骤S6 中S-CSCF#1把INVITE消息转发给S-CSCF#2，在步骤S7中S-CSCF#2 根据运营商策略减少支持的编解码器集合，这实际上和步骤S5中由 S-CSCF#1执行的方式很相似，在这之后在步骤S8中把INVITE消息 转发给P-CSCF#2，P-CSCF#2采用和步骤S3中由P-CSCF#1执行的 相类似的方式检查媒体参数并在步骤S9中去除那些网络运营商根据 本地策略决定在网络上不支持的那些选择，然后在步骤S10中将该消 息发送给被叫UE#2。
UE#2比较能支持所请求的会话的编解码器，并确定在邀请消息 中出现在SDP中的交集。对于不支持的每种媒体流，UE#2和SDP输 入端口＝0的媒体(m＝line)。对于支持的每种媒体流，UE#2插入 一个SDP条目，该SDP条目分配了端口，以及与来自UE#1的那些 编解码器相同编解码器，这些活动在步骤S11中执行。UE#2在步骤S12 中返回列在常见媒体流中的SDP和到P-CSCF#2的编解码器。
P-CSCF#2在步骤S13中批准用于剩余媒体流的QoS资源系统和 用于会话的共同的编解码器的编解码器选择，并在步骤S14中将该SDP 消息转发给S-CSCF#2。在步骤S15中，S-CSCF#2把SDP消息转发 给S-CSCF#1，在步骤S16中S-CSCF#1把SDP消息转发给P-CSCF#1。 在步骤S17中P-CSCF#1认可用于会话的共同的编解码器的资源，并 在步骤S18中把SDP转发给UE#1。
UE#1在步骤S19中确定会话的初始编解码器和会话应使用的媒 体流。如果有多个媒体流或者一个媒体流有多个编解码器选择，在步 骤S20中，UE#1包括由UE#1发送到UE#2的一个SDP和一个“最 终SDP”消息，这些消息被转发，如步骤S21到S24所示。
UE#2把“最终SDP”消息按照由INVITE请求设置的信令路径 发送给UE#1，为了简化起见，我们省略了信令路径，认为信令路径 和现有的能力一样。多媒体会话的剩余部分是按照传统方法的单个编 解码器会话的方法完成的。
图4显示了一个具体实现了本发明的原理的呼叫(会话)流程， 其中图8和图9之间同样的步骤用同样的数字表示，不同的步骤用不 同的“质数(prime)”表示。
在图9显示的过程中，UE#1在步骤S1′中除了确定请求会话支持 的编解码器的全集并根据图8中的步骤S1构建SDP之外，还确定本 会话UE#1可支持的QoS协议，比如RSVP DiffServ等，从而使UE#1 能支持该会话，如图10中的42所示。利用图8中给出的步骤S1中 的目前的方法，包含每个媒体流带宽特征以及分配给各可能媒体流的 本地端口号的SDP被构建。可以如行n＝SDP所示的方式提供多媒体 流，例如在图11中，显示了位于图11中44和46的两个视频媒体流 和两个音频媒体流，并给出多个呼叫。然而要注意到图11中的这两 个音频媒体流每个都采用不同的QoS协议，一个是RSVP，另外一个 是DiffServ。
UE#1在步骤S2中把上述的SDP INVITE消息发送给P-CSCF#1。 在步骤S3′中，P-CSCF#1检查媒体参数并去除那些网络运营商根据本 地策略决定不支持的选择，这种情况和步骤S3相同，请参见图8。P- CSCF#1还进一步检查UE#1的RSVP能力以及它的RSVP代理操作 的优选项。P-CSCF#1把这些信息传给策略控制功能(PCF)以请求对 网络设置作出选择。P-CSCF#1去除(rc＝)条目，如图11中的48所 示，图12所示的SDP中省略了该条目，如步骤S4所示，该SDP消 息(图12)作为邀请消息被转发了给S-CSCF#1。在步骤S5中，S-CSCF#1 检查媒体参数并去除那些客户无权请求的选择，这和图8中所示的实 施例的步骤S5类似，于是在步骤S6中，S-CSCF#1通过S-CSCF#2 经S-S会话流过程转发INVITE。
和图8中显示的步骤S7中的当前网络技术类似，S-CSCF#2在步 骤S8中检查媒体参数并去除那些目的客户无权请求的选择并把 INVITE消息转发给P-CSCF#2。
在步骤S9′中，P-CSCF#2通过检查媒体参数和去除网络运营商根 据本地策略决定不支持的选择，执行图8中所示的步骤S9中给出的 P-CSCF#2执行的功能。此外，P-CSCF#2在向PCF传递消息之前检查 SDP消息中提供的用于决定可选功能支持的QoS协议，比如GGSN RSVP代理功能。然后在步骤S10中，把这个SDP INVIT消息转发给 UE#2，如图12所示。
在步骤S11′中，UE#2确定在会话中可支持的编解码器的全集以 及支持的QoS协议，比如RSVP、DiffServ等。和图8中所示的当前 技术中的步骤S11类似，UE#2用出现在SDP中的消息和INVITE消 息确定交集。对于每种不支持的媒体流，UE#2插入一个用于媒体的SDP 条目，也就是n＝line，port＝0。对于每种支持的媒体流，UE#2插入一 个这样的SDP实体，它具有分配的端口，还具有与来自UE#1的SDP 消息中的那些一样编解码器的编解码器。这些步骤和图8中显示的S11 基本相同。UE#2还能告诉P-CSCF#2它能否支持RSVP以及RSVP发 送器/接收器代理功能是否是优选设置。UE#2还能在现有的不支持的 情况下提出不同的QoS协议，如图13到图15所示。更特别的，图13 显示从UE#2到P-CSCF#2的响应UE#1 INVITE消息的修改的SIP 183 消息格式，图13中的实施例给出了在UE#2具备RSVP能力时的情况， 如图13中的50所示。图14显示在UE#2具备RSVP能力情况下从 P-CSCF#2到S-CSCF的SIP 183消息格式。图15给出了在UE#2具备 RSVP能力情况下从UE#2到P-CSCF#2的响应UE#1 INVITE消息的 修改的SIP 183消息格式，如图16中的52所示。
如图12中所示的步骤S12，UE#2向P-CSCF#2传输SDP列表、 媒体流以及编解码器。
在步骤S13′中，P-CSCF#2批准用于剩余媒体流的QoS资源和编 解码器选择。P-CSCF#2检查UE#2的RSVP能力，并将该信息传给PCF 来对RSVP代理功能以及提出会话的整个支持作出选择。根据对提出 QoS质量支持的缺少，P-CSCF#2可拒绝会话也可通过向QoS协议传 递提出改变建议来继续协商。如图16的52所示，在UE#2具备RSVP 能力的情况下，P-CSCF#2确定网络配置并向支持RSVP的发起网络 传输一个指示。在UE#2不具备RSVP能力并且UE#2声称自己使用 不同QoS协议也就是DiffServ支持建议的媒体类型的情况下，而网络 支持RSVP代理功能时，图11显示了在UE#2不具备RSVP能力并且 请求RSVP代理功能的情况下从UE#2到P-CSCF#2的SIP 183消息格 式。图12显示了在UE#2不具备RSVP能力而网络具备RSVP能力的 情况下从P-CSCF#2到S-CSCF#2的向UE#1的SIP 183消息格式。
P-CSCF#2还能实现RSVP代理功能，恢复建议的QoS，例如 RSVP，并向支持RSVP的发起网络传送一个指示。在如图13中54 所示的UE#2和服务网络不具备RSVP能力的例子中，P-CSCF#2可选 择向发起方传送一个指示：不支持RSVP，并继续使用它当前由UE#2 提出的建议来携带媒体类型、携带另外一种QoS协议；或者根据运营 商的策略简单地拒绝会话。在步骤S14中，P-CSCF#2转发对S-CSCF#2 的SDP响应。在步骤S15中，S-CSCF#2转发对S-CSCF#1的SDP响 应，在步骤S16中S-CSCF#1转发对P-CSCF#1的SDP响应。
在步骤S17′中，P-CSCF#1批准用于剩余媒体流的QoS资源和编 解码器选择，还检查被叫网络的RSVP能力，并将该信息传给UE#1， 如图18和图19所示。P-CSCF#1还能传递对GGSN RSVP代理功能 作出的选择，也就是是否支持RSVP代理功能。在支持代理功能的情 况下，如图16中56所示的“停止RSVP信令”消息通过消息“具备 RSVP能力”发送到UE#1，指示另一边支持RSVP，如图18中58所 示。如果不支持RSVP代理功能，发送消息“继续RSVP信令”作为 替代，这些替代消息分别出现在图18中的56和58。如果被叫方不支 持RSVP，则“不具备RSVP能力”和“停止RSVP信令”的组合被 发送给UE#1，从而不对建议的媒体流使用RSVP，也不安装代理功能。 在这种情况下，在给出的例子中的图18中的58处插入替代消息“不 具备RSVP能力”。
在步骤S18中，P-CSCF#1把SDP响应从UE#2转发给UE#1。
UE#1确定哪些媒体流应该用于该会话以及哪些编解码器应用于 每个媒体流。如果有多个媒体流或者每个媒体流有多个编解码器选 择，则UE#1必须在“最终SDP”消息中包括一个SDP，或者如果媒 体流不能用建议的QoS协议转发，UE#1选择终止会话建立过程，这 些活动在步骤S19′中执行。
沿步骤S20到步骤S24所示的由INVITE请求建立的信令路径， UE#1向UE#2发送“最终SDP”消息，这些步骤和应用在图8中所 示的呼叫(会话)流中的当前技术中的步骤S20到S24类似。多媒体 会话的剩余部分的完成方式和上面描述的与图8中显示的目前方法有 关的单媒体/单编解码器会话的完成方式相同。图10中显示的用于SDP 的修改的会话描述协议代表从UE#1发送到UE#2的“SDP”消息。