Re: [AVT] RFC2833 (and draft) question regarding packet format

[Henning Schulzrinne <hgs@cs.columbia.edu>]

Wong, David wrote:

> Regarding the retransmission of event packets at the end of an event, I
> thought the wording was a little ambiguous regarding whether or not 
> the RTP
> sequence number should be incremented. Is the correct interpretation 
> the one
> you just stated, to always increment the RTP sequence number, or could it
> also be implemented the other way? I think I can see how this could be

I'm not Bill Clinton, so the meaning of the word "is" seems sufficiently 
clear :-) I will change to MUST for his benefit...


>  a
> bad/confusing thing because these packets would be calculated as duplicate
> packets on the receiving end. However, I know of one implementation 
> (fairly
> recent as well) that retransmits event packets this way--as in setting the
> end bit in all three end of event packets and using the same RTP sequence
> number.
It's clearly broken.


> Regarding the question about the redundant encoding using RFC 2198, I was
> still trying to understand how RFC 2198 fit together with 2833. The way I
> understand it now, the number of events (the history) is implementation
> specific, but the value is recommended to be 5.
Yes.

> -----Original Message-----
> From: Henning Schulzrinne
> To: Wong, David
> Cc: 'avt@ietf.org'
> Sent: 10/21/02 8:52 PM
> Subject: Re: [AVT] RFC2833 (and draft) question regarding packet format
>
>
>
> Wong, David wrote:
>
>
> >I wanted to make sure that my understanding of the packet formats for
> >named events is correct.
> >
> >In section 3.6 of RFC2833 (and the draft), there is the statement "If
> >there has been no new event in the last interval, the event SHOULD be
> >retransmitted three times or until the next event is recognized." Say
>
> an
>
> >event for the digit "9" is detected and is to be transmitted. Does
>
> this
>
> >mean that the packet containing the event for digit 9 should be sent
>
> out
>
> >3 times, without incrementing the RTP timestamp or changing the RTP
> >header, but perhaps only changing the identifier in the IP header? How
> >strictly should this be interpreted (ie. would this be interpreted as
>
> a
>
> >"must" in this case).
>
>
>
> In the same paragraph:  "In both cases, the RTP sequence number is
> incremented by one in each RTP packet."
>
>
> >
> >In section 3.7, there is the statement "During an event, the RTP event
> >payload format provides incremental updates on the event." Sections
>
> 3.8
>
> >and 3.9 contain an example of the digits "911" being dialed. Should
>
> the
>
> >format of the packet described in Figure 2 be taken as a "must" for
>
> the
>
> >format? Ie. as long as the time offset can fit into 14 bits, that
> >information should be included in the packet?
>
>
> Yes, although I don't understand your question. What would you like to
> change?
>
>
>
> >I also have a question for transmitting both in-band and out-of-band
> >information. Take the example of "911" in the RFC/draft with the
>
> pauses
>
> >in between the digits. If audio clips for the digits are to be
> >transmitted in addition to named events, then the audio clips would be
> >the primary encoding and the named events the redundant info?
>
>
> Yes.
>
>
> >Would it
> >be correct to send out a silence audio clip between the digit audio
>
> clips?
>
>
> Not sure what you mean by a "silence audio clip". You could certainly
> send samples representing silence, if that's what you mean. Not
> particularly helpful and wasteful of bandwidth, but possible.
>
>
> >
> >*David Wong*
> >Software Engineer*
> >*Communications Infrastructure Test Group
> >
> >*****p|* 978.661.1241* f|* 978.988.0148
> >*email |* dwong@empirix.com
> >205 Lowell Street | Wilmington, MA***** |* 01887
> >
> >*****E M P I R I X
> >__*___http://www.empirix.com _
> >
> >

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt