Attila, The second stream is correct because the timestamp is the same for all packets that represent the same event. (3.4/RFC2833: "The RTP timestamp reflects the measurement point for the current packet. The event duration ... extends forwards from that time.", 3.5: "... the event began at the instant identified by the RTP timestamp and has so far lasted as long as indicated by [the duration] parameter.", and 3.6: "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.".)
Your first stream actually represents four different events, i.e., "8 8 8 8", because different timestamps represent different events: 3.5: "the receiver can start a tone and play it until it receives ... the next tone, distinguished by a different timestamp value ..." Regarding UAs interleaving RFC2833 DTMF packets in with their audio, yeah, I've seen that, too. I guess the vendor is playing it safe by sending "everything" in hopes that the receiver will find something to its liking. As you probably know, RFC2833 explicitly allows this. I've also seen UAs ignore the other UA's SDP and send RFC2833 DTMF regardless of whether it supports it. Go figure. How does that saying go? "Be liberal in what you send..." :-) Paul -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Attila Sipos Sent: Wednesday, September 04, 2002 6:24 AM To: [EMAIL PROTECTED] Subject: RE: [Sip-implementors] testing of RFC2833 Hi all, I have seen a few different implementations of RFC2833. Some implementations update the timestamp for every packet. This gives an RFC2883 stream as follows (only RTP data is supplied. Also, the RFC2833 packets use the same SSRC as the audio packets): e.g. for key press of '8' at 20ms intervals packet real time(ms) seq ts MB PT data 1 0 22186 26960 1 127 08 0A 00 A0 2 20 22187 27120 0 127 08 0A 01 40 3 40 22188 27280 0 127 08 0A 01 E0 4 60 22189 27440 0 127 08 0A 02 80 MB - marker bit PT - payload type (NOTE the increasing timestamp) Other implementations use the same timestamp for a RFC2833 packet relating to the same key press: e.g. for key press of '8' at 20ms intervals packet real time(ms) seq ts MB PT data 1 0 22186 26960 1 127 08 0A 00 A0 2 20 22187 26960 0 127 08 0A 01 40 3 40 22188 26960 0 127 08 0A 01 E0 4 60 22189 26960 0 127 08 0A 02 80 MB - marker bit PT - payload type (NOTE the timestamp stays the same) WHICH OF THE ABOVE IS CORRECT? ARE THEY BOTH CORRECT? Secondly, when UA's transmit DTMF using RFC2833 RTP, many of them ALSO transmit the audio. I can see why this is done because it makes the implementation easier. However this is also bad: 1. You are effectively transmitting the same data twice: once in the audio stream and once in the RFC2833 RTP stream It's such a waste of bandwidth. 2. It's difficult to interop test RFC2833 with UA's because how can you be sure that the sound you hear is generated from the audio stream or the RFC2833 RTP stream? 3. It seems unnecessary. The SDP will tell you if the other SIP endpoint can't do RFC2833, won't it? So if it can't, then you know not to try to send RFC2833 packets. My main concern is point 2. How can one effecitvely interop test RFC2833? Regards, Attila Attila Sipos Software Engineer <mailto:[EMAIL PROTECTED]> <http://www.vegastream.com> _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
