Subject: [AVT] rfc2833 and rfc3550 marker bit for audio

From: tk <[email-masked]>
Date: Wed, 19 Oct 2005 12:15:05 +0800

hi all,
 Question about rfc2833
1) I do not see the rationale behind allowing the additional scenario of
sending both
regular coded data and dtmf payload data during a dtmf event. What is the
purpose
of the coded data, esp for a low bitrate codec?
 Question for rfc3550
1) i have gone through perkin's book on RTP. for audio, one use of marker
bit is
to indicate the start of talk spurt. as the packet with marker bit could be
lost,
the receiver should do some implicit talk spurt detection (taking into
account
extra ordinary events such as dtmf). i presume most receivers that do
jitter buffering would work with senders that do not set the marker bit.
my question is what is the need to set this marker bit (in this case), any
other usage?
 thanks in advance
tk
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 20 Oct 2005 13:17:54 +0900

RFC2833 bis (currently under WGLC) does not recommend this, only allow
it.  Here is what is stated at the beginning of section 2.5.1.1:

    Events are usually sent in combination with or alternating with other
    payload types.  Payload negotiation may specify separate event and
    other payload streams, or may specify a combined stream that mixes
    other payload types with events using RFC 2198 [2] redundancy
    headers.  The purpose of using a combined stream may be for debugging
    or to ease the transition between general audio and events.

And that's all.  Data tones as opposed to DTMF are another matter, and
there is rather more discussion of combined streams in rfc2833bisdata.

> of the coded data, esp for a low bitrate codec?
...

---

From: Colin Perkins <[email-masked]>
Date: Thu, 20 Oct 2005 08:54:00 +0100

On 19 Oct 2005, at 05:15, tk wrote:
...
> Question for rfc3550
> 1) i have gone through perkin's book on RTP. for audio, one use of  
> marker bit is to indicate the start of talk spurt.  as the packet  
> with marker bit could be lost, the receiver should do some implicit  
> talk spurt detection (taking into account extra ordinary events  
> such as dtmf).  i presume most receivers that do jitter buffering  
> would work with senders that do not set the marker bit. my question  
> is what is the need to set this marker bit (in this case), any  
> other usage?

The marker bit is just a hint to the receiver, marking times when it  
would be appropriate to adapt the playout point. Since RTP is  
unreliable, the receiver must be able to work without necessarily  
receiving any packets with the M bit set.

Colin