Summary:	ASTERISK-08326: Asterisk stays in the audio path if "t" option in Dial is used
Reporter:	Brad Templeton (bradtem)	Labels:
Date Opened:	2006-12-11 00:20:35.000-0600	Date Closed:	2011-06-07 14:02:48
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) aout ( 1) aout-with-debug ( 2) conf.tar ( 3) fbugout
Description:	A SIP INVITE comes in from a Sip PSTN originaton DID to Asterisk.  As a result in the dialplan, a Dial is done to two channels, ie. Dial(SIP/at320&SIP/brad,r).   This sends an individual invite to each device with an SDP pointing back to the Asterisk server (not the SDP of the DID.) When a phone answers (this phone is behind a remote NAT, but due to STUN is able to correctly receive calls when called on its own, Dial(SIP/at320) it sends back a 200 OK with the  correct SDP for itself to the Asterisk Server, and the Asterisk server sends a 200 OK to the DID with the SDP of the phone (at320.) This fails (no audio in either direction) because the phone was INVITEd with an SDP of the Asterisk box.  It sends audio there and expects to get it from there. The DID sends audio to the phone (which rejects it since it is not expecting audio from that address).   Being a liberal device it accepts audio from the Asterisk box but receives none.  The Asterisk box must not even be bridging the outgoing audio from Phone -> Asterisk -> DID.   (On the DID we do hear the generated ringtone from the ",r" but not from the phone.) Correct behaviour here, I think, is a reinvite to the phone (to tell it to exchange native bridged audio with the DID) or if canreinvite is disabled, to send the DID an Asterisk server's SDP, and to hairpin bridge audio for the two channels.   The former is preferred, of course. ****** ADDITIONAL INFORMATION ****** Step 2:  Press HOLD on phone.   Causes INVITE with IP address of 0.0.0.0 in the SDP.  DID begins hearing music on hold, as expected.    Audio begins to work, both ways.  Reason unknown (may be phone becoming more liberal.)  However, the SDPs in the various messages are definitely wrong. Example of this is in the attached log. For reference, DID is icall 74.52.15.138:5060 Asterisk Serveri is 198.144.201.82:5160  (Also known internally as 192.168.123.10 to the other channel it calls which does not get connected) Phone in this example is at 68.122.32.101:5160
Comments:	By: Joshua C. Colp (jcolp) 2006-12-11 09:56:25.000-0600 Could you also please upload your configuration plus core debug? Core debug can be gotten by setting debug to output to console in logger.conf and typing "set debug 9" in the CLI. By: Brad Templeton (bradtem) 2006-12-11 13:49:14.000-0600 I have uploaded debug output, and an edited down version of my sip.conf with the appropriate channels in it.   Let me know if you really need the more expanded one. I must admit the behaviour of going on hold is confusing me a touch.  This may indicate the phone is doing something odd, but it remains the case that the call works to the phone with a direct single channel dial but not a multi, and the SDP relationships seem to be wrong. Is there a way to get asterisk to stop putting colour change and other terminal codes into the console output?   I would like to turn that off permanenty if I could. By: Brad Templeton (bradtem) 2006-12-11 14:50:19.000-0600 One other note -- this config is slightly modified from others, but I have tried all permutations of canreinvite= and nat= on the phone and DID channels and the result is the same. By: Olle Johansson (oej) 2006-12-15 05:20:48.000-0600 bradtm: The 200 OK to the DID does include ASterisk's IP, not the phone. c=IN IP4 198.144.201.82 1.2 never sets up a call directly, it sets it up to and from Asterisk, then re-invites if possible. With clients behind NAT using stun, re-invites may not work properly. You report this as 1.2, but there's talk of t.38 in the log file - which version are you really using? The start of the output says "svn trunk". We need to know exact version to help you. Let's take call setup first, then the hold scenario. One thing at a time, please. For colours, try the "n" option or check the options in asterisk.conf. By: Brad Templeton (bradtem) 2006-12-15 14:16:49.000-0600 Thanks.  Note that nocolor=yes in asterisk.conf only turns off some of the annoying color.  A -n on the start of the daemon does turn it all off. So you're right.  The aout-with-debug has the right SDP sent (for hairpinned audio).   The original aout without debug however does send the SDP of the phone to the DID, while the remote phone was invited with the DID of the asterisk server -- and thus, I presume no audio. I have no idea why the behaviour changed after I enabled debug for you.  The server was also restarted and it doesn't duplicate now at home.  (I will take the phone to the other location, behind a different NAT, to try to duplicate with debug on.) As for my version, I _thought_ I had checked out the latest trunk of the 1.2 branch when I built in June, but maybe I got the 1.4 trunk instead. The Rev I have is 47821 and I now see it's from URL: http://svn.digium.com/svn/asterisk/trunk, so I will update as well when I get a break. Sorry, I hate duplicatability problems as much as the next guy. By: Brad Templeton (bradtem) 2006-12-15 14:38:47.000-0600 Oh yes, I should also add that in neither case do we see exactly the right behaviour.   If both channels can talk directly, the thing to do is to invite the phones that can talk directly to the DID with the SDP of the DID, and feed the DID early media with simulated ringtone from the Asterisk server.   When a phone that can talk directly to the DID answers, its SDP should be sent in the OK to the DID. If a phone can't talk directly to the DID (ie. it's a different type of channel, or is on a network that can't see the DID) then the phone should get a server SDP in its invite, and the server will bridge the audio. Reinvite is not needed here.  The only danger is that a non-strict originator (DID) might receive audio from another phone that answers or attempts to send early media to the address in the SDP it is invited with.   A strict originator would only accept audio from the SDP in the early media response, then switch to the new SDP in the OK response. To avoid that, you would instead use server SDPs, and then after the first channel has answered, do reinvites to make that channel talk to the DID natively and directly.   Of course in a port-rewriting nat there could be issues as there always are with reinvites. Right now Asterisk does not seem to detect when two channels it wants to natively bridge are not on the same internet.   (Ie. one is on the real external internet, and the other is on an internal natted network the Asterisk server can see but the outside world can't.   Sometimes it tries to native bridge those, which fails, but that's a different issue than this.) By: Brad Templeton (bradtem) 2006-12-17 03:04:58.000-0600 I've attached a new file fbugout, which demonstrates the SDP problem.  Not quite sure why it happens reliably on the remote NAT but not on the NAT which the * server has access to. This is still the same Asterisk version from earlier this year.  I have not yet installed the latest trunk and will do so early next week if you like. This one was not done with the "r" tag, however, I also did it with that tag and got the same result. However, I have annotated this log with lines tagged with "BUGNOTE" to comment on the SDPs so I didn't upload the similar unit with the r tag. As noted the right behaviour here is, I think a reinvite to have the phone and DID connect directly, as both have canreinvite=yes. By: Brad Templeton (bradtem) 2006-12-17 03:55:19.000-0600 Note I have upgraded to SVN Trunk 48507 (yesterday) and behaviour and output are the same. I have now determined this bug is due to the "t" flag which I was using as an option on my dial commands.  With the "t" flag absent, audio works, when it is present the audio does not work until you put the call on hold and release it. So the SDPs are a bit of a diversion -- though they are still not correct. So now I'm at a bit of a loss to explain what's taking place.  The phone would be sending audio to Asterisk, which is presumably forwarding it to the DID, which is taking it from Asterisk even though it got the SDP of the phone.  Ie. it's being insecure.   However, the "t" flag is somehow blocking asterisk forwarding that until after the hold/unhold. The DID should be sending its audio directly to the phone.  I don't know why the 'hold' fixes this. The "t" flag is keeping Asterisk in the audio path.  Without the "t" asterisk is doing a proper reinvite to the phone to tell it to talk directly to the DID, and audio flows as it should. Note that if canreinvite=no, asterisk claims it is doing a packet bridge but in fact there is one way audio because the bad SDP relationship is set up and never corrected by a reinvite. (I'm starting to believe canreinvite=no should almost never be set, even if it did not generate buggy behaviour.  It is only truly needed in two situations.  The first is if you try to connect two devices that, upon reinvite, both change their port number and can't do invite-without-sdp.  The second is when you have devices on a hidden network visible to the Asterisk box but not to the outside world, connecting to devices on another network including the external internet.  There asterisk must packet bridge.  However, in this case, Asterisk should not need a canreinvite=no because it should be able to spot that the hidden network device has an SDP that is invisible and inconsistent with the external network device.  However, this is another bug which I should file on its own.) By: Brad Templeton (bradtem) 2006-12-18 14:53:55.000-0600 Adding a note based on the revised title: Asterisk is of course supposed to stay in the audio path if "t" is used (except see note below).   The problem is it is doing so in a way that results in no audio in certain circumstances. This may be because of the assymetrical audio path which might be deliberate.  If you can do an assymetrical audio path it is the right choice, since Asterisk really only needs to be in the audio path from the channel with the "t" going out to hear those DTMF tones, and need not be in the other path. However, Such an assymetric path will not always work.  A strict endpoint may not accept audio from an address it is not expecting, for security reasons.  And of course, many NATs and firewalls will not allow UDP streams in from an address they have not sent to. However, I believe most endpoints are not strict and full-cone NATS do allow all comers to send traffic to a port, as do manually opened NATs.  This makes the assymetric audio worth preserving -- but it might have to be yet another flag. Now for the bottom note, which I haven't yet checked.  Asterisk could avoid staying in the audio stream if the endpoint it wishes to get DTMF from is using SIP INFO for DTMF instead of inband or in the RTP.   This would actually be a very useful feature, allowing "t" and other DTMF capturing modes to exist without having to force the audio stream through the Asterisk server. I was talking about this in IAX with Mark, the idea that IAX should be modified when it redirects the RTP for native bridge to hairpin the DTMF (which is always out of band in IAX) but not the audio, for similar purposes.  This may be beyond the scope of 1.4 though. By: Brad Templeton (bradtem) 2006-12-19 21:37:57.000-0600 Followup note:  Looks like there is a patch available to take Asterisk out of the media stream when SIP INFO is used, and only DTMF is desired from the media stream.  So that's great (just need the same for IAX).    While most people seem to be preferring rfc2833 for DTMF, in fact SIP INFO should be the encouraged choice because it means Asterisk really only needs to stay in the media stream when connecting phones that can't reach each other, or for recording/meetme, but not for most of the flags on Dial. This in turn means less risk of these assymetric RTP streams I'm getting over this issue. By: Serge Vecher (serge-v) 2006-12-26 14:31:09.000-0600 bradterm: what patch are you referring to? By: Olle Johansson (oej) 2006-12-27 09:36:31.000-0600 The patch for direct media in invites is severly broken and should have been disabled before the 1.4 release. It's on my todo-list. By: Brad Templeton (bradtem) 2007-01-02 18:36:03.000-0600 The patch I refer to is at  bug 6735, however it notes that the patch was not applied but the problem was solved by "Kevin" though it says no more. I've updated to the latest trunk (post 1.4 official release) so will test some of these things a bit more.   The version I was using was pretty unstable, hopefully the various seg faults are also gone. By: Olle Johansson (oej) 2007-02-15 11:45:51.000-0600 What's the status here? Any specific bug to look into with latest svn trunk? I see a lot of good ideas for future development, but do we still have a bug? By: Brad Templeton (bradtem) 2007-02-15 13:33:10.000-0600 I regret that after this I had to give up on trunk due to stability issues and go to the 1.4 svn, so I have been unable to track progress on this. By: Olle Johansson (oej) 2007-02-16 06:21:18.000-0600 Closing this for now. Will re-open if this becomes an issue again. Thanks.