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

[Roni Even <[e-mail]>]

> Den 2017-05-03 kl. 12:56, skrev Roni Even:
> > inline
> >
> >> -----Original Message-----
> >> From: avt [mailto:[e-mail]] On Behalf Of Magnus
> >> Westerlund
> >> Sent: יום ד 03 מאי 2017 11:27
> >> To: [e-mail]; [e-mail]; 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.
> >> 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.
> >>
> >
> >  [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.
> 
> 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.


> 
> 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?
> 
> >>
> >> 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
> >>
> >>
> >>
> >
> > [Roni Even] I assumed that the behavior is similar to session level extmap
> except that the RTP extension is only for the m-line
> >
> >> 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.
> >>
> >  [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.
> 
> >
> >> 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.
> >>
> >
> > [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] 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.



> 
> >
> >
> >> 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.
> 
> 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
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------