[Home]

Summary:ASTERISK-02454: change in chan_mgcp.c causes dtmfmode=inband to not work
Reporter:duanecox (duanecox)Labels:
Date Opened:2004-09-23 16:24:35Date Closed:2011-06-07 14:05:07
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:There was a change in chan_mgcp.c on 8/14/04 that has caused our dtmfmode and mediagateways to cease function.

We have our mgcp.conf device set to dtmfmode=inband
and with this new change in chan_mgcp.c, asterisk will not recognize key tones; will not dial numbers.

I see this same problem with asterisk-1.0.0
Here was the change.

diff -ur asterisk.2004.08.13/channels/chan_mgcp.c asterisk.2004.08.14/channels/chan_mgcp.c
--- asterisk.2004.08.13/channels/chan_mgcp.c    2004-08-12 15:26:40.000000000 -0500
+++ asterisk.2004.08.14/channels/chan_mgcp.c    2004-08-13 08:19:29.000000000 -0500
@@ -2002,7 +2002,7 @@
            add_header(&resp, "R", "L/hd(N)");
            break;
        case MGCP_OFFHOOK:
-            add_header(&resp, "R", "L/hu(N), L/hf(N), D/[0-9#*](N)");
+            add_header(&resp, "R", (p->dtmfmode & MGCP_DTMF_INBAND) ? "L/hu(N),L/hf(N)" : "L/hu(N),L/hf(N),D/[0-9#*](N)");
            break;
    }
    if (strlen(tone)) {
@@ -2056,7 +2056,7 @@
            add_header(&resp, "R", "L/hd(N)");
            break;
        case MGCP_OFFHOOK:
-            add_header(&resp, "R", "L/hu(N),L/hf(N),D/[0-9#*](N)");
+            add_header(&resp, "R",  (p->dtmfmode & MGCP_DTMF_INBAND) ? "L/hu(N),L/hf(N)" : "L/hu(N),L/hf(N),D/[0-9#*](N)");
            break;
    }
    if (strlen(tone2)) {
@@ -2096,7 +2096,7 @@
            add_header(&resp, "R", "L/hd(N)");
            break;
        case MGCP_OFFHOOK:
-            add_header(&resp, "R", "L/hu(N),L/hf(N),D/[0-9#*](N)");
+            add_header(&resp, "R",  (p->dtmfmode & MGCP_DTMF_INBAND) ? "L/hu(N), L/hf(N)" : "L/hu(N),L/hf(N),D/[0-9#*](N)");
            break;
    }
    /* SC: fill in new fields */
Comments:By: Brian West (bkw918) 2004-09-24 06:54:19

Please attach a diff -u and do you have a disclaimer onfile?
By: duanecox (duanecox) 2004-09-24 08:54:56

This is not a patch, the diff above is the change that was made in CVS on or around 8/14/2004.  I hadn't cvs updated in a while.  Loading asterisk-1.0.0 broke everything that I have been working with for several months.  I started from the current CVS, found that my problem existed there as well, and started working backwards.

The diff above was the change that was made and I hadn't discovered it until now.  I'm not sure why it was changed... ?
By: Mark Spencer (markster) 2004-09-24 11:11:50

It was changed to prevent duplicate digits because if you're doing inband, your endpoint should be sending its digits in-band and not out of band.
By: duanecox (duanecox) 2004-09-24 12:42:49

BTW, this was the origin:  http://bugs.digium.com/bug_view_advanced_page.php?bug_id=0002248

edited on: 09-24-04 14:23
By: duanecox (duanecox) 2004-09-24 14:21:02

Found out more info...

Wave7 sends DTMF out-of-band until the call is setup.  Once the RTP session is established they send the DTMF inband.

Apparetnly this is the normal behaviour for inband, as there is no way to send DTMF inband until the RTP is established, so prior to to RTP setup, DTMF is passed out-of-band.

So apparently asterisk was changed to not look for any out-of-band DTMF when set to inband.  From what I am finding out, this is incorrect and asterisk should support out-of-band DTMF up to the point the RTP is established.

edited on: 09-24-04 14:24
By: Mark Spencer (markster) 2004-09-24 15:18:35

okay try latest cvs...
By: duanecox (duanecox) 2004-09-27 09:51:48

Updated to latest cvs.  I see the change made to chan_mgcp.c, but * still doesn't recognise digits during call setup.
By: Mark Spencer (markster) 2004-09-27 11:40:47

Just find me on IRC or call and I'll see what I can do.
By: twisted (twisted) 2004-10-14 08:21:14

What's the status on this?
By: Mark Spencer (markster) 2004-10-14 09:24:52

We have strong reason to believe this is not actually a bug on the Asterisk side, but one on the other side because they don't send RTP traffic after the CRCX.
By: twisted (twisted) 2004-10-14 12:52:26

so this is/should not be classified as a MAJOR bug?
By: Mark Spencer (markster) 2004-10-14 14:26:21

At this point, I have no reason to suspect this is a bug at all since as I understand it the trace shows no rtp traffic.
By: Digium Subversion (svnbot) 2008-01-15 15:08:07.000-0600

Repository: asterisk
Revision: 3831

U   trunk/channels/chan_mgcp.c

------------------------------------------------------------------------
r3831 | markster | 2008-01-15 15:08:07 -0600 (Tue, 15 Jan 2008) | 2 lines

If no RTP stream is up, always request digits (bug ASTERISK-2454)

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

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