SIP ACK响应SIP 200 OK消息的有效性

时间:2015-09-14 20:00:19

标签: sip

我们正在向我们的合作伙伴发送一个SIP电话。他们在200 OK消息中向我们发送“Record-Route”和“Contact”标题。我们方正在向Record-Route中提到的IP地址发送ACK,但是它正在用“Route”标头替换“Contact”标头,而另一方则没有遵守我们的ACK并向我们发送重复的200 OK,这导致呼叫断开。 / p>

我不确定我们是否通过更改" Contact"违反了任何SIP RFC。标题为"路线"同时保持标题的内容。任何人都可以了解它吗?

以下是合作伙伴方面的200 OK:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.100.100.100;received=100.100.100.100;rport=5060
Record-Route: <sip:200.200.200.2:5060;lr>
Contact: <sip:+100@10.10.10.135:7654>
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 INVITE
Allow: ACK, INVITE, BYE, CANCEL
Content-Type: application/sdp
Server: YATE/3.0.0
Content-Length: 195

v=0
o=yate 1441225325 1441225325 IN IP4 201.201.201.30
s=SIP Call
c=IN IP4 201.201.201.30
t=0 0
m=audio 19305 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

这是我们对200 OK消息的确认:

ACK sip:200.200.200.2:5060 SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:+100@10.10.10.135:7654>
Content-Length: 0

以下是整个SIP对话框:

INVITE sip:+200@200.200.200.2:5060 SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100
To: +200<sip:+200@200.200.200.2:5060>
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
Contact: +100<sip:+100@100.100.100.100:5060>
User-Agent: Excel_CSP/84.11.34
Supported: timer
Session-Expires: 3660
Min-SE: 300
CSeq: 1 INVITE
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 144

v=0
o=sip 0 0 IN IP4 100.100.100.100
s=SIP_Call
c=IN IP4 100.100.100.230
t=0 0
m=audio 46750 RTP/AVP 0 101
a=rtpmap:101 telephone-event/8000

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 100.100.100.100;received=100.100.100.100;rport=5060
Record-Route: <sip:200.200.200.2:5060;lr>
To: +200<sip:+200@200.200.200.2:5060>
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 INVITE
Server: YATE/3.0.0
Content-Length: 0

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 100.100.100.100;received=100.100.100.100;rport=5060
Record-Route: <sip:200.200.200.2:5060;lr>
Contact: <sip:+100@10.10.10.135:7654>
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 INVITE
Allow: ACK, INVITE, BYE, CANCEL
Server: YATE/3.0.0
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.100.100.100;received=100.100.100.100;rport=5060
Record-Route: <sip:200.200.200.2:5060;lr>
Contact: <sip:+100@10.10.10.135:7654>
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 INVITE
Allow: ACK, INVITE, BYE, CANCEL
Content-Type: application/sdp
Server: YATE/3.0.0
Content-Length: 195

v=0
o=yate 1441225325 1441225325 IN IP4 201.201.201.30
s=SIP Call
c=IN IP4 201.201.201.30
t=0 0
m=audio 19305 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

ACK sip:200.200.200.2:5060 SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:+100@10.10.10.135:7654>
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.100.100.100;received=100.100.100.100;rport=5060
Record-Route: <sip:200.200.200.2:5060;lr>
Contact: <sip:+100@10.10.10.135:7654>
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 INVITE
Allow: ACK, INVITE, BYE, CANCEL
Content-Type: application/sdp
Server: YATE/3.0.0
Content-Length: 195

v=0
o=yate 1441225325 1441225325 IN IP4 201.201.201.30
s=SIP Call
c=IN IP4 201.201.201.30
t=0 0
m=audio 19305 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
ACK sip:200.200.200.2:5060 SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:+100@10.10.10.135:7654>
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.100.100.100;received=100.100.100.100;rport=5060
Record-Route: <sip:200.200.200.2:5060;lr>
Contact: <sip:+100@10.10.10.135:7654>
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 INVITE
Allow: ACK, INVITE, BYE, CANCEL
Content-Type: application/sdp
Server: YATE/3.0.0
Content-Length: 195

v=0
o=yate 1441225325 1441225325 IN IP4 201.201.201.30
s=SIP Call
c=IN IP4 201.201.201.30
t=0 0
m=audio 19305 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
ACK sip:200.200.200.2:5060 SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:+100@10.10.10.135:7654>
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.100.100.100;received=100.100.100.100;rport=5060
Record-Route: <sip:200.200.200.2:5060;lr>
Contact: <sip:+100@10.10.10.135:7654>
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 INVITE
Allow: ACK, INVITE, BYE, CANCEL
Content-Type: application/sdp
Server: YATE/3.0.0
Content-Length: 195

v=0
o=yate 1441225325 1441225325 IN IP4 201.201.201.30
s=SIP Call
c=IN IP4 201.201.201.30
t=0 0
m=audio 19305 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
ACK sip:200.200.200.2:5060 SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:+100@10.10.10.135:7654>
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.100.100.100;received=100.100.100.100;rport=5060
Record-Route: <sip:200.200.200.2:5060;lr>
Contact: <sip:+100@10.10.10.135:7654>
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 INVITE
Allow: ACK, INVITE, BYE, CANCEL
Content-Type: application/sdp
Server: YATE/3.0.0
Content-Length: 195

v=0
o=yate 1441225325 1441225325 IN IP4 201.201.201.30
s=SIP Call
c=IN IP4 201.201.201.30
t=0 0
m=audio 19305 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
ACK sip:200.200.200.2:5060 SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:+100@10.10.10.135:7654>
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.100.100.100;received=100.100.100.100;rport=5060
Record-Route: <sip:200.200.200.2:5060;lr>
Contact: <sip:+100@10.10.10.135:7654>
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 INVITE
Allow: ACK, INVITE, BYE, CANCEL
Content-Type: application/sdp
Server: YATE/3.0.0
Content-Length: 195

v=0
o=yate 1441225325 1441225325 IN IP4 201.201.201.30
s=SIP Call
c=IN IP4 201.201.201.30
t=0 0
m=audio 19305 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv


ACK sip:200.200.200.2:5060 SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100
To: +200<sip:+200@200.200.200.2:5060>;tag=784054843
From: +100<sip:+100@100.100.100.100:5060>;tag=4244235125227
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:+100@10.10.10.135:7654>
Content-Length: 0

BYE sip:+100@100.100.100.100:5060 SIP/2.0
Via: SIP/2.0/UDP 200.200.200.2:5060;branch=z9hG4bK-524287-1---baf0e608a3be462e3d9534147efb1150;rport
Via: SIP/2.0/UDP 10.10.10.135:7654;rport=7654;branch=z9hG4bK962836463;received=10.10.10.135
Max-Forwards: 69
Record-Route: <sip:200.200.200.2:5060;lr>
To: <sip:+100@100.100.100.100:5060>;tag=4244235125227
From: <sip:+200@200.200.200.2:5060>;tag=784054843
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 95618 BYE
Allow: ACK, INVITE, BYE, CANCEL
User-Agent: YATE/3.0.0
Reason: SIP;cause=408;text="Request Timeout"
Content-Length: 0

SIP/2.0 200 OK 
To: <sip:+100@100.100.100.100:5060>;tag=4244235125227
From: <sip:+200@200.200.200.2:5060>;tag=784054843
Call-ID: CANTATA21.1a8.1200679.50@100.100.100.100
CSeq: 95618 BYE
Record-Route: <sip:200.200.200.2:5060;lr>
Via: SIP/2.0/UDP 200.200.200.2:5060;branch=z9hG4bK-524287-1---baf0e608a3be462e3d9534147efb1150;rport
Via: SIP/2.0/UDP 10.10.10.135:7654;rport=7654;branch=z9hG4bK962836463;received=10.10.10.135
User-Agent: Excel_CSP/84.11.34
Content-Length: 0

已手动更新IP地址和SIP TO / FROM信息以隐藏原始身份。

我已经浏览了RFC 3261,我在第161页上找到了以下内容。我不确定,如何阅读下表。这是否意味着Contact头不适用于对2xx消息的ACK?

Header field          where   proxy ACK BYE CAN INV OPT REG
      ___________________________________________________________
      Contact          2xx           -   -    -   m   o   o

2 个答案:

答案 0 :(得分:3)

200 Ok包含:

Record-Route: <sip:200.200.200.2:5060;lr>
Contact: <sip:+100@10.10.10.135:7654>

您的应用程序不了解“lr”参数的含义:rfc3261中引入的“loose routing”参数。它甚至与最初的rfc2543不兼容。

如果您的应用仅与rfc2543兼容,则ACK将包含您具有的确切消息,但附加了“lr”参数。这将向服务器指示订单是rfc2543,理论上,服务器将理解并重新排序:(rfc3261,第16.6节,第6步。后处理路由信息)

ACK sip:200.200.200.2:5060;lr SIP/2.0
Route: <sip:+100@10.10.10.135:7654>

但是,正确的消息应符合最新的rfc3261,因此您的应用必须生成以下SIP消息:

ACK sip:+100@10.10.10.135:7654 SIP/2.0
Route: <sip:200.200.200.2:5060;lr>

整个问题是关于错误处理应用程序中的“lr”参数!解决方案是修复丢失的“lr”并根据rfc3261确保订单准确。

答案 1 :(得分:0)

我猜你在发布问题时已经剥离了SIP标题的某些部分。大多数Via头都缺少强制分支参数,这在INVITE事务处理中尤其重要。

除了问题AymericM哈希突出显示关于联系人和路线标题你&#34;可以&#34;关于ACK请求中的Via头分支参数,还有另一个问题。具体来说,您应该查看章节13.2.2.4 2xx Responses17.1.1.3 Construction of the ACK Request,了解有关如何构建ACK请求的详细信息。

关键是ACK请求必须在确认非2xx失败响应时启动新事务。当确认2xx响应时,ACK请求必须是事务内请求,并使用相同的头字段(包括Via头分支参数)作为原始INVITE请求。

构建ACK请求是SIP中最大的问题之一。