Subject: [rtcweb] draft-roach-mmusic-unified-plan-00 expired

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 19 Jan 2014 00:50:41 +0100

Hi, draft-roach-mmusic-unified-plan-00 has expired two days ago.

Please let me know because may be I've missed something: if "Unified
Plan SDP" the chosen way to go for WebRTC? (AFAIK no browser
implements it yet).

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 19 Jan 2014 12:00:50 +0000

Hi,

My understanding is that the draft was never intended to progress. Once we decide that the UP is the road to fame and glory, the different parts would be defined in different drafts (in many cases also in different WGs).

Having said that, maybe it would be a good idea to keep the draft alive until we have actually finished the work above.

Regards,

Christer

Sent from Windows Mail

From: Iñaki Baz Castillo<mailto:[email-masked]>
Sent: ‎Sunday‎, ‎January‎ ‎19‎, ‎2014 ‎1‎:‎51‎ ‎AM
To: [email-masked]<mailto:[email-masked]>

Thanks a lot.

--
Iñaki Baz Castillo
<[email-masked]>
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 19 Jan 2014 14:23:49 +0100

2014/1/19 Christer Holmberg <[email-masked]>:
> My understanding is that the draft was never intended to progress. Once we
> decide that the UP is the road to fame and glory, the different parts would
> be defined in different drafts (in many cases also in different WGs).
>
> Having said that, maybe it would be a good idea to keep the draft alive
> until we have actually finished the work above.

And why no one browser or WebRTC device implements it yet? Do we
understand the impact of changing from
_whatever_sdp_browsers_are_using_today_ to Unified Plan?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 19 Jan 2014 07:19:24 -0800

On Sun, Jan 19, 2014 at 5:23 AM, Iñaki Baz Castillo <[email-masked]> wrote:
> And why no one browser or WebRTC device implements it yet?

I can't speak for Chrome, but Mozilla is actively working on it. Software
takes time.

-Ekr

 Do we

---

From: Philipp Hancke <[email-masked]>
Date: Sun, 19 Jan 2014 16:27:45 +0100

thus spoke Eric Rescorla:
> I can't speak for Chrome, but Mozilla is actively working on it.

Chrome has a working implementation of "Plan B". It's working rather 
nicely, even though using it for conferencing convinced me that I prefer 
"no plan".

In the end, I expect having to hide this under many layers of JS.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 19 Jan 2014 16:34:34 +0100

No, you cannot hide it. With Unified Plan if your browser makes a SDP offer
with one audio and one video track, and the server is a conference server
with multiple audio and video tracks, then the server must reply you with a
fake useless SDP answer with one audio and one video track and later
perform a new SDP O/A by offering all the conference tracks. You cannot
hide that horrible stuff with just JS.

That is one of the most painful SDP consequences: the SDP answer MUST have
the same number of m lines than the offer, and in Unified Plan that means
the same number of tracks.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Jan 2014 04:24:30 +0000

Hi,

I can’t comment on what people implement, but the specifications of some UP features, e.g. the partial offer/answer mechanism, are not ready, so they can’t be implemented yet.

Regards,

Christer

Sent from Windows Mail

From: Iñaki Baz Castillo<mailto:[email-masked]>
Sent: ‎Sunday‎, ‎January‎ ‎19‎, ‎2014 ‎3‎:‎24‎ ‎PM
To: Christer Holmberg<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jan 2014 14:47:50 +0100

2014/1/20 Christer Holmberg <[email-masked]>:
> I can’t comment on what people implement, but the specifications of some UP
> features, e.g. the partial offer/answer mechanism, are not ready, so they
> can’t be implemented yet.

What we need, at least, is to drop the absurd rule of SDP "the answer
MUST have the same number of m lines as the offer in order to match
them".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Jan 2014 06:27:19 -0800

> MUST have the same number of m lines as the offer in order to match

I don't see that happening. However, if it were to happen it would happen
on the mmusic list.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 20 Jan 2014 15:53:39 +0100

2014/1/20 Eric Rescorla <[email-masked]>:
> I don't see that happening.

In Unified Plan each m line has a diferent (and unique) SSRC
identifier. That is all we need to match m lines of the offer and the
answer.

> However, if it were to happen it would happen on the mmusic list.

Right.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 20 Jan 2014 16:52:20 +0100

I believe that the components of -unified-plan are mainly addressed as:

- POF/PAN are going to MMUSIC
- BUNDLE is going to MMUSIC
- The one-track-per-M-line is going to be in -rtcweb-jsep (section 5.2.1 
of -05, in particular)

But a) this is just what I think; the chairs have the task of making 
decisions, and b) I don't have a complete picture of whether there are 
pieces of -unified-plan not covered by the above.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jan 2014 14:27:05 -0500

> MUST have the same number of m lines as the offer in order to match

What is it that troubles you about this.

I guess from prior comment that you want to add more m-lines in the answer?

But O/A is a negotiation/handshake. If you include extra m-lines in the 
answer then there is no completion to the negotiation of those.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Jan 2014 00:34:22 +0000

>>> I can't comment on what people implement, but the specifications of 
>>> some UP features, e.g. the partial offer/answer mechanism, are not 
>>> ready, so they can't be implemented yet.
>>

Me neither.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 22 Jan 2014 15:34:45 +0100

> answer then there is no completion to the negotiation of those.

Having two endpoints establshing a media session, the only they need is:

- To decide a transport or transports for sending media one to each other.
- To tell one to each other what it is sending.

SDP is good (enough) in classic and simple communications in which
both endpoints send and receive something similar (i.e. one single
audio track in both directions).

But nowadays we want that endpoint-A can send just one audio track and
one video track and receive 8 audio tracks and 8 video tracks from
endpoint-B. If endpoint-A makes the SDP offer, it "should" include 16
m lines:

- 1 audio line for sending its single audio track and receive *one* of
the remote tracks (a=sendrecv).
- 7 audio tracks just for receiving the rest of the remote audio
tracks (a=recvonly).
- Same for video.

This is completely unnecessary if we skip the SDP tradition. There is
no need at all for endpoint-A to tell endpoint-B "you can send me up
to 8 audio tracks since I have added 8 m audio lines in my SDP offer,
otherwise you can only send me a single audio track, but you can send
me later a re-offer".

This is something that ORTC "fixes".

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Wed, 22 Jan 2014 08:46:26 -0600

On 1/22/14 08:34, Iñaki Baz Castillo wrote:
> me later a re-offer". This is something that ORTC "fixes".

Continually attempting to re-litigate a closed point of consensus is 
disruptive. Please stop.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Jan 2014 15:58:33 +0000

Hi,

I thought the idea of the UP was that each m- line was going to represent a unidirectional stream, which would make it easier to negotiate a different number of streams per direction.

But, maybe I remember wrong….

Regards,

Christer

Sent from Windows Mail

From: Iñaki Baz Castillo<mailto:[email-masked]>
Sent: ‎Wednesday‎, ‎January‎ ‎22‎, ‎2014 ‎4‎:‎35‎ ‎PM
To: Paul Kyzivat<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Regards.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 22 Jan 2014 17:30:10 +0100

2014/1/22 Adam Roach <[email-masked]>:
>> This is completely unnecessary if we skip the SDP tradition. There is no
>> need at all for endpoint-A to tell endpoint-B "you can send me up to 8 audio
>> tracks since I have added 8 m audio lines in my SDP offer, otherwise you can
>> only send me a single audio track, but you can send me later a re-offer".

It was not my intention to re-open the discussion. It is just that,
AFAIK, the complete usage of SDP in WebRTC is not yet fulfilled and
hence I thought there is still room for proposals regarding the
Unified Plan specification.

Sorry if I was wrong in this matter.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jan 2014 14:18:01 -0500

Iñaki,

I've read what you read below, but I cannot figure out what you want the 
O/A to contain, and what you want it to mean.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 23 Jan 2014 10:31:14 +0100

2014/1/22 Paul Kyzivat <[email-masked]>:
> Iñaki,
>
> I've read what you read below, but I cannot figure out what you want the O/A
> to contain, and what you want it to mean.

Hi Paul,

My proposal is basically that the SDP offer send by Peer-A contains N
m lines (meaning N tracks) which are just about sending RTP from
Peer-A to Peer-B.
The SDP answer contains M m lines (N can be different than M), which
are just about sending RTP from Peer-B to Peer-A.

Of course this breaks the SDP negotiation model, specially the step in
which codecs are negotiated. That should be done in some other way
which does not rely in mathing m lines.

Yes, this is too complex and would end in something totally different
to what SDP is, so please let's forget this subject and sorry for the
noise.

P.S. Said that I don't like Unified Plan at all since it relies on 1 m
line = 1 media track, and makes negotiation with a conference server
really complex (explained in my mails above).

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Jan 2014 10:41:04 +0100

Iñaki,
(As WG Chair)

I don't see these posting as productive for the WG. We have a consensus
on using SDP and Offer/Answer. This WG can't change the Offer/Answer
process. That is done in MMUSIC.

So please stop wasting peoples time with proposals that doesn't fit the
limits established by consensus decisions.

Regards

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 23 Jan 2014 15:15:01 +0100

> limits established by consensus decisions.

Hi Magnus.

Currently I was not proposing to drop SDP but to modify the current
SDP spec for WebRTC (taking into account that AFAIK it is not yet
fulfilled). The feature I was asking for is not feasible with SDP so I
was certainly wrong, but it was not my intention to reopen the debate
about SDP yes or not.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Jan 2014 08:40:46 +0100

> was certainly wrong, but it was not my intention to reopen the debate

If that was your intention, then I suggest that you provide draft text
to be added to the relevant document, I assume JSEP. Note, my reading of
what you raised earlier in this thread is in fact a modification of SDP
O/A process, not a JSEP usage of O/A question. But, that would be
clearer if you provide draft text.

Cheers

Magnus Westerlund

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 30 Jan 2014 00:39:49 +0000

We spent hundreds of hour discussing SDP between this WG and others. Much consensus was reached. The unified plan draft was a tool to help document that. Now theses decisions are being moved to the appropriate WG documents as Harald pointed out below. 

Iñaki's proposal to "'drop the absurd rule of SDP the answer MUST have the same number of m lines as the offer in order to match them" has so little support from anywhere that the WG is not spending time discussing that proposal. It has been discussed in the past and rejected. I would explain why it was rejected but I’m fairly sure Iñaki understand why and I view this as just moving into trolling at this point. We have got better things to sort out. 

On Jan 20, 2014, at 8:52 AM, Harald Alvestrand <[email-masked]> wrote:

> - The one-track-per-M-line is going to be in -rtcweb-jsep (section 5.2.1 of -05, in particular)
> 
> But a) this is just what I think; the chairs have the task of making decisions, and b) I don't have a complete picture of whether there are pieces of -unified-plan not covered by the above.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 30 Jan 2014 15:48:53 +0100

2014-01-30 Cullen Jennings (fluffy) <[email-masked]>:
> Iñaki's proposal to "'drop the absurd rule of SDP the answer MUST have the same number of m lines as the offer in order to match them" has so little support from anywhere that the WG is not spending time discussing that proposal. It has been discussed in the past and rejected. I would explain why it was rejected but I’m fairly sure Iñaki understand why and I view this as just moving into trolling at this point.

Hi Cullen,

I don't want to spend more time on this topic (I already tryed to
leave it) but I must answer your mail above:

1) I suggested breaking the "m lines rule" in order to resolve a real
problem/limitation of SDP O/A, and I suggested it because AFAIK the
SDP usage in WebRTC is not yet totally specified (so there could be
room for additions/changes).

2) I realized that such a change would indeed break the entire SDP O/A
model, so I accepted that it can not take place at this time (may be
never).

3) I was not trolling.

Said that, there is something I really don't like at all:

> It has been discussed in the past and rejected

Where? When? Probably before WebRTC was born so not in this WG, right?
I don't consider fair that we cannot make questions or proposals for
SDP O/A just because somebody already said "no" to the same or a
similar proposal 7 years ago in some SIP WG or MMUSIC WG (when WebRTC
did not even exist nor its needs).

Anyhow, I don't want to reopen this topic, really.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>