Subject: [MMUSIC] RID update

From: Adam Roach <[email-masked]>
Date: Thu, 15 Oct 2015 16:53:57 -0500

Based on the discussions during the interim, I've updated the RID draft.

New version:

https://tools.ietf.org/html/draft-pthatcher-mmusic-rid-01

Changes:

https://tools.ietf.org/rfcdiff?url2=draft-pthatcher-mmusic-rid-01.txt

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Oct 2015 23:04:13 -0400

* Section 7.1:

In:

  1. It MUST generate a 'rid-identifier' that is unique within a media
     description

IIUC, the rid-identifier must be unique within an RTP session, including 
all the media descriptions pertaining to that RTP session.

* Section 7.2.2, item 2:

Restating my earlier comment, why not simply check the PT against those 
listed in the m-line? There could be default PTs in use that have no 
rtpmap or fmtp. Those are only defined for audio, but there *could* be 
rid constraints applied to audio. (I think max-br would potentially be 
applicable. Or new ones might be defined that apply.) At least it seems 
harmless to define it this way.

* Section 7.4, item 4:

I think there should be a check that the PTs in the answer are a subset 
of those in the offer.

(And, while it can be inferred, it might be good to state somewhere that 
in cases where the answerer m-line PT values differ from those in the 
offer, the PTs in the answer rid use the offerer's PT values.)

* Section 10:

As somebody noted, it is confusing to have ";" separate multiple PT 
*values* within rid-fmt-list, and also to separate rid-params.

Possible solutions:
- use a different separator for fmt values
- use a different separator for params
- use a "pt=" for *each* fmt.

	Thanks,
	Paul

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 16 Oct 2015 04:01:06 +0000

See Mo: comments inline. 

On Oct 15, 2015, at 11:04 PM, Paul Kyzivat <[email-masked]> wrote:

* Section 7.1:

In:

IIUC, the rid-identifier must be unique within an RTP session, including all the media descriptions pertaining to that RTP session.

Mo: When using bundle, MID maps to unique m sections, so RID must only uniquely identify the streams within an m section. When not bundled, the transport maps to unique m sections, so again RID must only uniquely identify the streams within an m section. Perhaps some text on this would be useful to add. 

* Section 7.2.2, item 2:

Restating my earlier comment, why not simply check the PT against those listed in the m-line? There could be default PTs in use that have no rtpmap or fmtp. Those are only defined for audio, but there *could* be rid constraints applied to audio. (I think max-br would potentially be applicable. Or new ones might be defined that apply.) At least it seems harmless to define it this way.

Mo: Agreed, good idea. 

* Section 7.4, item 4:

I think there should be a check that the PTs in the answer are a subset of those in the offer.

Mo: That seems like a basic O/A thing. Does each draft with any mention of PT need to echo this?

(And, while it can be inferred, it might be good to state somewhere that in cases where the answerer m-line PT values differ from those in the offer, the PTs in the answer rid use the offerer's PT values.)

Mo: I would like to hear opinions on this. Whether the answer rid should use offer or answer PTs. 

* Section 10:

As somebody noted, it is confusing to have ";" separate multiple PT *values* within rid-fmt-list, and also to separate rid-params.

Possible solutions:

Mo: Agreed, the syntax needs to be cleaned up a bit. 

   Thanks,
   Paul

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Adam Roach <[email-masked]>
Date: Fri, 16 Oct 2015 08:22:37 -0500

I agree with Mo's responses in general, but there's one comment that I'm 
a little confused by:

> *values* within rid-fmt-list, and also to separate rid-params.

In the -01 document 
(https://tools.ietf.org/html/draft-pthatcher-mmusic-rid-01#page-13), 
rid-fmt-list is defined as:

    rid-fmt-list      = "pt=" fmt *( "," fmt )
                         ; fmt defined in {{RFC4566 <https://tools.ietf.org/html/rfc4566>}}

That is, the separator is a comma.

Is there somewhere else in the syntax this is botched? I thought I 
caught all of these inconsistencies in the -01 revision.

/a

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 16 Oct 2015 14:05:26 +0000

Adam is correct, he already fixed this in rid-01. We just need to fix the examples in simulcast-02 which show space instead of semicolon for delimiting PT and other parameters. We may want to allow optional white space after each semicolon for human convenience (but machine/parser inconvenience), but this is a very minor nit.

Mo

On Oct 16, 2015, at 9:22 AM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

I agree with Mo's responses in general, but there's one comment that I'm a little confused by:

In the -01 document (https://tools.ietf.org/html/draft-pthatcher-mmusic-rid-01#page-13), rid-fmt-list is defined as:

   rid-fmt-list      = "pt=" fmt *( "," fmt )
                        ; fmt defined in {{RFC4566<https://tools.ietf.org/html/rfc4566>}}

Is there somewhere else in the syntax this is botched? I thought I caught all of these inconsistencies in the -01 revision.

/a
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 10:56:21 -0400

> caught all of these inconsistencies in the -01 revision.

Oops! My fault for not seeing that change that is right in front of me.

That solution works. It gives me a *slight* amount of heartburn because 
(due to SIP syntax) I'm wired to think that ";" binds tighter than ",". 
But I can get over it. (Or the roles of "," and ";" could be swapped. 
But I'm also wired to expect params to be separated by ";".)

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 16 Oct 2015 11:41:57 -0500

On 10/15/15 22:04, Paul Kyzivat wrote:
> IIUC, the rid-identifier must be unique within an RTP session, 
> including all the media descriptions pertaining to that RTP session.

Added:

     Note that 'rid's are only required to be unique within a media
     section ("m-line"); they do not necessarily need to be unique within
     an entire RTP session.  In traditional usage, each media section is
     sent on its own unique 5-tuple, which provides an unambiguous scope.
     Similarly, when using BUNDLE
     [I-D.ietf-mmusic-sdp-bundle-negotiation], MID values associate RTP
     streams uniquely to a single media description.

>
> * Section 7.2.2, item 2:
>
> Restating my earlier comment, why not simply check the PT against 
> those listed in the m-line? There could be default PTs in use that 
> have no rtpmap or fmtp. Those are only defined for audio, but there 
> *could* be rid constraints applied to audio. (I think max-br would 
> potentially be applicable. Or new ones might be defined that apply.) 
> At least it seems harmless to define it this way.

Updated to:

      ...payload types is verified against the list of valid payload types
         for the media section (that is, those listed on the "m=" line).
         If there is no match for the Payload Type listed in the "a=rid"
         line, then remove the "a=rid" line.

> subset of those in the offer.

Added:

     4.  If the "a=rid" line contains a "pt=" parameter, the offerer
         verifies that the list of payload types is a subset of those sent
         in the corresponding "a=rid" line in the offer.

> (And, while it can be inferred, it might be good to state somewhere 
> that in cases where the answerer m-line PT values differ from those in 
> the offer, the PTs in the answer rid use the offerer's PT values.)

Added:

     Note: in the case that the answerer uses different PT values to
     represent a codec than the offerer did, the "a=rid" values in the
     answer use the PT values that were sent in the offer.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2015 12:56:43 -0400

Thanks. These changes resolve my concerns.
One comment inline.

>      streams uniquely to a single media description.

This means with bundling both will need to be monitored in the RTP/RTCP 
by the receiver to properly process the incoming packets.

Obviously this wasn't clear to me before, so the statement helps.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Oct 2015 11:46:02 -0600

Thanks - that seems to have addressed most the open issues I am aware of so if there are more I hope people can send them to the list. 

> On Oct 15, 2015, at 3:53 PM, Adam Roach <[email-masked]> wrote:
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Oct 2015 16:14:44 -0500

Based on feedback received on the -01 draft, I have updated the RID 
draft again:

Diffs from the previous version:

https://tools.ietf.org/rfcdiff?url2=draft-pthatcher-mmusic-rid-02.txt

And recognizing that this is moving fairly quickly, here's a diff from 
the -00 version:

https://tools.ietf.org/rfcdiff?url1=draft-pthatcher-mmusic-rid-00.txt&url2=draft-pthatcher-mmusic-rid-02.txt

[AVTEXT is copied on this email for their awareness of the SDES work 
described in this document -- please send any followups to MMUSIC]

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2015 18:31:33 -0400

Just a few comments on this version!

* Section 6:

    o  max-fs, for frame size in pixels per frame.  This is the product
       of frame width and frame height, in pixels, for rectangular
       frames.

Are non-rectangular frames possible? If so, what would this mean in that 
case? Does it mean:

- for rectangular frames the max-fs is the product of frame width and 
height, while it can also be used for non-rectangular frames, using some 
other algorithm?

- OR, does it mean that this can only be used for rectangular frames?

* Section 7.4.  (Offering Processing of the SDP Answer)

*Offering* processing??? Is this a spec for a church? :-)

I think you mean "Offer Processing".

Then:

        ... If the rid-
        level parameters are incompatible with the other codec
        properties, then the "a=rid" line is removed.

I don't think it works for the offerer to remove the rid at this point. 
The answerer thinks its answer was ok and use of rid is in effect. So 
some more drastic action is needed to get the two in sync.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 21 Oct 2015 18:03:10 +0200

Hello Adam, all,

The draft indicates uniqueness of the RID is given as per media 
description. The draft also defines a RTP header with the RID. Do we 
need to specify somewhere what happens when the RTP media with a RID 
header traverses a middlebox (e.g. a gateway)? If I understand the 
proposal correctly there would be a need to maintain RID synchronisation 
between any subsequent Offer and the RTP header RID. This may have 
implication on the RTP topologies that could be supported.

Regards, Christian