Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt

From: [email-masked]
Date: Tue, 02 May 2017 23:33:24 -0700

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

        Title           : A General Mechanism for RTP Header Extensions
        Authors         : David Singer
                          Harikishan Desineni
                          Roni Even
	Filename        : draft-ietf-avtcore-rfc5285-bis-11.txt
	Pages           : 23
	Date            : 2017-05-02

Abstract:
   This document provides a general mechanism to use the header
   extension feature of RTP (the Real-Time Transport Protocol).  It
   provides the option to use a small number of small extensions in each
   RTP packet, where the universe of possible extensions is large and
   registration is de-centralized.  The actual extensions in use in a
   session are signaled in the setup information for that session.  This
   document obsoletes RFC5285.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-11
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rfc5285-bis-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rfc5285-bis-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 3 May 2017 10:26:34 +0200

WG,

So this latest update was done, based on the IANA expert reviewer for 
the SDP registrations. Roni quickly updated the template to resolve 
contact and muxing category for the SDP attributes. However, I think we 
do need to do a bit more here, and I think the WG needs to review this. 
So below are my comments, and what I think need to be included.

First, is really "Normal" the mux category for a=extmap-allow-mixed?

To me "Identical" would make much more sense. Either you are capable of 
support mixed or one is not. Having some m= lines in a mux saying yes it 
is possible, and others saying no, I can't. That do not make any sense 
to me, at least across RTP m= lines.

Secondly, I wonder if there needs to be more discussion and spec text on 
muxing for extmap. So draft-ietf-mmusic-sdp-mux-attributes says on special:

4.8.  Category: SPECIAL

    For the attributes in the SPECIAL category, the text in the
    specification defining the attribute MUST be consulted for further
    handling when multiplexed.

    As an exampel, for the attribute extmap [RFC5285], the specification
    defining the extension needs to be referred to understand the
    multiplexing implications.

and

5.13.  RFC5285: RTP Header Extensions

    [RFC5285] provides a general mechanism to use the header extension
    feature of RTP.  It provides the option to use a small number of
    small extensions in each RTP packet, where the universe of possible
    extensions is large and registration is de-centralized.  The actual
    extensions in use in a session are signaled in the setup information
    for that session.

    +---------+--------------------------------------+-------+----------+
    | Name    | Notes                                | Level | Mux      |
    |         |                                      |       | Category |
    +---------+--------------------------------------+-------+----------+
    | extmap  | Refer to the document defining the   | B     | SPECIAL  |
    |         | specific RTP Extension               |       |          |
    |         |                                      |       |          |
    +---------+--------------------------------------+-------+----------+

                       5.13 RFC5285 Attribute Analysis

To my understanding the properties that applies to extmap when muxing a 
set of RTP m= lines are the following:

1. The ID space is common across all m= lines (using RTP) in a BUNDLE group.

2. Each m= block can define a subset of the total defined ID numbers 
indicating limits in use for a particular media source. This allows for 
example audio and video media sources to use different set of header 
extensions.

3. An ID number that is defined in multiple m= blocks MUST have 
identical extmap configuration, i.e. the same URL and any extension 
attributes that effect the usage or form of the RTP header extension.

4. The extmap direction setting for a particular ID number MAY be 
independently set per media source (m= block). This as some media source 
may be unidirectional and other bi-directional.

I think there is need that we actually document this in this level of 
detail so that we get consistent implementation support.

So, WG opinions, or comments on my proposal of how one needs to deal 
with extmap?

I have recommend to Ben that we don't put this document onto the IESG 
agenda until the above is resolved.

Cheers

Magnus Westerlund
Doc shepherd

-- 

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roni Even <[email-masked]>
Date: Wed, 3 May 2017 10:56:38 +0000

inline

> -----Original Message-----
> From: avt [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: יום ד 03 מאי 2017 11:27
> To: [email-masked]; [email-masked]; Ben Campbell
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt
> 
> WG,
> 
> So this latest update was done, based on the IANA expert reviewer for the
> SDP registrations. Roni quickly updated the template to resolve contact and
> muxing category for the SDP attributes. However, I think we do need to do a
> bit more here, and I think the WG needs to review this.
> support mixed or one is not. Having some m= lines in a mux saying yes it is
> possible, and others saying no, I can't. That do not make any sense to me, at
> least across RTP m= lines.
> 

 [Roni Even] I am not sure, currently you can have some m-lines support mixed and some not (use session level for all). 
Why do you want to enforce identical for bundle. One can repeat the allowed mixed or use session level if this is what he wants.
By your logic why do we need to allow in the not bundles case to support some with allowed mixed and some without? We could have used only session level for not bundled case.
>     extensions in use in a session are signaled in the setup information

[Roni Even] I assumed that the behavior is similar to session level extmap except that the RTP extension is only for the m-line

> 1. The ID space is common across all m= lines (using RTP) in a BUNDLE group.
 [Roni Even] this is like session level

> indicating limits in use for a particular media source. This allows for example
> audio and video media sources to use different set of header extensions.
> 
 
[Roni Even] so you are saying that if you use media level, the support for this extensions are only for this specific m-line

> 3. An ID number that is defined in multiple m= blocks MUST have identical
> extmap configuration, i.e. the same URL and any extension attributes that
> effect the usage or form of the RTP header extension.
> 

[Roni Even] My suggestion is to not repeat ID in different m-lines even if use the same extension, one space with unique IDs. This will be simpler. I do not think we have a problem with the number of IDs.

> I think there is need that we actually document this in this level of detail so
> that we get consistent implementation support.
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 3 May 2017 13:45:33 +0200

Hi,

Follow up inline.

> By your logic why do we need to allow in the not bundles case to support some with allowed mixed and some without? We could have used only session level for not bundled case.

So the extmap configuration for an RTP session has a common ID space. So 
for all RTP m= lines that ends up in the same bundle, needs to have a 
consistent space and thus, it becomes difficult for an answerer to 
create an answer to an offer where one m= line in a bundle allows mixed, 
and the other not as it affects how to assign IDs. It is the same RTP 
session those RTP streams are going into. The only approaches to handle 
this is to act as mixed being disallowed, or not bundle at all.

I might have missed how Identical is treated in bundles with different 
protocols (PROTO). Because this clearly only need to be identical for 
all m= blocks that are using the same PROTO. Is this a missing category 
in SDP mux attributes draft?

>  [Roni Even] this is like session level

I wasn't actually thinking about session level, but from a treatment 
level it is what you would aggregate across all the m= lines in the bundle.

> [Roni Even] so you are saying that if you use media level, the support for this extensions are only for this specific m-line

Yes, actual usage is only for RTP streams belonging to this m= block. An 
example of this would be this abbrevaited SDP

a=group BUNDLE a b c
m=audio RTP 97
a=mid:a
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
m=audio RTP 97
a=mid:b
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
m=video RTP 98
a=mid:c
a=extmap:2 urn:3gpp:video-orientation

This above shows an example using header extensions that makes no sense 
to actually use in the other m= in the bundle, but the configuration of 
the RTP header extension is something that happens on RTP session level 
and thus, they must have unique and different numbers.

Yes, one could have configure the two extmap on SDP session level and 
get the same configuration. But it would lack the indication on which 
one they are used. And in the above case, maybe mid b) would not include 
audio-level, and then one could exlude the examap attribute and indicate 
this.

> [Roni Even] My suggestion is to not repeat ID in different m-lines
even if use the same extension, one space with unique IDs. This will be
simpler. I do not think we have a problem with the number of IDs.

Actually, we only have 14 short format IDs, so I disagree with you. Take 
a CLUE conferencing scenario where one uses BUNDLE, then each m= block 
for audio may have 5 configured IDs (ssrc-audio-level, encrypt, 
sdes:cname, sdes:CaptId, sdes:mid). Unless you resuse them across the m= 
lines it will not work.

Cheers

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Wed, 3 May 2017 13:41:27 +0000

> >> contact and muxing category for the SDP attributes. However, I think
> >> we do need to do a bit more here, and I think the WG needs to review
> this.
> >> To me "Identical" would make much more sense. Either you are capable
> >> of support mixed or one is not. Having some m= lines in a mux saying
> >> yes it is possible, and others saying no, I can't. That do not make
> >> any sense to me, at least across RTP m= lines.
> >>
> >
> >  [Roni Even] I am not sure, currently you can have some m-lines support
> mixed and some not (use session level for all).
> > Why do you want to enforce identical for bundle. One can repeat the
> allowed mixed or use session level if this is what he wants.
> > By your logic why do we need to allow in the not bundles case to support
> some with allowed mixed and some without? We could have used only
> session level for not bundled case.
> 
> consistent space and thus, it becomes difficult for an answerer to create an
> answer to an offer where one m= line in a bundle allows mixed, and the
> other not as it affects how to assign IDs. It is the same RTP session those RTP
> streams are going into. The only approaches to handle this is to act as mixed
> being disallowed, or not bundle at all.

[Roni Even] If I understand your point, I think that by not allowing the same ID in multiple m-lines even if the same header extension with the same values will work.

> protocols (PROTO). Because this clearly only need to be identical for all m=
> blocks that are using the same PROTO. Is this a missing category in SDP mux
> attributes draft?
> 
> >>
> > [Roni Even] I assumed that the behavior is similar to session level extmap
> except that the RTP extension is only for the m-line
> >
> example
> > [Roni Even] so you are saying that if you use media level, the support for
> this extensions are only for this specific m-line
> 

[Roni Even] The example does not have any attribute value, when there is one and you want to change you will need to negotiate a new ID.

> sdes:cname, sdes:CaptId, sdes:mid). Unless you resuse them across the m=
[Roni Even] This is why we have the two byte header extensions, and I assume that if you support bundle you should support RFC5285-bis

---

From: David Singer <[email-masked]>
Date: Thu, 04 May 2017 14:01:37 -0700

> On May 3, 2017, at 3:56 , Roni Even <[email-masked]> wrote:
> 
> inline
> 

I am not sure we need to enforce consistency, since either end can insist on it is they wish. Maybe my video demuxer copes and my audio one doesn’t.

>>    As an exampel,

s/exampel/example/

>> for the attribute extmap [RFC5285], the specification

David Singer
Manager, Software Standards, Apple Inc.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 8 May 2017 15:11:06 +0200

Please see inline.

> [Roni Even] If I understand your point, I think that by not allowing the same ID in multiple m-lines even if the same header extension with the same values will work.

So under the restriction that no extmap lines in any bundled m= block 
can have the same ID, then different applications of 
a=extmap-allow-mixed would result in that some m= blocks only can use 
one number space. Considering the limited space for one-byte header 
compatible IDs, they will be difficult to apply. Especially considering 
like 8 concurrent audio sources with identical needs for CNAME, MID, 
RID. In that case one is forced to use 2-byte headers. This results in 
an unnecessary overhead.

To be clear I have no issue with keeping extmap-allowed-mixed to be 
normal. As long as you can write up an explanation for when it occurs. 
And your session levels vs media level may make sense. However, I do not 
like the limitation that one may not use the same ID in multiple m= 
block that are bundled in the same RTP session, assuming identical 
configuration.

> [Roni Even] The example does not have any attribute value, when
> there  is one and you want to change you will need to negotiate a new ID.

Yes, that is correct if one changes the attributes one would need to 
negotiate a new ID. I don't think that is different from what is 
required today if one want safe operations across a switch as signaling 
and RTP is not synchronized.

Is there even any header extensions that uses attributes in signaling?

> [Roni Even] This is why we have the two byte header extensions, and I assume that if you support bundle you should support RFC5285-bis

That is still creating an very artificial limitation that is not needed. 
An ID is an RTP session level configuration. Forcing the signalling to 
create X*Y IDs instead of simple X appears very strange to me. I would 
note that for conferencing with many sources one would possibly run into 
the limitation. There are after all only 254  IDs that can be used by 
the implementation. If one uses 5 IDs per media source then the limit is 
50 sources, that isn't that high.

I fail to see any issues with allowing for a given header extension 
configuration to be re-used in multiple m= blocks with the same ID. This 
is the same as the RTP PT.

And, the Chrome WebRTC SDP examples I have seen do re-use extmap values 
across multiple m= blocks.

Cheers

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Thu, 11 May 2017 07:40:02 +0000

Hi Magnus,
Since I do not have strong opinion about the IDs issues I can live with your text, and add it to section 7 "SDP offer/answer".

2. Each m= block can define a subset of the total defined ID numbers indicating limits in use for a particular media source. This allows for example audio and video media sources to use different set of header extensions.

3. An ID number that is defined in multiple m= blocks MUST have identical extmap configuration, i.e. the same URL and any extension attributes that effect the usage or form of the RTP header extension.

4. The extmap direction setting for a particular ID number MAY be independently set per media source (m= block). This as some media source may be unidirectional and other bi-directional.

Just some clarifications

From 3 and 4 I am not sure about the following bundled m-lines, is this allowed based on 4 or not because of 3?

M=video
A=extmap:1/recvonly uri-gps-string

M=video
A=extmap:1/sendrecv uri-gps-string

There is no problem if the directionality is not specified and is based on the RTP stream directionality.

As for the allowed mixed as normal I do not understand your concern about having one m-line support it and the other not. 

Thanks
Roni

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: יום ב 08 מאי 2017 16:11
> To: Roni Even; [email-masked]; [email-masked]; Ben
> Campbell
> >>>> So this latest update was done, based on the IANA expert reviewer
> >>>> for the SDP registrations. Roni quickly updated the template to
> >>>> resolve contact and muxing category for the SDP attributes.
> >>>> However, I think we do need to do a bit more here, and I think the
> >>>> WG needs to review
> >> this.
> >>>> To me "Identical" would make much more sense. Either you are
> >>>> capable of support mixed or one is not. Having some m= lines in a
> >>>> mux saying yes it is possible, and others saying no, I can't. That
> >>>> do not make any sense to me, at least across RTP m= lines.
> >>>>
> >>>
> >> So the extmap configuration for an RTP session has a common ID space.
> >> So for all RTP m= lines that ends up in the same bundle, needs to
> >> have a consistent space and thus, it becomes difficult for an
> >> answerer to create an answer to an offer where one m= line in a
> >> bundle allows mixed, and the other not as it affects how to assign
> >> IDs. It is the same RTP session those RTP streams are going into. The
> >> only approaches to handle this is to act as mixed being disallowed, or not
> bundle at all.
> >
> >
> > [Roni Even] If I understand your point, I think that by not allowing the same
> ID in multiple m-lines even if the same header extension with the same
> values will work.
> >
> 
> So under the restriction that no extmap lines in any bundled m= block can
> have the same ID, then different applications of a=extmap-allow-mixed
> would result in that some m= blocks only can use one number space.
> Considering the limited space for one-byte header compatible IDs, they will
> be difficult to apply. Especially considering like 8 concurrent audio sources
> with identical needs for CNAME, MID, RID. In that case one is forced to use 2-
> byte headers. This results in an unnecessary overhead.
> 
> like the limitation that one may not use the same ID in multiple m= block that
> are bundled in the same RTP session, assuming identical configuration.
> 
> 
> 
> >>>
> >>>> 2. Each m= block can define a subset of the total defined ID
> >>>> numbers indicating limits in use for a particular media source.
> >>>> This allows for
> >> example
> >> Yes, actual usage is only for RTP streams belonging to this m= block.
> >> An example of this would be this abbrevaited SDP
> >>
> >> a=group BUNDLE a b c
> >> m=audio RTP 97
> >> a=mid:a
> >> This above shows an example using header extensions that makes no
> >> sense to actually use in the other m= in the bundle, but the
> >> configuration of the RTP header extension is something that happens
> >> on RTP session level and thus, they must have unique and different
> numbers.
> >>
> >> one they are used. And in the above case, maybe mid b) would not
> >> include audio-level, and then one could exlude the examap attribute
> >> and indicate this.
> >
> > [Roni Even] The example does not have any attribute value, when there
> > is one and you want to change you will need to negotiate a new ID.
> 
> Yes, that is correct if one changes the attributes one would need to negotiate
> a new ID. I don't think that is different from what is required today if one
> want safe operations across a switch as signaling and RTP is not synchronized.
> 
> >> even if use the same extension, one space with unique IDs. This will
> >> be simpler. I do not think we have a problem with the number of IDs.
> >>
> >> Actually, we only have 14 short format IDs, so I disagree with you.
> >> Take a CLUE conferencing scenario where one uses BUNDLE, then each
> m=
> >> block for audio may have 5 configured IDs (ssrc-audio-level, encrypt,
> >> sdes:cname, sdes:CaptId, sdes:mid). Unless you resuse them across the
> >> m= lines it will not work.
> > [Roni Even] This is why we have the two byte header extensions, and I
> > assume that if you support bundle you should support RFC5285-bis
> 
> An ID is an RTP session level configuration. Forcing the signalling to create X*Y
> IDs instead of simple X appears very strange to me. I would note that for
> conferencing with many sources one would possibly run into the limitation.
> There are after all only 254  IDs that can be used by the implementation. If
> one uses 5 IDs per media source then the limit is
> configuration to be re-used in multiple m= blocks with the same ID. This is
> the same as the RTP PT.
> 
> And, the Chrome WebRTC SDP examples I have seen do re-use extmap
> values across multiple m= blocks.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 May 2017 17:43:04 +0200

Hi Roni,

Den 2017-05-11 kl. 09:40, skrev Roni Even:
> Hi Magnus, Since I do not have strong opinion about the IDs issues I
> can live with your text, and add it to section 7 "SDP offer/answer".

First of all, do not add my text raw, that will not make sense I 
believe. You will need to add context and framing to the rules.

> indicating limits in use for a particular media source. This allows
> for example audio and video media sources to use different set of
> header extensions.
> 
> independently set per media source (m= block). This as some media
> source may be unidirectional and other bi-directional.
> 
> Just some clarifications
> 
> From 3 and 4 I am not sure about the following bundled m-lines, is
> this allowed based on 4 or not because of 3?
> 
> M=video A=extmap:1/recvonly uri-gps-string
> 
> M=video A=extmap:1/sendrecv uri-gps-string
> 

I am of the opinion that the above example shall be allowed. The RTP 
session configuration do not care about direction. The usage 
configuration of the media streams sent in the RTP session may care 
about direcitonality.

It might be that folding the exception 4) provides into 3) is the better 
text solution here.

> based on the RTP stream directionality.

Agreed

> 
> As for the allowed mixed as normal I do not understand your concern
> about having one m-line support it and the other not.

My main issue is the uncertainty over the functionality and what will 
happen when there is one m= line with mixed and one without in a bundle 
group. As I see it creates a number of potential outcomes, depending on 
how the answerer behaves.

Alt 1) The answer splits the bundle group to avoid having different 
capabilities in the same RTP session.

alt 2) The answer refuses to support mixed. And I would argue that would 
be the default case unless the m= lines are split into differnt RTP 
sessions due to this sentence in Seciton 4.1.2:

    A stream MUST contain only one-byte or two-byte
    headers unless it is known that all recipients support mixing, either
    by SDP Offer/Answer [RFC3264] negotiation (see section 6) or by out-
    of-band knowledge.

As it is explicitly stated that not all receivers, i.e. all m= streams 
supports the functionality it is turned off.

alt 3) The answer accepts mixed for one and non mixed for the other m= 
stream. Making another interpretation or missing the above sentence. 
Thus resulting in that some SSRCs sends mixed and other not.

I can accept that it can be allowed, but then please clarify what the 
interpretation of that state is. Because I have as you see multiple ones.

Cheers

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Thu, 18 May 2017 04:48:39 +0000

Hi Magnus,
I will draft the proposed text and send it to the list

As for allowed mix, I understand your comment now.

The question is what is a stream, it is clear in the non bundled case but for the bundle case my assumption was that still each m-line provide a separate stream so the each m-line can have different allowed mix, one use case is for a media switching MCU that may redirect the incoming streams to different receivers, some support bundle and some not in which case the ones that do not support bundle may negotiate allowed mixed only for part of the m-lines.
I think that at least we should allow this but maybe mention that the best way is to have allowed mixed on the session level or in all bundled m-lines

Roni

> Sent: יום ד 17 מאי 2017 18:43
> To: Roni Even; [email-masked]
> First of all, do not add my text raw, that will not make sense I believe. You will
> need to add context and framing to the rules.
> 
> >
> I am of the opinion that the above example shall be allowed. The RTP session
> configuration do not care about direction. The usage configuration of the
> media streams sent in the RTP session may care about direcitonality.
> 
> It might be that folding the exception 4) provides into 3) is the better text
> solution here.
> 
> My main issue is the uncertainty over the functionality and what will happen
> when there is one m= line with mixed and one without in a bundle group. As
> I see it creates a number of potential outcomes, depending on how the
> answerer behaves.
> 
> alt 2) The answer refuses to support mixed. And I would argue that would be
> the default case unless the m= lines are split into differnt RTP sessions due to
> this sentence in Seciton 4.1.2:
> 
> As it is explicitly stated that not all receivers, i.e. all m= streams supports the
> functionality it is turned off.
>