[Home]

Summary:ASTERISK-03820: [patch] dtmf rfc2833 and senddigit
Reporter:cherso (cherso)Labels:
Date Opened:2005-03-31 07:39:20.000-0600Date Closed:2011-06-07 14:05:11
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) senddigit.diff
( 1) senddigit.diff.txt
Description:Marker bit set only on the first event packet and Duration field increment when timestamp = 0 as explained in the rfc2833

Comments:By: Olle Johansson (oej) 2005-03-31 08:06:32.000-0600

Please read bug guidelines and coding guidelines!

* Is this patch disclaimed?

* No // style comments.
By: cherso (cherso) 2005-03-31 08:16:08.000-0600

yep sorry about the comment, I can't send the disclaimer right now so add it if you think that is good
By: Olle Johansson (oej) 2005-03-31 08:47:20.000-0600

We can't add without the disclaimer, so this patch is open for peer review, but not a candidate for CVS until we get a confirmation of a disclaimer.
By: Kevin P. Fleming (kpfleming) 2005-03-31 10:38:51.000-0600

I don't understand this line:

+                if (x < 7) duration+=320; /* 800 = 100ms */

How does this relate to the original code that just set the duration one time? As I look at this, it appears that the sixth packet to be sent will have a duration of 1920.
By: cherso (cherso) 2005-03-31 11:59:28.000-0600

rfc2833 examples set the duration time > 0
when the timestamp is 0 or fixed you have to increment the duration field
1920 / 800 = ~250ms (standard DTMF)

the last 3 packets should use the same duration field and the "end bit" = 1
The marker bit is 1 just on the first packet

The originale ast_rtp_senddigit set the marker bit = 1 for the first 3 packets and duration=0
for the last 3 packets duration=800, market bit = 0, end bit=1
timestamp is always = 0

edited on: 03-31-05 12:05
By: cherso (cherso) 2005-03-31 12:10:39.000-0600

I was capping rtp packets to checkout why cisco 7960 is not playing digits using app senddtmf.
Cisco is using this scheme, sjphone and others are using the same scheme.
Noone is using original ast_rtp_senddigit scheme (3+3) sending DTMF out of band (except asterisk :-) )
Am I wrong?

edited on: 03-31-05 12:11
By: Kevin P. Fleming (kpfleming) 2005-03-31 20:39:55.000-0600

Please review the notes in ASTERISK-3643675 as well to see if any of the work/comments there apply as well; there is likely some overlap between that bug and this one.
By: cherso (cherso) 2005-04-01 01:29:19.000-0600

ok I read that bug report but I think the right example is something like this:
The RTP header timestamp is the same for all of the packets during
the event (0) and the duration increments by 400 timestamp units per
packet.

RTP seq#        RTP timestamp        duration
---------------        ---------------------        ------------
     0                        0                     400
     1                        0                     800
     2                        0                     1200
     3                        0                     1600

According to rfc2833 the marker bit is "true" just on the first packet
and the "end bit" must be true on the last 3 packets. The last 3 packets should have the same timestamp and duration field (just a retrasmission)
My patch is doing that. I did not play attention to lastts, 0 is a good value and last voice rtp timestamp is good too.

edited on: 04-01-05 01:30
By: Kevin P. Fleming (kpfleming) 2005-04-01 11:45:20.000-0600

OK, since there are more people already involved in the other bug, can you post your patch and analysis over there and we'll keep the discussion going in a single bug? Thanks.
By: Kevin P. Fleming (kpfleming) 2005-04-01 13:16:41.000-0600

Not exactly a duplicate, but close enough that the same fix will apply to both issues.
By: Bayan Towfiq (implicit) 2005-05-12 02:54:04

Reopened per request of reporter so that patches can be uploaded
By: Bayan Towfiq (implicit) 2005-05-12 02:54:57

Mistake, was trying to reopen 3675