RE: [AVT] RTP padding

Hi

I think you should have a look to the RTP header extension mechanism, which could carry the data you want to put in the padding.

See RFC3550 5.3.1 and draft-ietf-avt-rtp-hdrext-13

Aurélien

________________________________

	De : daniele renzi (bsoft) [mailto:daniele@bsoft.info] 
	Envoyé : mercredi 14 novembre 2007 15:45
	À : Tom Taylor
	Cc : avt@ietf.org
	Objet : Re: [AVT] RTP padding

	Hi Tom,

	thanks for the quick answer (and sorry for the wrong document reference, RFC3550 is the right one).

	By the way, I'd like to better define my question...
	I do agree on the "intention", but at the moment I can't see any reason for strictly use zero-octets (is there any?), as in my opinion if the last padding byte "contains a count of how many padding octets should be ignored", in any case the receiver will ignore the other padding bytes, irrespective of the actual value of these bytes (zero or non-zero).
	Is that correct? If so, I think that in any case any RTP receiver will handle such a padding correctly, irrespective of the bytes values (except the last one, of course).

	However, if the zero-value is a MUST, I agree that there could be some receiver making an additional check on the bytes values (even though useless).
	That's what I was trying to understand and perhaps you already provided me the final answer...
	Btw, please provide further comments/answers if you consider it significant.

	Thanks!

	Best regards,

	Daniele

	Daniele Renzi
	bSoft -- www.bsoft.info <http://www.bsoft.info> 
	+39-0733-57707  (tel/fax)

	----- Original Message ----- 
	From: "Tom Taylor" <tom.taylor@rogers.com <mailto:tom.taylor@rogers.com> >
	To: "daniele renzi (bsoft)" <daniele@bsoft.info <mailto:daniele@bsoft.info> >
	Cc: <avt@ietf.org <mailto:avt@ietf.org> >
	Sent: Wednesday, November 14, 2007 3:19 PM
	Subject: Re: [AVT] RTP padding

	>I believe the intention is that padding bytes (except for the last one -- see 
	> definition of P bit in the next section) MUST have value zero, as the 
	> specification says. And by the way, RFC 1889 has been updated. You should refer 
	> to RFC 3550 now.
	> 
	> daniele renzi (bsoft) wrote:
	>> Dear Experts,
	>> 
	>> I have a question concerning RFC1889 "RTP: A Transport Protocol for Real-Time
	>> Applications".
	>> 
	>> In section 4 - "Byte Order, Alignment, and Time Format" - I found the
	>> following sentence: "Octets designated as padding have the value zero.". a)
	>> Does this mean that we are forced to use only zero-bytes for padding? Or... 
	>> b) can the above sentence be intepreted as an example on the specific use of
	>> padding for byte alignment? If the latter one is correct and assuming that
	>> the padding bit is set to 1 and that the last padding octect correctly
	>> indicate how many padding octects are present, are we allowed to use non-zero
	>> bytes as padding (e.g. to carry additional - proprietary - information in the
	>> RTP packet, which would be simply discarded by any standard receiver)? Does
	>> this scenario anyhow violate the standard?
	>> 
	>> Thanks.
	>> 
	>> Best regards,
	>> 
	>> Daniele
	>> 
	>> 
	>> Daniele Renzi bSoft -- www.bsoft.info <http://www.bsoft.info>  +39-0733-57707  (tel/fax)
	>> 
	>> 
	>> ------------------------------------------------------------------------
	>> 
	>> _______________________________________________ Audio/Video Transport Working
	>> Group avt@ietf.org <mailto:avt@ietf.org>  https://www1.ietf.org/mailman/listinfo/avt <https://www1.ietf.org/mailman/listinfo/avt> 
	> 
	> 
	> 
	> -- 
	> No virus found in this incoming message.
	> Checked by AVG Free Edition. 
	> Version: 7.5.503 / Virus Database: 269.15.31/1129 - Release Date: 13/11/07 21.22
	> 
	> 

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