[asterisk-bugs] [JIRA] (ASTERISK-27545) chan_sip: improper handling of Re-invites between IPv4 and IPv6

Thu Jan 4 03:13:39 CST 2018

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241338#comment-241338 ] 

Nir Simionovich (GreenfieldTech - Israel) commented on ASTERISK-27545:
----------------------------------------------------------------------

Please note that the same issue arises when the re-invite is performed from IPv6 back to IPv4 - thus, the issue is consistent across the 
entire network transit.

> chan_sip: improper handling of Re-invites between IPv4 and IPv6
> ---------------------------------------------------------------
>
>                 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)
>            Severity: Critical
>              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)