Summary:	ASTERISK-08944: 'r' option disable RTP early bridge problem
Reporter:	Marcel Barbulescu (marcelbarbulescu)	Labels:
Date Opened:	2007-03-06 01:14:04.000-0600	Date Closed:	2007-05-16 13:54:44
Priority:	Trivial	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_dial
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) trace.txt ( 1) verbosedebug.txt
Description:	Asterisk SVN-branch-1.4-r57263 running on CentOS 4.4 with kernel 2.6.9-42.0.10.EL. directrtpsetup=no canreinvite=nonat or canreinvite=no (same behavior) All the peers are on public IPs, no NAT. When a call comes in, the IVR picks up (a2billing) and the caller enters the destination number. The destination is dialed using a provider (with the 'r' option in the dial command) that uses VoipSwitch software, which sends both 183 Session Progress and 180 Ringing with SDP. Asterisk sends a ringing sound to the caller after the Dial command is executed (because of the ?r? option) until the 183 Session Progress message comes in. At that point the Asterisk stops sending any RTP packets back to the caller. As a result the caller hears a short ring and silence after that. After the destination picks up the RTP bridge is performed and the call continues normally. The Asterisk should perform an early bridge when 183 Session Progress and 180 Ringing messages contain SDP with early media. ****** ADDITIONAL INFORMATION ****** A trace file with sip and rtp debug messages is attached. Please note that the IP addresses and the phone numbers in the trace file are not real.
Comments:	By: Serge Vecher (serge-v) 2007-03-06 08:54:44.000-0600 why don't you just set canreinvite=yes? By: Marcel Barbulescu (marcelbarbulescu) 2007-03-06 09:47:07.000-0600 The problem is still the same if canreinvite=yes so the early bridge is not done no matter the canreinvite setting. By: Serge Vecher (serge-v) 2007-03-06 09:50:19.000-0600 ok, can you please download a clean Asterisk 1.4.1 tarball, and attach a debug log with canreinvite=yes as per: 1) Prepare test environment (reduce the amount of unrelated traffic on the server); 2) Make sure your logger.conf has the following line:   console => notice,warning,error,debug 3) restart Asterisk with the following command:   'asterisk -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt' 4) Enable SIP transaction logging with the following CLI commands (1.4/trunk commands in parenthesis): set debug 4 (core set debug 4) set verbose 4 (core set verbose 4) sip debug (sip set debug) 5) Reproduce the problem 6) Trim startup information and attach verbosedebug.txt to the issue. By: Marcel Barbulescu (marcelbarbulescu) 2007-03-06 13:50:59.000-0600 I've attached verbosedebug.txt as per your request. By: Serge Vecher (serge-v) 2007-03-06 14:11:46.000-0600 what happens if you take the 'r' option out? By: Marcel Barbulescu (marcelbarbulescu) 2007-03-06 14:20:09.000-0600 If I take out the 'r' option, the early bridge is performed correctly. By: Serge Vecher (serge-v) 2007-03-06 14:43:53.000-0600 well, there you go, 'r' option forces Asterisk to stay in the call path until it is answered. file, should this be documented in app_dial description or is there a better place? By: Marcel Barbulescu (marcelbarbulescu) 2007-03-06 14:48:35.000-0600 The problem isn't that Asterisk stays in path. After the 183 Session Porgress message with SDP, it stops sending any RTP back to the caller. It doesn't do the early bridge nor generates the ringing sound anymore. By: Marcel Barbulescu (marcelbarbulescu) 2007-03-06 16:18:05.000-0600 I have some ideeas of why is not working (just let me know if I'm way off... :)) app_dial it's coded to try an early bridge when AST_CONTROL_PROGRESS or AST_CONTROL_RINGING if "single", that means "only one destination is enabled" and not ring back nor music back. Because of the 'r' flag (ring back), no early bridge is performed. It makes sense. However, for some reason, the ring back generated to the caller is cut off when it should continue. I suspect that's something related to chan_sip/process_sdp which is executed when 183 and 180 messages come in with SDP. I'm wondering if processing the sdp is necessary for 183 and 180 when the dial has the 'r' option. By: Joshua C. Colp (jcolp) 2007-05-16 13:54:43 This has been fixed in the latest 1.4/trunk from SVN for... probably awhile. Confirmed by me.