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

From: Tim Panton <[email-masked]>
Date: Wed, 28 Sep 2011 08:59:38 -0700

I just want to ask folks to take a look at a proposal Neil Stratford wrote for the
Low Level Javascript API and sent to the webrtc list.

It  is based on his and my experience of web based audio plugins and on a
proposal of Cullen's a while back.

http://lists.w3.org/Archives/Public/public-webrtc/2011Sep/0106.html

We'd appreciate any feedback either here or on the webrtc list as appropriate.

Tim.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Sep 2011 12:12:52 -0400

Few questions that I have in regard to this:

1. How can you get local codec capabilities to implement something like SIP
OPTIONS?

2. Can you specify multiple stun/turn/turns servers? If you do what is the
candidate generation process? On the same note why do we provide both stun
and turn relays? Isn't turn server is normally stun server as well?

3. How do you process multiple answers for the same dialog?

4. What do we do with multiple answers from a forked dialog? Is it even
supported?

5. What is the process for synchronizing audio and video streams?
_____________
Roman Shpount

On Wed, Sep 28, 2011 at 11:59 AM, Tim Panton <[email-masked]> wrote:

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

---

From: Tim Panton <[email-masked]>
Date: Wed, 28 Sep 2011 11:09:25 -0700

> Few questions that I have in regard to this:
(Neil seems to be having trouble posting to this list - so I'm forwarding his reply):

Answers inline:

> 1. How can you get local codec capabilities to implement something like
> SIP OPTIONS?

The local codecs and capabilities can be queried at any time, returned
as a json object to the javascript. This is really just asking the
browser what codecs it supports, which we have separated out from SDP
negotiation.

> 2. Can you specify multiple stun/turn/turns servers? If you do what is
> the candidate generation process? On the same note why do we provide
> both stun and turn relays? Isn't turn server is normally stun server as
> well?

I believe that you should be able to specify multiple servers if you
wanted to and that all candidates would be generated and tested based on
priorities etc. One relay may be in a better physical location for
instance than another for a given pair of users.

There may be cases when you want to specify both a stun and turn relay
even if the turn server can serve both purposes, for example as a backup.

> 4. What do we do with multiple answers from a forked dialog? Is it even

The intention is that we leave that to the javascript (library)
developer to decide how best to handle it. Forking presents some
interesting challenges.

> 5. What is the process for synchronizing audio and video streams?

We have the concept of a synchronization group as an attribute that can
be applied to streams, the intention being that those streams in the
same group should be synchronized by the lower layers if possible using
whatever mechanism they can.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 30 Sep 2011 21:18:38 +0200

2011/9/28 Tim Panton <[email-masked]>:
> Forking presents some interesting challenges.

Not in case you implement pure SIP on top of JavaScript/WebSocket :)

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 30 Sep 2011 21:46:27 +0200

> We'd appreciate any feedback either here or on the webrtc list as appropriate.

Hi, the API in that document is just valid for a few specific
scenarios (make a call, receive a call and maybe putting a session on
hold). That is a very limited subset of what any VoIP protocol can
offer, so I don't think it's a good idea for rtcweb to assume a custom
protocol like that for inclusion in WebRTC JS API (as native JS code
within the browser).

Of course, a simple API like that would be useful for lot of people
offering basic media services to the web site users (basic scenarios
in which there is no call transfer, parallel forking and so).

Regards.

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

---

From: Tim Panton <[email-masked]>
Date: Fri, 30 Sep 2011 21:10:39 +0100

> Not in case you implement pure SIP on top of JavaScript/WebSocket :)

So the question is - do you think that you _could_ implement SIP on top of JavaScript/WebSocket
and use the RTP/media api as described ? We tried to make them orthogonal, but I think Neil feels that
to support forking you may need additional features or flags to the calls described in the proposal.

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 30 Sep 2011 22:57:14 +0200

> to support forking you may need additional features or flags to the calls described in the proposal.

I don't know (yet) if a WebRTC client can establish different media
sessions with different peers at the same time (it seems difficult as
there is supposed to be a single microphone). If not, then at
javascript level I can decide which session to enable and which one to
pause (I hope). Also, if I make an outgoing call from the webbrowser
and receive multiple 180/183 with different SDP, I could choose which
one to render so I just establish the media session with one of them.

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

---

From: Roman Shpount <[email-masked]>
Date: Sat, 1 Oct 2011 00:07:29 -0400

On Fri, Sep 30, 2011 at 4:57 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> there is supposed to be a single microphone).
>

You should be able to setup multiple video calls. For audio you should be
able to mix on the client side or provide a way for the client to switch.
_____________
Roman Shpount