Hi again Vivek, It occurred to me you're asking: when do you start processing the received telephone-event payload?
I'm pretty sure this is implementation specific. My implementation processes tones on the first received packet (minding timestamp problems) which is the first recommended algorithm in the RFC. Refer to RFC 4733 section 2.5.2 (http://tools.ietf.org/html/rfc4733#section-2.5.2) for recommended algorithms of processing received tones: ... In the first algorithm, the receiver simply places a tone of the given duration in the audio playout buffer at the location indicated by the timestamp. As additional packets are received that extend the same tone, the waveform in the playout buffer is extended accordingly. (Care has to be taken if audio is mixed, i.e., summed, in the playout buffer rather than simply copied.) Thus, if a packet in a tone lasting longer than the packet interarrival time gets lost and the playout delay is short, a gap in the tone may occur. Alternatively, the receiver can start a tone and play it until one of the following occurs: o it receives a packet with the E bit set; o it receives the next tone, distinguished by a different timestamp value (noting that new segments of long-duration events also appear with a new timestamp value); o it receives an alternative non-event media stream (assuming none was being received while the event stream was active); or o a given time period elapses. This is more robust against packet loss, but may extend the tone beyond its original duration if all retransmissions of the last packet in an event are lost. Limiting the time period of extending the tone is necessary to avoid that a tone "gets stuck". This algorithm is not a license for senders to set the duration field to zero; it MUST be set to the current duration as described, since this is needed to create accurate events if the first event packet is lost, among other reasons. ... Brandon -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Vivek Batra Sent: Monday, June 13, 2011 4:42 AM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] When to detect DTMF in Outband (RFC2833)? Hi Folks, I would like to know is there any standard practice when to declare DTMF event in Outband (RFC 2833) viz 1. Whether immediately on receipt of Start Packet without waiting further for End Packet OR 2. On receipt of Start Packet followed by End Packet OR 3. On receipt of End Packet without bothering about whether Start Packet was received or not. I would highly appreciate if you can share your views how it is implemented in SIP gateways available in the fields. P.S: Although the question is not related to SIP but problem is encountered in SIP call, that's why I have placed my query in SIP forum. Best Regards, Vivek Batra _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
