Subject: Re: [AVT] rfc2833. rtp for dtmf. sending dtmf packets (issue with implicit talk-spurt)

From: tk <[email-masked]>
Date: Thu, 20 Oct 2005 11:22:15 +0800

dear Tom and all,
 thanks for illuminating me esp for case (2).
the reason i asked this is because i see a potential
problem when jitter buffering is being implemented
if case (2) is admitted. i got Perkin's book on RTP
and it mentioned how to determine beginning of talkspurt
explicitly or implicitly. however, for case (2),
i do not see how implicit talk-spurt detection in receivers
can be achieved since now the rtp sequence number
and rtp timestamp do not change correspondingly if i
understand the concept correctly. so, i presume in this case,
jitter buffering can only rely on checking the marker bit.
 appreciate any comments.
 thanks in advance.
tk

 On 7/27/05, Tom-PT Taylor <[email-masked]> wrote:
>
> I think the assumption behind the RFC2833 requirement is that the events
> are being transmitted in the same stream as the audio. There are two
> possibilities:
>
> 1) The sender stops transmitting audio and starts transmitting events.
> In this case, if the sequence number of the last audio packet was N,
> that of the first event packet is N+1. The timestamp behaves similarly,
> even if the increment from the last audio packet to the first event
> packet is larger than the increment between successive audio packets.
>
> 2) The more complicated case is that the sender continues to transmit
> audio even as it sends events. The logic still works. Here's an
> example, where T is in ms units and timestamp increments at the rate of
> 8000 per second. Assume that we're talking about a single tone
> continuing through the period being depicted.
>
> Time Packet content Seq No. Timestamp
>
> T Audio N X
>
> T Event N+1 X
>
> T+20 Audio N+2 X+160
>
> T+40 Audio N+3 X+320
>
> T+50 Event update N+4 X
>
> T+60 Audio N+5 X+480
>
> etc.
>
>
>
>
>
> tk wrote:
> > hi,
> >
> > I have a question on sending dtmf packets. under Section 3.6
> > of Rfc2833, it says that "...start transmitting event packets as soon
> > as it recognizes an event and every 50ms thereafter or the packet
> interval
> > for the audio codec used for this session, if known. ..."
> >
> > Assuming that the packet interval has been negotiated
> > to be 20ms. Under section 3.1 "DTMF digits...MUST use the same sequence
> > number and time-stamp base as the regular audio channel..."
> > Given the above sentence, I don't see how one is able to fulfill the
> above
> > requirement (sending audio and event packets when the 2 packet sizes
> > are different.
> >
> > pls advise.
> >
> > thanks.
> > tk
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/avt
> >
> >
>
>
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt