青海西宁高端网站建设,wordpress 去除版本号,定制软件开发文案,网页版whatsapp怎么下载SIP协议是VoIP中最重要的信令控制协议。SIP中第一件事情就是主叫发送INVITE给被叫#xff0c;被叫响铃。本文从多角度详细描述INVITE消息发送的全过程。一、阅读RFC权威描述关于INVITE消息发送#xff0c;先查看RFC 3261中权威描述#xff1a;INVITE client transaction: ht…SIP协议是VoIP中最重要的信令控制协议。SIP中第一件事情就是主叫发送INVITE给被叫被叫响铃。本文从多角度详细描述INVITE消息发送的全过程。一、阅读RFC权威描述关于INVITE消息发送先查看RFC 3261中权威描述INVITE client transaction: https://tools.ietf.org/html/rfc3261#page-128从TU收到发送INVITE的要求通过transport层发出去进入Calling状态启动Timer ATimer A触发时发送INVITE启动Timer BTimer B触发时通知TU网络错误或收到1xx2xx300-699响应时处理逻辑各不相同Figure 5: INVITE client transactionINVITE server transaction: https://tools.ietf.org/html/rfc3261#page-136收到INVITE时将INVITE传给TU并进入Proceeding状态从TU收到100-199响应通过transport层发出去在Proceeding状态收到INVITE发送responseFigure 7- INVITE server transaction很容易产生几个疑问Q1: TU是什么意思实际中TU具体是什么Q2: 为什么要启动Timer A和Timer BQ3: 被叫收到INVITE是从哪里收到的Q4: “send 100 if TU wont in 200ms” 是什么意思实际中是怎样的二、理解基础细节Q1: TU是什么意思实际中TU具体是什么TU是Transaction User的缩写表示的是使用Transaction层服务的上层模块。从RFC 3261的 5 Structure of the Protocol 小节可以知道SIP协议是分层阐述的总结如下图从上图可知Transaction层上面是Core层所以TU就是Core层。对于主叫端是UAC Core对于被叫端是UAS Core对于代理服务器就是Proxy Core。如下面两图所示Q3: 被叫收到INVITE是从哪里收到的从上面的分层描述总很容易看出被叫收到INVITE是从Transport Sublayer收到的而Transport Sublayer是从具体使用系统网络传输层如UDP或TCP层收到的。小结将上面两个状态机和相关SIP消息综合在一起可以得到下图INVITE client and server transaction三、理解关键设计第一节阅读RFC时产生的疑问Q2和Q4都涉及到timer为什么要引入这些timer呢这就涉及到SIP协议设计上对底层网络的假设。RFC 3261中明确表示SIP works with both IPv4 and IPv6.即SIP是设计运行在IP网络协议之上的SIP最初设计就是为VoIP服务的。SIP协议对网络传输层没有可靠性的要求在不可靠的传输层如UDP上可以良好地工作。所以SIP就要自己保证信令消息的可靠性传输这也是SIP Transaction层的主要职责消息丢失重传、消息去重。自然地SIP Transaction层的状态机就要通过timer来实现重传通过状态迁移实现去重。具体解释如下Q2: 为什么要启动Timer A和Timer BTimer A的工作逻辑发出第一次INVITE请求在超时时间(第一次是0.5秒)内未收到任何响应则Timer A触发此时发出第二次INVITE请求将超时时间加倍后(0.5x21秒)重新计时超时未收到任何响应则Timer A再次触发INVITE的发送依此类推每次Timer A超时时间加倍。这样Timer A就实现了以经典的指数型延迟重试策略来确保INVITE的发送和响应接收如果INVITE发送失败如下图F01则Timer A会触发INVITE请求重发如果INVITE发送成功但响应返回途中丢失如下图F05则Timer A也会触发INVITE请求重发UAS收到重复的INVITE请求后保持状态为Proceeding不变重新发送响应给UACINVITE client and server transaction with timers上面解释了Timer A的作用确保INVITE成功送达且成功收到响应。那么Timer B呢很简单在无网或者网络很差的情况下INVITE不应无限重发这就是Timer B的作用当Timer B超时(RFC建议为32秒)触发时则停止发送给TU报告发送失败。Q4: “send 100 if TU wont in 200ms” 是什么意思实际中是怎样的在RFC 17.2.1 INVITE Server Transaction 中有明确说明When a server transaction is constructed for a request, it enters theProceeding state. The server transaction MUST generate a 100(Trying) response unless it knows that the TU will generate aprovisional or final response within 200 ms, in which case it MAYgenerate a 100 (Trying) response. This provisional response isneeded to quench request retransmissions rapidly in order to avoidnetwork congestion.简单来说如果transaction知道TU不会在200毫秒内发送一个响应那么transaction应立刻回一个100 Trying响应以便告知发送方自己已经接收到INVITE请求了请不要重传INVITE了。这样可以降低网络拥堵。要回答实际中UAS是否会发100 Trying响应要看端到端的消息发送过程了。我们看常见的 “客户端 - 服务端 - 客户端” 的网络拓扑下的情况从上图可以看到从主叫客户端UAC到服务端服务端要转发给被叫客户端服务端无法确定多久能转发完成于是在F02步骤立刻回复主叫客户端UAC一个100 Trying响应告诉主叫我收到你的INVITE了我在努力发送给被叫请不要重发INVITE了然后我们看被叫客户端UAS在F04步骤收到INVITE请求被叫的transaction知道其TU即UAS Core会立即响应一个180 Ringing所以被叫客户端UAS不会回复服务端100 Trying响应。总结一下整个INVITE发送到响铃的过程如下图要点如下通过Timer A和B来保障消息可靠送达通过状态机来实现消息去重
