[Home]

Summary:ASTERISK-27545: chan_sip: improper handling of Re-invites between IPv4 and IPv6 and vice-versa
Reporter:Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech)Labels:IPv4 IPv6 pjsip sip
Date Opened:2018-01-04 00:47:31.000-0600Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Channels/chan_sip/Interoperability Channels/chan_sip/IPv6
Versions:13.18.5 14.7.5 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS 7.X CentOS 6.XAttachments:( 0) Asterisk_ipv4_reinvite_ipv6_transition_issue.pcapng
( 1) Asterisk_ipv6_reinvite_ipv4_transition_issue.pcapng
Description:  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@xxxxxx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
To: sip:600@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@xxxxxx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
To: sip:600@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@xxxxxx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
To: sip:600@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@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@xxxxxx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
To: sip:600@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@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@xxxxxx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
To: sip:600@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.
Comments:By: Asterisk Team (asteriskteam) 2018-01-04 00:47:32.507-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2018-01-04 03:12:27.793-0600

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.

By: Joshua C. Colp (jcolp) 2018-01-04 05:31:33.707-0600

I'm not surprised chan_sip doesn't work like this, and I don't think it ever has. Things are set up once and it doesn't expect any change from IPv4 to IPv6 or back to occur.

The chan_pjsip module supports failover and going to different targets within a call attempt so it supports this behavior and updates the SDP to match the signaling. That is done above PJSIP itself though and in our code, I think by default PJSUA/normal PJSIP would suffer the same thing.

I'm changing this down to Major though. If it starts impacting a large number of people it can be revisited but treating it as critical right now is early.

As well chan_sip is community supported so it will be up to the community to resolve this shortcoming in chan_sip.
By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2018-01-04 05:50:29.994-0600

While chan_sip is indeed under community support, we can't look away from the fact that currently - it is the de-facto standard,
it provides better bang-4-buck ratio and it is more widely accepted by the community. As the community will start moving more
and more servers into the cloud - and the shortage of IPv4 addresses world-wide, this is no longer a "let's wait for them to shout",
I see it as a "they will shout, might as well just handle it now and prevent future issues".

The issue is this, for large scale platforms, you can front Asterisk with Kamailio and rtpengine, which will provide a full blown
media proxying solution and will resolve the issue correctly. But, it will not solve the issue for the rest of the world.

I would like to have some other people in here comment on the above as I see it as a "critical" issue, not a "major" issue.



By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2018-01-04 06:24:20.794-0600

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.


By: Joshua C. Colp (jcolp) 2018-01-04 06:34:06.578-0600

That issue is different. It's referring to reinvites initiated from Asterisk as a result of direct media.
By: Nir Simionovich (GreenfieldTech - Israel) (greenfieldtech) 2018-01-04 07:29:03.586-0600

OK, that is my bad in reading the other issue. Just one more thing I'd like to point out, regardless of the
"community interest" - this is an interoperability/standards issue.

May I refer you to RFC 6157 "IPv6 Transition in the Session Initiation Protocol (SIP)", specifically to section
4.1 subsection 2 of the RFC (https://tools.ietf.org/html/rfc6157#section-4.1):

2.  Each media description in the SDP answer MUST use the same
    network type as the corresponding media description in the offer.
    Thus, if the applicable "c=" line for a media description in the
    offer contained a network type with the value "IP4", the
    applicable "c=" line for the corresponding media description in
    the answer MUST contain "IP4" as the network type.  Similarly, if
    the applicable "c=" line for a media description in the offer
    contained a network type with the value "IP6", the applicable
    "c=" line for the corresponding media description in the answer
    MUST contain "IP6" as the network type."

By: Alexander Traud (traud) 2018-01-21 10:00:22.790-0600

> ICE candidates \[…\] includes the "fe80:" subnet

Just for your information (that should not happen, yes, it is a bug as well), you are able to blacklist local addresses via the configuration file {{rtp.conf}}. There, the black-list allows a range parameter, so you can black-list all IPv4 and IPv6 local addresses with four statements. I did the same last month. If you need the exact statements, please, say so. Currently, those are on some of my testing disks – have to check which one it was. However, even then, you just workaround the issue because many UACs with ICE go for IPv4 on default (because it is recommended in the RFC about ICE).

I think, the best solution to your case would be ICE with no IP address but just the FQDN as candidate. Not required for your case, I guess, but that FQDN candidate should be extracted from externhost (chan_sip) or external_media_address (chan_pjsip). With a FQDN, there should not be any IP candidates anymore. This is a huge change. No idea – how to do it and whether PJProject supports this at all. I created a new issue for that: ASTERISK-27605. Perhaps something you want to vote on (or completely the wrong direction, then sorry).