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
