[asterisk-bugs] [JIRA] (ASTERISK-27545) chan_sip: improper handling of Re-invites between IPv4 and IPv6
Nir Simionovich (GreenfieldTech - Israel) (JIRA)
noreply at issues.asterisk.org
Thu Jan 4 03:11:39 CST 2018
[ https://issues.asterisk.org/jira/browse/ASTERISK-27545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nir Simionovich (GreenfieldTech - Israel) updated ASTERISK-27545:
-----------------------------------------------------------------
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 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.
was:
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 file 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.
> 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
>
>
> 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