CN103475639A

CN103475639A - 一种rtp回退处理方法及装置

Info

Publication number: CN103475639A
Application number: CN2013103468220A
Authority: CN
Inventors: 杨瑞峰; 陈捷
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: Hangzhou H3C Technologies Co Ltd
Priority date: 2013-08-09
Filing date: 2013-08-09
Publication date: 2013-12-25

Abstract

本发明提供一种RTP回退处理方法及装置，应用于网络设备或者终端上，其中该方法包括：步骤A、向对端发送Invite消息，并在该消息中携带SRTP相关媒体信息以请求协商SRTP呼叫；步骤B、在从对端接收到携带RTP相关媒体信息的应答消息后，检查请求协商的协议类型与对端回应的协议类型是否一致，如果不一致，转步骤C处理；步骤C、向对端发送Re-invite消息，并在该消息中携带RTP相关媒体信息以请求协商RTP呼叫。相较于现有技术而言，本发明能够在对端存在识别错误时，依然能够顺利地实现RTP回退，且具有良好的兼容性。

Description

一种RTP回退处理方法及装置

技术领域

本发明涉及网络多媒体通信领域，尤其涉及一种RTP回退处理方法及对应的装置。

背景技术

SIP协议是一个应用层的控制协议，其广泛应用于视频监控以及网络电话等应用场景中，在互联网高度发达的今天，SIP协议几乎和我们每个人的工作生活都有直接或者间接的联系，比如说人们在公司使用VoIP电话时，呼叫过程就会涉及到SIP协议中各种信令的交互；再比如说，当交通指挥人员在指挥中心调度各个路口的视频实况时，SIP协议一样在发挥着业务调度的功能。从功能上来说，SIP协议可以用来建立、修改、和终止多媒体会话（或者会议）。典型地，通过SIP消息可以协商媒体信息，比如以下即将阐述的安全呼叫模式。

SRTP的全称是Secure Real-time Transport Protocol，即安全RTP协议。RTP协议是传递多媒体数据流的重要技术，是目前最为流行的一种多媒体数据流封装技术。SRTP协议的主要目标是RTP承载的数据流进行加密、认证和重传保护。随着VoIP系统的广泛应用，用户对于VoIP网络的安全性要求越来越高，比如银行、政府部门等，SRTP便是在这样的应用需求下诞生的。SRTP和RTP将在长时间内共存，如何处理好共存中各种相关问题是业界需要解决的一个重要技术问题。

发明内容

有鉴于此，本发明提供一种RTP回退处理装置，应用于网络设备或者终端上，该装置包括初始协商单元、协商处理单元以及二次协商单元；其中：

初始协商单元，用于向对端发送Invite消息，并在该消息中携带SRTP相关媒体信息以请求协商SRTP呼叫；

协商处理单元，用于在从对端接收到携带RTP相关媒体信息的应答消息后，检查请求协商的协议类型与对端回应的协议类型是否一致，如果不一致，通知二次协商单元处理；

二次协商发起单元，用于向对端发送Re-invite消息，并在该消息中携带RTP相关媒体信息以请求协商RTP呼叫。

本发明还提供一种RTP回退处理方法，应用于网络设备或者终端上，其中该方法包括：

步骤A、向对端发送Invite消息，并在该消息中携带SRTP相关媒体信息以请求协商SRTP呼叫；

步骤B、在从对端接收到携带RTP相关媒体信息的应答消息后，检查请求协商的协议类型与对端回应的协议类型是否一致，如果不一致，转步骤C处理；

步骤C、向对端发送Re-invite消息，并在该消息中携带RTP相关媒体信息以请求协商RTP呼叫。

相较于现有技术而言，本发明能够在对端存在识别错误时，依然能够顺利地实现RTP回退，并且由于本发明借用了标准的实现手段，因此具有优异的兼容性。

附图说明

图1是一种典型的协商SRTP呼叫过程示意图。

图2是一种典型的协商SRTP呼叫失败但成功回退到RTP呼叫的示意图。

图3是一种典型的协商SRTP呼叫失败且回退RTP失败的示意图。

图4是本发明一种实施方式中RTP回退处理装置的逻辑结构及典型的硬件环境示意图。

图5是本发明一种实施方式中RTP回退处理过程的示意图。

具体实施方式

从实际应用来看，参与者的角色往往是固定的，以VoIP为例，业务的发起者称为呼叫方（Caller），被呼叫的一方称为被叫（Callee），在通话结束前，这样的角色并不会发生变化。但从SIP协议本身的交互模型来看，双方的角色又时动态。SIP协议采用C/S（Client/Server，客户端/服务器）模型。Caller以及Callee被称为UA（User Agent，用户代理），Caller以及Callee均可以作为Client，同时也可以作为Server；通常来说发起信令请求的一方会被称为UAC（User Agent Client），而响应的一方被称为（User Agent Server）。这些在后续描述中将不再详细解释，本领域普通技术人员可以参考相关RFC获取更详尽的了解。

请参考图1，采用SRTP进行呼叫的基本协商流程通常包括以下步骤：

步骤10，UAC向UAS发送INVITE消息，并在SDP（会话描述协议）消息体中携带SRTP相关媒体信息；

步骤11，UAS在收到INVITE消息后，协商SRTP相关媒体信息后，发送成功的200OK消息，并在SDP消息体中携带协商成功的SRTP媒体信息，从而建立安全的呼叫。

在实际的应用过程中，不得不考虑的问题是，对于网络中既有的传统网络设备（比如老款路由器）以及终端（比如IP电话）来说，其可能不支持SRTP媒体协商，此时需要做兼容性考虑，允许双方采用非安全的RTP呼叫，这种机制通常也称为回退机制。请参考图2，一个典型的RTP回退过程包括以下步骤：

步骤20，UAC向UAS发送INVITE消息，并在其中携带SRTP相关媒体信息；

步骤21，UAS收到INVITE消息后发现自身不支持SRTP协商，于是回复488消息通知UAC自身不支持SRTP媒体；

步骤22，UAC重新发送INVITE消息携带RTP相关媒体信息；

步骤23，UAS收到INVITE消息协商RTP相关媒体信息后，发送协商成功的200OK消息，建立非安全的RTP呼叫，实现从SRTP向RTP媒体的回退。

步骤21到步骤23描述了一种比较理想的回退情况。但是在实际的网络应用过程中，一些更为实际的问题又浮现出来。由于各个厂商在具体软件/硬件实现有较大差异，有时候上述回退过程会出现异常。举例来说，部分传统网络设备或者IP电话并不能很好的识别SDP消息体中携带的是自身不支持的SRTP媒体，不少设备或终端会误把SRTP协议识别为RTP协议，这将导致并不能按照上述流程进行协商处理，导致回退失败，呼叫异常拆线，使用者能够直接感知到异常现象是用户振铃摘机后听即刻听到忙音。整个出现异常的流程可以参考图3，具体来说包括以下步骤：

步骤30，UAC向UAS发送INVITE消息，并在SDP消息体中携带SRTP相关媒体信息；

步骤31，由于UAS错误地将SRTP协议识别为RTP协议，其并不会按照图2流程通过488通知UAC不支持SRTP媒体，而是在用户摘机后错误地回复携带RTP相关媒体信息的200OK应答；

步骤32，UAC收到以后会立刻发现协商失败，然后发送BYE消息。

本发明提供一种RTP回退处理机制来解决上述异常问题。以软件实现为例，本发明提供一种RTP回退处理装置，其应用在网络设备或终端上。请参考图3，该装置运行的基本硬件环境包括CPU、内存、非易失性存储器以及其他各种硬件。从逻辑层面来说，该装置包括：协商发起单元以及协商处理单元。请参考图4，在运行过程中该装置执行如下处理流程。

步骤41，初始协商单元向对端发送Invite消息，并在该消息中携带SRTP相关媒体信息以请求协商SRTP呼叫；

步骤42，在从对端接收到携带SRTP相关媒体信息的响应消息时，协商处理单元向对端发送确认消息以完成SRTP协商；

步骤43，从对端接收到携带RTP相关媒体信息的应答消息后，协商处理单元检查请求协商的协议类型与对端回应的协议类型是否一致，如果不一致，通知二次协商单元处理；如果一致，转步骤45处理；

步骤44，二次协商发起单元向对端发送Re-invite消息，并在该消息中携带RTP相关媒体信息以请求协商RTP呼叫；

步骤45，协商处理单元在收到应答消息后确认协商成功，向对端发送确认消息以完成RTP协商。

所谓的相关媒体信息通常可以包括：端口号、地址、音频视频编解码标准（如G.7系列的编解码）等，这些参数的传递以及协商过程属于现有技术，本发明并不进一步扩展介绍。在正常情况下，若本端和对端都支持SRTP，那么协商过程会顺利地进入步骤42完成SRTP协商。当然若本端和对端只有一端是支持SRTP以及RTP的新设备，另一端是只支持RTP的老设备，那么整个协商过程会有两种可能性，一种是老设备发起，另一种是新设备发起。

在实际应用中，若一个不支持SRTP协议的设备发起呼叫，其会作为UAC发送Invite消息到对端（也就是UAS），此时Invite消息中携带的将是RTP相关媒体信息，并不存在回退的问题。当然目前有一种前滚式设计方案，也就是UAC在Invite消息中携带RTP相关媒体信息，但是同时在该消息中携带SRTP标记，用来表明自身支持SRTP，如果对端也支持SRTP，并且也能够识别该SRTP标记，则对端会将自身作为UAC向本端（此时为UAS）发送Invite消息以协商SRTP呼叫，由于双方都支持SRTP，如果其他协商参数没有问题，那么协商就可以成功。但这种方式存在明显的缺陷，首先这要求对端能够识别出这个SRTP标记，而这个标记可能是私有定义的，因此兼容性较差，不容易广泛应用。其次，这样的处理流程缺乏合理性，在协商过程中如果条件允许，应当优先协商安全性更高的SRTP呼叫。假设对端设备是其他厂商制造的，该设备支持SRTP，但不能识别SRTP标记，此时双方协商的结果仍然是RTP。也就是说这种方案会存在明明能够协商出更安全的SRTP呼叫，但结果却协商安全性更低的RTP呼叫；这样的结果显然是用户难以接受的。

在本发明中，首先并不需要引入任何SRTP标记这样的私有定义，整个软件的改进仅仅在首先发起呼叫的作为UAC的新设备/终端即可，对于作为UAS的传统设备/终端来说，回退过程中其并无法感知到自身出错的问题。UAC发送携带SRTP相关媒体信息的INVITE消息给UAS。假设UAS将SRTP错误地识别为RTP，其会直接回复不带SDP的180消息或者183消息，180和183消息的区别是振铃到底是UAC本地产生的还是远端产生的。180消息或183消息是一个临时应答消息，对于Invite消息，UAS必须回应编号为200以上的应答消息，比如说200OK消息。请参考图5，由于UAS回应的200OK消息中携带的协议类型是RTP，该协议类型显然与请求协商的SRTP不一致，此时UAC一端会感知到这样的错误，在现有技术中，UAC会回应ACK然后发送BYE消息。但是本发明在感知到这样的错误之后，会发送Re-invite消息来重新协商RTP实现回退。

Re-invite消息与Invite消息类似，其是在一个已经存在的会话的中再次发送Invite消息，但是双方仍然有一些区别，比如说Invite消息中并没有标准定义的“To Tag”，而Re-invite消息中可以有“To Tag”。Re-invite消息最常用的功能是，在一个媒体协商已经成功的会话中捆绑新的媒体属性或者引入新的会议参与者。在RFC3261中，标准不建议自动产生Re-invite消息，因为其有可能导致网络拥塞。但是本发明是在确认媒体协议类型不一致，也就是媒体协商没有成功的时候才自动产生Re-invite消息，这个Re-invite消息主要目标并不是在当前的会话上捆绑新的媒体，也不是引入新的参与者，而是回退媒体协议类型，从安全的SRTP回退到非安全的RTP，并不是随意产生Re-invite消息，因此不会导致网络拥塞。

UAS收到携带RTP相关媒体信息的Re-INVITE报文，由于UAS支持RTP这种协议类型，如果协商其他环节没有问题，那么协商成功后，UAS会回复200OK，并携带对应的RTP媒体信息。UAC回复ACK，双方更新媒体信息建立起呼叫，顺利地从安全SRTP呼叫回退到非安全的RTP呼叫，回退成功。在整个过程中，首先，对于实施本发明的厂商来说，整个回退过程不需要其他厂商的设备或终端配合，因为回退失败通常是发生在不同厂商的设备/终端之间的，同一个厂商设备/终端之间通常不会发生这种识别错误引发的回退失败。这也就是说，本发明对于实施的厂商而言，不存在兼容性的问题，亦即无需其他厂商进行配合，整个过程只是巧妙地将标准中定义Re-invite消息合理地重新利用起来，利用Re-invite消息起来去解决一个新的问题—安全协商失败同时又无法回退的问题。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims

1.一种RTP回退处理装置，应用于网络设备或者终端上，该装置包括初始协商单元、协商处理单元以及二次协商单元；其特征在于：

2.如权利要求1所述的处理装置，其特征在于：

所述协商处理单元，进一步用于在从对端接收到携带SRTP相关媒体信息的响应消息时，向对端发送确认消息以完成SRTP协商。

3.如权利要求1所述的处理装置，其特征在于：

所述协商处理单元进一步用于：在检查到协议类型一致时，确认协商成功，向对端发送确认消息以完成RTP协商。

4.一种RTP回退处理方法，应用于网络设备或者终端上，其特征在于，该方法包括：

5.如权利要求4所述的处理方法，其特征在于，在所述步骤A之后，还包括：

步骤D、在从对端接收到携带SRTP相关媒体信息的响应消息时，向对端发送确认消息以完成SRTP协商。

6.如权利要求4所述的处理方法，其特征在于：所述步骤B还包括：

在检查到协议类型一致时，确认协商成功，向对端发送确认消息以完成RTP协商。