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

【问题标题】：Validity of SIP ACK response to SIP 200 OK message对 SIP 200 OK 消息的 SIP ACK 响应的有效性
【发布时间】：2015-09-14 20:00:19
【问题描述】：

我们正在向我们的一位合作伙伴发送 sip call。他们在 200 OK 消息内向我们发送“Record-Route”和“Contact”标头。我方正在向 Record-Route 中提到的 IP 地址发送 ACK，但它正在用“Route”标头替换“Contact”标头，而另一方不遵守我们的 ACK 并向我们发送重复的 200 OK，从而导致呼叫断开。

我不确定我们是否违反了任何 SIP RFC，将“Contact”标头更改为“Route”，同时保留标头的内容。谁能解释一下？

这是来自合作伙伴方面的 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 消息：

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 header不适用于2xx消息的ACK？

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

【问题讨论】：

    标签： sip


    【解决方案1】：

    200 Ok 包含：

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

    您的应用程序看起来不理解“lr”参数的含义：rfc3261 中引入的“松散路由”参数。它甚至与最初的 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 确保顺序准确。

    【讨论】：

      【解决方案2】：

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

      除了关于 Contact 和 Route 标头突出显示的 AymericM 哈希问题之外，您“可能”在 ACK 请求中的 Via 标头分支参数方面还有另一个问题。具体来说，您应该查看章节13.2.2.4 2xx Responses 和17.1.1.3 Construction of the ACK Request，了解如何构造 ACK 请求的详细信息。

      关键是ACK请求在确认非2xx失败响应时必须启动NEW事务。确认 2xx 响应时，ACK 请求必须是事务中请求，并且使用与原始 INVITE 请求相同的标头字段，包括 Via 标头分支参数。

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

      【讨论】：

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-12-28
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多
        热门标签
        Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode