Subject: [MMUSIC] WGLC on draft-ietf-mmusic-decoding-dependency-02

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 23 Jun 2008 04:44:08 -0600

This is to announce a Working Group Last Call for comments on 
http://tools.ietf.org/html/draft-ietf-mmusic-decoding-dependency-02

Please provide your comments to the authors and the mmusic mailing list
by July 8, 2008 (two weeks from today).

Thank you,
Joerg and Jean-Francois.

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Jun 2008 16:14:29 -0700

1. Section 6.1 says:

   Depending on the implementation, a node that does not understand DDP
   grouping (either does not understand line grouping at all, or just
   does not understand the DDP semantics) SHOULD respond to an offer
   containing DDP grouping either (1) with an answer that ignores the
   grouping attribute or (2) with a refusal to the request (e.g., 488
   Not acceptable here or 606 Not acceptable in SIP).

   In the first case, the original sender of the offer MUST respond by
   offering a single media stream that represents an Operation Point.

"MUST" seems too strong:  the original sender of the offer might only wish
to establish communications with an answerer that understands the grouping;
this seems reasonable.  I would adjust the text to something like:

  "In the first case, if the original sender of the offer still wishes
   to establish communications, it MUST generate a new offer with a 
   single media stream that represents an Operation Point."

(I noticed that RFC3388 itself uses a SHOULD, with the following language
in section 8.4.2, "Answerer does not Support "group"":
  "An implementation might also decide to refuse the request (e.g., 488
   Not acceptable here or 606 Not Acceptable) because it contains
   several "m" lines.  In this case, the server does not support the
   type of session that the caller wanted to establish.  In case the
   client is willing to establish a simpler session anyway, he SHOULD
   re-try the request without "group" attribute and only one "m" line
   per flow.")

2. Section 6.2 includes the text:

   Edt. Note: we received a comment from Joerg Ott as follows [JO: Maybe
   double-check that the RTSP Transport: header is sufficiently explicit
   to allow this kind of choice.  SAVPF has some discussion on what do
   with RTSP.].  Neither of us feels competent in following up this
   point.  Input of the MMUSIC WG is requested.  If the WG feels that
   there is no need to address this comment, perhaps we can remove this
   whole paragraph?  An alternative would be to use language comparable
   to section 6.3 below, and leave the issue for further study.  We DO
   NOT want to see a normative dependency to RTSP v2 in this draft due
   to timing and deployment considerations.

This Editor's Note needs to be removed and the issue resolved prior to 
forwarding to IESG.

3. Example "a" in Section 6.4 uses "k=":

...
          m=video 40006 RTP/SAVP 102 103
          c=IN IP4 192.0.2.2/127
          b=AS:512
          k=uri:conditional-access-server.example.com    <<<<<<<<<<<
          a=framerate:30
          a=rtpmap:102 H264-SVC/90000
          a=rtpmap:103 H264-SVC/90000
          a=mid:4
          a=depend:102 lay 1:96,97 2:98; 103 lay 1:97 2:99
...

the use of "k=" is NOT RECOMMENDED by RFC4566, and RFC4566 is normatively
referenced by draft-ietf-mmusic-decoding-dependency-02.  (see
http://tools.ietf.org/html/rfc4566#section-5.12).  "k=" shouldn't be in the
example.  In fact, I would discourage using the RTP/SAVP profile at all in the
document -- it does not help the reader understand
draft-ietf-mmusic-decoding-dependency.

4. Nit: The SDP example in section 6.4 includes blank lines.  I assume this is
done to enhance readability.  Please include text indicating that the blank
lines are not to be included in a real SDP.

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jean-Francois Mule
> Sent: Monday, June 23, 2008 3:44 AM
> To: [email-masked]
> Subject: [MMUSIC] WGLC on draft-ietf-mmusic-decoding-dependency-02
>

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Mon, 23 Jun 2008 22:30:46 -0700

In the first example, should not the following line 

a=depend:100 lay 1:96 2:98; 101 lay 1:97 2:99 

be replaced with

a=depend:100 lay 1:96,97 2:98; 101 lay 1:97 2:99 ?

BR,
-acbegen

> Please provide your comments to the authors and the mmusic 
> mailing list by July 8, 2008 (two weeks from today).
> 
> Thank you,
> Joerg and Jean-Francois.
>

---

From: "Xavier Marjou" <[email-masked]>
Date: Tue, 24 Jun 2008 09:09:40 +0200

In the example of 6.4.a, each m line contains twice the same media format.
Is it a mistake, or is it really wanted?

Cheers,
Xavier

          m=video 40000 RTP/AVP 96 97
          ...
          a=rtpmap:96 H264/90000
          a=rtpmap:97 H264/90000

          m=video 40002 RTP/AVP 98 99
          ...
          a=rtpmap:98 H264-SVC/90000
          a=rtpmap:99 H264-SVC/90000

          m=video 40004 RTP/AVP 100 101
          ...
          a=rtpmap:100 H264-SVC/90000
          a=rtpmap:101 H264-SVC/90000

---

From: Thomas Schierl <[email-masked]>
Date: Wed, 25 Jun 2008 14:24:47 +0200

Hi Dan,

Thanks for the feedback, please find my comments in line.

Thomas

>    re-try the request without "group" attribute and only one "m" line
Our aim was to follow RFC3388, but I agree with you the case you 
described is relevant.
> This Editor's Note needs to be removed and the issue resolved prior to 
We kept this comment for having all information present in the draft. 
This will be removed in the next stage.
> draft-ietf-mmusic-decoding-dependency.
I have no strong opinion on this. SAVP profile can be removed from the 
example.
> lines are not to be included in a real SDP.
Correct. But it may be better to just remove the blank lines.

---

From: Thomas Schierl <[email-masked]>
Date: Wed, 25 Jun 2008 14:25:03 +0200

Hi Ali,

Yes, you are right, leaving out payload type 97 is confusing but 
possible. It could be the case of using different "packetization modes" 
for the different payload types. Here, payload type 100 can just work 
with 96 of the m-line with mid=1. But to avoid confusion, I will adjust 
the example as proposed below.

Thanks,
Thomas

---

From: Thomas Schierl <[email-masked]>
Date: Wed, 25 Jun 2008 14:25:18 +0200

Hi Xavier,

No, it is correct. The different payload types with the same encoding 
name may use different "packetization modes" or different coding parameters.

Thomas

---

From: "Ali Begen (abegen)" <[email-masked]>
Date: Wed, 25 Jun 2008 07:04:41 -0700

Hi Thomas,

Sounds good. Maybe you can add this little explanation (why the examples
have multiple payload types, etc) in the examples section. This would
help readibility, IMHO as well as would answer Xavier's question.

BR,
-acbegen 

> From: Thomas Schierl [mailto:[email-masked]] 
> Sent: Wednesday, June 25, 2008 5:25 AM
> To: Ali Begen (abegen)
> Cc: Jean-Francois Mule; [email-masked]; 
> [email-masked]
> Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-decoding-dependency-02
> 
> Hi Ali,
> 
> Yes, you are right, leaving out payload type 97 is confusing 
> but possible. It could be the case of using different 
> "packetization modes" 
> for the different payload types. Here, payload type 100 can 
> just work with 96 of the m-line with mid=1. But to avoid 
> confusion, I will adjust the example as proposed below.
> 
> Thanks,
> Thomas
> 
> >> Please provide your comments to the authors and the mmusic mailing 
> >> list by July 8, 2008 (two weeks from today).
> >>
> >> Thank you,
> >> Joerg and Jean-Francois.
> >>

---

From: Thomas Schierl <[email-masked]>
Date: Thu, 26 Jun 2008 09:39:24 +0200

Hi Ali,

makes sense.

Thomas

-- 
Thomas Schierl
--------------
Fraunhofer HHI