[Home]

Summary:ASTERISK-16851: RFC2833 DTMF generation broken due to SSRC change on bridges channels
Reporter:Marc Boucher (marcbou)Labels:
Date Opened:2010-10-22 12:13:19Date Closed:2010-12-07 17:00:46.000-0600
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Core/RTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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


Comments:By: Dmitry Andrianov (dimas) 2010-10-22 18:23:46

marcbou, from what version you upgraded? (which worked fine?)

I'm curious because we have exactly the same issue - providers which worked well with 1.4.26 do not see our DTMF anymore after upgrading to 1.6.2.13. We see that DTMF RTP packets are sent out but they are ignored by the other side.
I'm also suspecting SSRC issue here and we will probably try your fix.
By: Marc Boucher (marcbou) 2010-10-24 14:02:48

dimas, the upgrade was from asterisk-1.6.2.8
By: Mikhail Slyusarev (mik3weider) 2010-10-25 10:27:13

marcbou, your fix is works for 1.6.2.13
But I have not tested it on a running system. And you?
By: Sébastien Couture (sysreq) 2010-10-25 15:10:34

We have the same problem here with 1.6.2.13. Packet traces reveal that new SSRC's are used for DTMF events.

This issue is most likely related that issue: https://issues.asterisk.org/view.php?id=16292
By: Brian Jones (joshaidan) 2010-10-25 22:56:03

I've experienced the same problem with 1.6.2.13, using a Linksys SPA-942. Confirmed in Wireshark that the SSRC does change after a DTMF packet is sent.

An interesting note, this does not happen on a Snom 370.  The SSRC does not change, and the DTMF tone is recognized.

Commenting out the two lines above seems to fix the problem.
By: Mikhail Slyusarev (mik3weider) 2010-10-26 11:35:06

Seems it works fine for 1.6.2.8 - 1.6.2.11 versions with "constantssrc=yes" in sip.conf
By: Johannes v. Langen (langen5) 2010-10-27 01:51:12

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 incompliant 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.


By: Dmitry Andrianov (dimas) 2010-10-27 02:26:11

langen5, which patch from 16292 are you referring to?
By: Johannes v. Langen (langen5) 2010-10-27 02:50:29

sorry; it's the patch uploaded 2009-12-03 20:56: asterisk-1.6.1.11-constantssrc.patch
By: Sébastien Couture (sysreq) 2010-10-27 23:55:55

You may want to take a look at this too:

https://reviewboard.asterisk.org/r/374/
https://reviewboard.asterisk.org/r/540/
By: Dmitry Andrianov (dimas) 2010-10-28 02:11:02

the second one just reverts the first one.
By: Johannes v. Langen (langen5) 2010-10-28 02:36:05

Yes - this explains, why "constantssrc" has been removed, but I still cannot figure out, why asterisk receives rtpevents with the same ssrc-identifier as the rest of the rtp media-stream from the sip-client and sends out rtpevents and rtp media-stream with different ssrc-identifiers to the provider. Asterisk stayes in the media-stream and there are no re-invites send out.
According to the second link, the ssrc should not change, but it does...
By: Terry Wilson (twilson) 2010-11-01 10:33:40

The ssrc change was put in to fix issue 17404 and causes this regression. I'll look at finding a way to fix 17404 that doesn't re-break this issue (as it has been fixed a couple of times now) and put in some comments to make sure it doesn't happen again.
By: Dmitry Andrianov (dimas) 2010-11-01 13:17:51

2010-11-01 13:13 lmadsen Target Version => 1.8.1

Come on, guys! What 1.8.1 ?
The bug is really serious - I cannot speak for others but we just can NOT use Asterisk with it - DTMF just does not work and users pissed off. Doesn't it make sense to fix 1.6.2 branch? AFAIK it is not EOL yet...
By: Terry Wilson (twilson) 2010-11-01 14:16:09

Yes, it will be fixed everywhere. Be calm. :-) You can also work around it currently by checking out 1.6.2 and running 'svn merge -c -281912 .' until a proper fix can be made.
By: Dmitry Andrianov (dimas) 2010-11-01 14:59:53

Thanks! We can wait unless you want us to test this patch in which case we can go back yo 1.6.2.13, apply the fix and report back.
By: warlock52 (warlock52) 2010-11-30 19:44:09.000-0600

This still seems to be an open issue because even up to 1.6.2.15RC1 this is still the same issue. When can we expect a fix in the DTMF SSRC handling which is obviously wrong according to RFC and is affecting us with our SIP provider.
By: Chris Baker (cmbaker82) 2010-12-01 11:33:47.000-0600

This seems to be related to
https://issues.asterisk.org/view.php?id=18352
and still happens in 1.8.0
By: warlock52 (warlock52) 2010-12-01 13:11:34.000-0600

we are using 1.6.2.13 and have commented out the 2 lines in main/channel.c as described and it is working for now. I am interested to know when a fix in 1.6.2 is available?
By: Chris Baker (cmbaker82) 2010-12-01 13:28:09.000-0600

On our 1.8.0 installation instead of commenting out the lines we changed them back to what they had been previously which also fixed our DTMF problems

- ast_indicate(c0, AST_CONTROL_SRCCHANGE);
- ast_indicate(c1, AST_CONTROL_SRCCHANGE);
+ ast_indicate(c0, AST_CONTROL_SRCUPDATE);
+ ast_indicate(c1, AST_CONTROL_SRCUPDATE);
By: Terry Wilson (twilson) 2010-12-01 14:21:32.000-0600

The reason it hasn't been fixed yet is because their is another problem that was fixed by making the change in the first place. So, we have to figure out how to fix both without breaking anything. The issue is assigned, we just haven't gotten it fixed yet.
By: warlock52 (warlock52) 2010-12-01 14:42:54.000-0600

What do you suggest in the meantime...just comment the 2 lines out or as cmbaker82 suggests changing back to SRCUPDATE instead of SRCCHANGE???
By: Terry Wilson (twilson) 2010-12-01 14:45:15.000-0600

I would change them back to SRCUPDATE since that is exactly how it was before the breakage.
By: Chris Baker (cmbaker82) 2010-12-01 14:49:00.000-0600

Just for reference I believe this is the problem twilson was refering to: https://issues.asterisk.org/view.php?id=17404

Our client determined that they would rather have the delay then the DTMF issues so we switched it back.
By: Jeff Peeler (jpeeler) 2010-12-04 16:09:50.000-0600

Yes, I think that's the approach I'm going to take. cmbaker - I do not think I was ever able to actually reproduce the delay. Can you describe how you or your client is doing so?
By: Chris Baker (cmbaker82) 2010-12-04 19:25:31.000-0600

We are able to reproduce the delay only sporadically.  We are using sip unboxed accounts from bandwidth.com and sip accounts from vitelity.com.  The problem happens more frequently with the bandwidth.com acccounts.  

On bad days the delay occurs on about 10% of calls; however, on most days it is usually far less.  One time we made 60 consecutive calls without experiencing the delay.

Our method of testing is for one person to call in from their cell phone, the person receiving the call picks up the call and immediately begins counting (1,2,3,4).  When the delay occurs the calling person will hear silence until 3.

It still happens occasionally so if there are any settings you want to know or logs you need that will help just let me know.
By: Jeff Peeler (jpeeler) 2010-12-06 14:44:21.000-0600

cmbaker - Were your delay issues not present with the changes from 17404? I don't know what to ask for yet. I'm afraid it is handset dependent behavior.
By: Chris Baker (cmbaker82) 2010-12-06 14:47:28.000-0600

We were only able to leave it that way for less than one day, but no one complained of the delay during that time frame, and we were unable to reproduce it during that time either.  However given how random that delay is I cannot guarantee that it fixed the delay.   We're using all polycom IP330 and IP450's.
By: Bryant Zimmerman (zktech) 2010-12-07 14:01:54.000-0600

For us this issue is driven by several factors. The primary is the gateway of the backend carrier. If the call is hitting a Sonus gateway the delay between the last rtp audio packet and the dtmf event exceeds 100ms the Sonus throws out the DTMF event. This sucks. The G729 transcoder pushs the delay up as well. I have found that if I disable all of the features.conf on the systems the delay drops and Sonus is happay but this cripples some features Also if you use the Dial options tT and you hit a Sonus switch the issue will occure. It appears that anything that is setting in the middle of the DTMF and incereased the delay between the last rtp audio packet and the dtmf event will cause this. I need a good fix that will address this with either features on or off. I am trying cmbaker82 idea to see if it helps. This issue looks to be at the root of the overal problem https://issues.asterisk.org/view.php?id=15642
By: Jeff Peeler (jpeeler) 2010-12-07 16:41:11.000-0600

zktech - thanks for pointing out the Sonus issue. I'm going to revert my incorrect changes and hopefully 15642 will be resolved shortly.
By: Digium Subversion (svnbot) 2010-12-07 16:57:50.000-0600

Repository: asterisk
Revision: 297823

U   branches/1.4/main/channel.c

------------------------------------------------------------------------
r297823 | jpeeler | 2010-12-07 16:57:48 -0600 (Tue, 07 Dec 2010) | 12 lines

Revert code that changed SSRC for DTMF.

Some previous behavior was attempted to be restored, but mistakingly I did
not realize that the previous behavior was incorrect. This fixes DTMF not
being detected since DTMF shouldn't cause the SSRC to change.

(related to issue ASTERISK-16154)
(closes issue ASTERISK-16851)
(closes issue ASTERISK-17001)
Reported by: marcbou
Tested by: cmbaker82

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

http://svn.digium.com/view/asterisk?view=rev&revision=297823
By: Digium Subversion (svnbot) 2010-12-07 16:58:56.000-0600

Repository: asterisk
Revision: 297824

_U  branches/1.6.2/
U   branches/1.6.2/main/channel.c

------------------------------------------------------------------------
r297824 | jpeeler | 2010-12-07 16:58:55 -0600 (Tue, 07 Dec 2010) | 19 lines

Merged revisions 297823 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r297823 | jpeeler | 2010-12-07 16:57:48 -0600 (Tue, 07 Dec 2010) | 12 lines
 
 Revert code that changed SSRC for DTMF.
 
 Some previous behavior was attempted to be restored, but mistakingly I did
 not realize that the previous behavior was incorrect. This fixes DTMF not
 being detected since DTMF shouldn't cause the SSRC to change.
 
 (related to issue ASTERISK-16154)
 (closes issue ASTERISK-16851)
 (closes issue ASTERISK-17001)
 Reported by: marcbou
 Tested by: cmbaker82
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=297824
By: Digium Subversion (svnbot) 2010-12-07 16:59:32.000-0600

Repository: asterisk
Revision: 297825

_U  branches/1.8/
U   branches/1.8/main/channel.c

------------------------------------------------------------------------
r297825 | jpeeler | 2010-12-07 16:59:30 -0600 (Tue, 07 Dec 2010) | 26 lines

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

................
 r297824 | jpeeler | 2010-12-07 16:58:54 -0600 (Tue, 07 Dec 2010) | 19 lines
 
 Merged revisions 297823 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r297823 | jpeeler | 2010-12-07 16:57:48 -0600 (Tue, 07 Dec 2010) | 12 lines
   
   Revert code that changed SSRC for DTMF.
   
   Some previous behavior was attempted to be restored, but mistakingly I did
   not realize that the previous behavior was incorrect. This fixes DTMF not
   being detected since DTMF shouldn't cause the SSRC to change.
   
   (related to issue ASTERISK-16154)
   (closes issue ASTERISK-16851)
   (closes issue ASTERISK-17001)
   Reported by: marcbou
   Tested by: cmbaker82
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=297825
By: Digium Subversion (svnbot) 2010-12-07 17:00:44.000-0600

Repository: asterisk
Revision: 297826

_U  trunk/
U   trunk/main/channel.c

------------------------------------------------------------------------
r297826 | jpeeler | 2010-12-07 17:00:42 -0600 (Tue, 07 Dec 2010) | 33 lines

Merged revisions 297825 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r297825 | jpeeler | 2010-12-07 16:59:30 -0600 (Tue, 07 Dec 2010) | 26 lines
 
 Merged revisions 297824 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r297824 | jpeeler | 2010-12-07 16:58:54 -0600 (Tue, 07 Dec 2010) | 19 lines
   
   Merged revisions 297823 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r297823 | jpeeler | 2010-12-07 16:57:48 -0600 (Tue, 07 Dec 2010) | 12 lines
     
     Revert code that changed SSRC for DTMF.
     
     Some previous behavior was attempted to be restored, but mistakingly I did
     not realize that the previous behavior was incorrect. This fixes DTMF not
     being detected since DTMF shouldn't cause the SSRC to change.
     
     (related to issue ASTERISK-16154)
     (closes issue ASTERISK-16851)
     (closes issue ASTERISK-17001)
     Reported by: marcbou
     Tested by: cmbaker82
   ........
 ................
................

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

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