Subject: [rtcweb] SDP is not suitable for WebRTC

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

Hi, I initiated a thread [*] about Plan-Unified and multiple m lines,
but it was moved to MMUSIC maillist (don't know why since it is about
WebRTC applications design):

http://www.ietf.org/mail-archive/web/mmusic/current/msg11966.html

Sorry for the cross-posting but at this point I'm a bit lost and do
not know which is the appropriate group for my concern.

So my concern is:

- Web application with a SIP over WebSocket client running in the web.

- The web user is provided with a conference SIP URI in which there
are *already* 8 participants (5 of them emitting audio and video and 3
just emitting audio).

- The user calls, from his webphone, to the given URI to join the conference.

Let's imagine that the JS app knows the number of participant in the conference.
Let's imagine my browser have mic and webcam.

QUESTION:

How can my browser join the conference without requiring SDP
renegotiation from the server and, at the same time, being able to
send audio/video and receive audio/video from others (different tracks
/ m=lines)?

"SOLUTIONS":

1)

I tell my browser to generate a SDP offer with:

  - 1 send/receive m=audio line.
  - 7 recvonly m=audio line.
  - 1 send/only m=video line.
  - 4 recvonly m=video line.

(Obviously this is a joke)

2)

SDP seems to allow that the offer and the answer have different number
of m lines (I'm not aware of that but I believe that SDP can do
"everything"). So my browser generates a SDP offer with 1 m=audio line
and 1 m=video line, and the server replies with 8 m=audio lines and 4
m=video lines.

Will my browser understand such a SDP answer with more m lines than
its generated offer? I assume NOT.

3)

My browser generates a SDP offer with 1 m=audio line and 1 m=video
line and the server too. And later the server sends re-INVITE with all
the m lines.

Oppss, SDP renegotiation...

SDP is bad for WebRTC. SDP is good for legacy symmetric communications
in which there is a single-track audio communication and, of course,
both endpoints emit audio. But SDP is bad for modern RTC protocols in
which an endpoint can emit tons of tracks to a single endpoint.

Do we really want this for WebRTC 1.0 ?

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

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 29 Jul 2013 19:42:59 +0200

No, this scenario seems more of a beta or maybe an alpha than a polished
1.0 version.

---

From: Bossiel thioriguel <[email-masked]>
Date: Mon, 29 Jul 2013 18:45:10 +0100 (BST)

You said: "2)
of m lines "

No at all:
RFC 3264:
For each "m=" line in the offer, there MUST be a corresponding "m="
line in the answer.  The answer MUST contain exactly the same number of "m=" lines as the offer.  This allows for streams to be matched up based on their order.  This implies that if the offer contained zero "m=" lines, the answer MUST contain zero "m=" lines.
Mamadou.

________________________________
 De : Iñaki Baz Castillo <[email-masked]>
À : "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Envoyé le : Lundi 29 juillet 2013 19h31
Objet : [rtcweb] SDP is not suitable for WebRTC

So my concern is:

QUESTION:

"SOLUTIONS":

1)

2)

3)

-- 
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: Mon, 29 Jul 2013 19:49:58 +0200

Thanks a lot for clarifying it. So Christer was wrong ;)

And it makes my scenario even worse. I really hope something will happen
and WebRTC will get rid of SDP...

--
Iñaki Baz Castillo
<[email-masked]>
El 29/07/2013 19:45, "Bossiel thioriguel" <[email-masked]> escribió:

>    line in the answer.  The answer MUST contain exactly the same number
>    of "m=" lines as the offer.  This allows for streams to be matched up
>    based on their order.  This implies that if the offer contained zero
>    "m=" lines, the answer MUST contain zero "m=" lines.
>
> Mamadou.
>
>   ------------------------------
>  *De :* Iñaki Baz Castillo <[email-masked]>
> *À :* "[email-masked]" <[email-masked]>; "[email-masked]" <
> [email-masked]>
> *Envoyé le :* Lundi 29 juillet 2013 19h31
> *Objet :* [rtcweb] SDP is not suitable for WebRTC
>

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 30 Jul 2013 08:52:51 +1000

> (Obviously this is a joke)

Since you seem to be doing a full mesh and you seem to be wanting to
receive from everyone and be able to talk back to everyone, wouldn't
this need to be 8 different SDP offers in a full mesh network rather
than one SDP offer with 13 different m-lines? I don't follow how each
of the recipients would pick the right m-line for themselves...

> its generated offer? I assume NOT.

I'm don't understand SDP, but logic would tell me that it would send a
single SDP offer with its own capabilities to each of the other 8
participants:
m=audio send/receive

(not sure if it also needs m=video, since it's not a video capable device IIUC)

> Oppss, SDP renegotiation...

Yes, I would expect a negotiation to happen between each of the 8
current participants and the one new participant individually.
It would end up in 8 O/A negotiations that should all end up with 5
m=audio send/receive and 3 m=audio receive-only (from the POV of the
webphone.

I'm taking a stab at this because I want to understand more about how
it works, but I actually have no idea if I am correct. Please,
somebody with SDP knowlege, clarify how this would actually work. I,
too, am very curious.

Thanks,
Silvia.

---

From: Ron <[email-masked]>
Date: Tue, 30 Jul 2013 08:44:36 +0930

> not know which is the appropriate group for my concern.

Have you tried a.r.k?

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Jul 2013 03:52:45 +0000

Hi,

I was not wrong, but I was maybe unclear. I meant that each entity would offer it’s m- lines as part of separate Offer/Answer transactions. It IS allowed to add m- lines in a subsequent Offer.

Regards,

Christer

Lähettäjä: Iñaki Baz Castillo [mailto:[email-masked]]
Lähetetty: 29. heinäkuuta 2013 20:50
Vastaanottaja: Bossiel thioriguel
Kopio: [email-masked]; [email-masked]
Aihe: Re: [rtcweb] SDP is not suitable for WebRTC

And it makes my scenario even worse. I really hope something will happen and WebRTC will get rid of SDP...

--
Iñaki Baz Castillo
<[email-masked]<mailto:[email-masked]>>
El 29/07/2013 19:45, "Bossiel thioriguel" <[email-masked]<mailto:[email-masked]>> escribió:
You said: "2)

No at all:
RFC 3264:

Mamadou.

________________________________
De : Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>>
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Envoyé le : Lundi 29 juillet 2013 19h31
Objet : [rtcweb] SDP is not suitable for WebRTC

So my concern is:

QUESTION:

"SOLUTIONS":

1)

2)

3)

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Jul 2013 09:45:59 +0200

> of the recipients would pick the right m-line for themselves...

Silvia, I don't feel I am doing a full mesh, but something really
common, which is:

- I contact, from my browser, to a conference server in which there is
an active conference with N participants.

- I provide my audio and video tracks to the conference server.

- The server provides me with N audio/video tracks belonging to N participants.

- I don't want to do a second SDP O/A round trip.

Please, note that my browser has a signaling and a media session with
the conference server. This is, the endpoints are my browser and the
conference server. The fact that the conference server acts as a mixer
by joining all the participants changes nothing. The browser
establishes a single RTC session with the server. This is not an
exotic scenario at all.

And no, I do not want to send 8 different SDP offers since I will
mantain just a single RTC session (with the conference server). All
the participants do the same, and the conference server is responsible
of taking all the tracks from participants and send them to all the
participants (via separate tracks).

I would like to hear the opinion of those in favour of SDP for WebRTC,
since what I am clearly stating is that SDP and Plan-Unified is *bad*
for this common scenario.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Jul 2013 09:48:29 +0200

2013/7/30 Christer Holmberg <[email-masked]>:
> I was not wrong, but I was maybe unclear.

OK

> I meant that each entity would
> offer it’s m- lines as part of separate Offer/Answer transactions. It IS
> allowed to add m- lines in a subsequent Offer.

Yes, but that seems 100% unnecessary. The only we need is that peer-A
tells peer-B about its tracks and peer-B tells peer-A about its
tracks. We don't have that with SDP.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Jul 2013 07:56:22 +0000

>> offer it’s m- lines as part of separate Offer/Answer transactions. It 
>> IS allowed to add m- lines in a subsequent Offer.
>
> Yes, but that seems 100% unnecessary. The only we need is that peer-A tells peer-B about its tracks and peer-B tells peer-A about its tracks. We don't have that with SDP.

Well, the peers have to use SOMETHING to do that.

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 30 Jul 2013 10:01:10 +0200

>> The only we need is that peer-A tells peer-B about its tracks and peer-B tells peer-A about its tracks. We don't have that with SDP.
>

Could you please explain it a bit more? If I am not wrong you insist
on the fact that, *theorically*, if a device knows (by other means)
the number of participants in a conference it can generate a SDP with
so many m lines (as in the "solution 1" I told about).

Then I recall: that is NOT possible in WebRTC. The API does not let me
to add 8 m=audio lines (all of them with a=recvonly but one with
a=sendrec).

It is not valid for me that SDP allows "magic". I am interested in
which I can do with SDP *within WebRTC* via the "SDP-blob based API".

Thanks.

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

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Tue, 30 Jul 2013 11:23:32 +0000

Classification: UNCLASSIFIED
Caveats: NONE

Iñaki:

Yes, the conference setup scenario is itself is restricted in a kind of start-conference-arch, as if, it is the third party call setup in the SIP-conf-scenario in your conf-flow.

So, the discussions need to be confined based on this particular conf-call-flow arch. Once we agree on this, we can then limit our discussions with thiis particular case instead of making a general case.

BR/Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: Tuesday, July 30, 2013 3:46 AM
To: Silvia Pfeiffer
Cc: [email-masked]; [email-masked]
Subject: Re: [rtcweb] SDP is not suitable for WebRTC

> of the recipients would pick the right m-line for themselves...

Silvia, I don't feel I am doing a full mesh, but something really common, which is:

- I contact, from my browser, to a conference server in which there is an active conference with N participants.

Please, note that my browser has a signaling and a media session with the conference server. This is, the endpoints are my browser and the conference server. The fact that the conference server acts as a mixer by joining all the participants changes nothing. The browser establishes a single RTC session with the server. This is not an exotic scenario at all.

And no, I do not want to send 8 different SDP offers since I will mantain just a single RTC session (with the conference server). All the participants do the same, and the conference server is responsible of taking all the tracks from participants and send them to all the participants (via separate tracks).

I would like to hear the opinion of those in favour of SDP for WebRTC, since what I am clearly stating is that SDP and Plan-Unified is *bad* for this common scenario.

Classification: UNCLASSIFIED
Caveats: NONE