SIP呼叫中关于PRACK的使用

已于 2022-11-23 17:44:22 修改
阅读量3.8k 收藏 7
点赞数 1
分类专栏： SIP 文章标签： 网络 p2p 服务器
于 2020-10-15 19:17:33 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_41681715/article/details/109103286
版权

PRACK是SIP消息中保证临时消息(101-199)可靠传输的机制。为达到该目的，UAC有两种选择，在inivite消息中加入Require:100rel或者Supported:100rel。UAS在接受到上述消息中，也存在选择的问题。

如果SIP UAC支持PRACK，则应该在INVITE消息的Allow字段携带PRACK，同时要在Suppoted字段中携带100rel，如果被叫回复的1XX临时响应中(一般是183)携带有Require: 100rel和RSeq字段，收到UAS回复的1XX消息的UAC应该发送PRACK，否则不发送不发送PRACK字段。

当Inivte中含有Require:100rel。UAS如果不支持PRACK需要使用420（不正确的扩展）来拒绝呼叫。否则临时消息中加入Require:100rel和Rseq字段，接到该消息UAC发送PRACK。

下面为其中的一个具体示例：

INVITE sip:+8699999@ims.ge.xxxx.com;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bK78BB08C70016d07401a8c0
From: "WIN226069200927" <sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>
CSeq: 1 INVITE
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
Contact: <sip:+8699999@192.168.1.116:5060;transport=tcp>;+sip.instance="<urn:uuid:22de3a79-ebe0-435b-9077-b5d9bfb95e02>"
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
Resource-Priority: dsn-000000.0
User-Agent: Polycom RealPresence Desktop for Windows (3.9.0.69889)
Supported: 100rel,timer,replaces,resource-priority
MRD: MRE; MRC-V=1.0.1
Multiplexing: EP
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 2165

v=0
o=- 1602753082 1602753082 IN IP4 192.168.1.116
s=MRD=MRE MRC-V=1.0.1
c=IN IP4 192.168.1.116
b=AS:1024
t=0 0
a=sendrecv
a=vnd.polycom.MBA.p2p:v=1.0.1
m=audio 3230 RTP/AVP 118 115 114 9 102 113 101 103 0 8 15 18 119
a=sendrecv
a=rtpmap:118 SIRENLPR/48000/1
a=fmtp:118 bitrate=64000
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:114 G7221/32000
a=fmtp:114 bitrate=32000
a=rtpmap:9 G722/8000
a=fmtp:9 bitrate=64000
a=rtpmap:102 G7221/16000
a=fmtp:102 bitrate=32000
a=rtpmap:113 G7221/32000
a=fmtp:113 bitrate=24000
a=rtpmap:101 G7221/16000
a=fmtp:101 bitrate=24000
a=rtpmap:103 G7221/16000
a=fmtp:103 bitrate=16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:15 G728/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:119 telephone-event/8000
a=fmtp:119 0-15
m=video 3232 RTP/AVP 111 109 110 96 34 31 106 105 116
a=sendrecv
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=vnd.polycom.forceVideoMode:9
a=rtpmap:111 H264/90000
a=fmtp:111 profile-level-id=64001f; packetization-mode=1; max-br=20010; sar=13
a=vnd.polycom.avcplus.p2p:111 max-temp-layer-p2p=3
a=rtpmap:109 H264/90000
a=fmtp:109 profile-level-id=42801f; max-br=20010; sar=13
a=vnd.polycom.avcplus.p2p:109 max-temp-layer-p2p=3
a=rtpmap:110 H264/90000
a=fmtp:110 profile-level-id=42801f; packetization-mode=1; max-br=20010; sar=13
a=vnd.polycom.avcplus.p2p:110 max-temp-layer-p2p=3
a=rtpmap:96 H263-1998/90000
a=fmtp:96 CIF4=1;CIF=1;QCIF=1;SQCIF=1;CUSTOM=352,240,1;CUSTOM=704,480,1;CUSTOM=1024,768,1;CUSTOM=800,600,1;CUSTOM=640,480,1;T
a=rtpmap:34 H263/90000
a=fmtp:34 CIF4=1;CIF=1;QCIF=1;SQCIF=1
a=rtpmap:31 H261/90000
a=fmtp:31 CIF=1;QCIF=1
a=rtpmap:106 H264-SVC/90000
a=fmtp:106 profile-level-id=56001f; packetization-mode=1; max-br=20010; sar=13
a=rtpmap:105 H264-SVC/90000
a=fmtp:105 profile-level-id=53e01f; packetization-mode=1; max-br=20010; sar=13
a=rtpmap:116 vnd.polycom.lpr/9000
a=fmtp:116 V=2;minPP=0;PP=150;RS=52;RP=10;PS=1400
m=application 3238 UDP/BFCP *
a=sendrecv
a=setup:actpass
a=connection:new
a=floorctrl:c-s
m=application 3236 RTP/AVP 100
a=sendrecv
a=rtpmap:100 H224/4800


SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bK78BB08C70016d07401a8c0;received=122.224.115.1;rport=63649
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
From: "WIN226069200927"<sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>
CSeq: 1 INVITE
Content-Length: 0

SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bK78BB08C70016d07401a8c0;received=122.224.115.1;rport=63649
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
From: "WIN226069200927"<sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>;tag=y8bhldlx
CSeq: 1 INVITE
Proxy-Authenticate: Digest realm="ims.ge.xxxxx.com",nonce="4kdfCTFDN2yxatf535ld3A==",algorithm=MD5,qop="auth"
Warning: 399 38002.588.S.261.5.105.0.17.34315.0.0.ge.chinamobile.com "Proxy authentication required"
Reason: Q.850;cause=21,SIP;cause=407
Content-Length: 0

ACK sip:+8699999@ims.ge.xxxxx.com;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bK78BB08C70016d07401a8c0
From: "WIN226069200927" <sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>;tag=y8bhldlx
CSeq: 1 ACK
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
Contact: <sip:+861099999@192.168.1.116:5060;transport=tcp>;+sip.instance="<urn:uuid:22de3a79-ebe0-435b-9077-b5d9bfb95e02>"
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
User-Agent: Polycom RealPresence Desktop for Windows (3.9.0.69889)
Max-Forwards: 70
Content-Length: 0

INVITE sip:+8699999@ims.ge.xxxxx.com;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bK2CEFE14B0016d07401a8c0
From: "WIN226069200927" <sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>
CSeq: 2 INVITE
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
Contact: <sip:+861099999@192.168.1.116:5060;transport=tcp>;+sip.instance="<urn:uuid:22de3a79-ebe0-435b-9077-b5d9bfb95e02>"
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
Resource-Priority: dsn-000000.0
User-Agent: Polycom RealPresence Desktop for Windows (3.9.0.69889)
Supported: 100rel,timer,replaces,resource-priority
MRD: MRE; MRC-V=1.0.1
Multiplexing: EP
Proxy-Authorization: Digest username="861099999@ims.ge.xxxxx.com", realm="ims.ge.xxxxx.com", nonce="4kdfCTFDN2yxatf535ld3A==", qop=auth, cnonce="XsWKG9GNC0fKzpn", nc=00000001, uri="sip:+8699999@ims.ge.xxxxx.com;transport=tcp", response="6e17335fb50cba9cfdef9b1c6b54aaf6", algorithm=MD5
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 2165

v=0
o=- 1602753082 1602753082 IN IP4 192.168.1.116
s=MRD=MRE MRC-V=1.0.1
c=IN IP4 192.168.1.116
b=AS:1024
t=0 0
a=sendrecv
a=vnd.polycom.MBA.p2p:v=1.0.1
m=audio 3230 RTP/AVP 118 115 114 9 102 113 101 103 0 8 15 18 119
a=sendrecv
a=rtpmap:118 SIRENLPR/48000/1
a=fmtp:118 bitrate=64000
a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:114 G7221/32000
a=fmtp:114 bitrate=32000
a=rtpmap:9 G722/8000
a=fmtp:9 bitrate=64000
a=rtpmap:102 G7221/16000
a=fmtp:102 bitrate=32000
a=rtpmap:113 G7221/32000
a=fmtp:113 bitrate=24000
a=rtpmap:101 G7221/16000
a=fmtp:101 bitrate=24000
a=rtpmap:103 G7221/16000
a=fmtp:103 bitrate=16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:15 G728/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:119 telephone-event/8000
a=fmtp:119 0-15
m=video 3232 RTP/AVP 111 109 110 96 34 31 106 105 116
a=sendrecv
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=vnd.polycom.forceVideoMode:9
a=rtpmap:111 H264/90000
a=fmtp:111 profile-level-id=64001f; packetization-mode=1; max-br=20010; sar=13
a=vnd.polycom.avcplus.p2p:111 max-temp-layer-p2p=3
a=rtpmap:109 H264/90000
a=fmtp:109 profile-level-id=42801f; max-br=20010; sar=13
a=vnd.polycom.avcplus.p2p:109 max-temp-layer-p2p=3
a=rtpmap:110 H264/90000
a=fmtp:110 profile-level-id=42801f; packetization-mode=1; max-br=20010; sar=13
a=vnd.polycom.avcplus.p2p:110 max-temp-layer-p2p=3
a=rtpmap:96 H263-1998/90000
a=fmtp:96 CIF4=1;CIF=1;QCIF=1;SQCIF=1;CUSTOM=352,240,1;CUSTOM=704,480,1;CUSTOM=1024,768,1;CUSTOM=800,600,1;CUSTOM=640,480,1;T
a=rtpmap:34 H263/90000
a=fmtp:34 CIF4=1;CIF=1;QCIF=1;SQCIF=1
a=rtpmap:31 H261/90000
a=fmtp:31 CIF=1;QCIF=1
a=rtpmap:106 H264-SVC/90000
a=fmtp:106 profile-level-id=56001f; packetization-mode=1; max-br=20010; sar=13
a=rtpmap:105 H264-SVC/90000
a=fmtp:105 profile-level-id=53e01f; packetization-mode=1; max-br=20010; sar=13
a=rtpmap:116 vnd.polycom.lpr/9000
a=fmtp:116 V=2;minPP=0;PP=150;RS=52;RP=10;PS=1400
m=application 3238 UDP/BFCP *
a=sendrecv
a=setup:actpass
a=connection:new
a=floorctrl:c-s
m=application 3236 RTP/AVP 100
a=sendrecv
a=rtpmap:100 H224/4800


SIP/2.0 100 Trying
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bK2CEFE14B0016d07401a8c0;received=122.224.115.1;rport=63649
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
From: "WIN226069200927"<sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>
CSeq: 2 INVITE
Content-Length: 0


SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bK2CEFE14B0016d07401a8c0;received=122.224.115.1;rport=63649
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
From: "WIN226069200927"<sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>;tag=3758
CSeq: 2 INVITE
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER,PUBLISH
Contact: <sip:103.212.118.1:5060;transport=tcp;did=mdxbu1-1602734578610;Hpt=8e72_16;CxtId=3;TRC=ffffffff-ffffffff>;servhuawei
Require: 100rel,100rel
RSeq: 1
P-Early-Media: gated
Content-Length: 304
Content-Type: application/sdp

v=0
o=- 1073768536 1073768536 IN IP4 103.212.118.2
s=SBC call
b=AS:1024
t=0 0
m=audio 22962 RTP/AVP 0 119
c=IN IP4 103.20.114.2
a=rtpmap:0 PCMU/8000
a=rtpmap:119 telephone-event/8000
a=ptime:20
m=video 22964 RTP/AVP 34
c=IN IP4 103.20.114.2
a=rtpmap:34 H263/90000
a=fmtp:34 CIF=1/MaxBR=3840


PRACK sip:103.212.118.1:5060;transport=tcp;did=mdxbu1-1602734578610;Hpt=8e72_16;CxtId=3;TRC=ffffffff-ffffffff SIP/2.0
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bK26A1A7D50016d07401a8c0
From: "WIN226069200927" <sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>;tag=3758
CSeq: 3 PRACK
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
Contact: <sip:+861099999@192.168.1.116:5060;transport=tcp>;+sip.instance="<urn:uuid:22de3a79-ebe0-435b-9077-b5d9bfb95e02>"
User-Agent: Polycom RealPresence Desktop for Windows (3.9.0.69889)
RAck: 1 2 INVITE
Proxy-Authorization: Digest username="861099999@ims.ge.xxxxx.com", realm="ims.ge.xxxxx.com", nonce="4kdfCTFDN2yxatf535ld3A==", qop=auth, cnonce="XsWKG9GNC0fKzpn", nc=00000002, uri="sip:+8699999@ims.ge.xxxxx.com;transport=tcp", response="452202ddc18b1b933e7f1d76ee9d0fce", algorithm=MD5
Max-Forwards: 70
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bK26A1A7D50016d07401a8c0;received=122.224.115.1;rport=63649
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
From: "WIN226069200927"<sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>;tag=3758
CSeq: 3 PRACK
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bK2CEFE14B0016d07401a8c0;received=122.224.115.1;rport=63649
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
From: "WIN226069200927"<sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>;tag=3758
CSeq: 2 INVITE
Authentication-Info: nextnonce="WObta02snlkVDH6OeTYUIQ==",qop=auth,rspauth="ae61b08697e936d7a1a0420ac6374eaa",cnonce="XsWKG9GNC0fKzpn",nc=00000001
Contact: <sip:103.212.118.1:5060;transport=tcp;did=mdxbu1-1602734578610;Hpt=8e72_16;CxtId=3;TRC=ffffffff-ffffffff>;servhuawei
Require: timer
Session-Expires: 1800;refresher=uac
Content-Length: 0

ACK sip:103.212.118.1:5060;transport=tcp;did=mdxbu1-1602734578610;Hpt=8e72_16;CxtId=3;TRC=ffffffff-ffffffff SIP/2.0
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bKACF8216C0016d07401a8c0
From: "WIN226069200927" <sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>;tag=3758
CSeq: 2 ACK
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
Contact: <sip:+861099999@192.168.1.116:5060;transport=tcp>;+sip.instance="<urn:uuid:22de3a79-ebe0-435b-9077-b5d9bfb95e02>"
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,INFO,MESSAGE,SUBSCRIBE,NOTIFY,PRACK,UPDATE,REFER
User-Agent: Polycom RealPresence Desktop for Windows (3.9.0.69889)
Max-Forwards: 70
Content-Length: 0

BYE sip:103.212.118.1:5060;transport=tcp;did=mdxbu1-1602734578610;Hpt=8e72_16;CxtId=3;TRC=ffffffff-ffffffff SIP/2.0
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bKCDF6648F0016d07401a8c0
From: "WIN226069200927" <sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>;tag=3758
CSeq: 4 BYE
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
Contact: <sip:+861099999@192.168.1.116:5060;transport=tcp>;+sip.instance="<urn:uuid:22de3a79-ebe0-435b-9077-b5d9bfb95e02>"
User-Agent: Polycom RealPresence Desktop for Windows (3.9.0.69889)
Max-Forwards: 70
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.1.116:5060;branch=z9hG4bKCDF6648F0016d07401a8c0;received=122.224.115.1;rport=63649
Call-ID: e7e2e738-1017a271-35fd09c6@192.168.1.116
From: "WIN226069200927"<sip:+861099999@ims.ge.xxxxx.com>;tag=3C4B6CC4-47FC1DCD
To: <sip:+8699999@ims.ge.xxxxx.com>;tag=3758
CSeq: 4 BYE
Content-Length: 0

Acmen_voip
关注
专栏目录
sipp脚本撰写（二）
qq_30615731的博客
08-23 5915
1.1脚本撰写 进行脚本撰写之前需要熟悉一些默认的参数关键字： 关键词 默认值 说明 【service】 service 由参数-s传递，一般用来指定单个主被叫 [remote_ip] 远端设备地址 [remote_port] 远端设备端口。可以在脚本中使用偏移量，如[remote_port+3] [local_i...
SIP协议之PRACK机制
szkbsgy的专栏
03-19 2435
SIP PRACK（Provisional Response ACKnowledgement）是由SIP的扩展协议RFC3262定义的，旨在为SIP的临时应答提供传输的可靠性。扩展机制使用选项100rel和临时应答方法PRACK实现。该机制同SIP协议中的2xx对INVITE应答的可靠机制类似。 流程图： 信令流程： 编号1：1015呼叫1012 INVITE sip:1012@192.168.0.24:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.0.2...
SIP ——了解PRACK
热门推荐
marken
04-09 1万+
概述 SIP定义了两种应答：临时（provisional)和最终（final）。 最终应答传送的是请求处理的结果，是可靠性的（reliably）。 而临时应答传送的是处理过程的信息，由RFC3261是非可靠的。 但是由现在的情况看来，特别是与PSTN交互过程中发现：临时应答也应该是可靠的。 RFC3262定义了一种SIP可选的扩展方法——PRACK（provisional ack），用
sip 协议 --PRACK
fancw的专栏
09-04 6429
1.   概念 ：   sip 协议中的PRACK 英文全称：Provisional Response ACKnowledgement      。临时恢复确认。 详细描述在：RFC3262中  http://www.ietf.org/rfc/rfc3262.txt 2. 目的：确保sip中  1xx  响应的可靠传输。  PRACK一般是对收到183 call in progress/1
SIP中的PRACK
blade2001的专栏
05-08 4225
PRACK：the Provisional Response ACKnowledgement   SIP中的最终响应被理解是会可靠传输的，例如对应INVITE的200OK响应，UAC会给一个ACK，告诉UAS已经收到了200OK。200与ACK间的可靠性是end-to-end的。PRACK是SIP消息中保证临时消息(101-199)可靠传输的机制。PRACK就是仿照200OK的可靠性响
IMS/SIP - 如何理解PRACK消息？
yu_yuan_hong的专栏
10-13 1万+
我们先来看看协议里对PRACK的解释：4.1.13 PRACK The PRACK [28] method is used to acknowledge receipt of reliably transported provisional responses (1xx). The reliability of 2xx, 3xx, 4xx
SIP呼叫流程详解：从注册到呼叫释放
"SIP呼叫流程典型流程包括注册、注销、基本呼叫建立、会话更改、呼叫释放、被叫忙处理、被叫无应答、呼叫转移、呼叫保持和呼叫等待等多个步骤，详细解析了SIP协议在实际通信中的操作流程。" SIP（Session ...
SIP扩展方法研究：PRACK与UPDATE详解
本文由北京邮电大学的李晓琴和詹舒波撰写，重点关注了SIP的两个关键扩展方法：PRACK（Pre-Answering Request with ACKnowledgement）和UPDATE。 PRACK是一个临时响应的可靠性增强机制，它允许在会话请求阶段就发送...
SIP常用消息实例参考 7、PRACK消息
无垠的天空专栏
10-24 2270
7、PRACK消息         1）头字段填写说明         必选头域如下：         Call-id         Cseq         From         To         Max-Forwards         Via         RAck         常用可选头域：         Content-Type        
PRACK消息
求真得真的博客
08-25 472
PRACK消息是sip协议的扩展，在RFC3262中定义，标准的名称是sip协议中的可靠临时响应。本文简单介绍标准中对PRACK消息流程的描述，以及fs配置PRACK的方式。freeswitch对PRACK的处理和RFC标准基本一致。如果呼叫场景中早期媒体比较重要，而且因为网络问题经常丢失，就需要开启100rel来保证早期媒体的可靠消息。空空如常求真得真。
IMS注册及CALL SIP信令分析
06-07
IMS注册及CALL SIP信令分析
SIP 请求方法（10）- PRACK
至虛極，守靜篤
02-03 1853
RFC3262定义了PRACK方法，它用于保证临时应答(1xx)的传输可靠性。INVITE请求的2xx, 3xx, 4xx, 5xx, 与 6xx应答的可靠性是通过ACK方法确定的。但是，如果临时应答(比如180 Ringing)对呼叫状态至关重要，则可能需要对收到的临时应答进行确认。PRACK方法适用于除了100 Trying之外的所有临时应答消息，它们在3261中没有可靠性保证。 UAC收到临时应答时，如果消息中包含RSeq可靠序列号和Supported: 100rel...
SIP协议中关于PRACK消息的研究
李永亮的专栏
08-23 9457
       PRACK是SIP消息中保证临时消息(101-199)可靠传输的机制。为达到该目的，UAC有两种选择，在inivite消息中加入Require:100rel或者Supported:100rel。UAS在接受到上述消息中，也存在选择的问题。       当Inivte中含有Supported:100rel，UAS在发送临时消息中，可以根据UAS中是否支持PRACK决定发送临时消息中
SIP PRACK method
最新发布
asd199086的博客
01-25 1156
对于provisional response可靠性，则采用相同的方式。如果UAC不希望一直使用可靠的provisional response，而只是在UAS需要发送response时才需要，那UAC request中的Supported header 必须包含带有option tag的100rel。如果收到初始请求的provisional response，并且该response有 Require header field 包含option tag 100rel，则代表要可靠地发送该response。
高通平台IMS短信发送流程
qq_42787177的博客
10-18 2767
IMS网络下短信发送流程
SIP协议中临时响应的可靠性
李永亮的专栏
10-08 5524
这次测试的过程中，出现困扰最多的问题是网关在呼叫过程中，没有收到Alerting事件，导致状态机的紊乱。实际上，SIP协议已经定义了临时响应的可靠性。在SIP标准中规定，规定了在呼叫建立过程中对临时消息可靠传输的定义，在其他过程中，可以借鉴这种机制，但是不是作为标准制定。如果呼叫建立需要支持临时消息的可靠性，需要加上SIP头——supported或者require，该头部任选参数为100rel
【SIP基础】SIP协议消息-掌握SIP的核心方法
VVSIP官网博客
09-05 4586
SIP消息有两种类型：请求和响应。 一个请求的打开行包含定义，其中该请求是要被发送的方法，它定义请求，以及请求URI。 同样响应的打开行包含一个响应代码。 请求方法SIP请求是用于建立通信的代码。为了补充它们，SIP响应其通常指示请求是成功还是失败。有一些命令称作方法，使SIP消息可行。 ME
SIP:100rel 扩展
weixin_30621919的博客
02-01 429
SIP:100rel 扩展 100rel扩展即是对中间状态响应的确认（即1xx的响应码）。原先在sip里，只有针对invite请求的200ok响应才会有ack，那么当中间状态响应携带重要的会话参数信息时，例如183响应，客户端是否收到响应就没有ack请求了，于是就定义了prack这一请求消息，即对中间状态响应的确认请求。当sip发送者支持这一扩展时，及在support头域增加这个100r...
VoLTE
星晓
10-16 1460
锚定（Anchoring）是指将呼叫从CS网络路由到IMS网络进行业务处理的过程。LTE用户通过CS网络接入，并且签约了IMS网络业务LTE用户作为被叫用户通过LTE网络接入，并且主叫用户为CS网络用户切换是指当LTE用户在通话过程中， 终端移动出LTE覆盖，并注册至2/3G网络时，终端与网络配合将话音无缝的从LTE切换至2/3G网络，通话不中断。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值