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

[Roni Even <[e-mail]>]

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".

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.

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


> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: יום ב 08 מאי 2017 16:11
> To: Roni Even; [e-mail]; [e-mail]; Ben
> Campbell
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rfc5285-bis-11.txt
> 
> Please see inline.
> 
> 
> 
> Den 2017-05-03 kl. 15:41, skrev Roni Even:
> >
> >
> >> 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.
> >
> 
> 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.
> 
> 
> 
> >>>
> >>>> 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.
> 
> 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?
> 
> 
> 
> >
> >
> >
> >>
> >>>
> >>>
> >>>> 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
> 
> 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
> 
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------