[Home]

Summary:ASTERISK-17079: Ealry media is lost on accepted calls (with open r2 support, Elastix 2 flavor)
Reporter:Raúl Torres-Duque (rtorresduque)Labels:
Date Opened:2010-12-08 12:33:48.000-0600Date Closed:2010-12-22 20:55:30.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:This seems to be a bug in R2 chan_dahdi support.

The problem is that the audio that you hear during the voicemail prompt ("Por favor deje su mensaje ... blah blah"), is sent as "early media". In
MFC-R2 there is really no signal to notify whether inband information is available, the call is just accepted. I am unsure if typically all telcos provide alerting information, the R2 support in Asterisk has been working without major complains for a while, so I don't want to break backwards compatibility by adding inband media to all calls.

To fix this I think a new configuration is needed, something like mfcr2_media_on_accept=yes or something along those lines. This would mean when the call is accepted (but not answered) media will be passed through instead of waiting for the answer signal. That should fix the problem with voicemail in the telco.
Comments:By: Moises Silva (moy) 2010-12-10 12:36:05.000-0600

This should be assigned to me. Any bugmarshals around?

I need to check if chan_dahdi.conf has already some option for early media, and I am even tempted to always pass-thru media after the call is accepted, from the ITU spec seems that is the proper behavior.

By: Richard Mudgett (rmudgett) 2010-12-10 14:08:04.000-0600

moy:
To fix, you just need to queue an AST_CONTROL_PROGRESS frame at the appropriate time.

I did not see you in the list to assign the issue.

By: Moises Silva (moy) 2010-12-12 18:28:36.000-0600

rmudgett: thanks for the hint, I'll try that. Do you know of other side-effects if I stop setting .needringing = 1 (which later enqueues AST_CONTROL_RINGING in dahdi_read), and I now enqueue AST_CONTROL_PROGRESS instead? Other than now media will pass-thru?

in SIP -> MFCR2 scenario, I guess that would mean the SIP leg would get a 183 and no 180  at all? which I guess is fine?

mariner7: can you please try the code from branch:

http://svn.digium.com/svn/asterisk/team/moy/mfcr2-1.6-progress

By: Richard Mudgett (rmudgett) 2010-12-13 09:41:02.000-0600

moy:  If you have a positive indication that the far end is ringing you should still send an AST_CONTROL_RINGING.  Other channel drivers may still need it for their protocol.

By: Raúl Torres-Duque (rtorresduque) 2010-12-13 16:49:28.000-0600

We'll have to wait until the weekend to test; the call center works from 6 to 22 monday to saturday and they have already told me to wait until then.
I must clone the current system to have a backup (just in case) but I was wondering if there is an alternative to recompile the whole thing? Something like copying only the files that changed? This is an Elastix server with the call center module and these flavored systems doesn't always like people messing around with code. Source code is not even there. On top of that it has QueueMetrics which shouldn't be an issue but given the history with this customer I wouldn't want to take a step back, so if I can only copy a couple of files I could test it and have a feedback for you much sooner



By: Digium Subversion (svnbot) 2010-12-22 19:46:17.000-0600

Repository: asterisk
Revision: 299493

U   trunk/channels/chan_dahdi.c

------------------------------------------------------------------------
r299493 | moy | 2010-12-22 19:46:16 -0600 (Wed, 22 Dec 2010) | 6 lines

Enqueue AST_CONTROL_PROGRESS after AST_CONTROL_RINGING when MFC-R2 calls are accepted

(closes issue ASTERISK-17079)
Reported by: mariner7
Tested by: moy

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=299493

By: Digium Subversion (svnbot) 2010-12-22 20:28:39.000-0600

Repository: asterisk
Revision: 299530

U   branches/1.6.2/channels/chan_dahdi.c

------------------------------------------------------------------------
r299530 | moy | 2010-12-22 20:28:38 -0600 (Wed, 22 Dec 2010) | 7 lines

Enqueue AST_CONTROL_PROGRESS after AST_CONTROL_RINGING when MFC-R2 calls are accepted

(closes issue ASTERISK-17079)
Reported by: mariner7
Tested by: moy


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=299530

By: Digium Subversion (svnbot) 2010-12-22 20:53:03.000-0600

Repository: asterisk
Revision: 299531

_U  branches/1.8/
U   branches/1.8/channels/chan_dahdi.c

------------------------------------------------------------------------
r299531 | moy | 2010-12-22 20:53:03 -0600 (Wed, 22 Dec 2010) | 13 lines

Merged revisions 299530 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

........
 r299530 | moy | 2010-12-22 21:28:37 -0500 (Wed, 22 Dec 2010) | 7 lines
 
 Enqueue AST_CONTROL_PROGRESS after AST_CONTROL_RINGING when MFC-R2 calls are accepted
 
 (closes issue ASTERISK-17079)
 Reported by: mariner7
 Tested by: moy
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=299531

By: Digium Subversion (svnbot) 2010-12-22 20:55:29.000-0600

Repository: asterisk
Revision: 299532

_U  trunk/

------------------------------------------------------------------------
r299532 | moy | 2010-12-22 20:55:29 -0600 (Wed, 22 Dec 2010) | 19 lines

Blocked revisions 299531 via svnmerge

................
 r299531 | moy | 2010-12-22 21:53:02 -0500 (Wed, 22 Dec 2010) | 13 lines
 
 Merged revisions 299530 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ........
   r299530 | moy | 2010-12-22 21:28:37 -0500 (Wed, 22 Dec 2010) | 7 lines
   
   Enqueue AST_CONTROL_PROGRESS after AST_CONTROL_RINGING when MFC-R2 calls are accepted
   
   (closes issue ASTERISK-17079)
   Reported by: mariner7
   Tested by: moy
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=299532