|Summary:||ASTERISK-03820: [patch] dtmf rfc2833 and senddigit|
|Date Opened:||2005-03-31 07:39:20.000-0600||Date Closed:||2011-06-07 14:05:11|
|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
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