[asterisk-bugs] [JIRA] (ASTERISK-27605) ICE: Not configurable by FQDN for externhost (chan_sip) / external_media_address (chan_pjsip).

[Alexander Traud (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-27605:
---------------------------------------

    Description: 
In Asterisk, ICE candidates are determined automatically, after setting
* {{icesupport=yes}} in the configuration file _sip.conf_ for the SIP channel driver _chan_sip_
* {{ice_support=yes}} in the configuration file _pjsip.conf_ for the SIP channel driver _chan_pjsip_

Furthermore, Asterisk allows
* {{externhost=example.com}} (sip.conf)
* {{external_media_address=example.com}} (pjsip.conf)

to set a fully-qualified domain-name (FQDN). With this, Asterisk can be used with a dynamic IP address, Asterisk resolves its global IPv4 address via DNS-A and this FQDN.

To use ICE in that case, one could go for a public STUN server in _rtp.conf_, like
{code}[general]
stunaddr=stun.l.google.com:19302{code}

However, this has two drawbacks:
# the NAT internal IPv4 address is mentioned in SDP as host ICE candidate
# the result of the STUN server is a server-reflexive ICE candidate (srflx)

Some user-agent clients (UACs; namely Linphone) pick the srflx even if a IPv6 based host ICE candidate is available. That can lead to IPv6 on the signaling layer (SIP) and IPv4 on the media layer (RTP). In such a case, Asterisk uses IPv6 on SIP and RTP. The UAC sends its media via IPv6 and expects to receive media via IPv4. Therefore, the UAC did not punch a possible NAT and all RTP packets from Asterisk are dropped by the NAT; a one-way audio scenario.

Another alternative is to blacklist all local IP addresses in _rtp.conf_:
{code}[general]
ice_blacklist = 192.168.0.0/16
ice_blacklist = 172.16.0.0/12
ice_blacklist = 10.0.0.0/8
ice_blacklist = fe80::/10{code}However, this has one drawback:
Asterisk does not determine srflx at all and only IPv6 are advertised. Some UACs (namely pjsua of PJProject) think that the Asterisk is not reachable via IPv4 (on the RTP layer) at all; the call is not established.

Another alternative is to override/replace the advertised IPv4 based host candidate:
{code}[ice_host_candidates]
192.168.0.2 => 76.164.171.238{code}However, this has one drawback:
Because the IPv4 changes dynamically, one would like to specify the FQDN as replacement here. This is not supported by Asterisk, only IP addresses work as replacement.

  was:
In Asterisk, ICE candidates are determined automatically, after setting
* {{icesupport=yes}} in the configuration file _sip.conf_ for the SIP channel driver _chan_sip_
* {{ice_support=yes}} in the configuration file _pjsip.conf_ for the SIP channel driver _chan_pjsip_

Furthermore, Asterisk allows
* {{externhost=example.com}} (sip.conf)
* {{external_media_address=example.com}} (pjsip.conf)
to set a fully-qualified domain-name (FQDN). With this, Asterisk can be used with a dynamic IP address, Asterisk resolves its global IPv4 address via DNS-A and this FQDN.

To use ICE in that case, one could go for a public STUN server in _rtp.conf_, like
{code}[general]
stunaddr=stun.l.google.com:19302{code}

However, this has two drawbacks:
# the NAT internal IPv4 address is mentioned in SDP as host ICE candidate
# the result of the STUN server is a server-reflexive ICE candidate (srflx)
Some user-agent clients (UACs; namely Linphone) pick the srflx even if a IPv6 based host ICE candidate is available. That can lead to IPv6 on the signaling layer (SIP) and IPv4 on the media layer (RTP). In such a case, Asterisk uses IPv6 on SIP and RTP. The UAC sends its media via IPv6 and expects to receive media via IPv4. Therefore, the UAC did not punch a possible NAT and all RTP packets from Asterisk are dropped by the NAT; a one-way audio scenario.

Another alternative is to blacklist all local IP addresses in _rtp.conf_:
{code}[general]
todo{code}However, this has one drawback:
Asterisk does not determine srflx at all and only IPv6 are advertised. Some UACs (namely pjsua of PJProject) think that the Asterisk is not reachable via IPv4 (on the RTP layer) at all; the call is not established.

Another alternative is to override/replace the advertised IPv4 based host candidate:
{code}[ice_host_candidates]
todo{code}However, this has one drawback:
Because the IPv4 changes dynamically, one would like to specify the FQDN as replacement here. This is not supported by Asterisk, only IP addresses work as replacement.


> ICE: Not configurable by FQDN for externhost (chan_sip) / external_media_address (chan_pjsip).
> ----------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-27605
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27605
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_pjsip, Channels/chan_sip/Interoperability
>    Affects Versions: 13.19.0, 15.2.0
>         Environment: IPv6
>            Reporter: Alexander Traud
>            Assignee: Unassigned
>            Severity: Critical
>              Labels: pjsip
>
> In Asterisk, ICE candidates are determined automatically, after setting
> * {{icesupport=yes}} in the configuration file _sip.conf_ for the SIP channel driver _chan_sip_
> * {{ice_support=yes}} in the configuration file _pjsip.conf_ for the SIP channel driver _chan_pjsip_
> Furthermore, Asterisk allows
> * {{externhost=example.com}} (sip.conf)
> * {{external_media_address=example.com}} (pjsip.conf)
> to set a fully-qualified domain-name (FQDN). With this, Asterisk can be used with a dynamic IP address, Asterisk resolves its global IPv4 address via DNS-A and this FQDN.
> To use ICE in that case, one could go for a public STUN server in _rtp.conf_, like
> {code}[general]
> stunaddr=stun.l.google.com:19302{code}
> However, this has two drawbacks:
> # the NAT internal IPv4 address is mentioned in SDP as host ICE candidate
> # the result of the STUN server is a server-reflexive ICE candidate (srflx)
> Some user-agent clients (UACs; namely Linphone) pick the srflx even if a IPv6 based host ICE candidate is available. That can lead to IPv6 on the signaling layer (SIP) and IPv4 on the media layer (RTP). In such a case, Asterisk uses IPv6 on SIP and RTP. The UAC sends its media via IPv6 and expects to receive media via IPv4. Therefore, the UAC did not punch a possible NAT and all RTP packets from Asterisk are dropped by the NAT; a one-way audio scenario.
> Another alternative is to blacklist all local IP addresses in _rtp.conf_:
> {code}[general]
> ice_blacklist = 192.168.0.0/16
> ice_blacklist = 172.16.0.0/12
> ice_blacklist = 10.0.0.0/8
> ice_blacklist = fe80::/10{code}However, this has one drawback:
> Asterisk does not determine srflx at all and only IPv6 are advertised. Some UACs (namely pjsua of PJProject) think that the Asterisk is not reachable via IPv4 (on the RTP layer) at all; the call is not established.
> Another alternative is to override/replace the advertised IPv4 based host candidate:
> {code}[ice_host_candidates]
> 192.168.0.2 => 76.164.171.238{code}However, this has one drawback:
> Because the IPv4 changes dynamically, one would like to specify the FQDN as replacement here. This is not supported by Asterisk, only IP addresses work as replacement.



--
This message was sent by Atlassian JIRA
(v6.2#6252)