IMS/SIP - 如何理解PRACK消息?

绝大多数人看IMS呼叫流程时,都容易自动忽略PRACK消息,原因是:

1) 大部分情况下,这条消息对理解呼叫流程影响不大。

2) 无法从字面看出PRACK是谁的缩写,而除了协议外,又很少有人讲PRACK,一般人又不喜欢看SIP协议,因为RFC协议属于INTERNET体系,其排版风格跟3GPP协议文档完全不一样,可读性对通信从业人员来说比较“差”,对于未知的东西,鸵鸟策略当然是“最佳”策略了。

但是有时候出问题,就是在那些非“大部分的情况下”,因此了解PRACK还是很有必要。

1. PRACK缘起

SIP提供两类响应消息(Response): 临时的(Provisional)和最终的(Final).

    - 最终响应消息(Final Responses后面简称FR)用于传达请求(比如INVITE请求)处理的结果。FR的发送过程是可靠的,也就是说FR发送出去后,要求收到确认结果(ACK). FR的一个例子是响应INVITE请求的200 OK消息。

    - 临时响应消息(Provisional Responses后面简称PR)用于提供请求处理过程中的信息,PR的一个例子是我们熟知180 Ringing.

在SIP主体协议RFC-3261里只要求对FR进行可靠传输,也就是要求发送出去后收到ACK,而对PR不要求可靠传输。

后来发现对于一些临时响应来说,其传输可靠性也很重要,比如180 Ringing对于决定呼叫状态(call state)非常关键,这就需要临时响应发出去后也能收到确认结果(ACK), 因此IETF专门针对这一点在SIP协议RFC-3261外进行了扩展,生成了一个新的协议:

<RFC 3262- Reliability of Provisional Responses in the Session Initiation Protocol (SIP)>

这样就引出了本文的主人公– PRACK.

PRACK是对PRACK(确认收到)消息。用于PR的可靠传输,也就是,发出的PR消息要求收到PRACK,否则PR消息将被重传。

这种发出的响应消息(Response)要求ACK的机制叫做可靠性机制- Reliability Mechanism.

2. PR传输的可靠性机制

1)如何开启PR的可靠性传输机制

也就是,什么情况下,UAC(User Agent Client)收到UAS(User Agent Server)的PR后需要回复PRACK呢?协议规定,如果UAC发送请求(比如Invite Request)的时候携带了Supported header  field: 100rel, 那么UAS回复的PR就要求UAC回复PRACK(UAC和UAS的概念会有专门笔记讲解,现在可以简单理解为客户端(请求端)和服务端).

//RFC 3262 - 3 UAS Behavior

A UAS MAY send any non-100 provisional response to INVITE reliably, so long as the initial INVITE request (the request whose provisional response is being sent reliably) contained a Supported header field with the option tag 100rel.

2) Backoff机制

PR的可靠性机制和FinalResponse类似,在设定的定时器超时后如果未收到PRACK,就会重传PR,直到收到PRACK, 请看协议描述:

//RFC3262 – 1 Introduction

The reliability mechanism works by mirroring the current reliability mechanisms for 2xx final responses to INVITE. Those requests are transmitted periodically by the Transaction User (TU) until a separate transaction, ACK, is received that indicates reception of the 2xx by the UAC.  The reliability for the 2xx responses to INVITE and ACK messages are end-to-end.  In order to achieve reliability for provisional responses, we do nearly the same thing.  Reliable provisional responses are retransmitted by the TU with an exponential backoff. Those retransmissions cease when a PRACK message isreceived.  The PRACK request plays the same role as ACK, but fo provisional responses.


 

3) 端到端的PR可靠性机制

PR可靠性机制只用于端到端(end-to-end),因此PRACK不能应用于“100 Trying ”,因为100 Trying是hop-to-hop消息,只有101~199 PR需要可靠传送,101~199 Provisional Response是end-to-end消息。

//RFC 3262 - 3 UAS Behavior

A UAS MUST NOT attempt to send a 100 (Trying) response reliably. Only provisional responses numbered 101 to 199 may be sent reliably. If the request did not include either a Supported or Require header field indicating this feature, the UAS MUST NOT send the provisional response reliably.

    100 (Trying) responses are hop-by-hop only.  For this reason, the reliability mechanisms described here, which are end-to-end, cannot be used.

3. PR/PRACK关键字段/头域(HeaderField)

各个关键字段的描述见右边文字,同颜色表示与左边流程图里消息里携带关键字段对应:

https://mmbiz.qpic.cn/mmbiz_png/CGdwVYoBFC4tved22ScH9A3SApfjgGWoAWjDP19rQDUUjB2UkveP4gCchQ6WU8UxHsiabT5hm8NVQBicqFr61qtQ/640?wx_fmt=png

4. 一个实例

我们来看一个消息log例子(log中关键字段/参数/数字颜色与上面描述中提到的对应):

---------- clip-----------

//手机接收到对端发过来的RINGING,该消息里携带Rseq

SIP Call ID=1482489267_2360040920@2409:8809:8530:857d:c575:f266:2aa0:dc24

SipMessage = SIP/2.0 180 Ringing

Via: SIP/2.0/TCP[2409:8809:8530:857D:C575:F266:2AA0:DC24]:8904;branch=z9hG4bK1019613377

Record-Route:<sip:[2409:8019:8430:4500:0000:0000:0000:0008]:9900;transport=tcp;lr;Hpt=8f62_116;CxtId=3;TRC=ffffffff-ffffffff;X-HwB2bUaCookie=14559>

Call-ID:1482489267_2360040920@2409:8809:8530:857d:c575:f266:2aa0:dc24

From:<sip:+8613603049709@gd.ims.mnc000.mcc460.3gppnetwork.org>;tag=1482489276

To:<tel:15723177335;phone-context=ims.mnc000.mcc460.3gppnetwork.org>;tag=55116ypd

CSeq:408747442INVITE

Allow:INVITE,ACK,OPTIONS,BYE,CANCEL,INFO,PRACK,NOTIFY,MESSAGE,REFER,UPDATE

Contact:<sip:[2409:8019:8430:4500:0000:0000:0000:0008]:9900;Hpt=8f62_16;CxtId=3;TRC=ffffffff-ffffffff>

Require:100rel

RSeq: 2

P-Early-Media: sendonly

P-Access-Network-Info: 3GPP-E-UTRAN;utran-cell-id-3gpp=46000286633BFE84;sbc-domain=sbc04.0755.gd.chinamobile.com;ue-ip=[2409:8809:8530:857D:C575:F266:2AA0:DC24];ue-port=8005;network-provided

Content-Length: 0

 //手机回复PRACK消息

SIP Call ID =1482489267_2360040920@2409:8809:8530:857d:c575:f266:2aa0:dc24

Sip Message = PRACK

sip[2409:8019:8430:4500:0000:0000:0000:0008]:9900;Hpt=8f62_16;CxtId=3;TRC=ffffffff-ffffffffSIP/2.0

i:1482489267_2360040920@2409:8809:8530:857d:c575:f266:2aa0:dc24

f:<sip:+8613603049709@gd.ims.mnc000.mcc460.3gppnetwork.org>;tag=1482489276

t:<tel:15723177335;phone-context=ims.mnc000.mcc460.3gppnetwork.org>;tag=55116ypd

CSeq:408747444PRACK

P-Access-Network-Info:3GPP-E-UTRAN-TDD;utran-cell-id-3gpp=46000286633BFE84

l: 0

v:SIP/2.0/TCP[2409:8809:8530:857d:c575:f266:2aa0:dc24]:8904;branch=z9hG4bK3379790848

Max-Forwards: 70

Security-Verify:ipsec-3gpp;alg=hmac-md5-96;prot=esp;mod=trans;ealg=null;spi-c=2643107290;spi-s=3412854899;port-c=9950;port-s=9900

RAck: 408747442 INVITE

Route:<sip:[2409:8019:8430:4500:0000:0000:0000:0008]:9900;transport=tcp;lr;Hpt=8f62_116;CxtId=3;TRC=ffffffff-ffffffff;X-HwB2bUaCookie=14559>

Proxy-Require: sec-agree

Require: sec-agree

k: timer

---------- clip-----------


笔者在公众号“协议工程师笔记”定期发布5G/LTE/IMS...学习笔记, 敬请关注、订阅和分享,谢谢!

                                                               图片

                                                                      一起努力,蒸蒸日上



  • 1
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1 IMS培训教程——SIP协议 北京阿法迪信息技术研究中心 2 目 录 SIP协议概述 SIP协议报文分析 SIP协议在IMS网络中的应用 3 什么是 SIP? SIP: Session Initiation Protocol 用于建立,控制和释放会话 SIP是 IETF 为多媒体会话而开发制定的协议 这里的会话包括文本,视频,游戏和传统的语音 SIP 是为Internet 而制定设计的协议 象HTTP协议一样是基于文本的 询问/应答机制 广泛应用于internet 可以基于UDP、TCP和SCTP传输,目前最常用UDP 4 协议簇 信令协议 – 注册、定位用户、路由 – 建立,修改,释放会话 媒体传输协议 – 用于传输语音/视频包 SIP – 信令协议 会话的管理(SIP)和会话的描述(SDP)是分离的 5 SIP的基本功能 SIP的5个方面基本功能: 用户定位(User Location):决定哪个终端系统参加通信 用户能力(User Capabilities):决定通信所采用的媒体和媒体参数 用户可用性(User Availability):决定被叫方是否愿意加入通信过程 呼叫建立(Call setup):振铃、主叫方和被叫方的连接和参数的建立 呼叫处理(Call handling):前转或终结呼叫 6 会话相关协议 SDP (Session Description Protocol) – 总是作为SIP消息体出现 – 会话描述协议和会话管理(SIP)协议是互相独立的 RTP (Real-time Transmission Protocol) – 用于在IP网上传输经过打包的实时媒体流,例如. 语音,视频 RTCP (Real-time Transmission Control Protocol) – 用于反馈媒体传输的质量报告信息 7 简单SIP网络架构 SIP Request SIP Request Media Stream (RTP) User Agent (Server) 接受SIP 请求 Request Proxy Server 决定把信令消息送到何 处 User Agent (Client) 发送SIP请求 SIP Response SIP Response 8 SIP逻辑实体 SIP 使用客户端/服务器架构 逻辑SIP实体包括 用户代理 (UA) User Agent Client (UAC): 发起SIP请求 User Agent Server (UAS): 返回SIP响应 一个实体可以既是客户 端,又是服务器 注册服务器: SIP客户端需要利用注册请求 来更新用户的位臵信息 代理服务器:为客户端转发请求或者响应。 可以同时做为服务器端和客户端,决定下 一跳转发请求消息 重定向服务器:将请求中的地址映射为零个 或多个新的地址,返回给客户端。 网络服务器 9 事务和对话 对话 – 是两个UE之间为建立、更改和释放媒体会 话所需要建立的信令关系,对话起始于 INVITE请求,并终止于BYE请求的200(OK )响应,INVITE 是唯一可以创建一个对 话的命令. – 一个对话由头域中的Call-ID, Local Tag and Remote Tag 等参数来标识 – 一个对话可以包括多个事务 事务 事务是指客户端发送到服务器的请 求以及服务器回送至客户端的所 有响应 包括一个请求和一个或多个响应 包含一个最终响应 (非1xx 响应) 使用 via域中的branch参数来定义 一个事务 10 事务和对话(2) 事务 – 一个请求和其所有的响应 Invite 180 Ringing 200 ok 183 对话 包含多个事务 Invite 180 Ringing ACK PRACK 183 200 200 200 Bye T1 T4 T3 T2 T1 11 目 录 SIP协议概述 SIP协议报文分析 SIP协议在IMS网络中的应用 12 目 录 SIP协议报文分析 –2.1 消息类型 –2.2 消息结构 –2.3 消息参数 13 消息类型 SIP 消息可以被分为两类: 请求 发起一个会话 响应 对请求的响应. 14 SIP请求消息 SIP 消息-请求消息 INVITE: 发起会话请求 ACK: 对 INVITE 请求的响应的确认 CANCEL: 取消尚未完成的请求 BYE: 结束会话 REGISTER: 注册,完成地址绑定 OPTIONS: 查询服务器能力 15 SIP相应消息 SIP 消息-响应消息 1xx: 临时响应 –表示已经接收到请求消息,正在对其进行处理 2xx: 成功 –表示请求已经被成功接受、处理 3xx: 重定向 --表示需要采取进一步动作,以完成该请求 4xx: 客户端错误 –表示请求消息中包

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值