Summary:	ASTERISK-24657: directmedia=no does not work in Asterisk 13.1.0
Reporter:	Thomas B. Clark (tbclark3)	Labels:
Date Opened:	2015-01-02 21:16:50.000-0600	Date Closed:	2015-01-27 12:43:07.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:	13.1.0	Frequency of Occurrence	Constant
Related Issues:
Environment:	The Asterisk server runs under Fedora 20, with static ipv4 addresses and working ipv6. The yealinkphone is a sip client of the asterisk server. The yealink phone has a non-routable ipv4 address and a routable ipv6 address, but preferentially uses the ipv6 address. The service provider, callwithus, does not have an ipv6 address.	Attachments:	( 0) issue_24657_full_log
Description:	I just upgraded from Asterisk 11.14.2 to asterisk 13.1.0, and that caused directmedia=no to stop working.  It worked in 11.14, and using the same sip.conf it does not work in 13.1.0.  Here is the relevant part of sip.conf: {noformat} [yealinkphone] type=friend host=dynamic context=outgoing secret=xxxxxx defaultuser=xxxxxxx insecure=port,invite directmedia=no qualify=yes {noformat} And here is what happens: {noformat}    -- SIP/callwithus-00000003 is making progress passing it to SIP/yealinkphone-00000002       > 0x7fa784016470 -- Probation passed - setting RTP source address to 69.85.185.222:21708    -- SIP/callwithus-00000003 answered SIP/yealinkphone-00000002 -- Channel SIP/yealinkphone-00000002 joined 'simple_bridge' basic-bridge <5fb81915-9eaa-4b69-9be8-26f8a1db1fff>    -- Channel SIP/callwithus-00000003 joined 'simple_bridge' basic-bridge <5fb81915-9eaa-4b69-9be8-26f8a1db1fff>       > Bridge 5fb81915-9eaa-4b69-9be8-26f8a1db1fff: switching from simple_bridge technology to native_rtp       > 0x7fa70400afd0 -- Probation passed - setting RTP source address to [2601:8:9181:4800:215:65ff:fe27:ac8e]:11786 {noformat} Even if I had {{directmedia=yes}}, Asterisk shouldn't issue a reinvite because the yealinkphone is using ipv6 and the service provider, callwithus, is using ipv4. However, as I stated, I have {{directmedia=no}}, so nothing else should matter, but the statement is being ignored. I have worked around the issue by setting {{,,t}} at the end of all of the Dial statements, and that successfully prevents switching to {{native_rtp}}.  Nothing else I tried does.
Comments:	By: Joshua C. Colp (jcolp) 2015-01-03 07:28:33.733-0600 The bridge_native_rtp module actually operates in two modes: Remote RTP bridging which is when both sides are reinvited to eachother. Local RTP bridging when packets are exchanged within the RTP stack. directmedia will prevent remote RTP bridging but will not stop local RTP bridging as media still flows through Asterisk, just in a more efficient way. Did a reinvite actually happen? By: Thomas B. Clark (tbclark3) 2015-01-03 11:20:42.530-0600 Thanks for the explanation of the native_rtp module; I was not aware of that.  However, I think it did issue reinvites.  I did not them in the debug messages, but the native_rtp causes one-way audio, which it would have no reason to do if the pathway were still through Asterisk.  Also adding ,,t to the Dial command fixes the one-way audio, which it likely does by preventing the external reinvites.  I would be glad to do more testing if you will tell me what you would like. By: Matt Jordan (mjordan) 2015-01-03 21:39:54.259-0600 We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information Make sure your log has 'sip set debug on' enabled. By: Thomas B. Clark (tbclark3) 2015-01-05 19:27:59.424-0600 Attached is a sanitized log produced with directmedia=no in the device definition and sip debug enabled.  It produced a call with one-way audio.  It doesn't look like Asterisk issued a re-invite, but I think it may have issued an initial invite to shift the audio stream to the two devices.  In any case, I have now discovered that if I set directmedia=no in both the general configuration section of sip.conf and in the specific device section, Asterisk remains in the path and I get 2-way audio without having to add ,,t to the Dial string.  This is not the behavior I would expect; I would expect that if you set directmedia=no for the device, it shouldn't matter what is anywhere else.  I do not know if you would consider this to be a bug. By: Matt Jordan (mjordan) 2015-01-12 09:49:11.952-0600 That isn't a complete debug log. It is missing all DEBUG statements. Please follow the instructions on the linked wiki page to generate a log file containing all of the information developers need. Thanks! By: Matt Jordan (mjordan) 2015-01-27 12:43:19.332-0600 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines