问题是，在某些时候，在端口更改（TCP）之后再次发送寄存器，标头不会更新：
REGISTER / cseq = 39874（tdta0xad552000）到TCP 10.123.3.121：5096：
REGISTER sip:10.123.3.121 SIP/2.0
Via: SIP/2.0/TCP 10.123.4.89:47413;rport;branch=some-branch;alias
Route: <sip:10.123.3.121:5096;transport=tcp;lr>
Max-Forwards: 70
From: <sip:%7bf6f78d85-442d-4d6f-871a-f491ddb9e005%7d@DJ-DV-TEST-V005>;tag=13bb55b7-bc11-40b6-808a-eed943a30752
To: <sip:%7bf6f78d85-442d-4d6f-871a-f491ddb9e005%7d@DJ-DV-TEST-V005>
Call-ID: 75aac0ae-45f0-4155-a893-02eafdeb257b
CSeq: 39874 REGISTER
User-Agent: Some Agent/2018-04-23 (Language=English) (OS=Android 7.0) (IP=10.123.4.89) (MAC=02:00:00:00:00:00)
Supported: outbound, path
Contact: <sip:%7bf6f78d85-442d-4d6f-871a-f491ddbagsr5%7d@10.123.4.89:47413;transport=TCP;tenantdomain=DJ-DV-TEST-V005;ob>;+sip.instance="<urn:uuid:0bc37cbc-3e5e-4c8b-badb-91617a1cd37c>";reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000e922f243>"
Expires: 660
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0
因此，RPORT与联系头（46815 - 47413）中的RPORT不同：
来自TCP 10.123.3.121:5096的200 / REGISTER / cseq = 39874（rdata0xad41d5d8）：
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.123.4.89:47413;rport=46815;received=10.123.4.89;branch=some-branch;alias
Path: <sip:10.123.3.121:64554;transport=tcp;lr>
Path: <sip:10.123.4.89:47413;transport=tcp;lr>
Contact: <sip:%7bf6f78d85-442d-4d6f-871a-f491ddb9e005%7d@10.123.4.89:47413;transport=TCP;ob;tenantdomain=DJ-DV-TEST-V005>;expires=660;+sip.instance="<urn:uuid:0bc37cbc-3e5e-4c8b-badb-91617a1cd37c>";reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000e922f243>"
To: <sip:%7bf6f78d85-442d-4d6f-871a-f491ddb9e005%7d@DJ-DV-TEST-V005>;tag=517ac26b
From: <sip:%7bf6f78d85-442d-4d6f-871a-f491ddb9e005%7d@DJ-DV-TEST-V005>;tag=13bb55b7-bc11-40b6-808a-eed943a30752
Call-ID: 75aac0ae-45f0-4155-a893-02eafdeb257b
CSeq: 39874 REGISTER
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE
Date: Tue, 24 Apr 2018 06:39:14 GMT
User-Agent: Some Agent /11.10.0.324
Content-Length: 0
但是邀请不会发送到返回端口，而是发送到联系人标题中提到的那个，因此调用不起作用。 取消注册并再次注册到服务器不是一种选择。
由于
答案 0 :(得分：1)
我认为问题出在注册商/代理商身上：它似乎在NAT环境中效果不佳。
在检查请求和响应后，我注意到以下内容：
如RFC6314 (Best practices)所述，该过程应如下：
注册将导致在注册器/代理服务器上创建出站连接元组。这用于将传入的INVITE请求路由到正确的地址。
['reg-id'和'sip.instance'联系人标题 参数]用于建立出站连接元组 如[RFC5626]中所定义。 [...]这确保了导致的任何入站请求 注册查找将导致重用连接路径 由注册成立。这消除了操纵的需要 联系头URI表示全局可路由地址 在公共场合感知到NAT。
RFC 6314 5.1.4.1解释了如何使用元组将传入的INVITE请求路由到正确的客户端：
[INVITE请求]不会转发给 Request-URI中指定的地址，作为标准SIP规则 强制执行，但将在与之关联的流程上发送 注册绑定（RFC 3263 [RFC3263]中的查找过程是 被RFC 5626 [RFC5626]覆盖。然后允许原件 从初始注册过程到的连接/映射 重复使用。
您应该检查注册商/代理是否有任何（其他）NAT支持方式。
<强>更新
我假设您的网络中使用了NAT。如果没有，解决方案有些不同。必须将INVITE请求发送到Contact头（47413）中的端口，就像这样。这是客户端（应该）正在侦听传入SIP消息的端口。