CN1870639A - 初始会话协议消息编码能力的协商方法及装置 - Google Patents
初始会话协议消息编码能力的协商方法及装置 Download PDFInfo
- Publication number
- CN1870639A CN1870639A CN 200510124149 CN200510124149A CN1870639A CN 1870639 A CN1870639 A CN 1870639A CN 200510124149 CN200510124149 CN 200510124149 CN 200510124149 A CN200510124149 A CN 200510124149A CN 1870639 A CN1870639 A CN 1870639A
- Authority
- CN
- China
- Prior art keywords
- sip message
- message
- equipment
- code capacity
- sip
- 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.)
- Granted
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种SIP消息编码方式的协商方法，该方法由发送SIP消息的设备在SIP消息中携带本设备的SIP消息编码能力信息；接收所述SIP消息的目标设备获取该SIP消息中携带的SIP消息编码能力信息，并在返回的SIP消息中携带本目标设备的SIP消息编码能力信息；所述发送SIP消息的设备从所述目标设备发送的SIP消息中获取SIP消息编码能力信息。本发明还同时公开了一种通信装置。
Description
技术领域
本发明涉及通信技术领域，尤其涉及一种初始会话协议(SIP)消息编码能力的协商方法及其装置。
背景技术
SIP是IETF制定的多媒体通信系统框架协议之一，它是一个基于文本的应用层控制协议，独立于底层协议，用于建立、修改和终止IP网上的双方或多方多媒体会话。
目前SIP协议采用文本的编码方式，这种方式使得SIP协议与其他同等功能的协议相比较具有非常好的可读性以及非常强大的扩展能力。但同样文本编码方式也为SIP协议带来了一些先天性的不足。主要表现在：
1、SIP协议消息过长，影响服务质量和浪费网络资源。
由于采用文本方式，SIP协议的制定者在制定SIP协议字段名称以及参数取值时都普遍使用所表述含义的自然语言字符串或者简单的缩写字符串，这使得在同等条件下为了表示一个简单的含义，SIP协议往往要使用比二进制编码协议多非常多比特位的消息内容，二进制编码协议中只需几个字节就能完全表达的含义如果使用SIP协议就必须使用几十甚至几百个字节。在无线领域的应用中由于空中接口速率通常都比较低，SIP协议的过长会严重影响对无线终端请求的响应速度以及服务质量；并且随着SIP协议应用爆炸式的增长，也会严重浪费网络资源。
2、严重影响网络服务器的性能和容量。
网络服务器在对文本协议消息进行处理之前必须首先将文本协议转换为内部可以识别的内码表示的消息(即消息的解码过程)，而这个过程其实是对文本字符串的语法分析和语义分析。对文本字符串进行语法分析的过程本身就非常耗费系统资源，因此文本编码的协议的处理效率比二进制编码协议的处理效率和性能低很多。
从目前SIP协议实施的实际情况来看，SIP消息的解码过程已经占据了整个系统对SIP消息以及业务处理过程中所耗费的系统资源的50％以上(包括CPU占用时间以及对内存的消耗)。
发明内容
本发明提供一种SIP消息编码能力的协商方法及装置，以解决现有技术中设备之间只能采用文本方式编码而且不能进行SIP消息编码能力协商，存在浪费网络资源和影响网络性能的问题。
本发明提供以下技术方案：
一种SIP消息编码能力的协商方法，包括以下步骤：
发送SIP消息的设备在SIP消息中携带本设备的SIP消息编码能力信息；
接收所述SIP消息的目标设备获取该SIP消息中携带的SIP消息编码能力信息，并在返回的SIP消息中携带本目标设备的SIP消息编码能力信息；
所述发送SIP消息的设备从所述目标设备发送的SIP消息中获取SIP消息编码能力信息。
根据上述方法：
所述SIP消息传送路径上的设备在向目标设备侧发送接收到的SIP消息时，在该SIP消息中加入本设备的SIP消息编码能力。
发送SIP消息的设备在获知接收所述SIP消息的相邻设备的SIP消息编码能力时，选择本设备和所述相邻设备支持的编码能力对所述SIP消息编码。
设备在发送SIP消息前，获知与相邻设备之间无共同支持的SIP消息编码能力，则拒绝与所述SIP消息相关的业务请求。
若所述SIP消息中用于携带SIP消息编码能力的头域内无编码格式信息，则接收到该SIP消息的设备确定发送该SIP消息的设备只支持发送SIP消息所使用的编码能力。
发送SIP消息的设备在生成路由列表时，保持每一个路由地址的编码格式信息；并且在后续生成的请求消息的路由列表中包含路由路径上的网络设备地址及其SIP消息编码能力。
所述设备在发送后续请求消息的响应消息时，根据下一跳路地址所对应的网络设备的SIP消息编码能力、本设备的SIP消息编码能力和本地策略选用编码方式生成响应消息。
若发送SIP消息的设备能够得到下一跳设备的SIP消息编码能力，则在发送SIP消息时根据本地策略，选择本设备和下一跳设备支持的编码方式对消息进行编码。
所述SIP消息传送路径上的设备将本设备支持的所有SIP消息编码能力加入到所述SIP消息中；或者，仅将本设备及相邻网络设备均支持的SIP消息编码能力加入到所述SIP消息中；或者，根据本地配置的策略将本设备的SIP消息编码能力加入到所述SIP消息中。
所述SIP消息传送路径上的设备在发送后续请求消息或请求消息的响应消息时，根据相邻设备的SIP消息编码能力、接收到的消息所采用有SIP消息编码方式，以及自身SIP消息编码能力和本地策略中的部分或全部信息，选择编码方式对转发的消息进行编码。
发送SIP消息的设备的SIP消息编码能力被用户禁止时，在发送的SIP消息中将不包含被禁止的编码能力。
参与SIP消息编码能力协商的设备，根据本设备和相邻设备的SIP消息编码能力，上一次收到的SIP消息所使用的编码方式，以及本地策略选择该会话可使用的编码方式和各编码方式的优先级中的部分或全部信息，确定最终使用SIP消息的编码方式。
各编码方式的优先级可由最短消息长度、最快编解码速度、最小系统要求或依据相邻设备的SIP消息编码能力优先级顺序确定，或通过用户指定方式确定。
所述设备在经过本地策略得到可使用的编码方式以及编码方式的优先级顺序后，在向SIP消息中填写SIP消息编码能力时按优先级顺序排列编码能力。
设备在发起注册请求时在该请求中携带地址及SIP消息编码能力，注册服务器在收到注册请求消息后保存所述注册地址及SIP消息编码能力。
转发所述注册请求的设备将本设备的SIP消息编码能力加入注册请求消息中。
所述转发注册请求的设备在向请求注册的设备返回注册请求的成功响应消息时，在该消息中加入本设备的SIP消息编码能力。
在参与SIP消息编码能力协商过程中，通过SIP消息的Contact和Via头域中的扩展参数携带呼叫状态代理客户端(UAC)设备的SIP消息编码能力，并通过SIP消息中Contact头域中的扩展参数携带呼叫状态代理服务器端(UAS)设备的SIP消息编码能力。
通过SIP消息中的Via头域和Record-Route头域，携带转发SIP消息的呼叫状态代理服务器的SIP消息编码能力；通过SIP消息中的Via头域，携带转发SIP消息的其他的代理服务器的SIP消息编码能力。
UAS设备在生成响应消息时，将所述SIP消息中Via头域内的地址以及其中所有的参数复制到响应消息中。
UAS设备在生成响应消息时，还将所述SIP消息中Record-Route头域内的地址和该头域中的所有的参数复制到响应消息中。
对于SIP请求消息，转发该SIP请求消息的设备根据Route头域中第一个地址的参数或选路结果的目的地址属性获得下一跳设备的SIP消息编码能力。
对于SIP响应消息，转发该SIP响应消息的设备根据剩余Via地址列表中第一个地址的参数获取得到下一跳设备的SIP消息编码能力。
收到SIP请求消息的设备在进行本地策略选择时，通过检查第一个Via地址的参数获取得到上一跳设备的SIP消息编码能力；或者，收到SIP请求消息的响应消息的设备，在进行本地策略选择时通过检查Record-Route地址中本设备地址的前面第一个Record-Route地址的参数，或者通过检查Contact地址的参数获取得到上一跳设备的SIP消息编码能力。
通过SIP消息中扩展头域携带设备的SIP消息编码能力。
所述扩展头域为事务支持信令编码类型(TSSET)头域和路由支持信令编码类型(RSSET)头域。
所述发送SIP消息的设备将本设备对SIP消息的编码能力携带在TSSET和RSSET头域中；并且，所述目标设备将接收到的SIP消息中的RSSET头域拷贝到等发送的SIP消息中，倒置RSSET编码能力列表，使用本目标设备的SIP消息编码能力列表替换RSSET头域的最后一个编码能力列表，并删除第一个TSSET编码能力列表。
转发所述SIP消息的的无状态代理服务器或事务代理服务器，将本服务器支持的SIP消息编码能力加入到TSSET头域中所有的编码能力列表之前，并从该SIP消息的响应消息中删除第一个TSSET头域的编码能力列表；并且，转发所述SIP消息的呼叫状态代理服务器，将本服务器支持的SIP消息编码能力加入TSSET头域和RSSET头域中所有的编码方式列表之前，并从该SIP消息的响应消息中删除第一个TSSET头域的编码能力列表。
所述扩展头域为支持信令编码类型(SSET)头域。
转发所述SIP消息的无状态代理服务器或事务代理服务器，删除SSET头域中本设备不支持的SIP消息编码能力；并且，转发所述SIP消息的呼叫状态代理服务器，将SSET头域中的编码能力列表替换为本服务器支持的或该呼叫内的消息可以使用的编码能力列表。
所述SIP消息为初始请求消息或后续请求消息。
一种通信装置，包括：
用于生成SIP消息，并将设备的SIP消息编码能力写入该SIP消息的第一处理模块；
用于编码并发送所述SIP消息的发送模块；
用于接收并解码SIP消息的接收模块；
用于从所述接收模块接收的SIP消息中提取相关设备的SIP消息编码能力的第二处理模块。
本发明在SIP消息中增加SIP消息编码能力描述完成编码能力的描述以及协商，从而为各个网络节点支持和使用ASN.1 BER等SIP信令编码方式进行SIP消息的交互提供机制上的保证。
本发明完全兼容现网络上已有的SIP协议应用以及SIP服务器，通过SIP消息编码能力的协商和传送方式，使得设备间可以获取对端SIP消息编码能力，在得知对端SIP信令编码后本端就可以根据本地策略、本设备编码能力以及对端设备编码能力选择一种更加适合的编码方式发送SIP消息，因此，本发明能够尽可能的节约网络资源，提高网络服务器的性能和容量。
附图说明
图1为本发明中终端设备之间直接互通时，进行SIP消息的编码方式协商的流程图；
图2为本发明中终端设备之间通过无状态代理服务器转发SIP消息时，进行SIP消息的编码方式协商的流程图；
图3为本发明中终端设备之间通过呼叫状态代理服务器发送SIP消息时，进行SIP消息的编码方式协商的流程图；
图4为本发明中终端设备注册和参与呼叫时，处理SIP消息的编码方式的流程图；
图5为本发明所示实例中终端设备之间进行SIP消息的编码方式协商的流程图；
图6为本发明中通过扩展头域携带编码方式进行协商的流程图；
图7为本发明中通过分段方式进行SIP消息的编码方式协商的流程图；
图8为本发明中终端设备的结构框图。
具体实施方式
由于二进制编码方式也有很多种，如常用的ASN.1就包括BER和DER等编码方式。本发明中将每一种编码方式都看作是一个单独的编码方式，如BER方式、DER方式等。在本实施例后续描述中分别使用bin-ber、bin-der表示上述提到的两种编码方式。除此之外，文本编码方式也仅仅是可用的编码方式中的一种，因此，本发明中的编码方式不仅包括以上提到的二进制编码方式，而且包括文本编码方式以及后续可能出现的其他编码方式。
为了在设备之间协商对SIP消息的编码能力，本发明在各设备填写Via、Record-Route以及Contact等头域时，在其中加入自己所支持的信令编码能力，或者，在SIP消息的扩展头域中加入自己所支持的信令编码能力，这样其他设备在向本设备发送SIP消息时就可以根据本设备的编码能力选择一种更优或更希望使用的信令编码能力。
在实际的组网中，终端设备之间可以直接互通，也可以通过代理设备实现互通，以下分别针对几种典型组网方式下的实现方案对本发明进行详细说明。
1、终端设备A、B之间直接互通。
参阅图1所示，终端设备A与终端设备B之间协商对SIP消息的编码能力的主要处理步骤如下：
步骤1、终端设备A向终端设备B发起初始请求消息，并在请求消息的Via头域和Contact地址头域中增加bin-ber、text等本设备支持的信令编码能力参数。
如果本设备支持多种编码能力，则需要根据本地策略等因素决定各种编码能力的优先级，在填写编码能力参数时需要依优先级从高到低的顺序列出所支持和愿意使用的所有编码能力。
如果Via以及Contact地址中没有填写任何编码格式，则其他设备应该认为该设备只支持该设备发送消息所使用的编码能力，这样就可以保证最大限度的互通可能性和灵活性。该方式作为各网络设备在任何条件下需要获取相邻网元的编码能力但消息中又无明确指示时的一种编码能力获取方式。后续在对技术方案以及各网元行为的描述中将不再对此种情况进行赘述，而是总是针对所有网元都可以获取相邻网元的编码能力属性的情况进行说明。
假设终端设备A支持ASN.1 BER编码方式(bin-ber)以及文本编码方式(text)，那么终端发送的INVITE请求消息的Via头于以及Contact头域分别为：
Via:SIP/2.0/UDP a_addr;bin-ber;text;branch=z9h235k
Contact:sip:a_addr;bin-ber;text
如果终端A在发送消息时能够通过其他途径得知下一个网络节点支持的编码方式，那么终端设备A可以直接使用本设备以及下一个网络节点都支持的编码方式生成请求消息并发送到下一个网络节点。但如果终端设备A发现本设备与下一个网络节点之间无共同的编码能力，则直接拒绝请求而不用向外发送任何请求消息。
由于网络设备在转发响应消息时将根据Via头域所列的地址以及参数选择响应消息目的地址以及发送方式，因此需要在Via头域中包含编码能力列表。只有通过Via头域携带本设备的编码能力，下一个网络节点才能够根据自身的选择策略、编码能力以及本设备的编码能力选择一种更优或双方更希望使用的信令编码能力。
由于Contact地址将会被加入路由地址列表中从而影响后续请求、响应消息的路由方式，因此需要在Contact头域中包含编码能力列表。只有通过Contact头域携带本设备的编码能力，相邻网络节点才能够根据自身的选择策略、编码能力以及本设备的编码能力选择一种更优或双方更希望使用的信令编码能力。
步骤2、终端设备B收到请求消息后，在按照RFC3261所述的方法根据Record-Route头域和Contact头域生成路由集合(Route Set)时，终端设备B不但需要复制每一个Record-Route地址和Contact地址到路由集合中，还需要同时复制该地址的编码能力属性。
终端设备B在生成响应消息时，需要将Record-Route头域中所有的信息复制到响应消息中，包括每一个Record-Route地址以及该地址的编码能力属性。同时，需要将Via头域中所有的信息复制到响应消息中，包括每一个Via地址以及该地址的编码能力属性。
终端设备B收到该请求消息后在发送响应消息时需要根据自己的本地策略、编码能力和消息接收设备的编码能力选择一种双方都支持的而且是最优或者双方更希望使用的信令编码方式生成响应消息，如终端设备A、B双方都支持bin-ber和text方式，而且终端设备B本地策略是依从主叫方编码能力优先级，或者是优先使用bin-ber方式，那么终端设备B就可以以ASN.1 BER方式生成响应消息并发送到对端。当然也可能根据本地策略选用其他的编码方式，如text等。
同时，终端设备B在生成的响应消息的Contact地址中需要增加bin-ber、text等本地支持的信令编码能力参数。如果本终端设备支持多种编码能力，则需要根据本地策略等因素决定各种编码能力的优先级，在填写编码能力参数时需要依优先级从高到低的顺序列出所支持和愿意使用的所有编码能力。
若终端设备B支持ASN.1BER编码方式(bin-ber)以及文本编码方式(text)，那么终端发送的响应消息的Contact头域为：
Contact:sip:b_addr;bin-ber;text
Contact地址将会被加入路由地址列表中从而影响后续请求、响应消息的路由方式，因此需要在Contact头域中包含编码能力列表。只有通过Contact头域携带本设备的编码能力，相邻网络节点才能够根据自身的选择策略、编码能力以及本设备的编码能力选择一种更优或双方更希望使用的信令编码能力。
步骤3、终端设备A收到响应消息后，在按照RFC3261所述的方法根据Record-Route头域和Contact头域生成路由集合(Route Set)时，不但需要复制每一个Record-Route地址和Contact地址到路由集合中，还需要同时复制该地址的编码能力属性。
终端设备A收到响应发送应答(ACK)等后续消息时需要根据自己的本地策略、编码能力以及消息接收设备的编码能力选择一种双方都支持的编码方式，如果双方都支持bin-ber方式以及text方式，则终端设备A就可以以ASN.1BER方式生成ACK消息并发送到对端。当然也可以继续以文本方式或者使用其它编码方式。
进一步地，终端设备A以及终端设备B在发送后续请求或响应消息时需要根据自己的编码能力和消息接收设备的编码能力选择一种双方都支持的而且是最优或者双方更希望使用的编码方式生成请求消息。如双方都支持bin-ber方式以及text方式，而且本地策略是优先使用bin-ber方式，那么终端设备A就以ASN.1 BER方式编码消息并发送到对端。
在完成初始请求消息处理后，终端设备A、B通信双方都得到了对端以及所涉及到的所有中间网络设备的编码能力等信息，之后终端设备A、B设备在发送消息时就可以根据自身的本地策略、编码能力和相邻网元的能力，以及优选编码能力等信息灵活选择一种最优或者最希望使用的编码方式生成消息并发送到相邻网元设备。终端设备A、B设备在生成后续消息时同样需要按照上述所描述的步骤1和步骤2。
终端设备A、B在生成后续请求消息时，需要进行下述处理：
(1)将路由集合填写到请求消息中。对于每一个Route地址，不但需要填写Route地址，还需要同时填写该Route地址的编码能力属性。
(2)按步骤1的方式填写Contact头域，即生成的消息的Contact头域中需要包含本设备的编码能力。
(3)按步骤1的方式填写Via头域，即生成的消息的Via头域中需要包含本设备的编码能力。
终端设备A、B在收到后续请求消息时，按照RFC3261中描述的方法对消息进行处理。特别是可能需要根据Record-Route头域和Contact头域刷新路由集合。在刷新路由集合并复制Record-Route地址和Contact地址到路由集合时同时也需要复制该地址的编码能力属性。
终端设备A、B在后续生成在生成响应消息时，需要进行下述处理：
(1)按照RFC3261的规定填写Record-Route头域。特别是，在从请求消息中复制Record-Route地址到响应消息中时需要同时复制相应的Record-Route地址的编码能力属性。
(2)按照RFC3261的规定填写Via头域。特别是，在从请求消息中复制Via地址到响应消息中时需要同时复制相应的Via地址的编码能力属性。
(3)按照步骤2所述的方法填写Contact头域，特别是其中对编码能力属性的填写。
终端设备A或B在收到最终响应消息时，按照RFC3261中描述的方法对消息进行处理。特别是可能需要根据Record-Route头域和Contact头域刷新路由集合。在刷新路由集合并复制Record-Route地址和Contact地址到路由集合时同时也需要复制该地址的编码能力属性。
2、终端设备之间通过无状态代理设备转发初始请求消息，即：终端设备A-无状态Proxy-终端设备B
参阅图2所示，协商对SIP消息的编码能力的主要处理步骤如下：
步骤1、终端设备A发起初始请求消息，并在请求消息的Via头域和Contact地址头域中增加bin-ber、text等本设备支持的信令编码能力参数(其处理过程与图1中的步骤1相同)。
步骤2、Proxy接收到初始请求消息后，在转发该初始请求消息时，根据本地策略选择对于该呼叫可支持的编码方式列表以及优先级顺序，并将编码方式列表以优先级从高到低的顺序排列填写到Via头域中。
Proxy本地可能的策略包括：
(1)Proxy不愿意在多种编码方式之间进行转换，或者想保持上、下游两侧使用同一种编码能力，那么Proxy仅仅需要将上游相邻网元(网元包括代理设备和终端设备)和本设备都支持的编码能力集合加入到Via头域即可。
(2)如果Proxy愿意在多种编码方式之间进行转换，那么Proxy就可以将本设备支持的所有的编码能力集合加入到Via头域即可。
请求消息的第一个Via地址参数中可识别的编码方式列表是上游相邻网元的编码能力集合，Proxy可以基于该列表按照上述方法进行处理。
如果上一个网络节点是终端设备A(消息中只有一个Via地址)，而且消息的Via地址中无编码能力参数，则Proxy将接收到的消息的编码方式填写到Via地址中作为上一个网络节点的编码能力。如果消息的Contact地址中无编码能力参数，则Proxy将接收到的消息的编码方式填写到Contact地址中作为上一个网络节点的编码能力。
如果上一个网络节点是Proxy(消息中只有多个Via地址)，而且消息的第一个Via地址中无编码能力参数，则Proxy将接收到的消息的编码方式填写到第一个Via地址中作为上一个网络节点的编码能力。如果消息中有Record-Route头域，而且第一个Record-Route地址中无编码能力参数，则Proxy将接收到的消息的编码方式填写到第一个Record-Route地址中作为上一个网络节点的编码能力。
如果Proxy在转发初始请求消息时可以确定下一个网络节点支持的编码方式，那么Proxy就可以在向下一个网络节点发送消息时选择和使用本设备以及下一个网络节点支持的，而且可以是最优或者最希望使用的编码方式生成消息并发送到下一个网络节点。但如果Proxy发现本设备与下一个网络节点之间无共同的编码能力，则直接返回失败响应消息拒绝请求。
步骤3、终端设备B收到初始请求消息后，在按照RFC3261所述的方法根据Record-Route头域和Contact头域生成路由集合(Route Set)时，终端设备B不但需要复制每一个Record-Route地址和Contact地址到路由集合中，还需要同时复制该地址的编码能力属性。
步骤4、Proxy收到终端设备B的响应消息时，根据本设备的编码能力、消息的下一跳网络节点(上游相邻网络设备)的编码能力以及本地策略选用最优或者最希望使用的编码方式生成并转发将响应消息。
转发响应消息所使用的编码方式可以和从上游收到请求消息的编码方式以及从下游收到响应消息的编码方式不同，但必须是上游网络设备所支持的编码方式之一。
步骤5、终端设备A收到响应消息后，以ASN.1 BER方式生成应答消息。在按照RFC3261所述的方法根据Record-Route头域和Contact头域生成路由集合(Route Set)时，不但需要复制每一个Record-Route地址和Contact地址到路由集合中，还需要同时复制该地址的编码能力属性。
由于无状态Proxy不在后续消息转发路径上，即不会收到并处理后续呼叫内的请求和响应消息，因此不存在其他消息的处理和转发问题。
3、终端设备之间通过事务状态代理设备转发消息，即：终端设备A-事务状态Proxy-终端设备B。
事务状态Proxy的处理方式与上述无状态Proxy的处理方式完全一致，不再赘述。
4、终端设备之间通过呼叫状态代理设备转发消息，即：终端设备A-呼叫状态Proxy-终端设备B。
呼叫状态Proxy对于创建Dialog或Subscription(为了方便描述，一下统一称之为Dialog)的事务中的消息(包括请求消息和响应消息)的处理方式以及转发消息时编码方式的选择包含无状态Proxy对初始请求消息和响应消息的处理方式和过程。除此之外，由于呼叫状态Proxy还会继续处理和转发Dialog内的后续其他所有消息，因此，呼叫状态代理设备除了按照无状态Proxy处理方式完成处理之外还必须完成一些其它事务处理。
参阅图3所示，协商对SIP消息的编码能力的主要处理步骤如下：
步骤1、终端设备A发起初始请求消息，并在请求消息的Via头域和Contact地址头域中增加bin-ber、text等本设备支持的信令编码能力参数(其处理过程与图1中的步骤1相同)。
步骤2、Proxy在转发请求消息时，需要根据本地策略选择该呼叫内后续事务消息可使用的编码方式列表以及优先级顺序，并将编码方式列表以优先级从高到低的顺序排列填写到Record-Route头域中。
可能的策略包括：
A、Proxy不愿意在多种编码方式之间进行转换，或者想保持上、下游两侧使用同一种编码能力，那么Proxy仅仅需要将上游相邻网元和本设备都支持的编码能力集合加入到Record-Route头域即可。
B、Proxy愿意在多种编码方式之间进行转换，那么Proxy就可以将本设备支持的编码能力集合加入到Record-Route头域即可。
上游相邻网元的编码能力集合为请求消息的第一个Record-Route地址(如果存在Record-Route头域)或者Contact地址(如果不存在Record-Route头域)参数中可识别的编码方式列表，Proxy可以基于该列表按照上述方法进行处理。如果所选取的地址中无编码能力则上游相邻网元的编码能力集合中只有一种编码能力，即收到的请求消息所使用的编码方式。如果本设备不支持该编码能力集合中的所有编码能力，则Proxy直接返回失败响应消息拒绝该呼叫。
如果Proxy在转发初始请求消息时可以确定下一个网络节点支持的编码方式，那么Proxy就可以在向下一个网络节点发送消息时选择和使用本设备以及下一个网络节点支持的，而且是最优或者最希望使用的编码方式生成消息并发送到下一个网络节点。但如果Proxy发现本设备与下一个网络节点之间无共同的编码能力，则直接返回失败响应消息拒绝请求。如果上游相邻网元的编码能力集合与下游相邻网元的编码能力集合无共同的编码能力，则Proxy也可以返回失败响应消息拒绝该呼叫，否则Proxy就需要在两种编码方式之间进行转换。
步骤3-步骤4、终端设备B生成响应消息，代理设备转发该响应消息。其处理与上述无状态Proxy的处理方式完全相同。
步骤5、终端设备A收到响应消息后，以ASN.1 BER方式生成应答消息。
步骤6、Proxy转发ACK消息。对于后续事务的消息，由于在进行后续消息处理时Proxy已经知道了上下游相邻设备的能力，因此Proxy可以根据本地策略、上下游网元的编码能力(可以通过Route等头域获取相关网元的编解码能力，也可以本地保存上下游网元的信息作为后续处理的依据)等信息选择一种最优或者最愿意使用的编码方式转发消息。对于个头域的处理与对Dialog创建事务消息的处理方式完全相同，不现赘述。
5、终端设备A→B2BUA→终端设备B。
B2BUA可以看作是两个终端设备在物理上的绑定，因此B2BUA可以在一端使用文本编码方式，而在另一端使用二进制编码方式，因此完全不受其他设备的能力支持情况的约束。因此B2BUA的处理方式完全与终端A与终端B直接互通的处理方式同理，不现赘述。
6、其它网络实体的处理方法
终端在向注册服务器发起注册时Contact头域可以包含终端支持的编码方式的列表。注册服务器收到REGISTER消息后需要将所有用户地址相关的记录下来，包括终端的信令编码能力列表等。后续Proxy等在进行处理时就可以根据获取得到的终端的编码能力等信息直接选用最优的或者最愿意使用的编码方式向终端发起请求。
终端在发送REGISTER请求消息时消息的Via头域的填写方法与上述终端设备的Via头域的填写方法一致。
注册服务器在处理REGISTER消息过程中除了保存终端的注册地址以及参数以外，返回响应消息的处理方式等与上述终端设备B的处理方式完全一致。
重定向服务器在收到请求消息后直接向主叫返回重定向响应消息，重定向响应地址可以包含新地址的编码方式列表以供相关设备处理时使用。除此之外，重定向服务器对响应消息的处理方式与上述终端设备B的处理方式完全一致。
在IMS系统中定义了Path、Service-Route头域用于分别记录P-CSCF以及为用户提供业务的S-CSCF的地址，并完成对初始请求消息的路由。在本发明中，P-CSCF以及S-CSCF在将自己的地址分别以Path和Service-Route加入消息中时也需要加入本设备支持的编码能力列表。
参阅图4所示，步骤F1至步骤F2为终端设备注册的主要过程：
在终端发起注册请求时，当REGISTER请求到达P-CSCF后P-CSCF除了按照上述对无状态Proxy的处理方式进行处理之外，还在REGISTER请求消息加入Path头域，Path地址中包含P-CSCF的地址以及编码能力列表。
REGISTER请求到达S-CSCF后S-CSCF时，除了上述REGISTRAR的处理方式进行处理之外还需要记录Path地址以及终端编码能力，并且在对REGISTER的200响应消息中加入Service-Route头域，Service-Route地址中包含S-CSCF的地址和编码能力列表。
REGISTER的200响应消息到达P-CSCF后，P-CSCF记录Service-Route地址以及编码能力列表。
步骤F5至步骤F19为终端设备作被叫时的各设备处理的主要过程：
当终端做被叫时，呼叫首先到达S-CSCF，S-CSCF将Path地址作为下一个消息路由目的地，因此S-CSCF中有P-CSCF详细信息，包括信令地址以及P-CSCF的编码能力列表，因此S-CSCF就可以按照2.2.1.4中呼叫状态代理服务器的处理方式灵活选择编码方式。
当呼叫消息到达P-CSCF后由于P-CSCF已经完全知道终端以及S-CSCF的编码能力，因此S-CSCF就可以按照2.2.1.4中呼叫状态代理服务器的处理方式灵活选择编码方式。
对其它消息以及终端等其它设备对消息的处理方式与前面各对应设备的消息处理方式分别一一对应，不再赘述。
步骤F20至步骤F34为终端设备作主叫时的各设备处理的主要过程：
当终端做主叫时，呼叫首先到达P-CSCF，P-CSCF将Service-Route地址作为下一个消息路由目的地，因此P-CSCF中有S-CSCF详细信息，包括信令地址以及S-CSCF的编码能力列表，因此P-CSCF就可以按照上述呼叫状态代理服务器的处理方式灵活选择编码方式。
当呼叫消息到达S-CSCF后S-CSCF可以按照上述中呼叫状态代理服务器的处理方式灵活选择编码方式。
对其它消息以及终端等其它设备对消息的处理方式与前面各对应设备的消息处理方式分别一一对应，不再赘述。
参阅图5所示，一个呼叫的实例处理流程如下：
F1：主叫终端向网络服务器发起呼叫请求INVITE，由于主叫终端并不知道p1支持何种编码方式，但至少知道它支持文本编码方式。因此INVITE消息将使用文本编码方式。因此INVITE消息会是：
INVITE b@example.com SIP/2.0
From:<sip:a@example.com>;tag=1928301774
To:<sip:b@example.com>
Via:SIP/2.0/UDP uaa.example.com;bin-ber;bin-der;text
Contact:sip:uaa.example.com;bin-ber;bin-der;text
……
F2：无状态代理服务器p1向呼叫状态代理服务器p2转发INVITE消息(假设p1支持bin-ber、bin-der以及text三种编码能力)：
INVITE b@example.com SIP/2.0
Via:SIP/2.0/UDP p1.example.com;bin-ber;bin-der;text
Via:SIP/2.0/UDP uaa.example.com;bin-ber;bin-der;text
Contact:sip:uaa.example.com;bin-ber;text
……
F3：无状态代理服务器p1向呼叫状态代理服务器p2转发INVITE消息(假设p2支持bin-ber和text两种编码能力)：
INVITE b@uab.example.com SIP/2.0
Record-Route:<p2.example.com;lr;bin-ber;text>
Via:SIP/2.0/UDP p2.example.com;bin-ber;text
Via:SIP/2.0/UDP p1.example.com;bin-ber;bin-der;text
Via:SIP/2.0/UDP uaa.example.com;bin-ber;bin-der;text
Contact:sip:uaa.example.com;bin-ber;text
……
F4：呼叫状态代理服务器p2向无状态代理服务器p1返回对INVITE的100响应消息。假设呼叫状态代理服务器p2经过本地决策后采用bin-ber方式编码响应消息(以十六进制序列表时消息)：
80；采用bin-ber编码方式编码
20；等价与文本编码方式下的SIP/2.0，表示协议版本为2.0
0123；消息总长度为0X123字节
0100；表示为100类响应消息
00；表示无Reason-Phase部分
……此消息为采用bin-ber方式编码的100Trying消息。
F5：无状态代理服务器p1向终端A转发100Trying响应消息。假设无状态代理服务器p1经过本地决策后采用bin-ber方式转发响应消息。消息内容与F4类似。
F6：终端B向呼叫状态代理服务器p2返回200响应消息(假设终端B支持bin-ber编码方式)，响应消息为bin-ber编码的二进制消息。为了表述方便，此处列出等价的文本消息：
SIP/2.0 200 OK
Record-Route:<p2.example.com;lr;bin-ber;text>
Via:SIP/2.0/UDP p2.example.com;bin-ber;text
Via:SIP/2.0/UDP p1.example.com;bin-ber;bin-der;text
Via:SIP/2.0/UDP uaa.example.com;bin-ber;bin-der;text
Contact:sip:uab.example.com;bin-ber;text
……
F7：呼叫状态代理服务器p2以bin-ber编码方式转发200响应消息，响应消息为bin-ber编码的二进制消息。为了表述方便，此处列出等价的文本消息：
SIP/2.0 200 OK
Record-Route:<p2.example.com;lr;bin-ber;text>
Via:SIP/2.0/UDP p1.example.com;bin-ber;bin-der;text
Via:SIP/2.0/UDP uaa.example.com;bin-ber;bin-der;text
Contact:sip:uab.example.com;bin-ber;text
……
F8：无状态代理服务器p1以bin-ber编码方式转发200响应消息，响应消息为bin-ber编码的二进制消息。为了表述方便，此处列出等价的文本消息：
SIP/2.0 200 OK
Record-Route:<p2.example.com;lr;bin-ber;text>
Via:SIP/2.0/UDP uaa.example.com;bin-ber;bin-der;text
Contact:sip:uab.example.com;bin-ber;text
……
F9：终端A向呼叫状态代理服务器p2发送ACK消息，消息采用bin-ber编码方式。为了表述方便，此处列出等价的文本消息：
ACK sip:uab.example.com;bin-ber;text SIP/2.0
Route:<p2.example.com;lr;bin-ber;text>
Via:SIP/2.0/UDP uaa.example.com;bin-ber;bin-der;text
Contact:sip:uaa.example.com;bin-ber;bin-der;text
……
F10：呼叫状态代理服务器p2向终端B转发ACK消息，消息采用bin-ber编码方式。为了表述方便，此处列出等价的文本消息：
ACK sip:uab.example.com;bin-ber;text SIP/2.0
Via:SIP/2.0/UDP p2.example.com;bin-ber;text
Via:SIP/2.0/UDP uaa.example.com;bin-ber;bin-der;text
Contact:sip:uaa.example.com;bin-ber;bin-der;text
……
上述描述使用Via、Contact、Record-Route、Route、Path以及Service-Route等头域携带网络节点的信令编码能力，完成编码能力的协商并辅助各设备完成编码方式的选择和本地策略的实施。其中Via头域用于指导响应消息路由时的编码方式的选择，Contact、Record-Route、Route用于指导后续信令消息路由时的编码方式的选择，Path、Service-Route等用于指导初始请求消息路由时的编码方式的选择。为了指导对以上三类信令消息路由时的编码方式的选择策略的实施，还可以通过扩展头域的方式完成以上所述的信令路径上的网络设备的信令编码能力的收集和记录，为各个网络设备选择信令编码方式提供充足的信息。
如可以通过tsset(Transaction Supported Signaling Encoding Type)扩展头域记录请求消息所经过的网络设备的编解码能力列表用于指导响应消息路由时的编码方式的选择，通过rsset(Route Supported Signaling Encoding Type)扩展头域记录UA以及呼叫状态Proxy等设备的编解码能力列表用于指导后续信令消息路由时的编码方式的选择等。
图6作为一个示例流程图表达了一种可能的实现方式，其中列出了与本发明相关的tsset和rsset头域的取值，取值参数中Luaa、Luab、Lp1、Lp2分别代表UAa、UAb、P1以及P2的编码方式列表(即编码能力，以下提到编码能力都是指某一设备的编码方式列表，编码能力列表则指多个设备的编码能力的列表)，而它们分别可能包含多种编码方式，多种编码方式之间通过分号“；”分隔。不同设备的编码方式列表之间通过“，”分隔。
1、用户终端A(UAC)的处理方式：
(1)用户终端A在发送初始请求消息时需要将本设备支持的编码能力Luaa加入tsset和rsset中。
(2)在收到对初始请求的可靠响应消息后需要记录rsset头域中的取值，并需要特别注意需要保持rsset头域中编码能力列表的顺序。
2、无状态代理服务器和事务状态代理服务器的处理方式：
(1)在收到初始请求消息后，无状态代理服务器或事务状态代理服务器将本设备的编码能力加入到tsset头域中的所有的编码能力列表之前。
(2)在收到对初始请求的响应消息后，无状态代理服务器或事务状态代理服务器需要删除第一个tsset列表并将消息向主叫侧转发。
3、呼叫状态代理服务器的处理方式：
(1)在收到初始请求消息后呼叫状态代理服务器需要将本设备的编码能力加入到tsset头域中的所有的编码能力列表之前和rsset头域中的所有的编码能力列表之前。
(2)在收到对初始请求的响应消息后呼叫状态代理服务器需要删除第一个tsset编码方式列表并将消息向主叫侧转发。
4、用户终端B的处理方式：
(1)在收到初始请求消息后用户终端B(UAS)记录rsset头域中携带的所有消息路由路径上的设备的编码能力列表，并保持rsset头域中编码能力列表的顺序。
(2)在返回响应消息时用户终端B将请求消息中的rsset头域拷贝到响应消息中，倒置rsset编码方式列表，使用自己的编码方式列表替换rsset头域的最后一个编码方式列表，删除第一个tsset编码方式列表；构造好响应消息后向主叫侧发送。
对于后续事务的请求和响应消息的处理方式：
(1)用户终端A(UAC)在发送后续请求消息时，拷贝rsset列表到新请求消息中rsset头域中并删除第一个rsset编码方式列表、将自己的编码能力列表添入tsset头域中，构造好响应消息后向对端发送。
(2)代理服务器(一定是呼叫状态代理服务器)收到后续请求消息后，将自己的编码能力列表添入tsset头域中的所有的编码能力列表之前，删除第一个rsset编码方式列表并将消息转发到下一跳网络设备。
(3)用户终端B收到请求消息后返回响应消息时，将请求消息中的tsset头域拷贝到响应消息中并删除第一个tsset编码能力列表；构造好响应消息后向主叫侧发送。
(4)代理服务器收到后续事务的响应消息后，删除第一个tsset列表并将消息向主叫侧转发。
除了以上描述的处理方式之外各网络实体只需要按照RFC3261定义的各网络实体对各类消息的处理方式进行处理即可。
各网络设备在发送消息时编码方式的选择方式与前述方案中编码方式的选择方式相同，唯一的差别是不再从Via、Route等头域获取相邻设备的编码能力，而是从rsset以及tsset中获取。
所有设备在将自己的编码能力加入到tsset或者rsset头域中时同样可以使用本地策略选择对于该呼叫只限于使用某些编码能力以及各编码能力的优先级。各设备需要将经过策略选择和处理后的编码方式列表加入到相应的头域中。
IMS系统中P-CSCF、S-CSCF彼此之间通过Path、Service-Route头域发布自己的地址等信息时，可以通过Path、Service-Route头域扩展参数或者使用新的扩展头域的方式将本设备的编码格式发布给对方，从而帮助对方在进行消息路由时选择更好的编码能力提供更加充足的信息。由于此部分内容比较简单，在此就不列出详细的消息流程和交互过程了。
以上的两种方案都是通过记录全路径上的设备的详细信息完成消息路由时的编码方式的选择，在本发明中也可通过逐段协商的方式进行编码能力协商。
参阅图7所示，在该呼叫流程中，假设用户终端A支持a、b、c三种编码能力，无状态代理服务器p1支持a、b、d上种编码能力，呼叫状态代理服务器p2支持a、d、e、f四种编码能力，用户终端B支持d、e、f三种编码能力，其主要处理流程如下：
F1、用户终端A在发起请求时时通过新增扩展头域SSET(SupportedSignaling Encoding Type)携带主叫终端支持的所有编码方式。如终端A支持a、b以及c三种方式，编码方式采用优先级从高到低的顺序排列。
F2、无状态代理服务器p1收到请求消息后转发请求消息。因为到无状态代理服务器p1不在后续事务消息的转发路径上，为了防止用户终端A和呼叫状态代理服务器p2之间因为选择不匹配的编码方式而导致呼叫失败，因此无状态Proxy通常只能将删除sset中本设备不支持的编码方式而只保留自己支持的编码能力。
F3、呼叫状态代理服务器p2收到请求消息后转发请求消息。呼叫状态代理服务器可以将sset头域中的编码列表替换为自己支持的或该呼叫内的消息可以使用的编码方式列表。本流程中假设呼叫状态代理服务器p2经过本地决策后该事务的请求和响应消息可以使用本设备支持的所有的编码方式，编码方式采用优先级从高到低的顺序排列，因此sset头域可以被重置为“a，d，e，f”。呼叫状态代理服务器P2通过其它方式得知下一跳用户终端B支持的部分编码方式后呼叫状态代理服务器p2需要使用已知的用户终端B以及自身支持的编码方式将消息转发到用户终端B。
F6、用户终端B在返回响应消息时需要在响应消息中增加sset头域，取值为本设备支持的编码方式列表，编码方式采用优先级从高到低的顺序排列。
F7、呼叫状态代理服务器P2在转发响应消息时可以采用与请求消息同样的处理方式选择编码方式以及改写sset头域。
F8、由于无状态代理服务器P1不在后续事务消息的转发路径上，为了在用户终端A和呼叫状态代理服务器p2之间进行充分的编码方式协商并且防止因为选择不匹配的编码方式而导致呼叫失败，因此无状态Proxy通常可以采用与请求消息同样的处理方式删除sset中本设备不支持的编码方式而只保留自己支持的编码能力，也可以只是简单的转发sset信息即可。
对于后续消息的处理各网络设备的处理方式与对初始请求消息的处理方式完全相同，只是由于经过初始请求、响应消息之后每个网络设备都已经知道了相邻网络设备的编码能力，因此就可以很灵活的选用最优的或者最愿意使用的编码方式发送消息。
IMS系统中P-CSCF、S-CSCF彼此之间通过Path、Service-Route头域发布自己的地址等信息时，可以通过Path、Service-Route头域扩展参数或者使用新的扩展头域的方式(如使用sset扩展头域)将本设备的编码格式发布给对方，从而帮助对方在进行消息路由时选择更好的编码能力提供更加充足的信息。由于此部分内容比较简单，在此就不列出详细的消息流程和交互过程了。
参阅图8所示，实现上述方法的终端设备至少包括：第一处理模块、发送模块、接收模块和第二处理模块(图中未示出其他完成现有基本功能的功能模块)。其中：
第一处理模块用于生成SIP消息，并将设备的SIP消息编码能力写入该SIP消息。
发送模块用于发送所述SIP消息。
接收模块用于接收从其他设备发送来的SIP消息。
第二处理模块用于从所述接收模块接收的SIP消息中提取相关设备的SIP消息编码能力。
本发明完全兼容现网络上已有的SIP协议应用以及SIP服务器，通过SIP消息编码能力的协商和传送方式，使得设备间可以获取对端SIP消息编码能力。在同等硬件配置情况下，如果使用ASN.1等编码方式，SIP协议的处理性能和容量将会增加一倍以上，从而可以充分的利用网络资源和提高网络性能。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若对本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
Claims (34)
1、一种SIP消息编码能力的协商方法，其特征在于，包括以下步骤：
发送SIP消息的设备在SIP消息中携带本设备的SIP消息编码能力信息；
接收所述SIP消息的目标设备获取该SIP消息中携带的SIP消息编码能力信息，并在返回的SIP消息中携带本目标设备的SIP消息编码能力信息；
所述发送SIP消息的设备从所述目标设备发送的SIP消息中获取SIP消息编码能力信息。
2、如权利要求1所述的协商方法，其特征在于，所述SIP消息传送路径上的设备在向目标设备侧发送接收到的SIP消息时，在该SIP消息中加入本设备的SIP消息编码能力。
3、如权利要求1或2所述的协商方法，其特征在于，发送SIP消息的设备在获知接收所述SIP消息的相邻设备的SIP消息编码能力时，选择本设备和所述相邻设备支持的编码能力对所述SIP消息编码。
4、如权利要求1或2所述的协商方法，其特征在于，设备在发送SIP消息前，获知与相邻设备之间无共同支持的SIP消息编码能力，则拒绝与所述SIP消息相关的业务请求。
5、如权利要求1或2所述的协商方法，其特征在于，若所述SIP消息中用于携带SIP消息编码能力的头域内无编码格式信息，则接收到该SIP消息的设备确定发送该SIP消息的设备只支持发送SIP消息所使用的编码能力。
6、如权利要求1或2所述的协商方法，其特征在于，发送SIP消息的设备在生成路由列表时，保持每一个路由地址的编码格式信息；并且在后续生成的请求消息的路由列表中包含路由路径上的网络设备地址及其SIP消息编码能力。
7、如权利要求6所述的协商方法，其特征在于，所述设备在发送后续请求消息的响应消息时，根据下一跳路地址所对应的网络设备的SIP消息编码能力、本设备的SIP消息编码能力和本地策略选用编码方式生成响应消息。
8、如权利要求1或2所述的协商方法，其特征在于，若发送SIP消息的设备能够得到下一跳设备的SIP消息编码能力，则在发送SIP消息时根据本地策略，选择本设备和下一跳设备支持的编码方式对消息进行编码。
9、如权利要求1或2所述的协商方法，其特征在于，所述SIP消息传送路径上的设备将本设备支持的所有SIP消息编码能力加入到所述SIP消息中；或者，仅将本设备及相邻网络设备均支持的SIP消息编码能力加入到所述SIP消息中；或者，根据本地配置的策略将本设备的SIP消息编码能力加入到所述SIP消息中。
10、根据权利要求1或2所述的方法，所述SIP消息传送路径上的设备在发送后续请求消息或请求消息的响应消息时，根据相邻设备的SIP消息编码能力、接收到的消息所采用有SIP消息编码方式，以及自身SIP消息编码能力和本地策略中的部分或全部信息，选择编码方式对转发的消息进行编码。
11、如权利要求1或2所述的协商方法，其特征在于，发送SIP消息的设备的SIP消息编码能力被用户禁止时，在发送的SIP消息中将不包含被禁止的编码能力。
12、如权利要求1或2所述的协商方法，其特征在于，参与SIP消息编码能力协商的设备，根据本设备和相邻设备的SIP消息编码能力，上一次收到的SIP消息所使用的编码方式，以及本地策略选择该会话可使用的编码方式和各编码方式的优先级中的部分或全部信息，确定最终使用SIP消息的编码方式。
13、如权利要求12述的协商方法，其特征在于，各编码方式的优先级可由最短消息长度、最快编解码速度、最小系统要求或依据相邻设备的SIP消息编码能力优先级顺序确定，或通过用户指定方式确定。
14、如权利要求13述的协商方法，其特征在于，所述设备在经过本地策略得到可使用的编码方式以及编码方式的优先级顺序后，在向SIP消息中填写SIP消息编码能力时按优先级顺序排列编码能力。
15、如权利要求1或2所述的协商方法，其特征在于，所述设备在发起注册请求时在该请求中携带地址及SIP消息编码能力，注册服务器在收到注册请求消息后保存所述注册地址及SIP消息编码能力。
16、如权利要求15所述的协商方法，其特征在于，转发所述注册请求的设备将本设备的SIP消息编码能力加入注册请求消息中。
17、如权利要求16所述的协商方法，其特征在于，所述转发注册请求的设备在向请求注册的设备返回注册请求的成功响应消息时，在该消息中加入本设备的SIP消息编码能力。
18、如权利要求1或2所述的协商方法，其特征在于，若重定向服务器在返回重定向响应消息时获知前转目的设备的SIP消息编码能力，则在重定向响应消息的重定向地址中携带目的设备的SIP消息编码能力。
19、如权利要求1或2所述的协商方法，其特征在于，在参与SIP消息编码能力协商过程中，通过SIP消息的Contact和Via头域中的扩展参数携带呼叫状态代理客户端(UAC)设备的SIP消息编码能力，并通过SIP消息中Contact头域中的扩展参数携带呼叫状态代理服务器端(UAS)设备的SIP消息编码能力。
20、如权利要求19所述的协商方法，其特征在于，通过SIP消息中的Via头域和Record-Route头域，携带转发SIP消息的呼叫状态代理服务器的SIP消息编码能力；通过SIP消息中的Via头域，携带转发SIP消息的其他的代理服务器的SIP消息编码能力。
21、如权利要求19所述的协商方法，其特征在于，UAS设备在生成响应消息时，将所述SIP消息中Via头域内的地址以及其中所有的参数复制到响应消息中。
22、如权利要求21所述的协商方法，其特征在于，UAS设备在生成响应消息时，还将所述SIP消息中Record-Route头域内的地址和该头域中的所有的参数复制到响应消息中。
23、如权利要求19所述的协商方法，其特征在于，对于SIP请求消息，转发该SIP请求消息的设备根据Route头域中第一个地址的参数或选路结果的目的地址属性获得下一跳设备的SIP消息编码能力。
24、如权利要求19所述的协商方法，其特征在于，对于SIP响应消息，转发该SIP响应消息的设备根据剩余Via地址列表中第一个地址的参数获取得到下一跳设备的SIP消息编码能力。
25、如权利要求19所述的协商方法，其特征在于，收到SIP请求消息的设备在进行本地策略选择时，通过检查第一个Via地址的参数获取得到上一跳设备的SIP消息编码能力；或者
收到SIP请求消息的响应消息的设备，在进行本地策略选择时通过检查Record-Route地址中本设备地址的前面第一个Record-Route地址的参数，或者通过检查Contact地址的参数获取得到上一跳设备的SIP消息编码能力。
26、如权利要求1或2所述的协商方法，其特征在于，通过SIP消息中扩展头域携带设备的SIP消息编码能力。
27、如权利要求26所述的协商方法，其特征在于，所述扩展头域为事务支持信令编码类型(TSSET)头域和路由支持信令编码类型(RSSET)头域。
28、如权利要求27所述的协商方法，其特征在于，所述发送SIP消息的设备将本设备对SIP消息的编码能力携带在TSSET和RSSET头域中；并且
所述目标设备将接收到的SIP消息中的RSSET头域拷贝到等发送的SIP消息中，倒置RSSET编码能力列表，使用本目标设备的SIP消息编码能力列表替换RSSET头域的最后一个编码能力列表，并删除第一个TSSET编码能力列表。
29、如权利要求28所述的协商方法，其特征在于，转发所述SIP消息的的无状态代理服务器或事务代理服务器，将本服务器支持的SIP消息编码能力加入到TSSET头域中所有的编码能力列表之前，并从该SIP消息的响应消息中删除第一个TSSET头域的编码能力列表；并且
转发所述SIP消息的呼叫状态代理服务器，将本服务器支持的SIP消息编码能力加入TSSET头域和RSSET头域中所有的编码方式列表之前，并从该SIP消息的响应消息中删除第一个TSSET头域的编码能力列表。
30、如权利要求26所述的协商方法，其特征在于，所述扩展头域为支持信令编码类型(SSET)头域。
31、如权利要求30所述的协商方法，其特征在于，转发所述SIP消息的无状态代理服务器或事务代理服务器，删除SSET头域中本设备不支持的SIP消息编码能力；并且
转发所述SIP消息的呼叫状态代理服务器，将SSET头域中的编码能力列表替换为本服务器支持的或该呼叫内的消息可以使用的编码能力列表。
32、如权利要求1所述的协商方法，其特征在于，所述SIP消息为初始请求消息或后续请求消息。
33、一种通信装置，其特征在于，包括：
用于生成SIP消息，并将设备的SIP消息编码能力写入该SIP消息的第一处理模块；
用于编码并发送所述SIP消息的发送模块；
用于接收并解码SIP消息的接收模块；
用于从所述接收模块接收的SIP消息中提取相关设备的SIP消息编码能力的第二处理模块。
34、如权利要求33所述的通信装置，其特征在于，所述发送模块根据本地和相关设备的SIP消息编码能力，选择编解码格式对发送的SIP消息进行编码。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2005101241491A CN1870639B (zh) | 2005-11-25 | 2005-11-25 | 初始会话协议消息编码能力的协商方法及装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2005101241491A CN1870639B (zh) | 2005-11-25 | 2005-11-25 | 初始会话协议消息编码能力的协商方法及装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN1870639A true CN1870639A (zh) | 2006-11-29 |
| CN1870639B CN1870639B (zh) | 2010-12-08 |
Family
ID=37444187
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2005101241491A Expired - Fee Related CN1870639B (zh) | 2005-11-25 | 2005-11-25 | 初始会话协议消息编码能力的协商方法及装置 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN1870639B (zh) |
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009049510A1 (fr) * | 2007-10-16 | 2009-04-23 | Huawei Technologies Co., Ltd. | Procédé, système et dispositif pour une négociation de signalisation de service de données de protocole d'ouverture de session |
| CN101212418B (zh) * | 2006-12-31 | 2010-05-12 | 华为技术有限公司 | 背靠背用户代理及其传输信息的方法 |
| CN102197700A (zh) * | 2008-10-14 | 2011-09-21 | 斯利府·米什创造有限公司 | 通信系统和方法 |
| CN102223201A (zh) * | 2010-04-15 | 2011-10-19 | 中兴通讯股份有限公司 | 一种编解码器能力协商方法及终端 |
| WO2013008248A1 (en) * | 2011-05-25 | 2013-01-17 | Madaiah Vinod Kumar | Method and system for exchanging content among communication entities over communication network |
| CN103582025B (zh) * | 2012-08-07 | 2017-04-12 | 中国电信股份有限公司 | 资源保留方法和系统 |
| CN106603880A (zh) * | 2016-11-21 | 2017-04-26 | 深圳市潮流网络技术有限公司 | 一种编解码协同处理方法 |
| CN107113223A (zh) * | 2014-12-19 | 2017-08-29 | 瑞典爱立信有限公司 | 用于消息会话中继协议会话的消息块大小的协商 |
| CN112104644A (zh) * | 2020-09-11 | 2020-12-18 | 维沃移动通信有限公司 | Ims请求消息的发送方法和装置 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2000070885A1 (en) * | 1999-05-17 | 2000-11-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Capability negotiation in a telecommunications network |
-
2005
- 2005-11-25 CN CN2005101241491A patent/CN1870639B/zh not_active Expired - Fee Related
Cited By (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101212418B (zh) * | 2006-12-31 | 2010-05-12 | 华为技术有限公司 | 背靠背用户代理及其传输信息的方法 |
| CN101415249B (zh) * | 2007-10-16 | 2011-02-16 | 华为技术有限公司 | 会话初始化协议数据业务信令协商的方法、系统及装置 |
| WO2009049510A1 (fr) * | 2007-10-16 | 2009-04-23 | Huawei Technologies Co., Ltd. | Procédé, système et dispositif pour une négociation de signalisation de service de données de protocole d'ouverture de session |
| CN102197700B (zh) * | 2008-10-14 | 2014-06-11 | 阿尔特布里奇有限公司 | 通信系统和方法 |
| CN102197700A (zh) * | 2008-10-14 | 2011-09-21 | 斯利府·米什创造有限公司 | 通信系统和方法 |
| US8953671B2 (en) | 2010-04-15 | 2015-02-10 | Zte Corporation | Codec capability negotiation method and terminal thereof |
| CN102223201B (zh) * | 2010-04-15 | 2014-01-01 | 中兴通讯股份有限公司 | 一种编解码器能力协商方法及终端 |
| WO2011127763A1 (zh) * | 2010-04-15 | 2011-10-20 | 中兴通讯股份有限公司 | 一种编解码器能力协商方法及终端 |
| CN102223201A (zh) * | 2010-04-15 | 2011-10-19 | 中兴通讯股份有限公司 | 一种编解码器能力协商方法及终端 |
| WO2013008248A1 (en) * | 2011-05-25 | 2013-01-17 | Madaiah Vinod Kumar | Method and system for exchanging content among communication entities over communication network |
| CN103582025B (zh) * | 2012-08-07 | 2017-04-12 | 中国电信股份有限公司 | 资源保留方法和系统 |
| CN107113223A (zh) * | 2014-12-19 | 2017-08-29 | 瑞典爱立信有限公司 | 用于消息会话中继协议会话的消息块大小的协商 |
| CN106603880A (zh) * | 2016-11-21 | 2017-04-26 | 深圳市潮流网络技术有限公司 | 一种编解码协同处理方法 |
| CN106603880B (zh) * | 2016-11-21 | 2021-06-15 | 深圳市潮流网络技术有限公司 | 一种编解码协同处理方法 |
| CN112104644A (zh) * | 2020-09-11 | 2020-12-18 | 维沃移动通信有限公司 | Ims请求消息的发送方法和装置 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1870639B (zh) | 2010-12-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN1870639A (zh) | 初始会话协议消息编码能力的协商方法及装置 | |
| CN101064726A (zh) | 地址变换装置、消息处理方法及网络系统 | |
| CN101053231A (zh) | 负载控制信息的基于消息的传递 | |
| CN1505429A (zh) | 移动终端设备及终端间包通信方法 | |
| CN101039247A (zh) | 一种点到点网络系统及重叠网间节点的互通方法 | |
| CN1801810A (zh) | 一种会话初始化协议消息体内容处理方法及网络 | |
| CN101052154A (zh) | Ip多媒体子系统及其编解码转换控制方法 | |
| CN1661990A (zh) | 协议版本转换器 | |
| CN1846420A (zh) | 嵌入的服务质量相关信息的传送 | |
| CN1835505A (zh) | 会话中继装置 | |
| CN1551583A (zh) | 数据包通信装置 | |
| CN1893427A (zh) | 一种进行业务支持能力协商的方法 | |
| CN1750543A (zh) | 服务器负载平衡系统、装置以及内容管理装置 | |
| CN1816053A (zh) | 基于会话初始化协议的流媒体直播p2p网络方法 | |
| CN1509577A (zh) | Ip多媒体中的存在服务器 | |
| CN101075890A (zh) | 实现群组会话体验质量的方法及系统 | |
| CN100343835C (zh) | 信息处理方法和设备 | |
| CN1729672A (zh) | 用于分布式多媒体应用的能力和服务质量协商和会话建立的软件体系结构 | |
| CN1711784A (zh) | 用于发送sms以及文本消息的系统和方法 | |
| CN1969528A (zh) | 用于点对多点传输系统的点对点修复响应机制 | |
| CN1677979A (zh) | 通过网络在计算机之间共享对象的系统和方法 | |
| CN101064866A (zh) | 一种短信的路由寻址方法及系统 | |
| CN1874328A (zh) | 实现业务互通的方法及系统 | |
| CN1801814A (zh) | 一种离线消息发送和接收方法 | |
| CN1868197A (zh) | 借助于sip协议的荷载信道变更的信令方法、软件产品和装置 |
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 | ||
| C17 | Cessation of patent right | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20101208 Termination date: 20121125 |