Summary:	ASTERISK-07303: Call drops on ACK-OK loop
Reporter:	R. Voermans (voermans)	Labels:
Date Opened:	2006-07-07 09:41:56	Date Closed:	2006-11-14 10:49:16.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) asteriskverbose.txt ( 1) chan_sip_reinvite_patch.diff.txt ( 2) messages_llamada ( 3) sip-ack-ok.txt
Description:	I have a strange problem with incoming SIP calls. When a call arives, all signaling goes well. The call is answered by a phone. Our ITSP then sends a re-INVITE. Asterisk OK's it, next our proxy ACK's the OK. Then a strange thing happens: asterisk sends an OK again, to which our proxy (SER) ACK's again. This happens for about 15 seconds, and has as result that the voice-path drops, or only one-way-audio. Please see attached sip-ack-ok.txt for the SIP trace of the call.
Comments:	By: Serge Vecher (serge-v) 2006-07-07 10:59:12 As per BUG GUIDELINES, we need Asterisk sip debug for this: Here is how to get it. 1) Prepare test environment (reduce the ammount of unrelated traffic on the server); 2) Make sure your logger.conf has the following line:   console => notice,warning,error,debug 3) restart Asterik. 4) Enable SIP transaction logging with the following CLI commands: set debug 4 set verbose 4 sip debug 5) Save complete log to file and _attach_ said file to the bug By: R. Voermans (voermans) 2006-07-08 12:22:47 I've attached the corresponding debug. The only thing is: sip debug isn't in it. I did a seperate ngrep in the already attached file. The newly attached file is the asterisk output of set verbose 100 and set debug 100. I couldn't reduce the amount of unrelated traffice on the server, since the PBX is already in production. However, I do hope someone can find something... By: Serge Vecher (serge-v) 2006-07-10 08:54:36 voermans: SIP debug is sort of there, but looks like you showed the output from debug file, which takes some of the information out (which may be a bug in itself). Can you please make sure that you capture from the console directly? Make sure that you follow my steps as outlined in 00048932. Thanks By: Olle Johansson (oej) 2006-08-07 15:57:19 Why would a SIP proxy ACK anything? ACK is sent from UA to UA... By: R. Voermans (voermans) 2006-08-08 02:55:22 OpenSer has RTPProxy installed, so it does respond with and ACK. By: Olle Johansson (oej) 2006-08-08 03:13:59 I don't think OpenSER produces an ACK in that case, that would be a protocol violation... By: Curt Moore (jcmoore) 2006-08-22 20:17:47 Although this bug is against 1.2, I found a similar OK/ACK behavior with trunk and thought I'd add this here instead of opening another bug. There is a missing call to ast_set_flag() in transmit_reinvite_with_sdp() which is present in 1.2.x versions. In trunk, due to the SIP_OUTGOING flag not being set properly in transmit_reinvite_with_sdp(), the reqprep() function inverts the To/From headers on the ACK message. I've attached a patch against trunk, chan_sip_reinvite_patch.diff.txt, which resolves my specific OK/ACK problem with trunk. I also noticed that the transmit_reinvite_with_t38_sdp() function performs pretty much the same functionality as transmit_reinvite_with_sdp().  It will likely fall victim to the same missing call to ast_set_flag().  I currently do not have a T.38 test setup so I can't test this for T.38. Please let me know if any other information is needed. I have a disclaimer on file. By: Serge Vecher (serge-v) 2006-08-23 08:29:23 voermans: could you please test tgrman's patch? Thanks. By: R. Voermans (voermans) 2006-08-23 09:20:51 This line is already in my chan_sip.c! By: Curt Moore (jcmoore) 2006-08-23 10:07:46 As I mentioned, my patch was for SVN trunk; voermans is correct, the call to ast_set_flag() is already present in the 1.2 branch. I have your same setup, SER->Asterisk farm, with 1.2, minus running RTPProxy on SER, and am not seeing the OK/ACK loop. I did see this sort of behavior in the past and if I recall correctly, it ended up being something in my ser.cfg which was causing the ACK to be sent to the wrong place, ie. never delivered, so the OK was continually sent since there was never an ACK received in response to the OK. Also, IMHO, if you're running Asterisk in conjunction with SER, there's really not a reason to use any of SER's media proxy handling as Asterisk does this natively anyway.  I'm sure there are situations where RTPProxy/Mediaproxy are useful but with Asterisk in the mix, from my perspective, proxying the media outside of Asterisk is unneeded.  If you're going to be proxying the media anyway, why not let Asterisk do it instead of using RTPProxy? Instead of using force_rtp_proxy() in SER you could just fix_nated_sdp() and pass the SDP over to Asterisk and Asterisk will send the media to the correct place, as long as it's fixed correctly in SER.  I have this setup running with tens of thousands of users on a farm of Asterisk servers without issue. If there is an issue with re-invites in the 1.2 branch, I'd like to find it and fix it.  What I normally do in order to troubleshoot these types of issues is do an Ethereal capture on the SER server so that I can see what is coming from the ITSP, what SER is sending to Asterisk, what Asterisk is sending back to SER, and what SER is sending back to the ITSP.  Assuming that SER is truly acting as a SIP proxy and the proper record_route() is being done, all SIP messaging should come through SER and it should be easy to see if the response is being sent back to the ITSP correctly.  Many times these are very subtle things like the message being sent to the wrong port, etc.  Without knowing what SER is relaying back to the ITSP, there's really not a good way of debugging this type of issue. My guess is that this is an SER configuation issue and not an Asterisk issue, I could be wrong. :-) By: Sergio Orlando Nasich (nasich) 2006-08-27 20:08:22 Verchers:         I am the same problem with Asterisk Ver. (1.0.x to 1.2.10 with all Patch) and SER (0.8.14) ( my SIP provider). * Calls originates from Grandstream BT100, arrive to SIP channel with SER and all OK. * Calls originates from PSTN on the SER arrives to SIP channel With my Asterisk but:             * If my Asterisk is registered without to edit user on sip.conf, the BT100 SIP phone ring but when answer, call end.             * If my Asterisk is registered with user edited on sip.conf, the tone on PSTN phone is congested. I had runed the DEBUG indicates for you and attached. Thank you By: Olle Johansson (oej) 2006-08-30 08:59:04 Changing the SIP_OUTGOING flag changes direction of the call, which is not what we want here. Let's try to find another patch for getting the headers right. The debug files have no SIP DEBUG packet output in them, so I can't see what's going on. Please attach a proper debug file. Thank you. By: Serge Vecher (serge-v) 2006-09-27 13:35:34 still need a proper debug file (see note ASTERISK-4770932), from 1.2.12.1 please. By: Olle Johansson (oej) 2006-10-25 15:00:20 Please try the "siptransdirection" branch, based on 1.2. Thanks. svn checkout http://svn.digium.com/svn/asterisk/team/oej/siptransdirection bugfix By: Olle Johansson (oej) 2006-10-29 13:19:57.000-0600 Please now try the latest 1.2 in svn. Thanks! By: Curt Moore (jcmoore) 2006-10-30 21:17:26.000-0600 oej: since you re-added the call to ast_set_flag(&p->flags[0], SIP_OUTGOING) to reset the direction of the dialog in transmit_reinvite_with_sdp(), should the same also be done in transmit_reinvite_with_t38_sdp()?  It appears to me that the same thing is being done in the T.38 case and we would want the RE-INVITE to be handled in the same manner. I'm not currently using T.38 and do not have a test environment. Anyone have any thoughts on this? By: Olle Johansson (oej) 2006-10-31 02:29:07.000-0600 tgrman: Absolutely - thank you. Committed to svn. By: Olle Johansson (oej) 2006-11-07 06:51:05.000-0600 Waiting for test results... Need feedback here! By: Olle Johansson (oej) 2006-11-14 10:49:15.000-0600 no answer from reporter.