CN100556040C - 一种会话发起协议消息的发送和接收方法 - Google Patents
一种会话发起协议消息的发送和接收方法 Download PDFInfo
- Publication number
- CN100556040C CN100556040C CNB2006100334332A CN200610033433A CN100556040C CN 100556040 C CN100556040 C CN 100556040C CN B2006100334332 A CNB2006100334332 A CN B2006100334332A CN 200610033433 A CN200610033433 A CN 200610033433A CN 100556040 C CN100556040 C CN 100556040C
- Authority
- CN
- China
- Prior art keywords
- message
- conversation launch
- launch protocol
- protocol message
- head
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明属于通信领域，提供了一种会话发起协议消息的发送和接收方法，所述发送方法包括：A.设置会话发起协议消息，所述会话发起协议消息中包括消息分隔头，所述消息分隔头包括分隔头开始标志；B.发送所述会话发起协议消息。本发明通过在SIP消息间加入消息分隔头对消息进行定界和分隔，提高了接收端SIP消息解码器对SIP消息的定界和解码效率，降低了解码实现难度，同时提高了SIP***性能。
Description
技术领域
本发明属于通信领域，尤其涉及一种基于传输控制协议的会话发起协议消息的发送和接收方法。
背景技术
会话发起协议(Session Initiation Protocol，SIP)是Interne工程任务组(TheInternet Engineering Task Force，IETF)制定的多媒体通信***框架协议之一，它是一个基于文本的应用层控制协议，用于建立、修改和终止IP网上的双方或多方多媒体会话。SIP协议独立于底层协议，即其协议本身可以基于传输控制协议(Transmission Control Protocol，TCP)、用户数据报协议(User DatagramProtocol，UDP)以及流控传送协议(Stream Control Transport Protocol，SCTP)等传输层协议。目前的SIP协议应用中大部分都是基于不可靠的UDP传输层协议传输的，但当消息报文超过网络最大传输单元(Maximum Transmission Unit，MTU)时，即不对UDP报文进行拆包情况下可以传输的最大UDP报文长度，发送端传输层就必须对报文进行拆包，在接收端就必须收到所有报文碎片后才能重新组包，上报给应用层处理。由于UDP本身的不可靠，使得报文某一碎片丢失就会导致发送端必须等待应用层定时器超时才能重新发送。因此一旦消息包长度超过MTU通常都不采用UDP进行数据的传输。SIP协议要求当发送方知道消息报文超过MTU或者在不知道MTU的情况下消息报文超过1400字节，SIP协议的传输必须采用可靠的，面向连接的传输层协议进行数据传输，如TCP、SCTP等。
随着SIP应用的日益增多和业务的日益丰富，业务请求消息中需要携带的信息也越来越多，SIP消息的长度变得越来越长，特别是随着SIP和XML(eXtensible Markup Language，可扩展标记语言)的结合，消息的长度更是增加了很多。因此基于TCP等面向连接的SIP的实现也越来越多。
TCP是面向连接的基于流式服务的可靠的传输层协议，它定义了一系列机制保证通信双方之间的业务数据可靠有序的传输，例如消息重发机制等。它将应用层请求发送的数据逐一、可靠、有序的发送到对端设备。然而在TCP承载应用层业务的时候，并不提供对不同应用层数据报文之间的定界或者分隔的功能，SIP协议以及目前的所有对SIP扩展的协议也都没有为SIP消息承载于TCP时提供对多条消息的定界或者分隔功能。这就使得接收端通过TCP层收到对端发送过来的字节流后无法很容易的知悉一个SIP消息是从哪里开始和在哪里结束，现有技术中一个解决的办法是根据SIP协议报文的语法格式、消息特定头域指示的消息体的长度和消息语法格式定义的消息体的起始位置等信息来获悉一个SIP消息是从哪里开始和在哪里结束。具体处理流程如下：
1、从对端收到的应用层数据第一个字节认为是一个SIP消息的开始位置。
2、根据SIP协议报文的语法格式从SIP消息的开始位置起对数据流进行尝试解码：
2.1如果解码成功而且已经获得了某些信息(如前面提到的消息特定头域指示的消息体的长度和消息语法格式定义的消息体的起始位置等)，那么接收端就可以根据这些信息知悉消息体的结束位置。
2.1a如果结束位置之前的所有数据都已经收到并解码，那么接收端按照SIP协议对消息进行处理。
2.1b如果结束位置之前的所有数据没有全部收到，那么接收端必须等待结束位置之前的所有数据全部收到并解码，再按照SIP协议对消息进行处理。
2.2如果解码失败，或者根据已经获得的信息无法定位准确的消息结束位置，那么接收端必须再等待收到更多的数据后重复尝试处理。由于必须等待更多的数据，接收端可以按照如下方式进行处理：
2.2a丢弃当前解码状态，缓存未处理的数据并在收到更多的数据后重新对消息进行解码。
2.2b缓存当前解码状态，等待收到更多的数据后继续解码过程。
3、一个消息的结束位置的下一个字节认为是下一个消息的开始位置，从这个起始位置重复第二个步骤。
在2.2a的实现方式中，因为解码器无法知道消息的长度和结束位置，接收端只能对已经接收到的数据进行解码。如果当前正在解码消息的后续数据没有全部到达接收端和解码器的缓冲区中，那么在获取到更多的数据后解码器必须重新尝试解码。在消息包比较长的时候这种尝试发生的十分频繁，在消息包长度比较小的时候为了提高***的响应速度通常也需要对消息碎片进行频繁的解码尝试。这样对接收到的消息碎片反复进行尝试解码会降低SIP***的性能。
采用2.2b的方式不用每次对已经收到的所有消息内容进行重新解码，只需要对最近一次收到的新数据进行解码，但该种解码器实现非常复杂，而且缓存解码状态会额外增加***的资源占用和降低***的可靠性。
发明内容
本发明的目的在于提供一种会话发起协议消息的发送方法，旨在于解决现有技术中在未得到消息特定头域指示的消息体的长度和消息语法格式定义的消息体的起始位置时，接收端解码器不知道一条SIP消息的结束位置而频繁尝试解码造成的解码效率低和缓存解码状态造成的解码实现复杂的问题。
本发明的另一目的在于提供一种会话发起协议消息的接收方法。
本发明的目的是这样实现的：
一种会话发起协议消息的发送方法，所述方法包括下述步骤：
A.设置会话发起协议消息，所述会话发起协议消息中包括消息分隔头，所述消息分隔头包括分隔头开始标志，其中相邻两个分割头开始标志之间的部分即为会话发起协议消息；
B.发送所述会话发起协议消息。
所述消息分隔头进一步包括会话发起协议消息长度信息、消息分隔头版本信息、分隔头可选参数或者分隔头可选参数的长度。
所述步骤A之前进一步包括：
F.查询接收端能否对所述会话发起协议消息进行解码的能力信息。
所述步骤F进一步包括以下步骤：
F11.动态主机配置协议DHCP服务器设置用于标识接收端所述能力信息的子选项；
F12.发送端向动态主机配置协议DHCP服务器发送查询请求；
F13.动态主机配置协议DHCP服务器返回带有所述子选项的响应消息。
所述步骤F进一步包括以下步骤：
F21.设置用于标识接收端所述能力信息的资源记录类型；
F22.发送端向域名***DNS服务器发送所述资源记录类型的查询请求；
F23.域名***DNS服务器返回与所述资源记录类型对应的响应消息。
所述步骤F进一步包括以下步骤：
F31.设置用于标识接收端所述能力信息的头域或消息体类型；
F32.发送端向接收端发送OPTIONS请求；
F33.接收端返回携带所述头域或消息体类型的响应消息。
所述方法进一步包括接收端在消息交互过程中主动向发送端报告自身能否对所述会话发起协议消息进行解码的能力信息的步骤。
所述接收端能否对所述会话发起协议消息进行解码的能力信息通过扩展Contact头域的统一资源标识URI参数或Via头域的参数携带。
所述能力信息包括消息分隔支持信息，所述消息分隔支持信息包括支持并启用对所述会话发起协议消息的解码、支持但不启用对所述会话发起协议消息的解码或者不支持对所述会话发起协议消息的解码。
当所述消息分隔支持信息为支持并启用对所述会话发起协议消息的解码时，所述能力信息进一步包括支持的消息分隔头的版本、分隔头开始标志或者分隔头开始标志长度。
一种会话发起协议消息的接收方法，所述方法包括下述步骤：
A.接收会话发起协议消息，所述会话发起协议消息中包括消息分隔头，所述消息分隔头包括分隔头开始标志，其中相邻两个分割头开始标志之间的部分即为会话发起协议消息；
B.根据所述消息分隔头，对所述会话发起协议消息进行解码。
所述步骤B进一步包括以下步骤：
B1.在所述接收到的会话发起协议消息中，查找到两个相邻的消息分隔头开始标志后，对两个消息分隔头开始标志之间的消息内容进行解码。
所述消息分隔头进一步包括会话发起协议消息长度信息。
所述步骤B进一步包括以下步骤：
B2.根据分隔头中消息长度信息读取相应长度的消息内容，对所述消息内容进行解码。
所述消息分隔头进一步包括消息分隔头版本信息、分隔头可选参数或者分隔头可选参数的长度信息。
本发明通过在SIP消息间加入消息分隔头对消息进行定界和分隔，提高了接收端SIP消息解码器对SIP消息的定界和解码效率，降低了解码实现难度，同时提高了SIP***性能。
附图说明
图1是加入消息分隔头后的SIP消息格式示意图；
图2是加入消息分隔头后的一段字节流片断示例图；
图3是本发明提供的第一实施例的实现流程图；
图4是采用OPTIONS查询对端能力的实现流程图；
图5是本发明提供的第二实施例的实现流程图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
本发明通过在SIP消息间加入消息分隔头对消息进行分隔，提高了接收端SIP消息解码器对SIP消息的定界和解码效率。
图1示出了加入消息分隔头后的SIP消息格式。
消息分隔头为一固定的或者互通双方预先约定的包含一个或多个字节的特殊的码流，包含分隔头开始标志。以下为一个简单的分隔头0xC0C0：
当接收端通过TCP协议接收到数据流后就可以首先查找分隔头开始标志，查找到消息分隔头开始标志后继续查找下一个消息分隔头开始标志，相邻两个分隔头标志之间的部分即为SIP消息。这样，消息接收端通过搜索特征字节来确定一个完整的SIP消息，提高对SIP消息的解码效率。
更优的，消息分隔头还可以包含如下信息：
1、消息分隔头的版本，例如版本号为0；
2、消息长度指示，为一固定长度的无符号整数值，或者采用ASN.1(AbstractSyntax Notation one，抽象句法记法一)整数编码等技术编码后的整数值，消息接收端查找到消息分隔头开始标志后确定SIP消息的开始位置，然后根据消息长度确定SIP消息的结束位置，接收端不需要如前所述不停的检索收到的数据流以获取下一个分隔符实现对SIP消息的定界，进一步提高了对SIP消息的解码效率；
3、分隔头可选参数，例如分隔头错误校验码或用于完成对消息进行加密压缩、TCP连接维护等功能的参数；
4、分隔头中可选参数的长度，当无此参数，默认分隔头可选参数为1个节。
在具体实现中，实现者可以根据需要对以上信息进行适当的筛选和替换等，以下为一个典型的分隔头：
图2示出了加入以上分隔头后的一段字节流片断，其中阴影部分6个元素为消息分隔头的内容，消息分隔头之前的部分为前一个SIP消息的末尾部分消息内容，分隔头之后为下一个SIP消息开始部分消息内容。
作为本发明的第一实施例，SIP消息发送端在向对端发送消息时判断对端是否支持并启用对SIP消息分隔头的解码，如果是，那么消息发送端在发送每一个SIP消息之前生成消息分隔头并通过TCP向对端发送，接收端通过消息分隔头对SIP消息的定界可以在接收到一条完整的消息后一次性解码。否则，消息发送端只需要通过TCP连接将待发送的消息发送到对端，接收端对接收到的数据包不断尝试解码，直到找到消息的结束位置，才解码出一条完整的消息，如前所述。
在本实施例下的一个典型应用如图3所示，终端a(user_a)通过代理服务器(Proxy.domain_a.com、Proxy.domain_b.com)向终端b(user_b)发起会话，具体实现流程详述如下：
1.user_a和user_b分别在注册之前采用动态主机配置协议(Dynamic HostConfiguration Protocol，DHCP)查询的方式来动态获取代理服务器Proxy.domain_a.com和Proxy.domain_b.com的地址、能力以及互通参数等信息。
所以在DHCP服务器的记录中加入代理服务器是否支持对SIP消息分隔头解码的能力信息，在查询过程中就可以将代理服务器的此能力信息返回给终端，终端在使用TCP与代理服务器进行互通之前就可以决策是否发送带有消息分隔头的SIP消息。IETF文档draft-lijun-dhc-clf-nass-option-01.txt中定义了通过DHCP查询后返回信息的格式，但只定义了子选项标识为1和2的参数和各比特位的含义。由于其格式具有很灵活的扩展性，所以实现者可以通过定义更多的参数来携带更多的选项信息。本发明定义的新的参数如下：
SubOpt Len Sub-option Value
+-----+-----+-----.........................................----+
|TBD |N|SIP消息分隔支持信息|版本|分隔头开始标志长度|分隔头开始标志|
+-----+-----+-----.........................................----+
其中，SubOpt为因特网编号分配委员会(Internet Assigned NumbersAuthority，IANA)分配给该参数的参数类型，即子选项标识，可以为3或4等，但不能为已有的1或2，此处为待定(TBD)；
Len为实际消息的长度；
SIP消息分隔支持信息，即是否支持对含有消息分隔头的SIP消息进行解码的标志，其取值包括支持但不启用、支持并启用和不支持三种可能；
版本，当前支持的SIP消息分隔头的版本；
分隔头开始标志长度，SIP消息分隔头开始标志长度；
分隔头开始标志，SIP消息分隔头开始标志，例如0xC0C0。
用户可以根据需要对以上信息进行适当的筛选，也可以根据参数之间的关系进行适当的取值复用。
在本发明的另一个实施例中，还可以通过域名***(Domain Name System，DNS)查询的方式获取对端是否支持并启用对SIP消息分隔头解码的能力信息。RFC3263定义了SIP协议中通过DNS服务器的服务定位(Service location，SRV)和名称权威指针(Naming Authority Pointer，NAPTR)两种资源记录(ResourceRecord，RR)类型来定位下一跳服务器地址以及获取一些互通参数的机制，本发明设置一种新的资源记录类型SIP-MSG-SEPARATOR用于查询目的设备是否支持对SIP消息分隔头解码的能力信息。该资源记录的实际记录数据(RecordData，RDATA)包含如前面所述的SIP消息分隔支持信息、版本、分隔头开始标志长度以及分隔头开始标志等信息。
在本发明的另一个实施例中，还可以在发送消息之前通过SIP协议定义的OPTIONS来查询对端是否支持并启用对SIP消息分隔头的解码。如图4所示，在OPTIONS请求消息的200 OK响应消息中可以通过新增一个扩展头域或者定义一种新的消息体类型用于返回SIP消息分隔支持信息、版本、分隔头开始标志长度以及分隔头开始标志等信息。
扩展头域的ABNF(Augmented Backus Normal Form，扩展巴克斯范式)定义如下：
msg-separator-hdr-header＝″msg-separator″HCOLON msg-separator-hdr-val*(COMMA msg-separator-hdr-param)
msg-separator-hdr-val＝″enabled″/″disabled″/″unsupported″
msg-separator-hdr-param＝msg-separator-hdr-version/msg-separator-hdr-len/msg-separator-hdr-data
msg-separator-hdr-version＝″version″″＝″1*DIGIT
msg-separator-hdr-len＝″separator-len″″＝″1*DIGIT
msg-separator-hdr-data＝″separator″″＝″1*msg-separator-hdr-data-char
msg-separator-hdr-data-char＝DIGIT/″A″/″B″/″C″/″D″/″E″/″F″/″a″/″b″/″c″/″d″/″e″/″f″
其中，msg-separator-hdr-val的取值包括enabled(表示支持并启用对含有消息分隔头的SIP消息的解码)、disabled(表示支持但不启用对含有消息分隔头的SIP消息的解码)以及unsupported(表示不支持对含有消息分隔头的SIP消息的解码)三种可能；当该参数值为“enabled”时，msg-separator-hdr-ver、msg-separator-hdr-len以及msg-separator-hdr-data的值有意义而且会被使用；当该参数值为“disabled”时，msg-separator-hdr-ver、msg-separator-hdr-len以及msg-separator-hdr-data的值有意义但不会被使用；当该参数值为“unsupported”时，msg-separator-hdr-ver、msg-separator-hdr-len以及msg-separator-hdr-data的值无意义。
msg-separator-hdr-ver表示该URI资源支持SIP消息分隔头的最高版本，当无此参数时默认值为1。
msg-separator-hdr-len表示该URI资源建议使用的分隔头开始标志的字节数。当有此参数但无参数msg-separator-hdr-data时，分隔头开始标志为指定字节数的，每一字节为0xC0的特殊分隔头开始标志。
msg-separator-hdr-data表示该URI资源建议使用的分隔头开始标志。当有此参数但无参数sip-msg-separator-hdr-len时，分隔头开始标志的长度由此参数的长度确定。
例如：
msg-separator：enabled；version＝2；separator-len＝2；separator＝C0C0
表示消息接收端支持并启用对含有消息分隔头的SIP消息的解码，并且其消息头版本号为2，分隔头长度为2字节，分隔头开始标记为0xC0C0。
msg-separator：disabled
表示消息接收端支持但不启用对含有消息分隔头的SIP消息的解码。
msg-separator：unsupported
表示消息接收端不支持对含有消息分隔头的SIP消息的解码。
定义新的消息体类型用于返回如前所述的SIP消息分隔支持信息、版本、分隔头开始标志长度以及分隔头开始标志等信息时，消息体内容和格式定义如下：
MIME media type name(MIME媒体类型)：application
MIME subtype name(MIME媒体子类型)：message-separator
Required parameters(必选参数)：none(无)
Optional parameters(可选参数)：none(无)
Encoding scheme编码方式：ABNF(文本ABNF方式)
根据以上规则，一个消息体msg-separator-body的ABNF编码格式定义如下：
msg-separator-body＝msg-separator-body-param
*(CRLF msg-separator-body-param)
msg-separator-body-param＝msg-separator-body-flag
/msg-separator-body-ver
/msg-separator-body-len
/msg-separator-body-data
msg-separator-body-flag＝″flag″″＝″msg-separator-body-val
msg-separator-body-val＝″enabled″/″disable d″/″unsupported″
msg-separator-body-ver＝″ver″＝″1*DIGIT
msg-separator-body-len＝″separator-len″″＝″1*DIGIT
msg-separator-body-data＝″separator″″＝″1*msg-separator-body-data-char
msg-separator-body-data-char＝DIGIT/″A″/″B″/″C″/″D″/″E″/″F″
/″a″/″b″/″c″/″d″/″e″/″f″
其中，msg-separator-body-val的取值包括enabled、disabled以及unsupported三种可能；当该参数值为“enabled”时，msg-separator-body-ver、msg-separator-body-len以及msg-separator-body-data的值有意义而且会被使用；当该参数值为“disabled”时，msg-separator-body-ver、msg-separator-body-len以及msg-separator-body-data的值有意义但不会被使用；当该参数值为“unsupported”时，msg-separator-body-ver、msg-separator-body-len以及msg-separator-body-data的值无意义。
msg-separator-body-ver表示该URI资源支持SIP消息分隔头的最高版本，当无此参数时默认值为1。
msg-separator-body-len表示该URI资源建议使用的分隔头开始标志的字节数。当有此参数但无参数msg-separator-body-data时分隔头开始标志为指定字节数的，每一字节为0xC0的特殊分隔头开始标志。
msg-separator-body-data表示该URI资源建议使用的分隔头开始标志。当有此参数但无参数msg-separator-body-len时分隔头开始标志的长度由此参数的长度确定。
例如：
Content-Type：application/message-separator
flag＝enabled
ver＝2
separator-len＝2
separator＝C0C0
表示消息接收端支持并启用对含有消息分隔头的SIP消息的解码，并且其版本号为2，分隔头长度为2字节，分隔头开始标记为0xC0C0。
2.user_a和user_b分别向Proxy.domain_a.com和Proxy.domain_b.com发起注册请求消息(REGISTER)。
本发明在REGISTER消息的Contact头域的URI参数中携带自身是否支持并启用对含有消息分隔头的SIP消息进行解码的能力信息，这样Proxy.domain_b.com在向被叫user_b发消息时就可以根据其注册地址中的参数获取其能力信息并决策是否发送含有消息分隔头的SIP消息。
3.Proxy.domain_a.com和Proxy.domain_b.com分别向user_a和user_b返回状态码为200的成功响应信号(OK)。
4.user_a根据获取到的Proxy.domain_a.com的能力信息，就可以本地决策是否发送含有消息分隔头的SIP消息，向Proxy.domain_a.com发送呼叫建立请求消息(INVITE)，请求呼叫domain_b.com域的user_b。
5.Proxy.domain_a.com采用OPTIONS查询Proxy.domain_b.com是否支持并启用对含有消息分隔头的SIP消息进行解码的能力信息。
6.Proxy.domain_b.com向Proxy.domain_a.com返回状态码为200的成功响应消息，并携带是否支持并启用对含有消息分隔头的SIP消息进行解码的能力信息。
7.Proxy.domain_a.com获取到Proxy.domain_b.com是否支持并启用对含有消息分隔头的SIP消息进行解码的能力信息后，就可以本地决策是否发送含有消息分隔头的SIP消息，并向Proxy.domain_b.com转发INVITE消息。
8.Proxy.domain_b.com根据user_b注册地址中的参数确定user_b是否支持并启用对含有消息分隔头的SIP消息进行解码的能力，本地决策是否发送含有消息分隔头的SIP消息，并向user_b转发INVITE消息。
9.user_b向Proxy.domain_b.com返回状态码为180的临时响应消息(Ringing)。
……
在后续信令交互过程中，关于如何获取对端的能力信息并发送相应消息的原理相同，不再赘述。
本发明在REGISTER消息的发送和INVITE消息的转发过程中，各设备可以通过扩展Contact头域的URI参数、Via头域的参数以及其它一些与SIP实体地址或标识相关的一些头域或者头域中的参数来携带自身是否支持并启用对含有消息分隔头的SIP消息进行解码的能力信息，这样就可以在后续的消息接收过程中便于对端决定是否发送含有消息分隔头的SIP消息。这种扩展SIP消息URI参数的ABNF描述如下：
uri-parameter＝transport-param/user-param/method-param/ttl-param/maddr-param/lr-param/sip-msg-separator-param/other-param
其中sip-msg-separator-param为本发明扩展的参数，其余部分为RFC3261中uri-parameter的定义，本发明在此引用，不再赘述。
sip-msg-separator-param＝sip-msg-separator-flag/sip-msg-separator-version/sip-msg-separator-len/sip-msg-separator-data
sip-msg-separator-param-flag＝″msg-separator-flag″″＝″sip-msg-separator-val
sip-msg-separator-val＝″enabled″/″disabled″/″unsupported″
sip-msg-separator-version＝″msg-separator-ver″″＝″1*DIGIT
sip-msg-separator-len＝″msg-separator-len″″＝″1*DIGIT
sip-msg-separator-data＝″msg-separator″″＝″1*sip-msg-separator-data-char
sip-msg-separator-data-char＝DIGIT/″A″/″B″/″C″/″D″/″E″/″F″/″a″/″b″/″c″/″d″/″e″/″f″
关于sip-msg-separator-param中各参数的定义与前例中msg-separator-body-param中的参数类似，不再赘述。
例如：
sip：proxy.example.com；msg-separator-flag＝enabled
表示sip：proxy.example.com实体支持并启用对含有消息分隔头的SIP消息进行解码，并且其分隔头版本号默认为1，分隔头长度默认为2字节，分隔头开始标记默认为0xC0C0。
以下为带有扩展参数的一些常见SIP头域：
Record-Route：<sips:ssl.example.com；lr；msg-separator-flag＝enabled>
Route：<sips:ssl.example.com；lr；msg-separator-flag＝enabled>
Contact：<sips:[email protected]；msg-separator-flag＝enabled>
Refer-To：sip:[email protected]；msg-separator-flag＝enabled
In-Reply-To：[email protected]；msg-separator-flag＝enabled
Reply-To：Bob<sip:[email protected]；msg-separator-flag＝enabled>
Service-Route：sip:[email protected]；msg-separator-flag＝enabled
Service-Route：sip:[email protected]；lr；msg-separator-flag＝enabled
Path：sip:pcscfl.example.com；lr；msg-separator-flag＝enabled
相应的扩展SIP消息Via头域参数的ABNF描述如下：
Via：SIP/2.0/TCPclient.atlanta.example.com：5061；branch＝z9hG4bK7；msg-separator-flag＝enabled
在本发明的一优选实施例中，发送端获得对端是否支持并启用对含有消息分隔头的SIP消息进行解码的能力信息后保存下来，在下次向对端发送消息之前就可以直接决策是否发送含有消息分隔头的SIP消息，而不需要每次发送消息之前重新向对端查询能力信息。
作为本发明的第二实施例，SIP消息发送端不判断对端是否支持并启用对含有消息分隔头的SIP消息进行解码的能力，根据自身的能力发送有消息分隔头或没有消息分隔头的SIP消息，而由SIP消息接收端自适应接收消息发送端发送的消息，下面以消息分隔头包含分隔头开始标志、分隔头可选参数以及会话发起协议消息长度信息为例进行说明，具体的解码实现流程如图5所示，详述如下：
在步骤S501中，SIP消息接收端判断当前收到的字节流是否是以消息分隔头开始标志开始(例如0xC0C0)，是则执行步骤S502，否则执行步骤S505；
在步骤S502中，接收端对分隔头可选参数解码后，对支持的分隔头可选参数按照相关规范做相应的处理；
本发明暂未定义任何可选参数，但随着应用的增多，有可能需要通过可选参数提供更多的增强功能。每一个可选参数对接收端处理消息的方式以及其它操作都将由定义可选参数的文档定义。
在步骤S503中，根据分隔头中指示的SIP消息长度从消息头后的第一个字节开始从解码器的字节流缓冲区中读取相应长度的消息内容，对所述消息内容进行解码，然后后按照SIP协议规范进行处理；
在步骤S504中，从解码器的字节流缓冲区中读取后续字节流并重复步骤501；
在步骤S505中，不断读取缓冲区内的字节流，如背景技术所介绍的重复尝试解码直到解码出一个完整的SIP消息，继续执行步骤S504。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
Claims (15)
1、一种会话发起协议消息的发送方法，其特征在于，所述方法包括下述步骤：
A.设置会话发起协议消息，所述会话发起协议消息中包括消息分隔头，所述消息分隔头包括分隔头开始标志，其中相邻两个分割头开始标志之间的部分即为会话发起协议消息；
B.发送所述会话发起协议消息。
2、如权利要求1所述的会话发起协议消息的发送方法，其特征在于，所述消息分隔头进一步包括会话发起协议消息长度信息、消息分隔头版本信息、分隔头可选参数或者分隔头可选参数的长度。
3、如权利要求1所述的会话发起协议消息的发送方法，其特征在于，所述步骤A之前进一步包括：
F.查询接收端能否对所述会话发起协议消息进行解码的能力信息。
4、如权利要求3所述的会话发起协议消息的发送方法，其特征在于，所述步骤F进一步包括以下步骤：
F11.动态主机配置协议DHCP服务器设置用于标识接收端所述能力信息的子选项；
F12.发送端向动态主机配置协议DHCP服务器发送查询请求；
F13.动态主机配置协议DHCP服务器返回带有所述子选项的响应消息。
5、如权利要求3所述的会话发起协议消息的发送方法，其特征在于，所述步骤F进一步包括以下步骤：
F21.设置用于标识接收端所述能力信息的资源记录类型；
F22.发送端向域名***DNS服务器发送所述资源记录类型的查询请求；
F23.域名***DNS服务器返回与所述资源记录类型对应的响应消息。
6、如权利要求3所述的会话发起协议消息的发送方法，其特征在于，所述步骤F进一步包括以下步骤：
F31.设置用于标识接收端所述能力信息的头域或消息体类型；
F32.发送端向接收端发送OPTIONS请求；
F33.接收端返回携带所述头域或消息体类型的响应消息。
7、如权利要求3所述的会话发起协议消息的发送方法，其特征在于，所述方法进一步包括接收端在消息交互过程中主动向发送端报告自身能否对所述会话发起协议消息进行解码的能力信息的步骤。
8、如权利要求7所述的会话发起协议消息的发送方法，其特征在于，所述接收端能否对所述会话发起协议消息进行解码的能力信息通过扩展Contact头域的统一资源标识URI参数或Via头域的参数携带。
9、如权利要求3至8任一权利要求所述的会话发起协议消息的发送方法，其特征在于，所述能力信息包括消息分隔支持信息，所述消息分隔支持信息包括支持并启用对所述会话发起协议消息的解码、支持但不启用对所述会话发起协议消息的解码或者不支持对所述会话发起协议消息的解码。
10、如权利要求9所述的会话发起协议消息的发送方法，其特征在于，当所述消息分隔支持信息为支持并启用对所述会话发起协议消息的解码时，所述能力信息进一步包括支持的消息分隔头的版本、分隔头开始标志或者分隔头开始标志长度。
11、一种会话发起协议消息的接收方法，其特征在于，所述方法包括下述步骤：
A.接收会话发起协议消息，所述会话发起协议消息中包括消息分隔头，所述消息分隔头包括分隔头开始标志，其中相邻两个分割头开始标志之间的部分即为会话发起协议消息；
B.根据所述消息分隔头，对所述会话发起协议消息进行解码。
12、如权利要求11所述的会话发起协议消息的接收方法，其特征在于，所述步骤B进一步包括以下步骤：
B1.在所述接收到的会话发起协议消息中，查找到两个相邻的消息分隔头开始标志后，对两个消息分隔头开始标志之间的消息内容进行解码。
13、如权利要求11所述的会话发起协议消息的接收方法，其特征在于，所述消息分隔头进一步包括会话发起协议消息长度信息。
14、如权利要求13所述的会话发起协议消息的接收方法，其特征在于，所述步骤B进一步包括以下步骤：
B2.根据分隔头中消息长度信息读取相应长度的消息内容，对所述消息内容进行解码。
15、如权利要求11所述的会话发起协议消息的接收方法，其特征在于，所述消息分隔头进一步包括消息分隔头版本信息、分隔头可选参数或者分隔头可选参数的长度信息。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2006100334332A CN100556040C (zh) | 2006-01-26 | 2006-01-26 | 一种会话发起协议消息的发送和接收方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CNB2006100334332A CN100556040C (zh) | 2006-01-26 | 2006-01-26 | 一种会话发起协议消息的发送和接收方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101009696A CN101009696A (zh) | 2007-08-01 |
| CN100556040C true CN100556040C (zh) | 2009-10-28 |
Family
ID=38697825
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CNB2006100334332A Expired - Fee Related CN100556040C (zh) | 2006-01-26 | 2006-01-26 | 一种会话发起协议消息的发送和接收方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN100556040C (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102036232B (zh) * | 2010-12-17 | 2015-12-09 | 中兴通讯股份有限公司 | 一种基站数据发送、接收方法及装置 |
| EP3297191A4 (en) * | 2015-07-10 | 2018-06-13 | Huawei Technologies Co., Ltd. | Protocol frame transmission method, device, node apparatus and system |
-
2006
- 2006-01-26 CN CNB2006100334332A patent/CN100556040C/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CN101009696A (zh) | 2007-08-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10855585B2 (en) | Session initiation protocol stack optimisation | |
| EP1929712B1 (en) | Sip header reduction | |
| US8001189B2 (en) | Routing of network messages | |
| US6888828B1 (en) | System and method for providing at least one service obtained from a service network for a user in a packet switched communication network | |
| EP1266503B1 (en) | Processing network communication control messages | |
| KR100487124B1 (ko) | 세션 이니세이션 프로토콜 시스템의 세션 정보 처리 방법및 그 기록매체 | |
| Camarillo et al. | The session description protocol (SDP) grouping framework | |
| JP5043392B2 (ja) | Ｓｉｐ通信セッションをセットアップする方法、並びに、そのシステム及びコンピュータ・プログラム | |
| US20050111467A1 (en) | Method and apparatus for configuring and controlling network resources in content delivery with distributed rules | |
| US20050185672A1 (en) | IPv6/IPv4 translator | |
| CN106850681B (zh) | 用于传递消息的方法和*** | |
| JP2009105903A (ja) | パケットフローに基づくセッションサービスの適用 | |
| JP2007128503A (ja) | ネットワーク資源を発見する手法 | |
| JP4927101B2 (ja) | 異種通信ノードを特徴付けるための方法およびシステム | |
| Cha et al. | A mobility link service for ndn consumer mobility | |
| EP2068524A1 (en) | A method and a system for acquiring the transmission path of the sip message | |
| Camarillo | Compressing the Session Initiation Protocol (SIP) | |
| US20090106428A1 (en) | Service intermediary Addressing for real time composition of services | |
| CN100556040C (zh) | 一种会话发起协议消息的发送和接收方法 | |
| KR100544195B1 (ko) | 모바일 ＩＰｖ６ 상에서의 세션 설정 프로토콜을 이용한세션 설정 방법 및 시스템 | |
| Herrero et al. | Application layer | |
| Nesser et al. | Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards Track and Experimental Documents | |
| JP4839620B2 (ja) | 呼制御システム、呼制御方法、および呼制御プログラム | |
| Nurmela | Session initiation protocol | |
| Pauly et al. | TAPS Working Group B. Trammell Internet-Draft ETH Zurich Intended status: Informational C. Perkins Expires: March 12, 2018 University of Glasgow |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20091028 Termination date: 20150126 |
|
| EXPY | Termination of patent right or utility model |