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

From: "Wong, David" <[email-masked]>
Date: Mon, 21 Oct 2002 21:55:22 -0400

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 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.

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. 

-----Original Message-----
From: Henning Schulzrinne
To: Wong, David
Cc: [email-masked]'
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 |* [email-masked]
> 205 Lowell Street | Wilmington, MA***** |* 01887
>
> *****E M P I R I X
> __*___http://www.empirix.com _
>
>

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 21 Oct 2002 22:10:08 -0400

Wong, David wrote:

> 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...

> end bit in all three end of event packets and using the same RTP sequence

It's clearly broken.

Yes.