Rport字段引起的国标取流失败问题

先秃为敬

已于 2024-05-29 23:51:40 修改

阅读量1k

点赞数 30

文章标签：音视频网络协议

于 2024-05-29 23:47:06 首次发布

本文链接：https://blog.csdn.net/qq_39965491/article/details/139307914

版权

四、附录（GB28181中对Rport字段的定义）

1.方案描述

2.Rport实例

一、问题现象

【问题现象】NVR使用GB接入三方平台预览失败。
大家遇到国标接入平台无法预览问题第一反应肯定是抓包看交互，看是否推流，本文对此问题
按照我当时的处理思路进行逐步解析，希望大家在问题原因以及处理思路上都能有借鉴。
客户拓扑如下：
图1.1：网络拓扑
上述拓扑很容易遇到，一般通过公网接入国标平台的拓扑与上述拓扑基本相差不大。
二、问题排查过程
1、平台侧抓包分析如下
平台侧抓包如下所示
图2.1：平台侧报文
从图2.1可看出平台侧发出invite报文但是并未收到回复
图2.2：平台侧报文流追踪
从图2.2可看出，平台侧相关的取流报文也符合相关GB标准，SDP字段与标准报文相比并无不同。
2、设备侧抓包分析如下
设备侧抓包如下：
图2.3：设备侧报文
从上述报文来看设备侧是存在200OK的回复，并不存在什么问题。
图2.4：设备侧CALLID过滤后的报文
从上述报文，可确定上述的200OK是用来回复平台的invite请求的。难道是因为网络原因导致的平台并未收到设备侧的回复报文吗？其实真相往往没有这么简单。
3、报文分析
如下图所示，为设备侧的流追踪结果。
图3.1：根据INVITE追踪流的结果
从上图可以看出，根据INVITE报文过滤后设备侧的现象与平台侧的现象相同，都是只有INVITE报文存在，所以难道和之前分析的相同，设备侧回复的200OK并不是对平台的INVITE请求做回复。
但是从图3.1可以发现，CALLID过滤后的效果是INVITE和200OK被认为是一个会话，（在国标中CALLID被定义为是会话ID，不同会话之间不会重复），但是在追踪流后发现200OK和INVITE被认为是两个会话，这个就比较奇怪了。
所以需要先找出来他们为什么会被认为是两个会话，才能进一步的去排查可能出现的问题。功夫不负有心人，这个先决条件还是被找到了。
注：经查，wireshark流追踪的原理可以大概理解为根据src.ip、src.port、dst.ip、dst.port做判断，然后根据报文序号进行排序。
图3.2 设备收到的invite报文端口
图3.3 设备回复200OK的dst.port
由上图可以发现，设备侧收到了invite报文src.port = 5900，dst.port = 5060，然后设备回复的200OK，src.port = 5060，dst.port = 9742，从网络角度来说，设备回复的200OK应该为dst.port = 5900，所以设备为什么会给9742回复相关消息呢，这个也成了目前已知的唯一线索，似乎解决这个就抓住了问题的根因。
图3.4 平台发送invite报文的dst.port
由图3.4，发现9742这个端口居然存在与平台发送的invite中，是平台发送的invite报文的dst.port。由此可判断9742端口是设备在找平台时候，出口侧光猫分配的公网端口。【（源NAT），基本功能为：此局域网的内网IP去访问公网，经过出口网关时，出口网关都会分配给他一个公网地址（此地址为出口网关的公网地址）+端口形式的IP作为他在公网访问的标识】此处不多做赘述。
所以根据上面的描述，好像事情已经盖棺定论了，按照上面的推测来看的话，是设备的问题。
平台侧发送的dst.port = 9742。
出口网关侧转换后让设备收到的invite的dst.port = 5900。
但设备回复的200OK dst.port = 9742，导致200OK经过转换后设备收不到相关报文；或者平台收到后却不认为是一个会话。
在网络层面来讲，端口标识了一个会话的唯一性，如果是一个会话，端口肯定是一样的。
所以真的是设备侧的问题吗，那设备侧为什么会突然回复给dst.port = 9742这个端口呢，或许找到了设备为什么这样回复的原因就能解开这个谜团。
4、深入分析
其实要排除设备侧的问题很简单，找到设备为什么会回复给9742这个端口的原因或许就能解开这个谜团。
（1）设备之所以回复给端口9742，必然是因为invite报文中携带的相关参数导致设备200OK回复错误端口。
（2）所以当务之急是找出9742这个端口出现过的地方。
4.1 端口9742出现过的地方
果然，我找到了一个可疑的参数，端口9742在rport这个参数中曾经出现过。那这个参数是否就是导致设备回复200OK的端口出错的端口呢？我们找一份正常的报文与这侧的抓包文件进行对比看看。
图4.1.1 9742出现过的地方
4.2 正常的交互报文
（1）平台发送invite取流报文，src.port设置为自身提供GB服务的端口，dst.port设置为对端NAT地址与自己src.port进行GB信令交互的端口。
此时rport字段不携带任何参数。
图4.2.1 正常平台发送的invite
（2）设备收到的invite报文中dst.port经过了NAT的转换，变为了设备侧提供GB服务的端口。
此时rport字段也不携带任何参数。
图4.2.2 正常设备收到的invite
（3）设备回复相关200OK，src.port = 10005（设备提供GB服务的端口）dst.port = 5061（平台提供GB服务的服务端口）。
此时设备侧将rport字段填写为平台提供GB服务的端口 5061。
图4.2.3 正常设备回复的200OK
（4）平台收到的200 OK报文中src.port经过了NAT的转换，变对端NAT地址与自己src.port进行GB信令交互的端口。
此时rport字段参数不变。
图4.2.4 正常平台收到的200OK
从上面截图可以看出。
正常条件下，设备收到的invite报文rport字段一般是空的。
Rport字段在设备回复的200OK时，会被填写为平台提供GB服务的端口。
4.3 异常的交互报文
下面我们看下异常的交互过程
平台发送invite取流报文，src.port设置为自身提供GB服务的端口，dst.port设置为对端NAT地址与自己src.port进行GB信令交互的端口。
此时rport字段不携带任何参数。
与正常报文第一步相同，证明平台发出的报文并无问题。
图4.3.1 平台发送的invite
设备收到的invite报文中dst.port经过了NAT的转换，变为了设备侧提供GB服务的端口。这一步也没问题
但是注意Rport字段被更改为9742。
图4.3.2 设备收到的invite
设备回复相关200OK，src.port = 5060（设备提供GB服务的端口）dst.port = 9427。
此时设备侧将rport字段还是9742并未进行更改
图4.3.3 设备回复的200OK
所以上述问题最终定位应为设备侧出口网关ALG误转换问题。将rport字段误携带了9742端口（NVR访问公网的端口）
5、拓展
从上述分析可以推断出关于设备对于VIA中的report字段存在一个判断逻辑：
（1）rport空的话将VIA字段中IP后携带的端口填写进入report字段，并将200OK回复给这个端口。
例子：
Via:SIP/2.0/UDPx.x.x.x:5060;rport;branch=z9hG4bK231570912
此时会使用这个x.x.x.x后的端口5060。
（2）非空的话直接使用rport已经携带的端口值，并给这个端口回复200OK。
三、解决方案
更换出口路由器后恢复正常。
四、附录（GB28181中对Rport字段的定义）
1.方案描述
获得IP地址是在Via头中带上received参数。为了得到端口信息，也参考了这种方式，即在Via头中带上rport属性来指明端口信息。
当在客户端和服务器之间是NAT的时候，请求可能会在NAT中创建（或刷新）一个绑定，为了让客户端收到响应信息，在事务处理的过程中这个绑定必须保持存在。大多数的NAT绑定有超过1分钟的超时时间，这超过了non-INVITE事务的持续时间，因而对non-INVITE事务的请求的响应只能在绑定存在的时候存在。INVITE事务倒是不存在这个问题。
为了保持这个绑定，客户端应该在每隔20s左右重发INVITE请求，这种重发机制需要发生在收到一个临时的响应后。
当然刚才所说的大概1分钟的超时时间也不是确定的，有时候会比这长，此时重发机制可以发慢一点，否则，可以发快一点。这些问题可参考RFC3489。
如果是支持rport机制的服务器，它需要在接收到的请求中检查Via头是否包含一个没有值的rport参数。如果有，它需要在回应中带上rport的值，这与received的处理类似。
为了穿越对称性的对称性的NAT，响应需要发送到相同的IP地址和端口。当服务器在多端口或接口的请求上监听请求时，它必须记住请求是从何处发的。对一个稳定的Proxy，在一个传输的持续时间中，记住这些东西是没有问题的。但是对于不稳定的Proxy，它不存储请求和响应中的状态信息，为了达到本规范的要求，它需要将地址和端口信息加密到Via头字段中，在响应信息到达的时候，它能提取加密的信息并将它放到响应中。
rport机制需要终端支持该种机制，因此应用情况比较受限。但是在笔者的应用场景（呼叫中心）中，主要要解决的问题是坐席能在NAT环境中穿越，给服务器发送信息。
2.Rport实例
下面举一个发送REGISTER信息的实例，在请求信息的Via头中包含了没有值的rport参数，如下所示：
REGISTER sip:124.40.120.188:5060 SIP/2.
Via: SIP/2.0/UDP 124.42.4.203:15500;branch=z9hG4bK-d8754z-1049ed261d2e643d-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:19988888888@192.168.2.65:12344;rinstance=7cd1c532e92fdb0e>;expires=0
To: "19988888888"<sip:19988888888@124.40.120.188:5060>
From: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=203ba359
Call-ID: Yzc4N2IwMzY5OWU4MTdkMzY0NWY4OWU3NjMzNmJiM2U.
CSeq: 1 REGISTE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1105a stamp 56793
Content-Length: 0
发送到的服务器支持rport机制，它看到请求中的rport后，将通过分析UDP包信息得到的的NAT的公网地址（124.42.4.203）和端口信息（15500）分别作为received和rport属性带给客户端：
SIP/2.0 200 OK
Via: SIP/2.0/UDP 124.42.4.203:15500;branch=z9hG4bK-d8754z-1049ed261d2e643d-1--- d8754z-;rport=15500;received=124.42.4.203
From: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=203ba359
To: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=0005-058-7d6dc90516ae2e21
Call-ID: Yzc4N2IwMzY5OWU4MTdkMzY0NWY4OWU3NjMzNmJiM2U.
CSeq: 4 REGISTER
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,UPDATE,PRACK,REFER,SUBSCRIBE,NOTIFY,MESSAGE
Contact: <sip:124.40.120.188:5060>
Content-Length: 0
客户端在得到响应信息后，知道了所使用的公网地址和端口，在而后定期重发的REGISTER信息中，Contact变换成124.42.4.203: 15500，例如新发的REGISTER信息变为
REGISTER sip:124.40.120.188:5060 SIP/2.0
Via: SIP/2.0/UDP 124.42.4.203:15500;branch=z9hG4bK-d8754z-1049ed261d2e643d-1---d8754z-;rport
Max-Forwards: 70
Contact: <sip:19988888888@124.42.4.203: 15500;rinstance=7cd1c532e92fdb0e>;expires=0
To: "19988888888"<sip:19988888888@124.40.120.188:5060>
From: "19988888888"<sip:19988888888@124.40.120.188:5060>;tag=203ba359
Call-ID: Yzc4N2IwMzY5OWU4MTdkMzY0NWY4OWU3NjMzNmJiM2U.
CSeq: 2 REGISTER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: eyeBeam release 1105a stamp 56793
Content-Length: 0
Report实例参考：RFC3581——SIP中的rport机制（一）_sip rport为空-CSDN博客