[asterisk-bugs] [JIRA] (ASTERISK-27545) chan_sip: improper handling of Re-invites between IPv4 and IPv6 and vice-versa
Nir Simionovich (GreenfieldTech - Israel) (JIRA)
noreply at issues.asterisk.org
Thu Jan 4 06:24:39 CST 2018
[ https://issues.asterisk.org/jira/browse/ASTERISK-27545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241346#comment-241346 ]
Nir Simionovich (GreenfieldTech - Israel) commented on ASTERISK-27545:
----------------------------------------------------------------------
One minor comment, seems like I'm not the only person complaining about this "global" issue. Looks like
ASTERISK-26784 is more-or-less identical, but with incomplete information.
> chan_sip: improper handling of Re-invites between IPv4 and IPv6 and vice-versa
> ------------------------------------------------------------------------------
>
> Key: ASTERISK-27545
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-27545
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/Interoperability, Channels/chan_sip/IPv6
> Affects Versions: 13.18.5, 14.7.5
> Environment: CentOS 7.X
> CentOS 6.X
> Reporter: Nir Simionovich (GreenfieldTech - Israel)
> Labels: IPv4, IPv6, pjsip, sip
> Attachments: Asterisk_ipv4_reinvite_ipv6_transition_issue.pcapng, Asterisk_ipv6_reinvite_ipv4_transition_issue.pcapng
>
>
> We've recently encountered an interesting bug with Asterisk 14 (the version we are testing with), but we believe as this is a fairly crazy (although reasonable) test scenario - the issue may still be there.
> The scenario is the following:
> UAC A ---- IPv4 + SIP + RTP ----> Asterisk --- IPv4 + SIP + RTP ---> UA B
> When the following happens, we all know that this is working correctly, no problem there. However, during the
> call, the network condition changes, namely in our case: Transit from UAC A to Asterisk changes from IPv4 to
> IPv6, thus the following happens:
> UAC A ---- IPv6 + SIP + RTP ----> Asterisk --- IPv4 + SIP + RTP ---> UA B
> The SDP response in the 200 OK coming back from Asterisk is malformed, and contains IPv4 addresses in the
> SDP, although it shouldn't. For example (pay attention to the bolded section):
> INVITE sip:4015@[2a03:b0c0:1:d0::176b:1001]:5090 SIP/2.0
> Via: SIP/2.0/UDP [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;rport;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1
> Max-Forwards: 70
> From: sip:4015 at xxxxxx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
> To: sip:600 at xxxxxx.dev.greenfieldtech.net;tag=as4b993656
> Contact: <sip:4015@[2001:470:1f06:404:8562:7dba:63c9:3986]:5090;ob>
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 INVITE
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800;refresher=uas
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 584
> v=0
> o=- 3723897380 3723897382 IN IP4 100.101.10.126
> s=pjmedia
> b=AS:117
> t=0 0
> a=X-nat:0
> m=audio 4002 RTP/AVP 98 97 99 104 3 0 8 9 120 96
> c=IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> b=TIAS:96000
> a=rtcp:4003 IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> a=sendrecv
> a=rtpmap:98 speex/16000
> a=rtpmap:97 speex/8000
> a=rtpmap:99 speex/32000
> a=rtpmap:104 iLBC/8000
> a=fmtp:104 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 opus/48000/2
> a=fmtp:120 useinbandfec=1
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
> INVITE sip:4015@[2a03:b0c0:1:d0::176b:1001]:5090 SIP/2.0
> Via: SIP/2.0/UDP [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;rport;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1
> Max-Forwards: 70
> From: sip:4015 at xxxxxx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
> To: sip:600 at xxxxxx.dev.greenfieldtech.net;tag=as4b993656
> Contact: <sip:4015@[2001:470:1f06:404:8562:7dba:63c9:3986]:5090;ob>
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 INVITE
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800;refresher=uas
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 584
> v=0
> o=- 3723897380 3723897382 IN IP4 100.101.10.126
> s=pjmedia
> b=AS:117
> t=0 0
> a=X-nat:0
> m=audio 4002 RTP/AVP 98 97 99 104 3 0 8 9 120 96
> c=IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> b=TIAS:96000
> a=rtcp:4003 IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> a=sendrecv
> a=rtpmap:98 speex/16000
> a=rtpmap:97 speex/8000
> a=rtpmap:99 speex/32000
> a=rtpmap:104 iLBC/8000
> a=fmtp:104 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 opus/48000/2
> a=fmtp:120 useinbandfec=1
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1;received=2001:470:1f06:404:8562:7dba:63c9:3986;rport=5090
> From: sip:4015 at xxxxxx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
> To: sip:600 at xxxxxx.dev.greenfieldtech.net;tag=as4b993656
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 INVITE
> Server: Asterisk PBX 14.7.0-rc2
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:600 at 178.yyy.zzz.231:5090>
> Content-Length: 0
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1;received=2001:470:1f06:404:8562:7dba:63c9:3986;rport=5090
> From: sip:4015 at xxxxxx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
> To: sip:600 at xxxxxx.dev.greenfieldtech.net;tag=as4b993656
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 INVITE
> Server: Asterisk PBX 14.7.0-rc2
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:600 at 178.yyy.zzz.231:5090>
> Content-Type: application/sdp
> Require: timer
> Content-Length: 914
> v=0
> o=root 676069009 676069011 IN IP4 178.yyy.zzz.231
> s=-
> c=IN IP4 178.yyy.zzz.231
> t=0 0
> m=audio 15862 RTP/AVP 120 9 8 0 104 96
> a=rtpmap:120 opus/48000/2
> a=rtpmap:9 G722/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:104 iLBC/8000
> a=fmtp:104 mode=30
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
> a=ptime:20
> a=maxptime:20
> a=ice-ufrag:1f57c2824b8b0c3c5a72ee310fea06d9
> a=ice-pwd:6353c06e7d9dfc7810554560071162a0
> a=candidate:H58842ba1 1 UDP 2130706431 [2a03:b0c0:1:d0::176b:1001] 15862 typ host
> a=candidate:H37d51abe 1 UDP 2130706431 [fe80::601:3dff:fe3a:a401] 15862 typ host
> a=candidate:Hb23e31e7 1 UDP 2130706431 178.yyy.zzz.231 15862 typ host
> a=candidate:H58842ba1 2 UDP 2130706430 [2a03:b0c0:1:d0::176b:1001] 15863 typ host
> a=candidate:H37d51abe 2 UDP 2130706430 [fe80::601:3dff:fe3a:a401] 15863 typ host
> a=candidate:Hb23e31e7 2 UDP 2130706430 178.yyy.zzz.231 15863 typ host
> a=sendrecv
> ACK sip:4015@[2a03:b0c0:1:d0::176b:1001]:5090 SIP/2.0
> Via: SIP/2.0/UDP [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;rport;branch=z9hG4bKPj4FSKjJqd4rqQv5cxcwWJU1D8YlXVJZj9
> Max-Forwards: 70
> From: sip:4015 at xxxxxx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
> To: sip:600 at xxxxxx.dev.greenfieldtech.net;tag=as4b993656
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 ACK
> Content-Length: 0
> Now, we resolved the issue by enabling ICE at the client side, but again, this is a workaround, not a solution.
> In addition, the ICE candidates reported by Asterisk, when IPv6 is used includes the "fe80:" subnet, which is the
> link local interface, which should not be reported back as an ICE candidate. I see no problem with reporting
> an ICE candidate that is IPv4, as in this case, CGNAT can take care of that one. However, the "c=" line, i believe,
> should include the IPv6 address, not the IPv4 address of Asterisk - in order to facilitate proper media negotiations.
> This issue should also be tested for correctness with chan_pjsip. We are using PJSIP on our mobile client, which has
> a fairly different state machine than the one implemented with PJSUA or Asterisk, but again, still needs a regression
> test for verification.
> Please find attached a pcap files including the complete trace of the above issue.
> The reason I'm marking this as a critical issue, not a "major" issue is simple. IPv6 is becoming the norm for many carriers around the world, specifically when dealing with LTE and VoLTE infrastructure. If the above scenario occurs in a carrier environment, it will incur massive implications for the entire VoLTE network and/or convergence between IPv4 Wifi and IPv6 LTE data.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list