Subject: [MMUSIC] Wording question draft-ietf-mmusic-rfc2326bis/SETUP

From: "Martin Stiemerling" <[email-masked]>
Date: Fri, 22 Feb 2008 15:00:39 +0100

Hi all,

During my edits for the new draft-ietf-mmusic-rfc2326bis version I ran in this text in the first paragraph of Section 13.3.  SETUP

   The SETUP request for an URI specifies the transport mechanism to be
   used for the streamed media.  The SETUP method may be used in three
   different cases; Create an RTSP session, add a media to a session,
   and change the transport parameters of already set up media stream.
   When in PLAY state, using SETUP to create or add media to a session
   when in PLAY state is unspecified.  Otherwise SETUP can be used in

I don't get the real meaning of the last sentence above (When in...). It does look at bit weird to me...

Can anybody help with that sentence?

Thanks,

  Martin

[email-masked]   <== NEW ADDRESS

NEC Laboratories Europe - Network Research Division

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 
_______________________________________________
mmusic mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 22 Feb 2008 16:21:45 +0200

Le Friday 22 February 2008 16:00:39 ext Martin Stiemerling, vous avez écrit :
> Hi all,
>
> During my edits for the new draft-ietf-mmusic-rfc2326bis version I ran in
> this text in the first paragraph of Section 13.3.  SETUP
>

I guess "[w]hen in PLAY state" should be only once. Also you cannot create a 
session if the same session is in PLAY state (implying it already exists). So 
perhaps it should be something as: "Using SETUP to add media to an existing 
session, when the session is in PLAY state, is unspecified."

In other words, SETUP can be used to change transport parameter of a media of 
a PLAYing session, but need not work to add a media to a PLAYing session.

-- 
Rémi Denis-Courmont

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Feb 2008 15:53:02 +0100

> Can anybody help with that sentence?

Yes. The purpose was to specify that the operation of adding a media 
stream when in PLAY state is not specified in such a way that you can 
successfully do it in an interoperable way. Thus it was unspecified.

The issue is that when adding a media stream to a playing session you 
need to get synchronization information. There is no support specified 
for that.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Jaehwan Kim" <[email-masked]>
Date: Sat, 23 Feb 2008 07:21:12 +0900

Hi Magnus,
Still it is not clear to me. Can I use the following interpretation?

... The SETUP method may be used in three
   different cases; create an RTSP session, add a media to a session,
   and change the transport parameters of existing media stream.
   In PLAY state, creating a session and adding a media to it are
   unspecified. (In INIT and READY state, however, above both cases 
   are possible. In other words, SETUP can be used only for changing 
   transport parameters in PLAY state.(1)) The main reason is that 
   adding a media stream to the existing session in PLAY state requires
   synchronization. However, it is unspecified. (2)

My question to (1) and (2): 
To (1): We don't need to add sentence (1) because the first sentence
clearly defined 3 cases and description after it is about exception in
PLAY state.
To (2): Creating session using SETUP to the existing session(in PLAY
state) means just making another one, not related to 'existing or
already set up session'. That's why Magnus did not mention this case...
To (2): As for synchronization, it would be no problem if PLAY with
Range is sent after SETUP for adding stream. However, if there is a rule
like 'In one aggregated session, all streams should have the same
state', then the above case breaks this rule because it became 'some
streams are in PLAY state, while new stream in READY. I think this is
the actual reason.
(But I can't find such a rule from draft; however, I can understand this
meaning behind.)

Regards,
Jaehwan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Magnus Westerlund
Sent: Friday, February 22, 2008 11:53 PM
To: Martin Stiemerling
Cc: [email-masked]
Subject: Re: [MMUSIC] Wording question
draft-ietf-mmusic-rfc2326bis/SETUP

Martin Stiemerling skrev:
> Hi all,
> 
> During my edits for the new draft-ietf-mmusic-rfc2326bis version I ran
in this text in the first paragraph of Section 13.3.  SETUP

Cheers

Magnus Westerlund

---

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 25 Feb 2008 09:48:35 +0100

Hi Remi, 

Thanks for the wording. It has been fixed.

 Martin

> From: Rémi Denis-Courmont [mailto:[email-masked]] 
> Sent: Friday, February 22, 2008 3:22 PM
> To: [email-masked]
> Cc: Martin Stiemerling
> > I don't get the real meaning of the last sentence above 
> (When in...). 
> > It does look at bit weird to me...
> >
> I guess "[w]hen in PLAY state" should be only once. Also you 
> cannot create a session if the same session is in PLAY state 
> (implying it already exists). So perhaps it should be 
> something as: "Using SETUP to add media to an existing 
> In other words, SETUP can be used to change transport 
> parameter of a media of a PLAYing session, but need not work 
> to add a media to a PLAYing session.
> 
> --
> Rémi Denis-Courmont
>

---

From: "Martin Stiemerling" <[email-masked]>
Date: Mon, 25 Feb 2008 09:51:22 +0100

> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Friday, February 22, 2008 3:53 PM
> To: Martin Stiemerling
> Cc: [email-masked]
> (When in...). It does look at bit weird to me...
> > 
> Yes. The purpose was to specify that the operation of adding 
> a media stream when in PLAY state is not specified in such a 
> way that you can successfully do it in an interoperable way. 
> Thus it was unspecified.

I believe that some stronger text would be required. This reads
as "not specified but everybody can give it a try." This would
jeopardize interoperability in this case. 

> 
> The issue is that when adding a media stream to a playing 
> session you need to get synchronization information. There is 
> no support specified for that.

This would argue for something align "unspecified and implemenations
MUST NOT try to do this."

Cheers,

 Martin

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 25 Feb 2008 13:54:38 +0100

> MUST NOT try to do this."

Well, the intention was that it would be possible to define this in the 
future if someone can resolve the issues. I can agree that one shouldn't 
implement any SETUP functionality in play state other than parameter 
changes until one has defined how it should work. That is what would 
create an interoperability issue. A future extension can always be 
resolved, even with a 501 response indicating that functionlity isn't 
supported.

But sure, tightening the language in this regard is fine.

Cheers

Magnus Westerlund

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 26 Feb 2008 09:33:37 +0200

> jeopardize interoperability in this case.

As far as I understand, this means that server are free to do whatever they 
want if this happens (start streaming without proper sync, kill the entire 
session, return an error, etc...). Therefore any sane client MUST NOT try to 
use it; I would agree that forbidding clients from using this explicitly is a 
good idea.

Not sure we need to say anything on the server side, as this is 
a "theoretically impossible" case.

> MUST NOT try to do this."

Yes.

And then, if someone ever wants to add this functionality, (s)he'd have to 
specify a feature for it, so clients can detect server support, right?