Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-rfc4566bis-29.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 5 Jun 2018 11:42:48 -0400

I just posted version -29.

This only has minor changes to usage of 'field' to improve consistency 
across the document. I've been holding these changes for awhile, 
awaiting additional issues to address, but there have been no comments 
and I don't want to hold these any longer.

I have no more changes planned. Please comment if you want anything else 
changed.

	Thanks,
	Paul

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-mmusic-rfc4566bis-29.txt
Date: Tue, 05 Jun 2018 08:30:12 -0700
From: [email-masked]
To: [email-masked], Mark Handley <[email-masked]>, Ali 
Begen <[email-masked]>, Colin Perkins <[email-masked]>, 
Mark Handley <[email-masked]>, Paul Kyzivat <[email-masked]>

A new version of I-D, draft-ietf-mmusic-rfc4566bis-29.txt
has been successfully submitted by Paul Kyzivat and posted to the
IETF repository.

Name:		draft-ietf-mmusic-rfc4566bis
Revision:	29
Title:		SDP: Session Description Protocol
Document date:	2018-06-05
Group:		mmusic
Pages:		59
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc4566bis-29.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-29
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-rfc4566bis
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-29

Abstract:
    This memo defines the Session Description Protocol (SDP).  SDP is
    intended for describing multimedia sessions for the purposes of
    session announcement, session invitation, and other forms of
    multimedia session initiation.  This document obsoletes RFC 4566.

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.

The IETF Secretariat

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 13 Jun 2018 18:23:43 -0400

Hi Paul

I have taken a closer look at the updated document, and I think the 
document looks good overall, incl. terminology consistency.

I did note a couple of issues, that require clarification:

1) Section 5.14 - Media Descriptions
The 6th paragraph talks about use of the rtcp attribute with 
hieararchically encoded streams, however AFAIK, the rtcp attribute does 
not support. If it does, then I think the explanation needs to be 
elaborated on (basically, you would need to have more than one of them I 
assume).

2) Section 8.2.3 - Media Formats ("fmt")
Per the beginning of Section 8.2, this is supposed to be a registry, 
however it doesn’t say how this registry works for RTP payload formats. 
Who registers what where ? I will also note, that, although the text is 
similar to RFC4566, such a registry doesn’t actually exist under SDP 
(nor do I think that is the intent).

3) Section 8.2.4.1 - New Attributes
Part of the registration requires "Offer/Answer procedures as explained 
in [RFC3264]". While I agree with that, as part of the recent IESG 
review on Bundle, there were some concerns with simply adhering to RFC 
3264. We plan to discuss this further in the upcoming MMUSIC session in 
Montreal (IETF 102).

I have a few minor nits as well which I will send separately.

Thanks

-- Flemming

On 6/5/18 11:42 AM, Paul Kyzivat wrote:
> I have no more changes planned. Please comment if you want anything 
> else changed.
>
>     Thanks,
>     Paul
>
>
> Status: https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rfc4566bis-29
>
> Abstract:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jun 2018 10:52:37 -0400

Flemming,

> elaborated on (basically, you would need to have more than one of them I 

This is text from 4566. I don't recall the discussions leading to that 
text, and I don't really understand what is intended here. Is RTP/RTCP 
intended to be an instance of a hierarchically encoded stream, or is 
that considered a distinct usage? What is another example of 
hierarchically encoded streams that should apply here.

It is interesting that the examples here all use port/2 for RTP streams, 
but that is clearly not current practice.

> (nor do I think that is the intent).

RTP payload fmts are numbers, and don't have a registry. The mapping of 
those to codecs is done with rtpmap, and so doesn't belong in this section.

This starts to get entangled with RTP specs. If it isn't clear enough 
then I need help from somebody who understands all that better than I do.

> 3264. We plan to discuss this further in the upcoming MMUSIC session in 

So you want to hold any decision on this until after that meeting?

I had previously (on 22may) requested feedback on some of the changes, 
and have yet to get any. Of note are the changes to t, r, and z. For 
those I made some non-backward compatible changes to the ABNF, that will 
reject some nonsense usage. What are your thoughts on these.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Jun 2018 15:31:50 -0400

On 6/14/18 10:52 AM, Paul Kyzivat wrote:
>> hieararchically encoded streams, however AFAIK, the rtcp attribute 
>> does not support. If it does, then I think the explanation needs to 
>> be elaborated on (basically, you would need to have more than one of 
>> them I assume).
>
> It is interesting that the examples here all use port/2 for RTP 
> streams, but that is clearly not current practice.
Maybe one of Colin, Magnus or Jonthan can chime in ?

>> however it doesn’t say how this registry works for RTP payload 
>> formats. Who registers what where ? I will also note, that, although 
>> the text is similar to RFC4566, such a registry doesn’t actually 
>> exist under SDP (nor do I think that is the intent).
>
> RTP payload fmts are numbers, and don't have a registry. The mapping 
> of those to codecs is done with rtpmap, and so doesn't belong in this 
> section.
Agreed.
> then I need help from somebody who understands all that better than I do.
I thought we were simply using the registered names under media types 
(https://www.iana.org/assignments/media-types/media-types.xhtml), but 
again, it would be good to hear from some of the more AVT-knowledgeable 
folks (like Colin, Magnus, Jonathan, etc.).

>> Part of the registration requires "Offer/Answer procedures as 
>> explained in [RFC3264]". While I agree with that, as part of the 
>> recent IESG review on Bundle, there were some concerns with simply 
>> adhering to RFC 3264. We plan to discuss this further in the upcoming 
>> MMUSIC session in Montreal (IETF 102).
>
We probably should, but it would be good to get some guidance from our 
AD here, since he was the one suggesting we need a longer term answer 
that may differ from the current approach. I'd personally prefer for it 
to not hold up 4566bis completion, but I think it's reasonable to at 
least wait for the discussion in Montreal.

> those I made some non-backward compatible changes to the ABNF, that 
> will reject some nonsense usage. What are your thoughts on these.
>
Those fields looked good to me when I read the spec, however I hadn't 
noticed they included non-backward compatible changes. In lieu of SIP 
and RTCWeb being the primary SDP users these days, I doubt it's a major 
concern, but just in case, it might be a good idea to resend your May 22 
message with a subject header that calls out that change.

Thanks

-- Flemming

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Jun 2018 13:06:58 +0100

> On 14 Jun 2018, at 20:31, Flemming Andreasen <[email-masked]> wrote:
>>> I have taken a closer look at the updated document, and I think the document looks good overall, incl. terminology consistency. 
>>> 
>>> The 6th paragraph talks about use of the rtcp attribute with hieararchically encoded streams, however AFAIK, the rtcp attribute does not support. If it does, then I think the explanation needs to be elaborated on (basically, you would need to have more than one of them I assume). 
>> 
>> This is text from 4566. I don't recall the discussions leading to that text, and I don't really understand what is intended here. Is RTP/RTCP intended to be an instance of a hierarchically encoded stream, or is that considered a distinct usage? What is another example of hierarchically encoded streams that should apply here. 
>> 
>> It is interesting that the examples here all use port/2 for RTP streams, but that is clearly not current practice. 

Hierarchically encoded streams, in this context, is layered coding. The draft gives an example:

          m=video 49170/2 RTP/AVP 31

      would specify that ports 49170 and 49171 form one RTP/RTCP pair
      and 49172 and 49173 form the second RTP/RTCP pair.  RTP/AVP is the
      transport protocol and 31 is the format (see below).  If non-
      contiguous ports are required, they must be signalled using a
      separate attribute (for example, "a=rtcp:" as defined in
      [RFC3605]).

The /2 does not refer to the port used for RTCP, it refers to the number of RTP streams in the layered stream.

>>> Per the beginning of Section 8.2, this is supposed to be a registry, however it doesn’t say how this registry works for RTP payload formats. Who registers what where ? I will also note, that, although the text is similar to RFC4566, such a registry doesn’t actually exist under SDP (nor do I think that is the intent). 
>> 
>> RTP payload fmts are numbers, and don't have a registry. The mapping of those to codecs is done with rtpmap, and so doesn't belong in this section. 
> Agreed. 

There is a registry for RTP payload type numbers (https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-1 <https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-1>) but it’s obsolete and closed to new registrations, as discussed in RFC 3551 section 3. 

In practice, the a=rtpmap: lines are used to map the payload type numbers to media types. 

>> This starts to get entangled with RTP specs. If it isn't clear enough then I need help from somebody who understands all that better than I do. 
>> 
> I thought we were simply using the registered names under media types (https://www.iana.org/assignments/media-types/media-types.xhtml <https://www.iana.org/assignments/media-types/media-types.xhtml>), but again, it would be good to hear from some of the more AVT-knowledgeable folks (like Colin, Magnus, Jonathan, etc.). 

Yes, we use media types for RTP. RFC 3555, section 3, describes how the media type, subtype, and parameters are mapped onto SDP. 

>>> Part of the registration requires "Offer/Answer procedures as explained in [RFC3264]". While I agree with that, as part of the recent IESG review on Bundle, there were some concerns with simply adhering to RFC 3264. We plan to discuss this further in the upcoming MMUSIC session in Montreal (IETF 102). 
>> 
> We probably should, but it would be good to get some guidance from our AD here, since he was the one suggesting we need a longer term answer that may differ from the current approach. I'd personally prefer for it to not hold up 4566bis completion, but I think it's reasonable to at least wait for the discussion in Montreal. 
> 
> 
>> I had previously (on 22may) requested feedback on some of the changes, and have yet to get any. Of note are the changes to t, r, and z. For those I made some non-backward compatible changes to the ABNF, that will reject some nonsense usage. What are your thoughts on these. 
>> 
> Those fields looked good to me when I read the spec, however I hadn't noticed they included non-backward compatible changes. In lieu of SIP and RTCWeb being the primary SDP users these days, I doubt it's a major concern, but just in case, it might be a good idea to resend your May 22 message with a subject header that calls out that change. 
> 
> Thanks 
> 
> -- Flemming 
> 
> 
> 
>>     Thanks, 
>>     Paul 
>> . 
>> 
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 30 Jun 2018 20:19:49 -0400

Colin,

On 6/15/18 8:06 AM, Colin Perkins wrote:

>>> This is text from 4566. I don't recall the discussions leading to 
>>> that text, and I don't really understand what is intended here. Is 
>>> RTP/RTCP intended to be an instance of a hierarchically encoded 
>>> stream, or is that considered a distinct usage? What is another 
>>> example of hierarchically encoded streams that should apply here.
>>>
> The /2 /does not/ refer to the port used for RTCP, it refers to the 
> number of RTP streams in the layered stream.

Is this form used in practice? I had the impression that hierarchically 
encoded streams were using separate m= lines for each layer.

And Flemming pointed out to me that a=rtcp isn't defined so it it has 
meaning with such an m= line. That would limit its usage further.

Should this /n usage be deprecated?

	Thanks,
	Paul