Subject: [AVT] Draft minutes from Montreal meeting

From: Colin Perkins <[email-masked]>
Date: Fri, 4 Aug 2006 16:07:14 +0100

Folks,

Attached are draft minutes from the AVT meeting in Montreal. Please  
send any comments or corrections to the chairs.

Colin

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

---

From: Dave Singer <[email-masked]>
Date: Fri, 4 Aug 2006 14:05:55 -0700

I just read the minutes, and it seems that the initial motivation was 
not discussed.

We wanted to carry SMPTE time-codes with RTP streams, sometimes:
* without having a new profile in which they were always or sometimes present
* in a codec-independent (payload independent) way
* without using a separate RTP stream for what is a low-bit-rate set 
of information
* without requiring that the end-points knew about or cared about 
SMPTE time-codes

The RTP header extension seems ideal for this purpose, but I was 
hesitant to define a SMPTE time-code header extension, since that 
would 'squat' on the single header extension and make it unavailable 
for other uses (e.g. ZRTP).  In addition, the current definition also 
relies on profiles to define the identifier space, and they currently 
say nothing at all, i.e. there is no registration etc.

Hence the genesis.

I have a hard time seeing how profile negotiation helps me here.  Say 
I want SMPTE time-codes on some streams, and then I realize I'd like 
transmission time offsets on some streams.  Do I now have four 
profiles (plain, time-code, transmission offset, both)?  This seems 
rapidly unworkable.

I don't get the comment "header extensions will need to be signalled, 
since some will be defined that can't be freely ignored", since this 
seems in conflict with 5.3.1 of the RTP spec that says
"This mechanism is designed so that the header extension may be 
ignored by other interoperating implementations that have not been 
extended." (Though where this leaves ZRTP I am not sure).

I do think we also need to ask "what happens if general RTP is 
extended with a feature" and be able to do the experiment in a 
backwards-compatible way (e.g. knowing transmission offsets).  This 
was designed as a place for such a sandbox.

So, for the carriage of small, ignorable, codec-independent but 
time-varying data, such as the two proposed here, this seems about 
the right way to go.  I'm not sure I get the anxieties about the use 
of these bits in this way.

Before I (or someone else) takes this to <[email-masked]>, what 
are the issues outside AVT that should be discussed there?
-- 
David Singer
Apple Computer/QuickTime

---

From: Randell Jesup <[email-masked]>
Date: Mon, 07 Aug 2006 15:52:43 -0400

Dave Singer <[email-masked]> writes:
>I just read the minutes, and it seems that the initial motivation was not
>discussed.
>
>* without using a separate RTP stream for what is a low-bit-rate set of
>information
>* without requiring that the end-points knew about or cared about SMPTE
>time-codes

This does sound like a good use for header extensions.

>I have a hard time seeing how profile negotiation helps me here.  Say I
>want SMPTE time-codes on some streams, and then I realize I'd like
>transmission time offsets on some streams.  Do I now have four profiles
>(plain, time-code, transmission offset, both)?  This seems rapidly
>unworkable.

There's a general issue with profile explosion - the inability to negotiate
details in profiles yields AVP/SAVP/AVPF/SAVPF already, and add in even a
few more options and the number of separate m= offers becomes WAY too big.

SDP profiles are a (mostly) broken concept for these sorts of details.
In theory, you could have N m= lines with different profiles, but the lack
of reasonable or supported standards for alternatives/grouping in SDP 
make this effectively unusable - even ignoring the almost total lack of
implementations that could handle anything like this, or that these would
require TCP/TLS as a transport, etc.

Magnus' 10K SDP would be considered small if we let this combinatorial
explosion occur.  :-)

>I don't get the comment "header extensions will need to be signalled, since
>some will be defined that can't be freely ignored", since this seems in
>conflict with 5.3.1 of the RTP spec that says
>"This mechanism is designed so that the header extension may be ignored by
>other interoperating implementations that have not been extended." (Though
>where this leaves ZRTP I am not sure).

ZRTP is fine - if it tries to talk to something that isn't ZRTP, the other
won't respond (and hopefully will ignore the extension).  This hdrext 
standard should be innocuous if it and a (current) ZRTP implementation
try to talk.

IMHO

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 8 Aug 2006 21:37:35 +0100

On 7 Aug 2006, at 20:52, Randell Jesup wrote:
>> SMPTE

Agreed.

>> profiles

Sure, SDP was not designed for these uses, and it hurts to use it  
that way.

>> ignored by

My problem with ZRTP is the RTP header extensions should be used for  
convey metadata about the media, not as a general signalling channel.

Colin

---

From: Randell Jesup <[email-masked]>
Date: Tue, 08 Aug 2006 18:59:26 -0400

Colin Perkins <[email-masked]> writes:
>>> seems in conflict with 5.3.1 of the RTP spec that says "This mechanism
>>> is designed so that the header extension may be ignored by other
>>> interoperating implementations that have not been extended."  (Though
>> ZRTP is fine - if it tries to talk to something that isn't ZRTP, the
>> other won't respond (and hopefully will ignore the extension).  This
>> hdrext standard should be innocuous if it and a (current) ZRTP
>> implementation try to talk.
>>
>> IMHO
>

I agree (to a point).  I have a different problem with ZRTP's use of header
extensions (and their use in general).  With some codecs, we "know" that
adding N bytes of header extensions won't cause a problem.  However, that
isn't the case in general.

For example, ZRTP w/ header extensions applied to a video stream.  If the
(possibly unaware) application were to use almost all the bytes available
in the path-MTU for a packet, adding the header extension (even if only a
few bytes) might cause fragmentation on that lowest-MTU hop.

I think direct media-channel keying makes more "sense" in RTCP than in RTP
header extensions.  The downside is that some SBCs/etc might block it (but
they could cause the same problems with header extensions, though perhaps
less likely).  The other problem for ZRTP-like implementations that vampire
on top of a random client's packets to encrypt them is that the application
might not send RTCP.  The obvious solution is to use a (minimally)
compliant application.

The only other major issue is RTCP frequency (especially in the face of
packet loss).  Personally, for an end-to-end (unicast) encryption
algorithm, the RTCP conferencing issues are less important.  Or the normal
RTCP rules could be modified (much as AVPF modifies them).