Re: [AVT] Open issue on hdrext draft

[Magnus Westerlund <[e-mail]>]

[e-mail] skrev:
> Hi,
> 
> An RTP gateway (translator/mixer) that for some reason does not
> receive/parse the SDP and is then not aware of the mapping between the
> RTP header extension and the ID will not be able to process the RTP
> packet appropriately. This speaks for IETF agreed registration (option
> c).

I think this is an irrelevant comment as any mixer or translator that
needs to understand the packet content anyway will require to be part of
the signalling context. Thus, I don't think there is a any benefit at
all with static mappings.

> On the other hand, since the space for 1-byte header IDs is very limited
> (14 values only), registration might exhaust the space rather quickly.
> One possible solution is to introduce registration for 2-byte headers
> and leave 1-byte headers for application-specific usage. However, this
> has the limitation that you cannot mix registered and
> application-specific extensions into a single RTP packet. It also
> imposes length limitations on application-specific extensions.

Exactly. There is also an implementation issue with increased complexity
to allow multiple mechanisms.

> 
> BTW, am I right in the assumption that this I-D still discourages the
> usage of RTP header extensions, as is the case in RFC3550? One might ask
> why do we need to register some headers that are just for experimental
> purposes?

Well, read the draft, or even David's mail properly. For experimentation
or proprietary extensions you only need a unique URI, any unique URI
representing your extension will do.

What we are discussing is what rules applies for the IETF URN space,
i.e. the header extensions that will look like they are blessed by IETF.
The current draft version was in fact a) as this specified
"Specification Required" from RFC 2434:

"      Specification Required - Values and their meaning must be
           documented in an RFC or other permanent and readily available
           reference, in sufficient detail so that interoperability
           between independent implementations is possible."

I think A is fine but would probably prefer this to be b) with explicit
rule requiring a publicly available specification. Having an expert look
at any registrations to ensure that they are not totally wacko is in my
book a good thing. But at the same time put minimal bar on the
registrations. Other SDOs should basically be able to send in an email
with a request containing a reference and things usually go through.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

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