Re: [rtcweb] Low Level Javascript API Proposal avail on the webrtc list

[Matthew Kaufman <[e-mail]>]

On 10/4/2011 8:19 PM, Roman Shpount wrote:
>
>
> On Tue, Oct 4, 2011 at 10:29 PM, Matthew Kaufman 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>     This stuff is exactly what you'll need to add yet more code to
>     solve if you try to bake SDP offer-answer into the browser to turn
>     it 90% of the way into a SIP phone.
>
>     And exactly what you *don't* need browser code to solve if it is
>     done elsewhere (for instance, the server might be handling the
>     entire SIP and SDP exchange and resolve forking issues at that end
>     without involving the client at all.)
>
>
> Let me rephrase my questions:
>
> 3. If I generate an offer using this API and then send it to the web 
> server, which will deal with SIP end of things, and will get multiple 
> answers in the same dialog, how do I process those answers via this 
> API? What I need is an ability to provide an answer update to the 
> connection. Should I just remove old streams and candidates and add a 
> new ones?

How about I rephrase?

If I generate an offer by writing SDP code in C++ using Win32 APIs to 
allocate sockets and send and receive packets, and I send a SIP packet 
that gets multiple answers in the same dialog, how do I process those 
answers using the Win32 API? See how silly that sounds?

Seriously though, if you need an additional local endpoint because of 
forking, you need to create a second connection object, which will then 
give you an onCandidates() callback, as I understand this API proposal. 
The other way to do it is to have the connection object be able to bind 
to multiple possible far endpoints, but that's not exactly what this API 
says, and it isn't clear that it is needed. (Because it isn't how other 
SIP devices use their network stacks to solve this problem either).

>
> 4. Same thing with an offer that created multiple dialogs. I want to 
> clone the connection and add streams and candidates to it. I don't 
> think this is possible with the current API.

I don't see why you can't create a second connection object (or extend 
this API to allow cloning), and add streams and candidates to that 
connection object. Should be possible to add the same stream to two 
different connection objects, too.

>
> Few new questions:
>
> 5. What is the priority order for generating candidates when multiple 
> STUN/TURN servers are specified? How would this be affected if we also 
> have proxies? I am not sure this is part of any specification so far 
> and probably should be part of RTC spec defined by IETF

Lots of ways to handle this... but yes, the current version of this 
proposed specification doesn't expose any sort of prioritization.
>
> 6. How do we deal with CODEC negotiated parameters? 

I believe that the codec parameters are exposed by the codec object, at 
least that's how I read this spec.

> It is possible to have codec level parameter that needs to be 
> negotiated via offer/answer exchange.

Maybe. Or maybe there's an offer-answer at the server that picks the 
right answer and then sends that down as a setting to the browser.

> There are also codec level parameters that are affected by stream 
> level parameters (like iLBC mode=30 that only makes sense with ptime 
> dividable by 30).

That's just a bug with how RTP works.

> Is it going to be implemented in JavaScript?

I suppose it might need to be, if you really need to select 
connection-level things to match codec-level things and vice versa. Or 
control it up at the server and then send the right settings down.

> This might not be the best idea, since this will require JavaScript to 
> have a detailed knowledge about each codec implementation provided by 
> the browser. For third party call control, it would be more robust to 
> provide a way to return actual codec parameters selected by the 
> browser so that they can be returned in the answer.

Except that we often don't want the codec parameters to be "selected by 
the browser". We want to know what the browser can do and just set them 
a particular way.

I've already suggested that the format of the "detailed knowledge" can 
actually just reuse the parameter strings that are already defined for 
use in SDP.

Matthew Kaufman