Summary:	ASTERISK-27989: res_pjsip_sdp_rtp: Asterisk sources RTP from wrong IPv6 address
Reporter:	Isaac McDonald (imcdona)	Labels:	pjsip
Date Opened:	2018-07-26 17:49:44	Date Closed:
Priority:	Minor	Regression?
Status:	Open/New	Components:	Resources/res_pjsip_sdp_rtp Resources/res_rtp_asterisk
Versions:	13.22.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	CentOS 7 64bit	Attachments:
Description:	Asterisk sources RTP traffic from the most recently assigned IPv6 address rather than the address configured in the transport. Steps to reproduce: 1. Configure a server with an IPv6 address. The following example config will provide a single global IPv6 address on CentOS 7: Config snippet from /etc/sysconfig/network-scripts/ifcfg-eth0 IPV6INIT="yes" IPV6_AUTOCONF="no" IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" IPV6_PEERROUTES="yes" IPV6_PRIVACY="no" IPV6ADDR=2001:DB8::55/64 IPV6_PEERDNS=no   IPV6_DEFAULTGW=2001:DB8::1/64 2. Configure a pjsip transport for the statically assigned IPv6 address [IPv6-udp] type=transport protocol=udp bind=[2001:DB8::55]:5060 allow_reload=yes tos=cs3 cos=3 3. Add a pjsip endpoint. Make sure you don't specify a transport with the "transport=" option. 4. Register a SIP client via IPv6 to the endpoint configured in step 3. 5. Place a test call from the IPv6 endpoint and note how everything works as expected. 6. Add an additional IPv6 address to eth0: ip -6 address add 2001:DB8::75/64 dev eth0 7. Start a tcpdump: tcpdump -i eth1  port not 22 -nn 8. Place a test call from the IPv6 endpoint and note how the SOURCE address of RTP packets, as seen in the tcpdump, is set to the IPv6 address you assigned in step 6 and NOT the IPv6 address assigned to the transport you created in step 2. If you specify the IPv6 transport configured in step 2 as the transport for the endpoint, the source address of RTP packets is the configured transport address. This isn't a viable option though considering that it would break the dual-stack nature of having a endpoint with no specific transport set.
Comments:	By: Asterisk Team (asteriskteam) 2018-07-26 17:49:46.370-0500 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: Isaac McDonald (imcdona) 2018-07-30 09:01:20.726-0500 I would like to add that this bug occurs anytime you get a new IPv6 address. It doesn't necessarily have to be that you've manually added an address. It could be that you've added a new router that's broadcasting a new prefix in which case the server would get a new IPv6 address via SLAAC. By: Joshua C. Colp (jcolp) 2018-08-15 09:11:58.196-0500 This is the result of ICE support for both IPv4 and IPv6. In order to do this the RTP is bound to the wildcard of the system, so we can send and receive traffic on multiple interfaces. The result of this is we rely on the underlying system itself to determine the interface and source address to use. While there is the bind_rtp_to_media_address option it doesn't allow moving between IPv4 and IPv6. I think to support your use case there would need to be a new option and feature which is off by default to behave as you need. By: Joshua C. Colp (jcolp) 2018-08-15 09:12:38.026-0500 Is what I mentioned something you would like to look into implementing to cover your use case? By: Isaac McDonald (imcdona) 2018-08-15 11:49:56.176-0500 Asterisk is putting an IPV6 address in SDP and then relying on the underlying OS to pick the IPv6 source address for RTP which may or may not be the address it put in SDP. Is this expected behavior for ICE? The end result is that an IPV6 endpoint is expecting RTP to come from the IPv6 address Asterisk put in the SDP, not whatever IPv6 address the OS decided to use. By: Joshua C. Colp (jcolp) 2018-08-15 12:10:06.825-0500 It's expected behavior in order for it to work, yes. For each candidate that is placed in the signaling it has to be reachable. The res_pjsip_sdp_rtp and res_rtp_asterisk module does this by binding to the wildcard. SDP itself doesn't define where media will come from - it defines where media should go to, usually they are the same though.