Summary:	ASTERISK-09171: Incoming early media problem after Asterisk generates its own early media
Reporter:	Marcel Barbulescu (marcelbarbulescu)	Labels:
Date Opened:	2007-04-03 03:45:49	Date Closed:	2007-05-17 11:00:49
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) verbosedebug.txt
Description:	Asterisk invites the destination and gets back "180 Ringing". It send "180 Ringing" to the source and "183 Session Progress" with SDP (early media) because of progressinband=yes. After a bit the provider responds back again with "183 Progress" with SDP. Asterisk stops sending and sound to the source and it also doesn't send any additional "183 Session Progress" with updated SDP. The source gets a very short ring (it starts when Asterisk sends its own "183 Session Progress" and stops when Asterisk gets the "183 Progress" with SDP from the provider) and only silence after that. ****** ADDITIONAL INFORMATION ****** The bug is somehow related to 9212. In that bug the Asterisk was told to generate ringback by using the Dial with 'r' option and as soon as the provider sends back early media it stops sending any sound to the source so the source gets silence. I guess that the correct behaviour would be in both cases (this bug and 9212) Asterisk to send additional "183 Session Progress" messages with updated SDP to include the IP of the destination as the source of the RTP stream.
Comments:	By: Marcel Barbulescu (marcelbarbulescu) 2007-04-03 03:48:24 There is no other sip message after what's in the trace until the disconnect messages, that are not included. Please note that the IPs and phone numbers in the trace file are not real. By: Marcel Barbulescu (marcelbarbulescu) 2007-04-03 16:38:50 The problem shows up every time when using directrtpsetup=yes and Asterisk indicates progress using its own generator (either using progressinband=yes and receiving a 18X message without SDP, or using Dial with 'r' option) followed by receiving a progress message with SDP. The chan_sip has a explicit test not to send the progress message twice (SIP_PROGRESS_SENT variable) in the case of AST_CONTROL_PROGRESS but in the same time app_dial stops any generators in the begining of wait_for_answer (at least in the case of this bug). So the SIP caller is not receiving additionals 18X with SDP nor the ring generator is restarted. Olle: What's the reason for chan_sip not sending a progress message every time it gets to indicate AST_CONTROL_PROGRESS? Asterisk can receive multiple progress messages with different SDPs, so I assume that it would be good for caller to be updated if the directrtpsetup=yes and the destination is sending early media directly to the caller, right? By: Joshua C. Colp (jcolp) 2007-04-09 07:57:03 Is this only the case when using directrtpsetup, or does it happen even without it on? By: Marcel Barbulescu (marcelbarbulescu) 2007-04-09 13:10:50 It happens with or without it. By: Joshua C. Colp (jcolp) 2007-05-17 11:00:49 I'm confident this issue has been fixed now, if not please reopen. Thanks!