----- Original Message ----- > From: "Vladimir Mikhelson" <v...@mikhelson.com> > To: "Asterisk Users Mailing List - Non-Commercial Discussion" > <asterisk-users@lists.digium.com> > Sent: Saturday, September 15, 2012 1:11:14 PM > Subject: Re: [asterisk-users] DTMF digits falsely detected
<snip> > Can you please quote the appropriate RFC here? It looks like the UA > just uses the real time of an event for time stamping. I still would > like to understand the logic and the math here as 121920+2400=124320, > not 122080 or 122240. Asterisk claims to follow RFC 2833 for DTMF events over RTP. That is the RFC that I'll refer to here. Yes, your UA is incrementing the source timestamp for each packet it sends corresponding to the same event, and that is incorrect. RFC 2833 defines the usage of the RTP timestamp and the duration field as follows in Section 3.4: Timestamp: The RTP timestamp reflects the measurement point for the current packet. The event duration described in Section 3.5 extends forwards from that time. The receiver calculates jitter for RTCP receiver reports based on all packets with a given timestamp. Note: The jitter value should primarily be used as a means for comparing the reception quality between two users or two time-periods, not as an absolute measure. duration: Duration of this digit, in timestamp units. Thus, the event began at the instant identified by the RTP timestamp and has so far lasted as long as indicated by this parameter. The event may or may not have ended. For a sampling rate of 8000 Hz, this field is sufficient to express event durations of up to approximately 8 seconds. Section 3.6 specifically states how these two fields are used when an event spans more than a single packet: If an event continues for more than one period, the source generating the events should send a new event packet with the RTP timestamp value corresponding to the beginning of the event and the duration of the event increased correspondingly. (The RTP sequence number is incremented by one for each packet.) If there has been no new event in the last interval, the event SHOULD be retransmitted three times or until the next event is recognized. This ensures that the duration of the event can be recognized correctly even if the last packet for an event is lost. Why is the timestamp handled this way? Consider the following RTP packets denoting a DTMF event: Seq No | Timestamp | Event | Duration | End of Event | 7991 | 13280 | 1 | 0 | 0 | 7992 | 13280 | 1 | 160 | 0 | 7993 | 13280 | 1 | 320 | 0 | Why does the RFC require the timestamp to be the same for all three packets? Well, what would happen if the first two packets were dropped? In that case, we'd still know how to construct the DTMF digit - we know the relative source time denoting the beginning of the DTMF event (13280), and we know the duration (320) - which is 40 ms. So we can start the DTMF digit at our appropriate relative time, and we can continue it for the appropriate length of time. What would happen instead if the timestamp increased in each RTP packet? Seq No | Timestamp | Event | Duration | End of Event | 7991 | 13280 | 1 | 0 | 0 | 7992 | 13440 | 1 | 160 | 0 | 7993 | 13600 | 1 | 320 | 0 | Now if the first two packets are dropped, we would begin generating the DTMF tone at the wrong time - we'd think it was supposed to start at the source relative time of t=13600, when it should have started at t=13280. This could cause a delay in the tone generation by 40 ms. This answers two of your questions: > > > Because RTP packets can arrive out of order, Asterisk is using > > the timestamp to determine if the packets correspond to the same > > DTMF event. > > Is that something mandated by the respective RFC? In other words is > it > "MUST" or "MAY" per RFC? Or is it not there at all? It happens because the RFC specifically says the timestamp should be the same for all event packets corresponding to the same event. Its not really a MAY, MUST, SHOULD, or SHALL. Its just how the RTP timestamp is supposed to be used. I'll explain the out of order scenario I alluded to later. > Why does the retransmission happen at all? Maybe something else is > broken? Its happening because the RFC in Section 3.6 says that when the DTMF end is detected, that is, there are no new events detected in the last interval, the event should be retransmitted three times. In that regard, your UA is behaving correctly (note in my previous e-mail that the duration did not increase) - but the new RTP timestamps denote different times that the event began, which is incorrect. So, why did the handling of this change in Asterisk 1.8.16.0 and 10.8.0? Asterisk used to determine that a new DTMF event was beginning when it received a non-end event that had a different timestamp and a different digit. It would store this event digit value as the current DTMF digit. It would recognize the end of a DTMF digit when it received a packet with End of Event set and a digit value matching the current DTMF digit value. It would ignore repeated end events based on a combination of sequence number checking and whether or not it had detected a DTMF begin or continuation packet. Take for example the following: Seq No | Timestamp | Event | Duration | End of Event | 7991 | 13280 | 1 | 0 | 0 | 7992 | 13280 | 1 | 160 | 0 | 7993 | 13280 | 1 | 320 | 0 | 7994 | 13280 | 1 | 480 | 1 | 7995 | 13280 | 1 | 480 | 1 | 7996 | 13280 | 1 | 480 | 1 | Asterisk would start a new DTMF digit when it received the first event packet at sequence number 7991. It would continue the digit until it received the first packet marking the End of Event (7994). At that point, it would create an DTMF_END frame and end the DTMF digit. It would use the sequence number (7994) to know that subsequent reception of End of Event packets (7995, 7996) were retransmissions. This was tolerant to your scenario, where the timestamps are erroneously inrecreasing, as it used the event value (of '1') and the sequence numbers to know that the repeated End of Event packets were retransmissions. Unfortunately, this fails in scenarios where packets arrive out of order. In ASTERISK-18404, various people reported that they would recieve multiple DTMF digits where the End of Event digits for a subsequent digit with the same value would arrive before any event begin or continuation packets. This would look something like this: Seq No | Timestamp | Event | Duration | End of Event | 7991 | 13280 | 1 | 0 | 0 | 7992 | 13280 | 1 | 160 | 0 | 7993 | 13280 | 1 | 320 | 1 | 7994 | 13280 | 1 | 320 | 1 | 7995 | 13280 | 1 | 320 | 1 | 7998 | 14340 | 1 | 320 | 1 | 7999 | 14340 | 1 | 320 | 1 | 8000 | 14340 | 1 | 320 | 1 | 7996 | 14340 | 1 | 0 | 0 | 7997 | 14340 | 1 | 160 | 0 | Since the End of Event packets arrive before the begin or continuation, and the digit value hadn't changed, Asterisk prior to 1.8.16.0/10.8.0 would treat the packets as retransmissions of the previous DTMF '1' digit. Because no End of Event packets would arrive after the begin/continuation packets, the digit would be dropped completely. The new implementation in 1.8.16.0/10.8.0 handles this scenario by using the RTP timestamp - which should denote the beginning of the DTMF event - to correlate the End of Event packets it has received. Thus, in the above scenario, it will properly reconstruct both DTMF digits. > > I need to test with IVR, but my bet results will be the same as with > Voice Mail. At least that is how it sounds from your explanation of > what behavior was modified and where. Yes, I would expect that any time Asterisk attempts to process a DTMF event sent from this UA, it would create DTMF frames inside Asterisk corresponding to each end of event packet sent from the UA. I would expect it to create three DTMF digits regardless of the application, as the decoding of the RTP stream into DTMF frames happens in the RTP implementation (res_rtp_asterisk) registered to the RTP engine, not at the application level. There may be a way to handle your endpoint's behavior, as well as maintain the handling of out of order packets. We certainly try to not have a new version of Asterisk break any existing devices, even if those devices are behaving oddly. -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users