[asterisk-bugs] [Asterisk 0017155]: SIP DTMF problem using RFC2833 between 1.2 <-> 1.4 <-> Unknown-brand/model SBC

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17155 
====================================================================== 
Reported By:                voxter
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17155
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.4.30 
JIRA:                       SWP-1277 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-04-08 17:18 CDT
Last Modified:              2010-04-12 12:41 CDT
====================================================================== 
Summary:                    SIP DTMF problem using RFC2833 between 1.2 <-> 1.4
<-> Unknown-brand/model SBC
Description: 
Basic rundown:

Call from SIP Phone (RFC2833) -> Asterisk 1.2 via SIP and RFC2833 = Digits
are read correctly. Packet trace reveals single digit being transmitted
with event duration 0 on the digit.  This is as expected.

Call from SIP Phone (RFC2833) -> Asterisk 1.2 via SIP and RFC2833 ->
Asterisk 1.4.30 via SIP and RFC2833 = Digits are read correctly, with
rfc2833compensate set on the sip peer between 1.2 and 1.4.  Single Digits
being transmitted with event duration 0 on each digit.  As expected I
believe.

Call from SIP Phone (RFC2933) -> Asterisk 1.2 via SIP and RFC2833 ->
Asterisk 1.4.30 via SIP and RFC2833 -> Unknown Make/model SBC at my ITSP,
not asterisk) with rfc2833compensate set on the peer between asterisk 1.2
and 1.4.30, as well as on the peer to my ITSP, the packets get passed along
as usual, single digits instead of the 6 that asterisk 1.4+ does now, with
event duration 0 = ITSP does not acknowledge valid DTMF.  Presumably due to
the fact that their SBC does not understand event duration = 0.

Workaround: Use IAX between asterisk 1.2 and 1.4 boxes, to force the 1.4
box to craft its own RFC2833  packets to the ITSP in the correct format.

Is there a way to force Asterisk 1.4 in this chain to not simply "forward"
on the broken RFC2833 DTMF from asterisk 1.2, and instead accept the "non
compliant" DTMF, and re-create the packets that are leaving towards the
ITSP?

I dont know if this should qualify as a bug or a feature request,
considering I dont believe it should be standard procedure to forward along
non-rfc compliant RFC2833.

FYI canreinvite=no is set on all peers as well.  I have packet captures to
back this all up, and configs if necessary.  I havent included them yet
because i believe this behavior is possibly intended, or at least expected,
unless I am missing an option that does what I am looking for and i simply
havent found it. 
====================================================================== 

---------------------------------------------------------------------- 
 (0120293) voxter (reporter) - 2010-04-12 12:41
 https://issues.asterisk.org/view.php?id=17155#c120293 
---------------------------------------------------------------------- 
I will be sure to post the captures later on today.  Like i said, im not
sure if this is how its "supposed to work" and therefore becomes a feature
request, but.. We'll figure that out :) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-12 12:41 voxter         Note Added: 0120293                          
======================================================================