Re: Late Last Call Gen-ART review of draft-ietf-avt-rfc4749-dtx-update-01
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Late Last Call Gen-ART review of draft-ietf-avt-rfc4749-dtx-update-01



Hi, Aurelien,

I think we're good on almost everything in your response.

On the SHOULD/MUST below, it could very well be OK to have this as SHOULD, but we've been asking for some indication of reasons why SHOULDs might not be implemented - which could be as simple as "there is a lot of deployed code that didn't implement this, because it was a SHOULD in RFC 3551".

If you leave this as SHOULD, you might want to say something about the effect on receivers, since conformant sender implementations aren't doing something that the spec assumed they would be doing. In this case, you're saying that the receiver can't look at the M-bit to identify the beginning of a talkspurt, right?

If you get any other feedback about SHOULD/MUST here, please take that into account, of course...

Thanks,

Spencer

----- Original Message ----- From: <aurelien.sollaud at orange-ftgroup.com>
To: <spencer at wonderhamster.org>
Cc: <fluffy at cisco.com>; <ietf at ietf.org>; <gen-art at ietf.org>; <ron.even.tlv at gmail.com>; <tom.taylor at rogers.com>
Sent: Tuesday, September 23, 2008 4:20 AM
Subject: RE: Late Last Call Gen-ART review of draft-ietf-avt-rfc4749-dtx-update-01


Hi

Thank you for the review.
Below some answers.

Aurelien

3.  RTP Header Usage

   If DTX is used, the first packet of a talkspurt, that is, the first
   packet after a silence period during which packets have not been
   transmitted contiguously, SHOULD be distinguished by setting the M

Spencer (review): why not MUST here?


[AS] It is the wording from RFC 3551 (4.1).
It could be a MUST, but I saw no reason to be stronger than the RTP spec.

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.