asterisk users - Jul 2006 - dtmfmode=inband but SDP also indicates rfc2833

I'm trying to figure out a way around a problem that I'm having.  My 
carrier sends me a SIP INVITE that indicates that the dtmf modes 
available are inband (0), and rfc2833 (101).  My asterisk server 
(1.2.9.1) sends back a 200 OK message and shows in its SDP Media 
Description that we accept inband (0) and rfc2833 (101).  My carrier 
therefore sends all DTMF via rfc2833 which obviously causes problems 
since asterisk is configured for inband.

I've tried going pure rfc2833 with the carrier, and am having DTMF 
related problems.  From the research that I have done with my issue it 
seems to be a problem with the way asterisk sends the rfc2833 packets 
out at nearly the same time.  Altering the timing that asterisk uses to 
send the rfc2833 packets seems too deeply seated in asterisk.  I 
therefore have settled on the idea on using inband for dtmf.  My 
termination tests using inband have been successful.

So here is what i think will solve my particular problem.  I just want 
to respond with a 200 OK that does not contain anything about rfc2833 in 
the SDP.  Is this fairly doable.  I've been diging through chan_sip.c 
and think I could just make a couple of modifications to make asterisk 
do what I need it to.  I'm hoping to have someone who is familiar with 
chan_sip.c enlighten me as to whether or not this can be done, and what 
functions I would need to modify in order to make it happen.

Thank You
Stagg Shelton
www.oneringnetworks.com

I answered my own question.  My objective was reached with a simple 
return statement on line 4384 of chan_sip.c in asterisk 1.2.9.1 ftp 
download.  The effect that this has is that asterisk will return a 200 
OK that indicates in the SDP that only inband DTMF is supported.  My 
carrier detects this and their NexTone Session Switch sends out dtmf  
inband.

It sucks having to force asterisk to operate in this manner, but 
hopefully asterisk implementation of rfc2833 will get the bugs worked 
out, if they are in fact bugs, and not design desicions.

Stagg Shelton wrote:
> I'm trying to figure out a way around a problem that I'm having. 
My
> carrier sends me a SIP INVITE that indicates that the dtmf modes 
> available are inband (0), and rfc2833 (101).  My asterisk server 
> (1.2.9.1) sends back a 200 OK message and shows in its SDP Media 
> Description that we accept inband (0) and rfc2833 (101).  My carrier 
> therefore sends all DTMF via rfc2833 which obviously causes problems 
> since asterisk is configured for inband.
>
> I've tried going pure rfc2833 with the carrier, and am having DTMF 
> related problems.  From the research that I have done with my issue it 
> seems to be a problem with the way asterisk sends the rfc2833 packets 
> out at nearly the same time.  Altering the timing that asterisk uses 
> to send the rfc2833 packets seems too deeply seated in asterisk.  I 
> therefore have settled on the idea on using inband for dtmf.  My 
> termination tests using inband have been successful.
>
> So here is what i think will solve my particular problem.  I just want 
> to respond with a 200 OK that does not contain anything about rfc2833 
> in the SDP.  Is this fairly doable.  I've been diging through 
> chan_sip.c and think I could just make a couple of modifications to 
> make asterisk do what I need it to.  I'm hoping to have someone who is 
> familiar with chan_sip.c enlighten me as to whether or not this can be 
> done, and what functions I would need to modify in order to make it 
> happen.
>
> Thank You
> Stagg Shelton
> www.oneringnetworks.com
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> Asterisk-Users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>
>

Mick,

I did ultimately force asterisk to the point where it will not accept or 
send rfc2833.  I did this by modifying chan_sip.c in the function 
add_noncodec_to_sdp  I simply put a return statement in the logic before 
it got to the point where asterisk would add all the supported codecs to 
the sdp.  Here is the snippet of the code that I altered.

static void add_noncodec_to_sdp(const struct sip_pvt *p, int format, int 
sample_rate,
                                char **m_buf, size_t *m_size, char 
**a_buf, size_t *a_size,
                                int debug)
{
        int rtp_code;

        if (debug)
                ast_verbose("Adding non-codec 0x%x (%s) to SDP\n", 
format, ast_rtp_lookup_mime_subtype(0, format));

        /*  Stagg Forcing Return so as to force INBAND in SDP Nothing 
below should execute*/
                return;
...


As I put it in my reply to the the mailing list, this is an ugly hack, 
but at least for my situation it works 99% of the time.  I am currently 
using my server as a proxy server between my customers and my upstream 
carrier, so I really don't care about rfc2833, and as such I can afford 
to implement this ugly hack.

--Stagg




Mick Noordewier wrote:
>Dear Stagg,
>
>I saw your posting on Asterisk-Users, and I have a similar problem.  I
>haven't seen any other solution, so I though I would ask if you had an
>update before I posted to the list myself.
>
>I tried a version of your modification, removing the "a=fmtp" line
on
>the SIP invite response.  However, there is still another line "m=audio
>10988 RTP/AVP 0 101" response that the carrier detects.  This seems
>unresponsive to any dtmfmode statement in sip.conf.  My carrier then
>sends out of band dtmf as it did before, even though I've got
>dtmfmode=inband in sip.conf.  Before I start hacking further, do you
>know a way to suppress the rfc2833 indication in this response?
>
>Many thanks for any help,
>
>Mick Noordewier
>mick@micktel.com
>
>------------------------------------------------------------------------------------
>
>Re: [Asterisk-Users] dtmfmode=inband but SDP also indicates rfc2833
>
>Stagg Shelton
>Sun, 02 Jul 2006 13:38:23 -0700
>I answered my own question. My objective was reached with a simple
>return statement on line 4384 of chan_sip.c in asterisk 1.2.9.1 ftp
>download. The effect that this has is that asterisk will return a 200 OK
>that indicates in the SDP that only inband DTMF is supported. My carrier
>detects this and their NexTone Session Switch sends out dtmf inband.
>
>It sucks having to force asterisk to operate in this manner, but
>hopefully asterisk implementation of rfc2833 will get the bugs worked
>out, if they are in fact bugs, and not design desicions.
>
>Stagg Shelton wrote:
>
>
>    I'm trying to figure out a way around a problem that I'm having.
My
>    carrier sends me a SIP INVITE that indicates that the dtmf modes
>    available are inband (0), and rfc2833 (101). My asterisk server
>    (1.2.9.1) sends back a 200 OK message and shows in its SDP Media
>    Description that we accept inband (0) and rfc2833 (101). My carrier
>    therefore sends all DTMF via rfc2833 which obviously causes problems
>    since asterisk is configured for inband.
>
>    I've tried going pure rfc2833 with the carrier, and am having DTMF
>    related problems. From the research that I have done with my issue
>    it seems to be a problem with the way asterisk sends the rfc2833
>    packets out at nearly the same time. Altering the timing that
>    asterisk uses to send the rfc2833 packets seems too deeply seated in
>    asterisk. I therefore have settled on the idea on using inband for
>    dtmf. My termination tests using inband have been successful.
>
>    So here is what i think will solve my particular problem. I just
>    want to respond with a 200 OK that does not contain anything about
>    rfc2833 in the SDP. Is this fairly doable. I've been diging through
>    chan_sip.c and think I could just make a couple of modifications to
>    make asterisk do what I need it to. I'm hoping to have someone who
>    is familiar with chan_sip.c enlighten me as to whether or not this
>    can be done, and what functions I would need to modify in order to
>    make it happen.
>
>    Thank You
>    Stagg Shelton
>    www.oneringnetworks.com
>
>
>  
>

----- Stagg Shelton <asterisk@oneringnetworks.com>
wrote:
> I did ultimately force asterisk to the point where it will not accept
> or 
> send rfc2833.  I did this by modifying chan_sip.c in the function 
Asterisk should not be sending an SDP with RFC-2833 in it when the
dtmfmode=inband in sip.conf. If it is doing that, please capture a 'sip
debug' of this happening and opening a bug on bugs.digium.com :-)

-- 
Kevin P. Fleming
Senior Software Engineer
Digium, Inc.