Subject: Re: [MMUSIC] [rtcweb] About unified Plan and multiple m lines

From: Emil Ivov <[email-masked]>
Date: Wed, 24 Jul 2013 18:09:45 +0200

(redirecting to mmusic)

On 24.07.13, 16:29, Eric Rescorla wrote:
>
>
>
> On Wed, Jul 24, 2013 at 7:08 AM, Iñaki Baz Castillo <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi, let's suppose WebRTC 1.0 borns with "Unified Plan" built-in, and
>     my browser receives a session invitation from a conference server, and
>     there are 8 audio participants in the conference.
>
>     So the SDP I receive has 8 "m=audio" lines, maybe with different audio
>     codecs in each line. And following SDP O/A rules my browser will
>     generate SDP answer that will also contain 8 "m=audio" lines.
>
>     Now, where it is supposed my browser will send my single audio track
>     to the conference server? What does it mean that I receive 8 "m=audio"
>     lines while I'm just able to send a single audio track? which m=audio
>     line should I use for sending RTP?
>
>
> One of them will be a=sendrecv. The others will be a=sendonly.
> The sendrecv line is the one you use to send media.

I have a few questions here but before that, could you please clarify 
the following:

Are you saying that the above is going to be the case on the offer that 
the callee receives? In other words, the caller "knew" that the callee 
intended to only send one stream so it preset all directions accordingly?

Emil

-- 
https://jitsi.org

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 24 Jul 2013 11:14:36 -0700

Offerer has all sendrecv , the answerer has one sendrecv (since he can send
only one audio track) and rest recvonly

so the answerer is ok to receive all the audio tracks sent by the offerer,
and he is sending only one from his side (marked as sendrecv)

On Wed, Jul 24, 2013 at 9:09 AM, Emil Ivov <[email-masked]> wrote:

> I have a few questions here but before that, could you please clarify the
> following:
>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jul 2013 11:31:01 -0700

> intended to only send one stream so it preset all directions accordingly?

It depends on the context obviously. But in the case of (for instance) a
Hangouts
like system if the conference bridge were the offerer, it would send a pile
of
m-lines with only one being sendrecv (or maybe even recvonly) for the
user's media and the rest being sendonly.

-Ekr

---

From: Emil Ivov <[email-masked]>
Date: Wed, 24 Jul 2013 23:17:39 +0200

On 24.07.13, 20:31, Eric Rescorla wrote:
>
>
>
> On Wed, Jul 24, 2013 at 9:09 AM, Emil Ivov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     (redirecting to mmusic)
>
>
>         On Wed, Jul 24, 2013 at 7:08 AM, Iñaki Baz Castillo
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>     I have a few questions here but before that, could you please
>     clarify the following:
>
>     Are you saying that the above is going to be the case on the offer
>     that the callee receives? In other words, the caller "knew" that the
>     callee intended to only send one stream so it preset all directions
>     accordingly?
>
>
> like system if the conference bridge were the offerer, it would send a
> pile of

Sorry, I am still not getting it. How does it know exactly how many "m=" 
lines to place in a=sendrecv? How does it know if the callee is planning 
on sending a webcam, or two, or webcam+slides? Or maybe 8 other streams 
because the callee turns out to be another MCU?

When you say that this depends on the context, do you mean that it has 
to be hardcoded/pre-provisioned or handled by app-specific signalling?

Emil

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Jul 2013 16:27:05 -0500

On 7/24/13 16:17, Emil Ivov wrote:
> Sorry, I am still not getting it. How does it know exactly how many 
> "m=" lines to place in a=sendrecv?

I think you need to re-read and meditate on section 5.1 of RFC 3264. 
This stuff is actually pretty well defined, and I'm not sure having an 
on-list tutorial is ideal.

Your follow-up questions are likely answered in section 6.1 of that same 
document.

/a

---

From: Emil Ivov <[email-masked]>
Date: Thu, 25 Jul 2013 00:01:32 +0200

> Your follow-up questions are likely answered in section 6.1 of that same

Sorry Adam, I must be having my dumb-day today, but I don't see how 3264 
is even related to what I am asking.

The original query here was about a bridge that invites an endpoint into 
a conference using "unified". The bridge knows that it will be streaming 
8 flows (e.g. from 8 participants) so it creates 8 "m=" lines.

I believe Iñaki's question was: if the callee only has one stream to 
send, how does it pick an "m=" line to associate it with (e.g. for the 
purposes of codec selection).

Eric's answer was: the Offer from the bridge would have marked *one*, 
and only one of the "m=" lines as "a=sendrecv", so that's the line you use.

My follow up question was then: how did the bridge know in advance, that 
the callee only had one media source and not any other number.

This is not a loaded question. I am trying to figure out what the best 
practices with "unified" are.

Again, I might be missing something, so if you feel this would be 
perfectly obvious to everyone else, then please ignore.

Emil

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Jul 2013 17:21:50 -0500

On 7/24/13 17:01, Emil Ivov wrote:
>
> Sorry Adam, I must be having my dumb-day today, but I don't see how 
> 3264 is even related to what I am asking.

Did you even look at the sections that I specifically cited? They 
discuss precisely how you determine how to set 
sendrecv/sendonly/recvonly/inactive attributes.

In the example EKR gave, the bridge is only asking for one video stream 
because that's what makes sense for *it*. It's not guessing how many 
cameras you might have.

/a

---

From: Emil Ivov <[email-masked]>
Date: Thu, 25 Jul 2013 00:58:50 +0200

On 25.07.13, 00:21, Adam Roach wrote:
> Did you even look at the sections that I specifically cited?

I did and they were delightful! Thanks for recommending!

> They

I don't think this is accurate. At least not in the context of the 
current scenario. What these sections talk about is how to set the 
direction attribute once you *know* what direction you'd like to have 
for your streams.

It does not talk about how you get to know what you want. Obviously this 
would be quite out of scope there.

> because that's what makes sense for *it*. It's not guessing how many

So you are confirming that the number of media sources, that the bridge 
expected to get from the callee, was hard-coded or pre-provisioned. Right?

If so, then that's cool and I off to my next question:

How would you handle the case where such pre-provisioning is impossible 
and a callee could respond with any number of sources.

To simplify let's get back to Iñaki's scenario of 8 "m=" lines in the 
offer, but lets also assume that different callees can answer with 
anything between 1 and 8 sources.

In this case, do you set all your "m=" lines to "a=sendrecv"?

If so, we are back to Iñaki's original question: how does a 
single-source callee know which if these "m=" lines to pick for its own 
stream?

I suppose one possible answer would be: it just takes any "m=" line 
that matches its needs and sends stuff there. It also sets everything 
else to "a=recvonly" in the answer. Is this what you'd suggest?

Or maybe the callee sends an answer where it sets everything to 
"a=recvonly" and then re-offers with a ninth "a=sendonly" "m=" line?

Or does the callee use app-specific signalling to tell the bridge that 
it has N sources so that the bridge would offer with N "a=sendrecv" "m=" 
lines and 8-N "a=sendonly" "m=" lines?

Or are all three of the above legal?

Emil

-- 
https://jitsi.org

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Jul 2013 19:00:54 -0500

On 7/24/13 17:58, Emil Ivov wrote:
> So you are confirming that the number of media sources, that the 
> bridge expected to get from the callee, was hard-coded or 
> pre-provisioned. Right?

It's part of the application. Sure. "Hard-coded" is a reasonable way to 
think about it.

> In this case, do you set all your "m=" lines to "a=sendrecv"?

If the bridge wanted to deal with receiving that many media streams, sure.

> single-source callee know which if these "m=" lines to pick for its 
> own stream?
>
> it has N sources so that the bridge would offer with N "a=sendrecv" 
> "m=" lines and 8-N "a=sendonly" "m=" lines?
>

Yes, the first one is what I would recommend.

The second one is certainly valid, but why would you do that? It delays 
the callee-to-caller media unnecessarily.

The third one is fine, too, assuming you want to bind yourself to that 
kind of signaling (it may complicate interdomain federation, if that 
ever becomes important to you).

But this is all pretty easy to derive from RFC 3264 section 6.1, really.

/a

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 25 Jul 2013 23:37:28 +0000

On Jul 24, 2013, at 4:58 PM, Emil Ivov <[email-masked]> wrote:

> If so, we are back to Iñaki's original question: how does a single-source callee know which if these "m=" lines to pick for its own stream?

If they don't have a=content line (see http://tools.ietf.org/html/rfc4796) , you probably don't know which one to use and just use the first. If they no have the a=content slide, then you likely have the information you need to make the right decision by matching up to the one that has the value for a=content as the video you want to send. Note this would work better if the registry also had front, left and right.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 27 Jul 2013 17:49:34 +0200

On 07/24/2013 11:27 PM, Adam Roach wrote:
> Your follow-up questions are likely answered in section 6.1 of that
> same document.

Adam, I couldn't find anything in those sections that addressed the
question either, so either I'm as uneducated in RFC 3264 as Eric, or
we're talking about 2 different questions.

I perceive the question to be a variant of the scenario that's
explicitly outlined in the -unified- draft in section 3.5:

3.5.  Negotiation of Stream Ordinality

   Within advanced applications, circumstances can easily arise in which
   the party creating the offer does not know ahead of time the number
   of streams the remote party will desire.  For example, in a meet-me
   videoconference application that sends a separate stream for each
   participant, a client creating an offer to send to the conference
   focus does not necessarily know how many video streams to indicate in
   its SDP.  Although this can be potentially be solved in an
   application-specific way (e.g., by always offering the maximum number
   of streams known to be supported by the application), this is not
   always desirable or even possible.

   To address this situation, a three-way handshake can be employed.

In addition to the situation outlined there, if an offerer places an
m-line in "sendonly" or "inactive" mode, it is making it unavailable for
the answerer, and I believe that a consistent answer is the same as in
section 3.5:

A three-way handshake can be employed.

In fact, I think it MUST be employed.

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

---

From: Emil Ivov <[email-masked]>
Date: Sat, 27 Jul 2013 18:16:36 +0200

> It's part of the application. Sure. "Hard-coded" is a reasonable way to

A follow up question here then: How strong of an indication is the 
direction? Let's say you do offer me a session with eight streams, seven 
of which are a=sendonly and only one is a=sendrecv. Does this mean that 
I should never consider sending you more than one stream?

In other words, once we complete the first offer/answer, can I send you 
a new offer with additional a=sendrecv "m=" lines? Following 3264 would 
mean that I could ... but if I did, I would essentially be ignore your 
wish to only receive a single stream.

Another question, when rendering the a=sendonly lines in the above 
8-stream offer, should the callee's GUI label them as being "on hold"? 
Given the original scenario, I don't think we'd want that, but how does 
the UA know this? Do we extend 3264 to say that a call is either 
entirely on hold or it is not?

One more: it is entirely possible that I missed this but I couldn't find 
anything in 3264 that says whether or not a callee can, at some point, 
change change the direction of an a=sendonly line to a=sendrecv. Do we 
need to say a word about this?

> Yes, the first one is what I would recommend.

OK

> the callee-to-caller media unnecessarily.

I am just trying to figure out the exact semantics of the 3/4-way 
handshake. So far the way I get it is that I express as much of my 
intentions as I could in my answer. Then, if I need to say something 
more, and only then, I send another offer. Is this correct? Or is it 
more specific than that and I should only follow up with an update offer 
in case I'd like to add streams?

> ever becomes important to you).

Well I do care about federation by I worry more about it when we start 
mentioning hard-coded assumptions in MCUs. An application-layer protocol 
could always be properly specified at some point (and some already are).

> But this is all pretty easy to derive from RFC 3264 section 6.1, really.

I don't really think it is that obvious (otherwise we wouldn't really 
need this document, would we)

I think the issue with directions is that in 3264 they only have an "m=" 
line scope. What you and Eric have implied is that now they actually 
mean something for the entire session.

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Jul 2013 19:58:21 +0000

Hi Emil,

I think you questions are not specific to the unified plan, but to Offer/Answer in general.

First, you can always offer additional m- lines. The receiver may accept them, or it may not, but just because you previously received an Offer with 8 m- lines doesn't automatically means the Offerer can't handle more.

Second, it is allowed to send an Offer, where you suggest to change a sendonly m- line to sendrecv. Again, the receiver may accept it, or it may not.

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Emil Ivov [[email-masked]]
To: Adam Roach [[email-masked]]
CC: IÃ±aki Baz Castillo [[email-masked]]; MMUSIC IETF WG [[email-masked]]
Subject: Re: [MMUSIC] [rtcweb] About unified Plan and multiple m lines

OK

Emil

--
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 28 Jul 2013 09:58:10 +0200

> Yes, the first one is what I would recommend.

There are potential problems with this approach. Having answered this 
and chosen the m-line for bidirectional use all is well for the moment. 
But then, one side may make another offer, proposing to change something 
about that m-line. At that point, its unclear whether the change is 
intended for the stream it is sending, the one it is receiving, or both.

For instance, some devices can really only use one codec, so the new 
offer might be to lock down to the first codec that was chosen. But it 
may be that the desire by the other side was to use a different codec 
for each direction.

I don't have an answer here. It is certainly tempting to use an m-line 
bidirectionally, at least in absence of bundle. With bundle there is a 
lot less motivation to do that.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Sun, 28 Jul 2013 13:04:21 +0200

> I think you questions are not specific to the unified plan, but to

Well that's the thing, they *are* about unified plan. Looking for 
answers to these questions in 3264 would be the same as looking for 
traffic regulations and ordinances in the manual of your car.

The answers you can get from 3264 are that pretty much anything and 
everything is possible. Some of that ambiguity would have to be removed. 
Ideally we'd do this in the spec but if we don't, then implementations 
would do it implicitly.

> First, you can always offer additional m- lines. The receiver may accept
> them, or it may not, but just because you previously received an Offer
> with 8 m- lines doesn't automatically means the Offerer can't handle more.
> Second, it is allowed to send an Offer, where you suggest to change a
> sendonly m- line to sendrecv. Again, the receiver may accept it, or it

This is a great example of how 3264 is not enough.

Let's say for example that you want to add a new stream by switching an 
a=sendonly "m=" line to a=sendrecv. However, I consider this line to be 
"on hold" and I don't want you thinking that you can unhold it, so I 
reject it. At the same time I am totally fine with you adding a new one 
for your stream.

Inversely, I might have sent you an offer with 8 "m=" lines as an 
indication that this is the maximum number of streams that I can deal 
with (this is actually labelled as bad practice in unified but I didn't 
find an alternative). In this case, I might be OK with you changing my 
directions to enable new streams but I would reject new "m=" lines 
because I don't want to have any more streams than the 8 already in the 
SDP.

In both of the above cases there are different ways of achieving the 
same thing and each time one would work, while others wouldn't. Yet it 
would be hard for the remote party to pick the right one.

Paul just made a case for using different sets of "m=" lines for either 
direction. This is totally valid from a 3264 perspective, but without 
further information, an implementation would have to go through a number 
of trials and errors until it figures out that this is how you expect 
things to happen.

Emil

> may not.
> Regards,
> Christer
>
>
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
> *From:* Emil Ivov [[email-masked]]
> *To:* Adam Roach [[email-masked]]
> *CC:* IÃ±aki Baz Castillo [[email-masked]]; MMUSIC IETF WG [[email-masked]]
> *Subject:* Re: [MMUSIC] [rtcweb] About unified Plan and multiple m lines

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 28 Jul 2013 13:55:52 +0200

> of trials and errors until it figures out that this is how you expect

I don't claim to know what is *right* here. I commented on some 
difficulties of using m-lines bidirectionally.

ISTM that 3264 is predicated on sendrecv describing a bi-directional 
usage, rather than two uni-directional usages. This can be inferred from 
the use of a single set of matched attributes for the two directions - 
no ability to say "use codec X in one direction and codec Y in the other 
direction."

But I am not aware of any clear guidelines about when you logically have 
a single bidirectional usage vs. two unidirectional usages.

I think we are lacking a conceptual model of the distinction.

In certain cases history provides a precedent. In particular, a basic 
audio call. In that case we can how common usage links the two 
directions: when I want to "put the call on hold" I want to stop 
receiving the stream from the far end and I either want to stop sending, 
or else I will send some sort of MoH stuff. These actions are viewed as 
coupled, so using a single m-line works out.

I suppose, if I had one sendonly and one recvonly audio m-line, then I 
could figure out what to to with the SDP. But would the other side 
understand?

But when you start adding streams - even audio/video - then those common 
usages provide little guidance for what to do. Does hold do make the 
same changes to both audio and video? Or are they managed separately.

And once I have more than one audio or video in each direction, it 
becomes quite unclear.

We have been living in blissful ignorance. Once we start seriously 
thinking about multiple audio or video m-lines we are forced to actually 
think about this stuff, make some decisons, and write them down.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 29 Jul 2013 11:32:05 +0200

2013/7/28 Emil Ivov <[email-masked]>:
> a=sendonly "m=" line to a=sendrecv. However, I consider this line to be "on
> hold" and I don't want you thinking that you can unhold it, so I reject it.
> At the same time I am totally fine with you adding a new one for your
> stream.
>
> Inversely, I might have sent you an offer with 8 "m=" lines as an indication
> that this is the maximum number of streams that I can deal with (this is
> actually labelled as bad practice in unified but I didn't find an
> alternative). In this case, I might be OK with you changing my directions to
> enable new streams but I would reject new "m=" lines because I don't want to
> have any more streams than the 8 already in the SDP.
>
> In both of the above cases there are different ways of achieving the same
> thing and each time one would work, while others wouldn't. Yet it would be
> hard for the remote party to pick the right one.
>
>
> further information, an implementation would have to go through a number of
> trials and errors until it figures out that this is how you expect things to
> happen.

The problem of SDP is not just the format or the O/A mandate, but the
fact that it was designed for legacy communications (i.e. single
telephone call) in which it is 100% obvious that both parties would
send audio to the other. It sometimes also works well when adding a
video stream (not so well when disabling and re-enabling it again).

So SDP assumes that a communication uses the same UDP IP:port tuple
for sending audio and receiving its corresponding audio, and thus, SDP
represents them in a single m=line. Note however that in WebRTC we
have multiplexed RTP.

So now we have a powerfull scenario in which a conference server wants
to send the client (browser) 8 audio tracks (from 8 participants) and
the webcam video of 3 of them, and the client just wants to send its
own audio and video track. This should be EASY:

- The conference server offers 8 audio tracks + 3 video tracks.
- The browser offers 1 audio track + 1 video track.

But not... we are in SDP, things cannot be cool and modern. Instead:

- The conference server offers 8 audio tracks + 3 video tracks.
- The browser *answers* with 8 audio tracks + 3 videos tracks.
  (but most of them "a=recvonly").

This is a hack. The 8 m=audio lines offered by the server belong to 8
participants (from Alice, Bob, Carol...). Why should the browser
*choose* one of those m=audio lines for sending its own audio track?
how can this stuff make sense in WebRTC where we have multiplexed RTP
flows? Why should the browser set the "Alice's audio track" for
sending and receiving and all the others for just receiving?

And *worse*:

- The conference server offers 8 audio tracks from 8 clients without webcam.
- The browser *wants* to offer 1 audio track +  1 video track (it does
have webcam).

FAIL !!! You cannot do that with SDP! The browser MUST reply with
exactly 8 m=audio lines and ZERO m=video lines, so if the browser
wants to add video it must re-negotiate later by adding a video track
(a new SDP O/A round trip).

So, leaving aside the SDP format and its O/A mandate, the fact is that
SDP semantics (even with Plan-Unified) is bad for modern
communications in which receiving a RTP flow does not mean that we
also send a RTP flow (and vice versa).

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 29 Jul 2013 13:28:22 +0200

> (a new SDP O/A round trip).

Obviously the conference server could be foolish in this way, but in
the type of scenario you suggest, the conference server would most
likely offer 8 sendonly audio tracks (for sending audio to the client)
and then one recvonly audio track and one recvonly video track
to elicit the client's a/v session, which will work reasonably well.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 29 Jul 2013 14:09:22 +0200

--
Iñaki Baz Castillo
<[email-masked]>
> to elicit the client's a/v session, which will work reasonably well.

And what about if the browser/device has two webcams (letf and right) and
wants to send both? How can the server determine it? Or should the device
does re-negotiation?

I am pretty sure SDP semantics is bad for modern RTC communications like
those we expect to take place in WebRTC.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Jul 2013 12:24:20 +0000

Hi,

No matter what protocol you use, how can the server know what the browser “wants to do” before the server has even contacted the browser???

When using SIP on the wire, the browser could send a REGISTER request and provide information about its media capabilities (number of cameras etc), which the server can then later use when generating the Offer towards the browser.

Alternatively, the server can send an OPTIONS to the browser, can the response would contain similar capability information.

Regards,

Christer

Lähettäjä: Iñaki Baz Castillo [mailto:[email-masked]]
Lähetetty: 29. heinäkuuta 2013 15:09
Vastaanottaja: Eric Rescorla
Kopio: Emil Ivov; Christer Holmberg; MMUSIC IETF WG
Aihe: Re: [MMUSIC] [rtcweb] About unified Plan and multiple m lines

--
Iñaki Baz Castillo
<[email-masked]<mailto:[email-masked]>>
El 29/07/2013 13:29, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> escribió:
>
>
>
>
> On Mon, Jul 29, 2013 at 11:32 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>

And what about if the browser/device has two webcams (letf and right) and wants to send both? How can the server determine it? Or should the device does re-negotiation?

I am pretty sure SDP semantics is bad for modern RTC communications like those we expect to take place in WebRTC.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 29 Jul 2013 14:45:05 +0200

2013/7/29 Christer Holmberg <[email-masked]>:
> No matter what protocol you use, how can the server know what the browser
> “wants to do” before the server has even contacted the browser???

Exactly !!!

That is the point Christer. The server (the offerer in this case) MAY
NOT know what the browser/client wants to offer (unless there is some
kind of announcement via previous registration or there is a hardcoded
scenario which well-known/proprietary devices).

So, if we assume that the "session offerer" (the server in this case)
MAY NOT be able to know which kind of media and/or how many tracks the
browser would like to send, why do we mandate a media signaling
protocol (SDP) in which the offerer MUST tell the browser/client how
many tracks (and which kind of media) it can send??

SDP is the problem here.

A good design would be someone in which the offerer (server) tells the
browser "I will send you 8 audio tracks and 3 videos tracks" and the
browser would reply "OK, I will send you 1 audio track and 2 video
tracks". Or a more complete one:

- The offerer tells the browser "I will send you 8 audio tracks and 3
videos tracks".

- The browser confirms all the audio tracks but tells the server to
disable 2 video tracks".

- The browser tells the server "I will send you 1 audio track and 2
video tracks".

- The server accepts receiving all of them.

This is: an unidirectional-track-negotiation media protocol. But that
is not what SDP is, so here we are.

Regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Jul 2013 12:55:50 +0000

Hi,

>> No matter what protocol you use, how can the server know what the 
>> browser “wants to do” before the server has even contacted the browser???
>
> Exactly !!!
>
> That is the point Christer. The server (the offerer in this case) MAY NOT know what the browser/client wants to offer (unless there is some kind of announcement 
> via previous registration or there is a hardcoded scenario which well-known/proprietary devices).
>
> So, if we assume that the "session offerer" (the server in this case) MAY NOT be able to know which kind of media and/or how many tracks the browser would like 
> to send, why do we mandate a media signaling protocol (SDP) in which the offerer MUST tell the browser/client how many tracks (and which kind of media) it can send??
>
>SDP is the problem here.
>
> A good design would be someone in which the offerer (server) tells the browser "I will send you 8 audio tracks and 3 videos tracks" and the browser would reply "OK, I will send you 1 audio track and 2 video tracks". 

Sounds like H.245 :)

> Or a more complete one:
>
> - The offerer tells the browser "I will send you 8 audio tracks and 3 videos tracks".
>
> - The browser confirms all the audio tracks but tells the server to disable 2 video tracks".
>
> - The browser tells the server "I will send you 1 audio track and 2 video tracks".
>
> This is: an unidirectional-track-negotiation media protocol. But that is not what SDP is, so here we are.

You CAN do this with SDP, using uni-directional streams: the server offer 8+3 sendonly streams, and then the browser offers 1-3 sendonly streams.

(I DO agree it is not how SDP has traditionally been used)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 29 Jul 2013 16:32:10 +0200

> (I DO agree it is not how SDP has traditionally been used)

And sure you agree that WebRTC browsers and devices will NOT allow
that because, regardless how "flexible" SDP is, the fact is that
devices do not allow all that flexibility.

So my concerns (and Emil's ones) remain alive. But, for simplifying, I
will summarize them in a single question:

- Alice, using her browser, can enter in an *active* audio/video
conference in which there are already 8 participants.

- The browser sends the SDP offer to the conference server.

- Should the browser *know* that there are 8 participants (so it
should add 8 m=audio and 8 m=video lines)?

- Or should it just add a single audio and video m lines? If so, could
the server reply a SDP answer with 9 audio lines and 9 video lines?
really? I am 100% sure that browsers will not understand it.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Jul 2013 16:47:34 +0200

> should add 8 m=audio and 8 m=video lines)?

Probably not. Maybe in some cases it can. (Because the web server told it.)

> - Or should it just add a single audio and video m lines?

This is certainly the straightforward thing to do.

> If so, could

No, this is not valid SDP. The best that can be done is for the server 
to answer the two m-lines. And then to send another offer that adds the 
other m-lines.

This is not ideal. But migrating away from SDP for sip has been tried 
and given up as infeasible.

Conceivably something different can be done for rtcweb if it wants to 
diverge from SDP and/or O/A. But if so, then the gatewaying to sip will 
be harder.

Perhaps we should reconstitute SDPng for rtcweb. :-)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Jul 2013 15:03:36 +0000

Hi,

> And sure you agree that WebRTC browsers and devices will NOT allow that because, regardless how "flexible" SDP is, the fact is that devices do not allow all that flexibility.
>
> So my concerns (and Emil's ones) remain alive. But, for simplifying, I will summarize them in a single question:
>
> - Alice, using her browser, can enter in an *active* audio/video conference in which there are already 8 participants.
>
> - Should the browser *know* that there are 8 participants (so it should add 8 m=audio and 8 m=video lines)?
>
> - Or should it just add a single audio and video m lines? If so, could the server reply a SDP answer with 9 audio lines and 9 video lines?

The browser can, in the first Offer, only include 1+1 m- lines. Then, the server can inform the browser about the number of participants, and the browser can create a second offer accordingly, e.g. with 8+8 m- lines.

(...or, the number of participants might be provided to the browser before it sends the first offer.)

I think one problem is that people often are so "fixated" in doing everything in a single O/A transaction. During the session establishment, it doesn't really matter if you have to send one or two more Offers :)

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 29 Jul 2013 17:22:59 +0200

2013/7/29 Christer Holmberg <[email-masked]>:
> The browser can, in the first Offer, only include 1+1 m- lines. Then, the server can inform the browser about the number of participants,

Via custom signaling, right? so we have a media session signaling
mandate (SDP O/A) which is not suitable for properly negotiating my
very basic scenario.

> and the browser can create a second offer accordingly, e.g. with 8+8 m- lines.
>

Again via custom signaling.

> I think one problem is that people often are so "fixated" in doing everything in a single O/A transaction. During the session establishment, it doesn't really matter if you have to send one or two…

May be that si good enough for SIP, but may be not for other (future)
RTC protocols.

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Jul 2013 15:40:51 +0000

Hi,

>> The browser can, in the first Offer, only include 1+1 m- lines. Then, 
>> the server can inform the browser about the number of participants,
>
> Via custom signaling, right? so we have a media session signaling mandate (SDP O/A) which is not suitable for properly negotiating my very basic scenario.

SDP O/A is used to negotiate the media channels - not to exchange generic capabilities (e.g. number of participants in the conference).

So, this is your chance to be innovative :)

>> I think one problem is that people often are so "fixated" in doing 
>> everything in a single O/A transaction. During the session 
>> establishment, it doesn't really matter if you have to send one or two 
>> more Offers :)
>
> May be that si good enough for SIP, but may be not for other (future) RTC protocols.

I don't really see why it would be any different for RTC protocols.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 29 Jul 2013 19:01:03 +0200

> SDP O/A is used to negotiate the media channels - not to exchange generic capabilities (e.g. number of participants in the conference).

I was thinking in the "standard video conference server" (purchased by
so many web providers) Cullen was talking about in other mail thread.

Anyhow I don't know why the browser must know the exact number of
participants in a conference before making its SDP offer and calling
to the conference server. It just does not make sense. Nobody will
comment it?

- I'm Alice calling to the conference server. This is my audio and
video track (2 m lines).

- OK Alice, I'm the server. Take those 8 audio tracks and 3 video
tracks from other participants already in the conference (so 11 m
lines).

Why something like this is not possible with SDP? Well, because SDP
was designed assuming bidirectional tracks (single telephony audio
track in which obviously both sides talk) and thus SDP is not good for
WebRTC in which we expect servers providing many tracks to clients.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 30 Jul 2013 10:57:38 +0200

Inaki, this is abuse of mailing lists.

Raising the issue of "how do I do this with the current proposal made to
MMUSIC" (aka "unified plan") is reasonable. You have been answered;
there are multiple ways that are valid SDP, and it is reasonable to have
a discussion on which ones to recommand, and if any of them should be
recommended against.

Your screed about how the fact that there's work to be done here
"proves" that SDP is unsuitable for RTCWEB belongs in the WEBRTC mailing
list.

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Tue, 30 Jul 2013 11:45:35 +0000

As just mentioned in mmusic, we are organizing a bar BOF for Thursday at 6:30 PM in the Marlene Bar to discuss SDP aspects in http://www.ietf.org/internet-drafts/draft-marcon-msrp-over-webrtc-data-channels-00.txt.  In particular, the draft includes SDP procedures to negotiate the use of any sub-protocol (e.g., msrp, bfcp, t140) over DataChannels (for sub-protocols that normally use SDP negotiation for other transport options).  Some minimal additional sub-protocol specific procedures might also need to be specified.  The draft also includes msrp-specific procedures needed for the transport of msrp over DataChannels.

This proposal is intended to complement the current DataChannel procedures without requiring any browser support, which is why this work has not been raised directly in rtcweb.

Please join us at the Marlene bar or let me know if you are interested but unable to participate.

Thanks,
Richard