headers
Mark Baugher | 13 Aug 01:50
Picon
Favicon
Gravatar

Re: Fwd: [Tsvwg] Looking for feedback on DTLS

I don't think avt needs to be concerned with yet another way to 
authenticate/encrypt RTP packets in addition to SRTP and IPsec.  I 
don't know what the advantages are of using TLS over IPsec.  If 
security at the internetwork layer is not the right place, then we have 
SRTP.  The only Datagram TLS application that is mentioned is SIP.  I 
don't know why since DTLS does nothing to address SIP's real security 
problems, which are middle-to-middle as much as end-to-end.  But this 
can be properly deferred to one of the SIP WGs IMHO.

Mark
On Aug 12, 2004, at 3:37 PM, Colin Perkins wrote:

> Is this something that should concern the AVT group? I assume that it 
> may be an alternative to IPsec and/or SRTP?
>
> Colin
>
>
>
>
> Begin forwarded message:
>> From: Eric Rescorla <ekr <at> rtfm.com>
>> Date: 11 August 2004 19:22:06 BST
>> To: tsvwg <at> ietf.org
>> Subject: [Tsvwg] Looking for feedback on DTLS
>>
>> As we all know, TLS is popular but is only compatible with reliable
>> transports. Unfortunately, a number of important protocols (SIP in
>> particular) run over datagram transport and therefore cannot use TLS. 
>> In
(Continue reading)

Permalink | Reply | 503 comments |
headers
Colin Perkins | 13 Aug 12:22

Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP andMedia Types)

On 12 Aug 2004, at 17:30, Jose Rey wrote:
> Dave, Magnus
>
> --cut--
>>>
>>> As I said in my previous email, registering under 'text' top level 
>>> type would mean that the modifiers cannot be used.
>>
>> why is that true?  does text/* only admit of plain text?  so, for
>> example, text/html would not be permitted either??
>>
>
> This is what I understand from the slides from Colin presented during 
> the
> meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip,
> "09-RTP-Media-Types.pdf"). Specially slide three where it says:
>
> ". In particular, it is expected that text media types are "to some
> extent readable even without the software that interprets them"
> - RFC 2046
> - This rule is derived from email client behaviour; want to pass the 
> message
> to a dumb pager if there's no better display option"
>
> Colin or Magnus may please correct me if I got it wrong...

The slides you quote are my interpretation of the traditional rules for 
media under the "text" top level type. As you know, there has been some 
discussion on relaxing these rules for media types with limited domain 
of applicability. The RTP Payload Format for 3GPP timed text might fall
(Continue reading)

Permalink | Reply | 28 comments |
headers
Magnus Westerlund | 13 Aug 14:06
Picon
Favicon

Re: Post WG last call edits on the H.264 payload format: Technical change

Hi,
[as an author, not WG chair]

I think I will need to give some further considerations on this issue.

First of all it is important to consider that several NALUs can have the 
same DON. Thus I was in error stating that max-don-diff can be used to 
determine how many NALUs the buffer may contain. It is not limited by 
that parameter.

Thus one can ask the questions:
1. Is it necessary to know what memory or space requirements are put on 
de-interleaving buffer?

If the answer is no, then we only need a parameter that tells the 
receiver how to move NALUs from the deinterleaving buffer. However it 
seem likely that one does indicate the amount of memory resources that 
will be used at the receiver. At least as a ballpark figure.

2. Is the most appropriate way to express the buffer size in number of 
bytes or NALUs?

This second question and how one answers it gives good insights into how 
to proceed. If it is required to express the max number of NALUs, then 
the interleaving-depth parameter is needed. If it is in bytes then we 
need the sprop-deint-buf-req. Due to the problem of determining the 
number of bytes that the average NALU will have, it is difficult to know 
how much memory is will approximately be required. At the same time this 
works also the other way, that from a memory figure, the number of NALUs 
are hard to determine. One reason I can see that one may need to know
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jose Rey | 13 Aug 14:35
Picon

RE: Media Types in 3GPP Timed text draft (was: RE: RTP andMedia Types)


> -----Original Message-----
> From: Colin Perkins [mailto:csp <at> csperkins.org]
> Sent: Friday, August 13, 2004 12:22 PM
> To: Jose Rey
> Cc: Magnus Westerlund; Dave Singer; IETF AVT WG; ietf-types <at> iana.org
> Subject: Re: Media Types in 3GPP Timed text draft (was: RE: [AVT] RTP
> andMedia Types)
>
>
> On 12 Aug 2004, at 17:30, Jose Rey wrote:
> > Dave, Magnus
> >
> > --cut--
> >>>
> >>> As I said in my previous email, registering under 'text' top level
> >>> type would mean that the modifiers cannot be used.
> >>
> >> why is that true?  does text/* only admit of plain text?  so, for
> >> example, text/html would not be permitted either??
> >>
> >
> > This is what I understand from the slides from Colin presented during
> > the
> > meeting (see in http://www.dcs.gla.ac.uk/~csp/IETF60-AVT-Tue.zip,
> > "09-RTP-Media-Types.pdf"). Specially slide three where it says:
> >
> > ". In particular, it is expected that text media types are "to some
> > extent readable even without the software that interprets them"
> > - RFC 2046
(Continue reading)

Permalink | Reply | 27 comments |
headers
miska.hannuksela | 13 Aug 14:57
Picon

RE: Post WG last call edits on the H.264 payload format: Technical change

Magnus, all,

sprop-max-don-diff cannot be used to control de-interleaving buffering in the use case described in the
Internet Draft (section 5.5):

       Live broadcast is interrupted 
       by pre-encoded content such as commercials from time to time.  
       The first intra picture of a pre-encoded clip is transmitted in 
       advance to ensure that it is readily available in the receiver.  
       At the time of transmitting the first intra picture, the 
       originator does not exactly know how many NAL units are going to 
       be encoded before the first intra picture of the pre-encoded 
       clip follows in decoding order.  Thus, the values of DON for the 
       NAL units of the first intra picture of the pre-encoded clip 
       have to be estimated at the time of transmitting them and gaps 
       in values of DON may occur. 

In this example, the first intra picture of the pre-encoded commercial must be given a large DON value to
make sure that it is not decoded too early. The value of DON for this first intra picture must also be such
that it does not cause pictures to be flushed from the de-interleaving buffer. Thus, the use of
sprop-interleaving-depth is required in this use case.

sprop-max-don-diff makes the de-interleaving process vulnerable to transmission losses in some cases.
For example, if the DONs of the transmitted stream are ..., 100, 101, 102, 200, 103, 104, 105, ..., and
sprop-max-don-diff is e.g. 50, NAL unit with DON 200 is supposed to flush the de-interleaving buffer.
However, if that NAL unit is lost during transmission the de-interleaving buffer keeps filling in and may overflow.

sprop-init-buf-time is useful at least in the following cases:
- The de-interleaving buffer can also be used to smooth out variations in transmission scheduling. Video
decoder input buffers are not guaranteed to handle non-constant input bitrate (or to be more specific:
(Continue reading)

Permalink | Reply | 668 comments |
headers
Magnus Westerlund | 13 Aug 16:37
Picon
Favicon

Re: Post WG last call edits on the H.264 payload format: Technical change

Hi Miska,

It seems that I had lost track of some of our more exotic use cases. See 
further comments below.

miska.hannuksela <at> nokia.com wrote:

> Magnus, all,
> 
>        Live broadcast is interrupted 
>        by pre-encoded content such as commercials from time to time.  
>        The first intra picture of a pre-encoded clip is transmitted in 
>        advance to ensure that it is readily available in the receiver.  
>        At the time of transmitting the first intra picture, the 
>        originator does not exactly know how many NAL units are going to 
>        be encoded before the first intra picture of the pre-encoded 
>        clip follows in decoding order.  Thus, the values of DON for the 
>        NAL units of the first intra picture of the pre-encoded clip 
>        have to be estimated at the time of transmitting them and gaps 
>        in values of DON may occur. 
> 
> In this example, the first intra picture of the pre-encoded commercial must be given a large DON value to
make sure that it is not decoded too early. The value of DON for this first intra picture must also be such
that it does not cause pictures to be flushed from the de-interleaving buffer. Thus, the use of
sprop-interleaving-depth is required in this use case.

I do agree that with the interleaving-depth parameter it is possible to 
have a rather small buffer and then put a few NALUs in there that can be 
considerably delayed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lee Dilkie | 13 Aug 16:40

Re: Fwd: [Tsvwg] Looking for feedback on DTLS


Mark Baugher wrote:

> I don't think avt needs to be concerned with yet another way to 
> authenticate/encrypt RTP packets in addition to SRTP and IPsec.  I 
> don't know what the advantages are of using TLS over IPsec.  If 
> security at the internetwork layer is not the right place, then we 
> have SRTP.  The only Datagram TLS application that is mentioned is 
> SIP.  I don't know why since DTLS does nothing to address SIP's real 
> security problems, which are middle-to-middle as much as end-to-end.  
> But this can be properly deferred to one of the SIP WGs IMHO.
>

Perhaps this isn't the right place for this discussion but I for one was 
pleased to read the paper. And seeing that SRTP requires external 
mechanism's for key exchange, this solution seems to be somewhat 
relevant to the participants of this forum. IPsec has deployment 
difficulities, TLS is dependant on TCP. This proposal seems to me to 
address the problem space (secure UDP-based transport)  nicely.

Not all of us are using SIP for session establishment of RTP streams.

regards,

Lee Dilkie

Mitel

_______________________________________________
Audio/Video Transport Working Group
(Continue reading)

Permalink | Reply | 13 comments |
headers
Mark Baugher | 13 Aug 18:18
Picon
Favicon
Gravatar

Re: Fwd: [Tsvwg] Looking for feedback on DTLS

Hi

On Aug 13, 2004, at 7:40 AM, Lee Dilkie wrote:

>
>
> Mark Baugher wrote:
>
>> I don't think avt needs to be concerned with yet another way to 
>> authenticate/encrypt RTP packets in addition to SRTP and IPsec.  I 
>> don't know what the advantages are of using TLS over IPsec.  If 
>> security at the internetwork layer is not the right place, then we 
>> have SRTP.  The only Datagram TLS application that is mentioned is 
>> SIP.  I don't know why since DTLS does nothing to address SIP's real 
>> security problems, which are middle-to-middle as much as end-to-end.  
>> But this can be properly deferred to one of the SIP WGs IMHO.
>>
>
> Perhaps this isn't the right place for this discussion but I for one 
> was pleased to read the paper. And seeing that SRTP requires external 
> mechanism's for key exchange, this solution seems to be somewhat 
> relevant to the participants of this forum.

If you're saying that DTLS key establishment can be used for SRTP 
sessions, then I'd like to understand how this is done.

> IPsec has deployment difficulities, TLS is dependant on TCP. This 
> proposal seems to me to address the problem space (secure UDP-based 
> transport)  nicely.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Singer | 13 Aug 18:30
Picon
Favicon

RE: Media Types in 3GPP Timed text draft (was: RE: RTP andMedia Types)

>  >
>>  The slides you quote are my interpretation of the traditional rules for
>>  media under the "text" top level type. As you know, there has been some
>>  discussion on relaxing these rules for media types with limited domain
>>  of applicability. The RTP Payload Format for 3GPP timed text might fall
>>  into this new category. Accordingly, we have this MIME review to decide
>>  if the format should be "text" or "video".
>
>Thanks for your answer. So we have that *only* registering for a wider
>domain of applicability would require to follow the *traditional* rules.
>
>Would one criteria for assessing the domain of applicability be to group the
>use cases in those that don't need modifiers and those that do? This is
>intuitive. I.e.:
>
>simple text apps (require no modifiers= no video requirements, thus
>text/3gpp-tt?)
>-----------
>- instant messaging
>- text conversation
>- other..
>
>more complex apps (have video reqs.)
>------------------
>- commercial banners (decorated)
>- news tickers (decorated)
>- karaoke
>- clickable text strings
>- captions (although most captions don't need modifiers, some do e.g.
>scrolling end actors' list)
(Continue reading)

Permalink | Reply | 25 comments |
headers
Internet-Drafts | 13 Aug 21:17
Picon
Favicon

I-D ACTION:draft-ietf-avt-rtp-vmr-wb-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: Real-Time Transport Protocol (RTP) Payload and File Storage Formats for the Variable-Rate
Multimode Wideband (VMR-WB) Audio Codec
	Author(s)	: S. Ahmadi
	Filename	: draft-ietf-avt-rtp-vmr-wb-02.txt
	Pages		: 33
	Date		: 2004-8-13
	
This document specifies a real-time transport protocol (RTP)
   payload format to be used for the Variable-Rate Multimode
   Wideband (VMR-WB) speech codec. The payload format is
   designed to be able to interoperate with existing VMR-WB
   transport formats on non-IP networks. In addition, a file
   format is specified for transport of VMR-WB speech data in
   storage mode applications such as email. A MIME type
   registration is included, for VMR-WB, specifying use of
   both the RTP payload and the storage formats

   VMR-WB is a variable-rate multimode wideband speech codec
   that has a number of operating modes, one of which is 
   interoperable with AMR-WB (i.e., RFC 3267) audio codec at
   certain rates. Therefore, provisions have been made in
   this draft to facilitate and simplify data packet exchange
   between VMR-WB and AMR-WB in the interoperable mode with no
   transcoding function involved.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vmr-wb-02.txt
(Continue reading)

Permalink | Reply | 0 comments |

Gmane