SBC功能部署规范 - RFC5853中文翻译（3）

 媒体流量管理

3.2.1.  功能说明和要求

媒体流量管理是控制媒体流量的功能.网络运营商可能需要此功能,以便控制其用户使用量其网络上承载的流量.流量管理有助于创建不同类型的计费模型（例如，视频电话的价格与仅语音呼叫的价格不同）.并且还使运营商能够强制用户使用所选的编解码器.

媒体流量管理的一个用例是提供支持审计或法律义务所需的拦截功能.值得注意的是,法律义务主要适用于提供语音服务的运营商,并且这些运营商通常具有基础设施（如充当B2BUAs的SIP代理）,即使没有SBC也能提供拦截功能.

由于媒体路径独立于信令路径,因此除非SBC修改会话描述,否则媒体可能不会访问运营商的网络.通过修改会话描述,SBC可以强制媒体通过媒体中继发送,媒体中继可以与SBC共处一地.例如,可以完成这种流量管理以确保某个QoS级别,或确保订户仅使用允许的编解码器. 值得注意的是,SBC与媒体路由拓扑没有直接联系,它们不会更改流量工程（TE）隧道上的带宽预留,也不会与路由协议直接交互.

有一些运营商不希望管理流量,而只是监控流量以收集统计信息并确保它们能够满足与其用户或合作伙伴的任何业务服务级别协议.从SBC的角度来看,监控媒体流量所需的协议技术与管理媒体流量的协议技术相同.

如果任一终端在会话中间死亡,则媒体路径上的SBC也能够处理“丢失的BYE”问题.SBC可以检测到媒体已停止流动并向双方发出BYE以清除其他中间元素和终端中的任何状态.

媒体流量管理的一种可能形式是SBC通过生成BYE请求来终止媒体流和SIP对话.例如,在付费用户用尽额度的情况下,可以进行这种操作.需要媒体管理以确保付费用户不能忽略SBC生成的BYE请求并继续其媒体会话.

3.2.2.  风险说明

SBC实现流量管理要求SBC访问和修改在用户代理之间交换的会话描述信息SDP（提供和响应）.因此,如果用户代理端到端加密或完整保护其消息正文,则此方法不起作用.同样,在没有用户同意的情况下修改消息,并且用户代理没有任何方式来区分SBC动作和MITM的攻击。 此外.这违反了身份验证身份管理[4]，请参阅第3.1.2节.

插入媒体中继可以防止媒体路径的“非媒体”使用,例如媒体路径密钥协议.有时这种预防是需要的,但并不总是必要的.例如，如果SBC仅用于启用媒体监控,而不是用于拦截.

使用媒体中继相关可能存在一些问题.如果媒体中继没有以正确的方式完成,则可能会破坏诸如显式拥塞通知（ECN）和路径MTU发现（PMTUD）之类的功能.媒体中继很容易破坏依赖于协议字段的正确处理的IP和传输层功能.一些特别敏感的字段例如是ECN和服务类型（ToS）字段以及不分段（DF）位.

媒体流量管理功能阻碍创新的方式.阻碍的原因在于,在许多情况下,SBC需要能够在新服务投入使用之前支持新形式的通信（例如，SDP协议的扩展）,这减缓了新创新的采用.

如果SBC通过网络中的中心点引导许多媒体流,则可能会导致大量额外流量到达该中心点的路径,这可能会在路径中造成可能的瓶颈.在该应用中,SBC可以发起用户可能无法认证的消息来自对话对等体或SIP注册器/代理.

3.2.3.  例子

流量管理可以通过以下方式来执行：SBC表现为B2BUA并且在媒体路径中插入自身或管理员控制下的某个其它实体.实际上,SBC修改SIP消息中携带的会话描述.结果,SBC从一个用户代理接收媒体并将其转发到另一个用户代理,并且与反向流向的媒体执行相同的操作.

如第3.2.1节所述，编解码器限制是一种流量管理形式.SBC限制用户代理之间在提议/应答交换[5]中协商的编解码器集.在修改会话描述之后，SBC可以检查媒体流是否对应于在提议/应答交换中协商的内容.如果它不同，则SBC能够终止媒体流或采取其他适当的（配置的）动作（例如，发出警报.

考虑以下示例场景：SBC从外部网络接收INVITE请求，在这种情况下是外部网络收到的SIP消息包含图6中所示的SDP会话描述符.

v=0

o=owner 2890844526 2890842807 IN IP4 192.0.2.4 c=IN IP4 192.0.2.4

m=audio 49230 RTP/AVP 96 98

a=rtpmap:96 L8/8000

a=rtpmap:98 L16/16000/2

图6: 流量管理前的请求消息体

在该示例中，SBC通过重写“m=”线并根据一些（外部）策略移除一个“a=”线来执行媒体流量管理功能。 图7显示了流量管理功能之后的会话描述.

v=0

o=owner 2890844526 2890842807 IN IP4 192.0.2.4

c=IN IP4 192.0.2.4

m=audio 49230 RTP/AVP 96

a=rtpmap:96 L8/8000

图7: 媒体管理处理后的请求消息体

媒体流量管理存在一个问题，即SBC需要了解会话描述协议和用户代理使用的所有扩展.这意味着为了使用新的扩展（例如，实现新服务的扩展）或新的会话描述协议，网络中的SBC可能需要与端点一起升级.值得注意的是，类似的问题，但有头字段,适用于拓扑隐藏功能，请参阅第3.1节.某些不需要主动操纵会话描述符以促进流量管理的扩展将能够在不升级现有SBC的情况下进行部署,具体取决于SBC实施所提供的透明度.在需要SBC修改以支持新协议功能的情况下,服务部署速率可能会受到影响.

3.3.   修复功能不匹配

3.3.1.  通用说明和要求

SBC修复功能不匹配使得具有不同功能或扩展的用户代理之间的通信成为可能.例如,SBC可以使普通SIP[1]用户代理连接到3GPP网络,或者启用支持不同IP版本,不同编解码器或处于不同地址域的用户代理之间的连接.运营商具有执行能力不匹配修复的要求和强烈动机,因此他们可以跨不同域提供透明通信.在一些情况下,用于实现相同SIP应用的不同SIP扩展或方法（如监视会话活跃度,呼叫历史/转移等也可以通过SBC进行交互.

3.3.2.  风险说明

SBC的协议修复是通过使用第3.2节中描述的过程将媒体元素插入媒体路径来实现.因此,这些SBC与执行流量管理的SBC具有相同的关注点：SBC可以在未经任何用户代理的同意的情况下修改SIP消息.这可能会破坏端到端的安全性和应用程序扩展协商.

从长远来看,能力不匹配修复是一项脆弱的功能.内置于各种网络元素中的不兼容性数量随着时间的推移而增加了脆弱性和复杂性.这可能导致SBC需要能够并行处理大量能力不匹配的情况.

3.3.3.  例子

请考虑以下示例场景,其中内部网络是使用IPv4的接入网络，外部网络使用IPv6.SBC从接入网络接收带有会话描述的INVITE请求:

INVITE sip:callee@ipv6.domain.example.com SIP/2.0

Via: SIP/2.0/UDP 192.0.2.4

Contact: sip:caller@u1.example.com

v=0

o=owner 2890844526 2890842807 IN IP4 192.0.2.4

c=IN IP4 192.0.2.4

m=audio 49230 RTP/AVP 96

a=rtpmap:96 L8/8000

图8: 功能不匹配前的请求

然后,SBC执行能力不匹配固定功能.在这种情况,SBC插入Record-Route和Via标头,并从会话描述符重写“c=”行.图9显示了功能不匹配调整后的请求.

INVITE sip:callee@ipv6.domain.com SIP/2.0

Record-Route: <sip:[2001:DB8::801:201:2ff:fe94:8e10];lr>

Via: SIP/2.0/UDP sip:[2001:DB8::801:201:2ff:fe94:8e10]

Via: SIP/2.0/UDP 192.0.2.4

Contact: sip:caller@u1.example.com

v=0

o=owner 2890844526 2890842807 IN IP4 192.0.2.4 c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10 m=audio 49230 RTP/AVP 96 a=rtpmap:96 L8/8000

图9: 功能不匹配后的请求

然后,该消息由SBC发送到后续IPv6网络.