欢迎访问 水平网    今天是:2018年06月18日 注册 | 登录 | 订阅 | 收藏
>> 网络技术 >> VOIP技术 >> SIP中的事务处理机制
推荐文章
热点文章
专题
JQuery框架
Prototype.js
HTML5

SIP中的事务处理机制

作者:未知,  来源:网络,  阅读:922,  发布时间:2014-08-11 【放入收藏夹
       SIP是一个基于事务处理的协议:部件之间的交互是通过一系列无关的消息交换所完成的。特别是,一个SIP 事务由一个单个请求和这个请求的所有应答组成,这些应答包括了零个或者多个临时应答以及一个或者多个终结应答。在事务中,当请求是一个INVITE(叫做INVITE事务),当终结应答不是一个2xx应答的时候,事务还包括一个ACK。如果应答是一个2xx应答,那么ACK并不认为是事务的一部分。
这个分开的原因是基于传递全部200(OK)应答到UAC的INVITE请求的重要性所决定的。要把所有的200应答全部发给UAC,那么UAS独自负责这些应答的重新传送(参见13.3.1.4),UAC独自负责挨个ACK确认(参见13.2.2.4)。由于ACK的重传只由UAC发起,所以在自己的事务中进行重传会比较有效。
 
事务分为客户端和服务端两方。客户端的事务是客户端事务,服务器端的事务就是服务端事务。客户端事务发出请求,并且服务端事务送回应答。客户端和服务端事务都是逻辑上的概念,他们可以被无数部件所包含。特别是,他们在UA中和有状态的proxy服务器中存在。以第四节的例子来说明。在这个例子中,UAC执行客户端事务,它的外发proxy执行服务端事务。外发proxy同时也执行客户端事务,把请求发送到一个那发proxy的服务端事务。这个proxy也同时执行一个客户端事务,把请求发到一个UAS的服务端事务上去。这个在图四中比较明白:
 

 
+---------+                +---------+                    +---------+                  +---------+
|       +-+|Request    |+-+    +-+|Request     |+-+     +-+|Request  |+-+       |
|       |C||------->       ||S|    |C||------->         ||S|     |C||------->       ||S|       |
|       |l||                    ||e|    |l||                     ||e|     |l||                   ||e|     |
|       |i||                    ||r|    |i||                      ||r|     |i||                    ||r|     |
|       |e||                   ||v|    |e||                    ||v|     |e||                 ||v|     |
|       |n||                   ||e|    |n||                   ||e|     |n||                  ||e|     |
|       |t||                    ||r|    |t||                     ||r|     |t||                   ||r|     |
|       | ||                    || |      | ||                    || |     | ||                    || |     |
|       |T||                   ||T|    |T||                     ||T|     |T||                  ||T|     |
|       |r||                   ||r|    |r||                       ||r|     |r||                   ||r|     |
|       |a||                  ||a|    |a||                     ||a|     |a||                  ||a|     |
|       |n||                  ||n|    |n||                     ||n|     |n||                  ||n|     |
|       |s||Response   ||s|    |s||Response       ||s|     |s||Response  ||s|       |
|       +-+|<-------      |+-+    +-+|<-------          |+-+     +-+|<-------|+-+       |
+---------+                  +---------+                      +---------+          +---------+
UAC                           Outbound                       Inbound                 UAS
                                       Proxy                            Proxy
                                                  图4: 事务关系
无状态的proxy并没有客户端或者服务端的事务。事务是一边基于UA或者有状态的proxy,另外一边也基于UA或者有状态的proxy。在SIP事务范畴下,无状态的proxy是用作透明转发很有效。客户端事务的用处是用于从一个元素中接收一个请求,这个客户端是内嵌的(这个元素就是”事务用户”或者TU;它可以是一个UA或者有状态的proxy),并且可靠的把这个请求传送到一个服务端事务。
 
客户端事务也负责接收应答并且把应答转交TU处理,过滤掉重发的应答或者不允许的应答(比如给ACK的应答)。另外,在INVITE请求的情况下,客户端事务也负责产生给2xx应答的ACK请求。
 
类似的,服务端事务也负责从通讯层接收请求并且转发这个请求到TU。服务端事务过滤重发的请求。并且服务端事务从TU接收应答并且转发到通讯层来发送。在INVITE事务的情况下,它需要接收给非2xx应答的终结应答的ACK请求。
 

2xx应答和它的ACK请求通过特定的方式来接收和处理。这个应答只会被UAS重发,并且它的ACK只由UAC产生。由于呼叫者知道整个已经接收呼叫的用户集合,所以需要这种端到端的处理。由于这样的特别处理,2xx应答的重发是基于UA核心的,并非基于通讯层。类似的,给2xx应答的ACK处理也是由UA核心处理的,每个路径上的proxy仅仅转发这些INVITE的2xx应答以及他们的ACK。

TGAS:SIP事务
评论【共有0条评论】查看所有评论
称呼:(*)   邮箱:   QQ:   验证码: 看不清楚?点击刷新验证码