Re: [AVT] RTP padding

"daniele renzi \(bsoft\)" <daniele@bsoft.info> Wed, 14 November 2007 14:45 UTC

Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJUF-000842-Tq; Wed, 14 Nov 2007 09:45:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJUE-00080s-CS for avt@ietf.org; Wed, 14 Nov 2007 09:45:02 -0500
Received: from smtpd3.aruba.it ([62.149.128.208] helo=smtp5.aruba.it) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IsJU7-0000G7-Q2 for avt@ietf.org; Wed, 14 Nov 2007 09:45:02 -0500
Received: (qmail 21919 invoked by uid 89); 14 Nov 2007 14:44:53 -0000
Received: by simscan 1.1.0 ppid: 21830, pid: 21861, t: 0.5402s scanners: clamav: 0.88.4/m:40/d:1722
Received: from unknown (HELO bsoft015) (daniele@bsoft.info@151.71.167.113) by smtp5.aruba.it with SMTP; 14 Nov 2007 14:44:52 -0000
Message-ID: <00b101c826cc$eabfa070$33010a0a@bsoft015>
From: "daniele renzi (bsoft)" <daniele@bsoft.info>
To: Tom Taylor <tom.taylor@rogers.com>
References: <003c01c826a4$e090d7e0$33010a0a@bsoft015> <473B03FC.1070303@rogers.com>
Subject: Re: [AVT] RTP padding
Date: Wed, 14 Nov 2007 15:44:52 +0100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Spam-Rating: smtp5.aruba.it 1.6.2 0/1000/N
X-Spam-Score: 1.1 (+)
X-Scan-Signature: c2e58d9873012c90703822e287241385
Cc: avt@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0490691832=="
Errors-To: avt-bounces@ietf.org

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
+39-0733-57707  (tel/fax)

----- Original Message ----- 
From: "Tom Taylor" <tom.taylor@rogers.com>
To: "daniele renzi (bsoft)" <daniele@bsoft.info>
Cc: <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 +39-0733-57707  (tel/fax)
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________ Audio/Video Transport Working
>> Group avt@ietf.org 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