Subject: RE: [AVT] Couple of clarifications on RFC2833

From: "Hashmi, Mohamed Hadi" <[email-masked]>
Date: Mon, 31 Mar 2003 16:30:01 -0700

Colin,

Thanks for you quick answers. 

>So? RTP does not mandate that packets are sent in order of increasing
>timestamp.

This can potentially impact the inter arrival jitter calculation and also latency. The way to overcome this problem will be to ignore DTMF packets

>If there are two separate RTP streams, they each have their own sequence
>number space. Accordingly, you'd use one set of sequence numbers for audio
>.stream and another for DTMF stream.

Is this observation based on RFC1889 or is this explicitly stated in RFC2833? I mean how do I convince a vendor that this is how it is supposed to be done?

Thanks

Hadi 

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Monday, March 31, 2003 4:07 PM
To: Hashmi, Mohamed Hadi
Cc: [email-masked]
Subject: Re: [AVT] Couple of clarifications on RFC2833 

--> "Hashmi, Mohamed Hadi" writes:
>Question-1
>
>the RFC 2833, section 3.6 states the following
>
>"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."
>
>What this "corresponding" mean?  Does it mean that all the RTP packets
>related to that event should use the SAME timestamp as that of its first
>packet or does it mean that timestamp for next packet timestamp of the
>first packet + duration of event?

My understanding is that all the packets comprising a single event have the
same timestamp. The second (and subsequent) packets have the same timestamp
as the first packet, but increased duration fields. 

>I have seen some implementations where all the RTP packets for one specific
>DTMF event use the timestamp as that of first packet. But this creates an
>interesting situation where audio RTP packets will have latest time stamp
>and then we have DTMF RTP packet carrying a previous timestamp. Since
>sequence number are incremented sequentially for both audio as well dtmf
>RTP packets, the dtmf  packets with higher sequence number will have
>smaller timestamp value compared to an audio RTP packet with  smaller
>sequence number.

So? RTP does not mandate that packets are sent in order of increasing
timestamp.

This can potentially impact the inter arrival jitter calculation and also latency

>Question-2
>
>While using inband DTMF detection the sequence numbers are incremented by
>"one" for every packet sent by the media gateway for that call whether they
>are dtmf or audio. That means in an RTP stream for example ,  sequence
>numbers 5,8,9,10,11 could belong to a DTMF event RTP packets while 1,2,3,
>4,6,7,12,13 to audio RTP packets. This is perfectly alright with in-band
>DTMF detection.
>
>How should the  sequence numbers be assigned  for out-of-band DTMF
>detection?  As in this case the re would be two RTP stream going to
>different IP address /port, one for audio and another one for DTMF. If
>sequence numbers are assigned as above then both audio receivers as well as
>DTMF receiver are going to get gaps in sequence numbers ? Or should there
>be one set of sequence numbers for audio stream and another for DTMF
>stream?  

If there are two separate RTP streams, they each have their own sequence
number space. Accordingly, you'd use one set of sequence numbers for audio
stream and another for DTMF stream.

Colin
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Mon, 31 Mar 2003 22:58:24 -0500

--> "Hashmi, Mohamed Hadi" writes:
>This can potentially impact the inter arrival jitter calculation and also
>latency. The way to over come this problem will be to ignore DTMF packets

It can affect the jitter calculation (there is a similar issue when video
frames are split across multiple RTP packets).  The latency should not be
affected, if you design the playout buffer appropriately. 

>Is this observation based on RFC1889 or is this explicitly stated in
>RFC2833? I mean how do I convince a vendor that this is how it is supposed
>to be done?

It's standard RTP behaviour. If you share a sequence number space across
multiple sessions, sent to different locations, you cannot tell if there
was loss.  Hence you should use separate sequence number spaces for each
RTP session.

Colin