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

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 4 Mar 2008 10:34:39 +0100

[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  

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Monday, February 25, 2008 1:55 PM
> To: Martin Stiemerling
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Wording question 
> draft-ietf-mmusic-rfc2326bis/SETUP
> 
> Martin Stiemerling skrev:
> >>>
> >> 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."
> > 
> 
> 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.

I have put it in the tracker and will come up with some wording in a while.
Tracker id 1906850  and link:
https://sourceforge.net/tracker/index.php?func=detail&aid=1906850&group_id=23194&atid=377744

  Martin

> 
> 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]
> ----------------------------------------------------------------------
> 
> 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 4 Mar 2008 10:36:51 +0100

Hi Remi, 

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

The serve can dump an error if a client tries it. So this is seems to be ok. 

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

Right.

  Martin