[asterisk-bugs] [Asterisk 0018189]: RFC2833 DTMF generation broken due to SSRC change on bridges channels

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18189 
====================================================================== 
Reported By:                marcbou
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18189
Category:                   Core/RTP
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.8.0 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-10-22 12:13 CDT
Last Modified:              2010-10-27 01:51 CDT
====================================================================== 
Summary:                    RFC2833 DTMF generation broken due to SSRC change on
bridges channels
Description: 

Since upgrading to the latest 1.8.0-rc, DTMF digits sent over SIP/RTP to
our service provider were no longer being detected.

We analyzed packet dumps, comparing old and new RTP packets being
generated by asterisk.

The difference was tracked down to asterisk 1.8.0-rc now changing the SSRC
value for RFC2833 DTMF digit packets.

If in main/channel.c:ast_channel_bridge() I comment out 

    ast_indicate(c0, AST_CONTROL_SRCCHANGE);
    ast_indicate(c1, AST_CONTROL_SRCCHANGE);

the SSRC no longer changes for DTMF digits and the provider can detect
them again.

However I am not sure if the change doesn't adversely affect other things.
Please advise.

Kind regards,

Marc Boucher



====================================================================== 

---------------------------------------------------------------------- 
 (0128409) langen5 (reporter) - 2010-10-27 01:51
 https://issues.asterisk.org/view.php?id=18189#c128409 
---------------------------------------------------------------------- 
Hi, as I had the same issue on sending rtpevents to our provider, I spend a
lot of time in searching and testing. As it might help I would like to
share what I found out so far.

1.) as mentioned before - rtpevents are dissmissed by our provider,
because the ssrc identifier of the rtpevent is different to the ssrc
identifier of the associated rtp-traffic. As this is incomplient to rfc1889
(SSRC, Synchornization source) the provider is right to dismiss the
rtpevents (please correct me, if I'm wrong, but that was the response from
our provider).

2.) by searching I also came along issue 16292 and applied the patch to
chan_sip.c. The ssrc identifier of the rtpevents were constant to the
associated rtp-traffic with the patch applied AND "constantssrc=yes" set in
sip.conf (constantssrc=yes alone did not have any influence - I tested
asterisk-versions 1.6.2.0, 1.6.2.2, 1.6.2.6, 1.6.2.11, 1.6.2.13).
further on:
- the patch does only work up to version 1.6.2.6 as with version 1.6.2.7
the "constantssrc" flag was removed from the sources (and also from example
sip.conf) - does anyone know, why? (that's why I'm sceptic regarding note
128405).

Cross-influences, I cannot explain, but maybe someone here:
the ssrc identifier is the same and rtpevents are processed IF:
- an rtpevent is sent by the dial-command with the "D" flag (but the ssrc
identifier is changed again, if rtpevents are generated due to
user-interaction)
OR
- if the "t" flag is set by the dial-command (in that case not even
"constantssrc=yes" is required in sip.conf) - is this due to some special
bridging-mode or so? Also, if the "t" flag is set, rtpevents are not
generated(regenerated?) by the asterisk, but directly passed through when
comming from the SIP-client, which is actually using the same ssrc
identifier for rtpevents and the associated rtp-voice-stream.

We are currently stuck to the patched version 1.6.2.6 - hope the patch
from issue 16292 will find it's way into the official sources onetime
(although it's mentioned in that bug-report, I cannot confirm it had ever
been fully implemented).

If examples, sip-traces or anthing else is needed, I'm happy to give more
input. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-10-27 01:51 langen5        Note Added: 0128409                          
======================================================================