Summary:	ASTERISK-06761: media path not always opened when needed
Reporter:	Jim Gottlieb (tokyojimu)	Labels:
Date Opened:	2006-04-11 23:49:37	Date Closed:	2011-06-07 14:07:47
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) pri-noaudio.debug ( 1) pri-yesaudio.debug
Description:	In certain cases, the media path is not being opened, so the playing of a prompt is not heard by the caller. For example, using Background with the 'n' option (before supervision) or Playback with the 'noanswer' option (again, without supervision) results in the caller not hearing the prompts. The workaround is to first run an application like Ringing, which does open the media path. This is a rather longstanding problem that I'm finally getting around to reporting and is a refiling of issue 0006648, now in the proper project. ****** ADDITIONAL INFORMATION ****** With an extension like this: exten => 16193640054,1,Playback(pleasewait|noanswer) exten => 16193640054,2,Dial(Zap/g1/01136302594407,20) the prompt never gets played (though its access time shows that it was read). But if I do this: exten => 16193640054,1,Ringing exten => 16193640054,2,Playback(pleasewait|noanswer) exten => 16193640054,3,Dial(Zap/g1/01136302594407,20) it works. I also tried using a Wait(1) as the first line, but it still didn't play.
Comments:	By: Andrey S Pankov (casper) 2006-04-12 11:13:42 Bugmarshals: Please add 0006648 into Relationships as a parent. > I'm finally getting around to reporting and is a refiling of issue 0006648, now in the proper project. If you want the issue to be placed into another category you should ask bugmarshals to do so and not repost the same issue as a separate bugreport. Moreover I explained you in details why the media path is not opened. This is not a bug, rather a feature request (should be mailed to mailing lists, not posted in the bugtracker). To facilitate your task I'd suggest you to ask about the possibility to configure incoming zap channel for early media (PROGRESS or ALERTING with in-band progress indicator set). By: Matthew Fredrickson (mattf) 2006-04-21 13:06:43 Can you  post a PRI debug with this?   Although I have serious doubts that anything like this would occur, since by default asterisk just reads whatever data comes in on the zap device regardless of the call state, if I can get more protocol level debug information (pri debug span x) on a call that demonstrates this malbehavior, and another on one that works (with the ringing or answer enabled), that would help in debugging the problem significantly. By: Jim Gottlieb (tokyojimu) 2006-04-21 17:14:44 I have uploaded two files of debug.  pri-yesaudio.debug is from the call that properly played the prompt audio.  pri-noaudio.debug is from the call where the recording did not play (silence was heard for the duration of the recording). Here is the digit table entry for the call with good audio: exten => 16193640054,1,Ringing exten => 16193640054,n,Background(5133|n) exten => 16193640054,n,Busy And here is the entry for the call with no audio on the recording: exten => 16193640054,1,Background(5133|n) exten => 16193640054,n,Busy By: Matthew Fredrickson (mattf) 2006-05-11 03:47:02 Ok, so I have an idea.  I deduce that your switch at the other end requires a progress or alerting message for it to connect the bearer channel (even though we indicate in the proceeding message that there is in band progress information available).  For the working example, try changing the Ringing() application to Progress(). By: Jim Gottlieb (tokyojimu) 2006-05-11 17:31:33 Yes, it also works with Progress() in place of Ringing(). So you believe this is a bug in our C.O. switch software?  That is quite possible.  I'll report it to them, though I could use as much info as possible to make them believe me.  Thanks. By: Matthew Fredrickson (mattf) 2006-05-15 08:58:23 It appears that your switch is requiring a PROGRESS message (as opposed to just the IE) for it to open the bearer circuit path.  We are sending our messages with a progress IE of type "Inband progress available", but it appears that they are not honoring the request until it is seen in an actual progress message. The workaround is to put the Progress() application in your dialplan when the call hits it.