Re: SDP is not suitable for WebRTC

2013/7/30 Harald Alvestrand <harald@alvestrand.no>:

>>> Given your constraints above (SIP, previous knowledge of the number of
>>> active participants), what's obvious about this being a joke?
>> Please, let me know how to do that (without mangling the SDP).
>
> One way is to suggest an API change where OfferToReceiveVideo is changed
> from taking a boolean to taking an integer (or defining that it takes
> either, where a boolean true is interpreted as integer 1).

Humm, I want to generate:

- 7 m=audio lines with a=recvonly
- 1 m=audio line with a=sendrecv
- 4 m=video lines with a=recvonly
- 1 m=video line with a=sendrecv

Is this feasible with the API modification you mention above?




>> Anyhow, as I've said in other mail: why should my browser know (before
>> calling) the
>> number of participants in the conference?
>
> You already said that it knows..... I can't answer the question that you
> didn't ask.

OK, now please let's assume I don't want to know the number of
participants before calling the conference server ;)




>> My browser should be able to tell the conference server:
>>
>> - These are my audio and video tracks (2 tracks).
>>
>> And the server should be able to accept the "call" and reply:
>>
>> - OK, and these are my multiple audio and video tracks (13 tracks).
>>
>> And that's all.But this is NOT possible with SDP due to SDP nature and
>> limitations.
>
> As I pointed out in scenario 4): Only if you're fixated on having a
> single offer/answer and having the first offer come from the browser.
> You have not given a rationale for either of those constraints.

Because I *want* to call from my browser instead of receiving a call
from the conference server (which may be I do not own).



>>>> Oppss, SDP renegotiation...
>>
>>> And why is that a problem, exactly?

>> Forcing renegotiation when there is no need for that in a well
>> designed and modern media signaling protocol (i.e. any custom media
>> signaling protocol a JS developer could create on top of a real JS
>> Object based API for WebRTC).
>
> Actually I suspect that the need for a (minimum) 3-way handshake is
> fundamental to the problem you're posing, so double offer/answer is just
> half a round-trip more expensive than the ideal case.

I don't think so. I could perfectly design a custom signaling protocol
(which also carries media info) in which:

- The browser tells the conference server that it will send one audio
+ one video tracks.

- The server, in a single protocol response, acknowledges both tracks
and announces it own N audio and video tracks to the browser.

- The browser accepts all of them so no need for a new ACK. But if the
browser would request the server to remove a track (or modify the
bandwidth or whatever) it could do.

That is my great and nice custom protocol. That is something I CANNOT
do in WebRTC since I'm constrained by legacy-SDP O/A semantics.




>>> And you did not include the scenario I'd prefer if I was operating
>>> within the limitations you mention (SIP over WebSockets):
>>>
>>> 4)
>>>
>>> The *server* generates an SDP offer with 8 m=audio lines and 4 m=video
>>> lines.
>>> One of each is sendrecv. The browser answers. End of story.
>> No, I want to call to the conference SIP URI from my webphone
>> application (and not the reverse).
>>
>> I hope WebRTC applications design is not so constrained by the current
>> SDP blob based API, and I can design my own application in which I
>> want that the client initiates the call, without that meaning that I
>> need later SDP O/A re-negotiation.
>
> Why?
> You already said that it's your application, it's not interoperating
> with anything existing. And the client already initiated the call (by
> loading the page and setting up the WS). Why do you insist that it
> should also be the one making the SIP OFFER?

For different reasons:


1) Because I want.

2) Because the wire protocol the web app and the conference server
talk is a custom protocol I've designed and implemented in JS (which
internally uses the lovely JS Object based API for WebRTC) and in C++
(for server side). And it happens that the JS client is a separate JS
widget provided by a 3rd party company (which implements my nice wire
protocol) and such a widget is embedded within the customer web page
(so it is not part of the web page itself). And the user must be able
to enter a number in the widget and generate an outgoing call to the
conference server.

3) Did I say "because I want"?




>>> I don't know how people get so hung up on the entity joining the call
>>> being the one to send the SDP offer; there's nothing in the protocol
>>> requiring that, and just the loading of the Web page and opening of the
>>> WS connection has already caused multiple round trips between the
>>> browser and the server.

>> If I want to do arbitrary round trips I will do them, but let me
>> choose where and how. Don't mandate me to do that with SDP just
>> because SDP or Plan-Unified is not suitable for the common scenario I
>> show above.
>
> Then you need to stop talking about using SIP. SIP constrains you much
> more than SDP alone does.

Sure. In my comments above I am talking about a nice and great custom
protocol. Let's forget SIP (oh yeah, but we cannot forget SDP right?)
;)




>>> one of the requirements is "we have to be able to produce and consume SDP from the data available on the API"

>> That's a very good argument in favour of SDP: "Based on a bad decision
>> taken years ago, WebRTC must deal with SDP and thus we must deal with
>> SDP now, and then it is good to have SDP since there is a requirement
>> mandating it".
>>
> That's not what I said. Thanks for not llistening.


Sorry, I would appreciate if you could explain what you meant with:

> I see many issues with the use of SDP.
> But when one of the requirements is "we have to be able to produce and consume SDP from the data available on the API", actually producing and consuming that SDP makes the requirement trivial to test.

(note: for sure this is my problem trying to understand it).



Thanks a lot.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>

Received on Tuesday, 30 July 2013 10:12:44 UTC