Fatal编程技术网
  • sip/
  • Sip 为什么'；VoIP网关是否发送任何媒体并中断呼叫？

Sip 为什么'；VoIP网关是否发送任何媒体并中断呼叫？

sip

Sip 为什么'；VoIP网关是否发送任何媒体并中断呼叫？,sip,voip,rtp,pjsip,sdp,Sip,Voip,Rtp,Pjsip,Sdp,使用PJSUA测试应用程序连接到Bodhicom 3408 p/O VoIP/FXO网关时出现问题。当我使用csipsimpleandroid应用程序（）时，一切都很好。当我使用PJSUA测试应用程序时，网关不会向我发送任何RTP数据包，并在我确认后立即中断调用。我花了相当多的时间查看网关和Android设备之间捕获的网络数据包，并将其与网关和PC交换的数据包进行比较。然而，我没有发现任何东西可以告诉我为什么网关会以不同的方式运行。我认为问题在于INVITE请求，因为在Android的情况下，它

使用PJSUA测试应用程序连接到Bodhicom 3408 p/O VoIP/FXO网关时出现问题。当我使用csipsimpleandroid应用程序（）时，一切都很好。当我使用PJSUA测试应用程序时，网关不会向我发送任何RTP数据包，并在我确认后立即中断调用。我花了相当多的时间查看网关和Android设备之间捕获的网络数据包，并将其与网关和PC交换的数据包进行比较。然而，我没有发现任何东西可以告诉我为什么网关会以不同的方式运行。我认为问题在于INVITE请求，因为在Android的情况下，它的响应是100次尝试，然后183次会话正在进行，以及一个RTP数据包流。在PC机的情况下，有100个正在尝试的会话和183个正在进行的会话，但没有传入的RTP数据包

以下是来自Android（works）的邀请请求：

INVITE sip:701203@10.17.17.2SIP/2.0
Via:SIP/2.0/UDP 10.17.17.119:60114；rport；分支=z9hG4bKPjd4I9mLGfdc-dHLeftgDhnB1QSKTwfp8L
最大前锋：70
出自：“亚当”；标记=.SLc6umpZHvQ8xLhKzIPyarZFGIFKcYa
致：
联系人：“亚当”
呼叫ID:VJnv1gCnGacB5plPReyxB-arbWy.zB1W
CSeq:695邀请
允许：恶作剧、邀请、确认、再见、取消、更新、信息、订阅、通知、参考、消息、选项
支持：替换、100rel、计时器、norefersub
会期届满：1800
Min SE:90
用户代理：CSipSimple_android_x86_64-25/r2457
内容类型：应用程序/sdp
内容长度：364
v=0
o=-3830333691 3830333691在IP4 10.17.17.119中
s=pjmedia
c=在IP4 10.17.17.119中
t=0
m=音频4000 RTP/AVP 9 99 0 8 101
c=在IP4 10.17.17.119中
a=rtcp:4001在IP4 10.17.17.119中
a=sendrecv
a=rtpmap:9 G722/8000
a=rtpmap:99丝/24000
a=fmtp:99 useinbandfec=0
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101电话事件/8000
a=fmtp:101 0-16
和来自PC的邀请请求（不起作用）：

INVITE sip:701203@10.17.17.2SIP/2.0
Via:SIP/2.0/UDP 10.17.17.134:5060；rport；分支=z9hG4bKPjEwTCSQN5M8KFw5Jrg9OPaA.7EnsKdhSq
最大前锋：70
发件人：sip:11@10.17.17.134;标签=z3RNgXnVH5JEsCH09YXKFNb5sj1kBGRv
致：sip：701203@10.17.17.2
联系人：
呼叫ID:AaWE5-53WQNrpgixujOluli7jbVEmeQM
CSeq:19571邀请
允许：恶作剧、邀请、确认、再见、取消、更新、信息、订阅、通知、参考、消息、选项
支持：替换、100rel、计时器、norefersub
会期届满：1800
Min SE:90
用户代理：PJSUA v2.10 Linux-5.8.0.53/x86_64/glibc-2.32
内容类型：应用程序/sdp
内容长度：629
v=0
o=-3830332754 IP4 10.17.17.134中的3830332754
s=pjmedia
b=AS:84
t=0
a=X-nat:0
m=音频4002 RTP/AVP 96 97 98 99 3 0 8 9 120 121 122
c=在IP4 10.17.17.134中
b=TIAS:64000
a=rtcp:4003在IP4 10.17.17.134中
a=sendrecv
a=rtpmap:96 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:98 speex/32000
a=rtpmap:99 iLBC/8000
a=fmtp:99模式=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:120电话事件/16000
a=fmtp:120 0-16
a=rtpmap:121电话事件/8000
a=fmtp:121 0-16
a=rtpmap:122电话事件/32000
a=fmtp:122 0-16
a=ssrc:1692601373 cname:3065339d70665017
上述IP地址和AOR仅用于隔离的测试网络。我不是故意把它们拿走的

我想如果我能从网关那里得到一些反馈信息会容易得多。不幸的是，我在网关UI中找不到任何详细的信息/日志。制造商也没有回答我的问题。

当我修改PJSUA测试应用程序源代码以不包含带宽信息时，它开始工作：

b=AS:84
b=TIAS:64000
现在INVITE请求看起来是这样的，它可以工作：

INVITE sip:701203@10.17.17.2 SIP/2.0
Via: SIP/2.0/UDP 10.17.17.134:5060;rport;branch=z9hG4bKPjAxGfIo8mYgfV2.OtyQNXne6jFEoHSl7J
Max-Forwards: 70
From: sip:11@10.17.17.134;tag=qo67aAphq-cgXXWYCX8RjvTR2rZxB2Wu
To: sip:701203@10.17.17.2
Contact: <sip:11@10.17.17.134:5060;ob>
Call-ID: C0Sf-v8BBaINSE.8j-8BsWgsPponNb2h
CSeq: 520 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: PJSUA v2.10 Linux-5.8.0.53/x86_64/glibc-2.32
Content-Type: application/sdp
Content-Length:   606

v=0
o=- 3830404967 3830404967 IN IP4 10.17.17.134
s=pjmedia
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 96 97 98 99 3 0 8 9 120 121 122
c=IN IP4 10.17.17.134
a=rtcp:4001 IN IP4 10.17.17.134
a=sendrecv
a=rtpmap:96 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:98 speex/32000
a=rtpmap:99 iLBC/8000
a=fmtp:99 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:120 telephone-event/16000
a=fmtp:120 0-16
a=rtpmap:121 telephone-event/8000
a=fmtp:121 0-16
a=rtpmap:122 telephone-event/32000
a=fmtp:122 0-16
a=ssrc:1942999776 cname:053aa66259195378

INVITE sip:701203@10.17.17.2SIP/2.0
Via:SIP/2.0/UDP 10.17.17.134:5060；rport；branch=z9hG4bKPjAxGfIo8mYgfV2.OtyQNXne6jFEoHSl7J
最大前锋：70
发件人：sip:11@10.17.17.134;标签=qo67aAphq-cgXXWYCX8RjvTR2rZxB2Wu
致：sip：701203@10.17.17.2
联系人：
呼叫ID:C0Sf-v8BBaINSE.8j-8BsWgsPponNb2h
CSeq:520邀请
允许：恶作剧、邀请、确认、再见、取消、更新、信息、订阅、通知、参考、消息、选项
支持：替换、100rel、计时器、norefersub
会期届满：1800
Min SE:90
用户代理：PJSUA v2.10 Linux-5.8.0.53/x86_64/glibc-2.32
内容类型：应用程序/sdp
内容长度：606
v=0
o=-3830404967 IP4 10.17.17.134中的3830404967
s=pjmedia
t=0
a=X-nat:0
m=音频4000 RTP/AVP 96 97 98 99 3 0 8 9 120 121 122
c=在IP4 10.17.17.134中
a=rtcp:4001在IP4 10.17.17.134中
a=sendrecv
a=rtpmap:96 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:98 speex/32000
a=rtpmap:99 iLBC/8000
a=fmtp:99模式=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:120电话事件/16000
a=fmtp:120 0-16
a=rtpmap:121电话事件/8000
a=fmtp:121 0-16
a=rtpmap:122电话事件/32000
a=fmtp:122 0-16
a=ssrc:1942999776 cname:053AA6659195378
然而，我不能100%确定这是否是网关的错，还是客户端的错。也许84kb/s或64kb/s太小了？如果我理解正确，这是发件人的声明。如果网关认为这太难处理，它有权中断呼叫。但是网关不应该继续呼叫（几秒钟），而应该没有音频流。我说得对吗？我很高兴我解决了这个问题，但如果有人向我解释为什么网关会这样，我会非常感激

但是网关不应该继续呼叫（几秒钟），而是 没有音频流。我说得对吗

是的，这是暂停会话建立的QOS先决条件：

While session establishment is suspended, user agents SHOULD not
send any data over any media stream.  In the case of RTP, neither
RTP nor RTCP packets are sent.
也许84kb/s或64kb/s太小了

SDP可能不符合具有这两个不同b字段的旧用户代理；一个在会话级别，另一个在媒体级别。 会话级别的b=AS:84表示所有流的带宽为84 Kbps，包括IP/UDP/RTP开销，音频媒体级别的b=TIAS:64000，最大为64 Kbps（因此，我认为84具有开销是可以的）

建议AS带宽说明符为u 
INVITE sip:701203@10.17.17.2 SIP/2.0
Via: SIP/2.0/UDP 10.17.17.134:5060;rport;branch=z9hG4bKPjAxGfIo8mYgfV2.OtyQNXne6jFEoHSl7J
Max-Forwards: 70
From: sip:11@10.17.17.134;tag=qo67aAphq-cgXXWYCX8RjvTR2rZxB2Wu
To: sip:701203@10.17.17.2
Contact: <sip:11@10.17.17.134:5060;ob>
Call-ID: C0Sf-v8BBaINSE.8j-8BsWgsPponNb2h
CSeq: 520 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800
Min-SE: 90
User-Agent: PJSUA v2.10 Linux-5.8.0.53/x86_64/glibc-2.32
Content-Type: application/sdp
Content-Length:   606

v=0
o=- 3830404967 3830404967 IN IP4 10.17.17.134
s=pjmedia
t=0 0
a=X-nat:0
m=audio 4000 RTP/AVP 96 97 98 99 3 0 8 9 120 121 122
c=IN IP4 10.17.17.134
a=rtcp:4001 IN IP4 10.17.17.134
a=sendrecv
a=rtpmap:96 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:98 speex/32000
a=rtpmap:99 iLBC/8000
a=fmtp:99 mode=30
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:120 telephone-event/16000
a=fmtp:120 0-16
a=rtpmap:121 telephone-event/8000
a=fmtp:121 0-16
a=rtpmap:122 telephone-event/32000
a=fmtp:122 0-16
a=ssrc:1942999776 cname:053aa66259195378

While session establishment is suspended, user agents SHOULD not
send any data over any media stream.  In the case of RTP, neither
RTP nor RTCP packets are sent.

v=0 
o=- 3830332754 3830332754 IN IP4 10.17.17.134 
s=pjmedia
b=AS:84
b=TIAS:64000 
t=0 0 
a=X-nat:0 
m=audio 4002 RTP/AVP 96 97 98 99 3 0 8 9 120 121 122 c=IN IP4 10.17.17.134
b=AS:84
b=TIAS:64000
...