Subject: [rtcweb] Summary of Signaling Components in RTCweb (clarifications)

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Oct 2011 13:44:38 +0200

Hi all,
I've tryed to identify all the signaling components of a RTCweb
communication ir order to identify each "signaling fragment" in all
the path. There are various connotations for the "signaling" keyword
in RTCweb and IMHO they are generating confusion.

I've exposed it into the following URL:

  http://public.aliax.net/RTCweb_Signaling_Components.html

Hope it helps. Best regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 10:26:45 +0200

>  http://public.aliax.net/RTCweb_Signaling_Components.html

Hi, I've made some changes to the document:

- Renamed "JS-Browser Media Signaling" to "JS-Browser Media API" (it's
an API and could also be a "protocol", but let's call it just "API"
for better understanding).

- Renamed "JS-Server Information Signaling" to "JS-Server Routing
Signaling". IMHO this is the correct word.

- Added a new section "3. JS Application API" (which is provided by
the custom JS retrieved from the webserver, which should hide the
internal complexity to the high-user => example: Phono API).

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

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 21 Oct 2011 11:11:58 +0200

>  http://public.aliax.net/RTCweb_Signaling_Components.html

Sounds better now. Hopefully we can all now be on the same page when we discuss stuff about "signaling".

Thanks,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Soo-Hyun Choi <[email-masked]>
Date: Fri, 21 Oct 2011 18:36:47 +0900

A nice summary. I found a minor typo though.

>From the text "This documents tries to summarize all the signaling
components of a RTCweb communication ir order to identify each
"signaling fragment" in all the path ",

ir order to => in order to

On Fri, Oct 21, 2011 at 17:26, Iñaki Baz Castillo <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Tim Panton <[email-masked]>
Date: Fri, 21 Oct 2011 10:38:25 +0100

> http://public.aliax.net/RTCweb_Signaling_Components.html

Thanks for putting the time into the document and updates, it
is very useful.

It does highlight one area that I think is problematic , you say:
"JS-Server Media Signaling (in-the-wire): This means carrying SDP (or like-SDP) bodies. In contrast to the JS-Server Routing Signaling this information MAY be treated as "blob" by the RTCweb server, by leaving it to pass verbatim to the destination of the message (which is indicated in the JS-Server Routing Signaling)."

Which is right, the RTCWebserver could treat the the media and network info as blobs. 
The local JS Application however can't.
It needs to know things that are in that SDP in order to render the application for the user. 
Examples include - 
	is it a video or audio stream? 
	is DTMF available (i.e. should it render a keypad) ? 
	What is the screen size of the video? 
To answer these questions the JS apps will need to parse the SDP-like blob, so strictly it isn't a Blob anymore.

What's more there is are examples where the server should be able to understand the JS-Server Media Signaling.
I'm thinking of the simplest use-case, peer to peer calls within a single website. As I mentioned in an earlier email,
the server can be told what the respective browsers support, and then make a determination of what the intersection of codecs is and then inform the browser's JSapp to use that. This has advantages in simplicity and
lack of risk of deadlocks, retries, glare etc.

So in short, I think that treating the SDP-like as a blob has significant disadvantages.

Tim.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Fri, 21 Oct 2011 11:50:13 +0200

Hi Tim,

> To answer these questions the JS apps will need to parse the SDP-like blob, so strictly it isn't a Blob anymore.

Assuming this SDP-like thing is ROAP, for example, an API could be produced for this purpose. If one wants low level access it ma extract the blob and parse it himself.

> So in short, I think that treating the SDP-like as a blob has significant disadvantages.

Notice the MAY ;-) 

--
Saúl Ibarra Corretgé
AG Projects

---

From: Tim Panton <[email-masked]>
Date: Fri, 21 Oct 2011 10:56:26 +0100

> Assuming this SDP-like thing is ROAP, for example, an API could be produced for this purpose. If one wants low level access it ma extract the blob and parse it himself.

My point being that I can't concieve of an app that _didn't_ want to know how big a screen area to
allocate to incoming video (for example). So that JS-window-on-the-blob-API becomes essential,
but we've been told that, it is a) hard b) not necessary to write such a thing.

>> So in short, I think that treating the SDP-like as a blob has significant disadvantages.

Sure. I'm pointing out that the MAY-NOT is a significant and useful case.

Tim.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 12:23:30 +0200

> ir order to => in order to

Thanks, fixed.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Oct 2011 12:30:33 +0200

> To answer these questions the JS apps will need to parse the SDP-like blob, so strictly it isn't a Blob anymore.

Hi, indeed that is out of the scope of the document, but honestly I
imagine that the JS Media API (i.e. ROAP) could include some JS
functions/helpers. For example RTCweb.ROAP.parsePlainSDP(sdp), which
receives a plain SDP and returns a ROAP object or some standarized
JSON object the high-user can insepct in order to determine codecs and
so (low leves access).

> lack of risk of deadlocks, retries, glare etc.

That's a possible choice, right. Just don't mandate it please ;)

> So in short, I think that treating the SDP-like as a blob has significant disadvantages.

That depends on each scenario. For example, I use SIP over WebSocket.
The RTCweb is a pure SIP proxy that speaks SIP over UDP, TCP and
WebSocket. It *never* inspects the SDP (the "JS-Server Media
Signaling" in my document), and it MUST NOT do it. I prefer the
intelligence to be in the UA (the SIP stack in JavaScript, which is
the "JS Application API" in my document).

Regards.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 21 Oct 2011 13:20:47 +0200

On 10/21/2011 11:38 AM, Tim Panton wrote:
>> 2011/10/19 Iñaki Baz Castillo<[email-masked]>:
>>> Hi all,
Well..... maybe not.

When negotiation is done, there will be onstreamadd() callbacks 
informing one about the added streams; these will have clear indications 
on whether they are audio, video or both.

When the video is available, I suspect that there will have to be an 
interface that allows one to tell the resolution of the video; I don't 
know if this is available from the <video> object it's presumably 
connected to, or needs to be available through APIs on a 
MediaStreamTrack. (The video may also be resized after the connection's 
established).

I don't have any idea what the APIs for DTMF are going to be; perhaps 
people will call SendDTMF("") (empty string) and see if it throws an 
exception; this may be simpler than detecting all 3 (or more?) ways of 
showing support for DTMF in SDP.

This theme can be carried further .... sometimes we can learn things by 
snooping on signalling; at other times, we may learn them by looking at 
the objects that results from the signalling. What is best in each 
situation? I don't know, and doubt that there is a single answer.
> lack of risk of deadlocks, retries, glare etc.
It is also functionally equivalent to the browsers all sending a ROAP 
OFFER to the server, and the server constructing a ROAP ANSWER according 
to its understanding of the intersection.

If we were not using ROAP, we would have to represent the codec sets and 
ICE candidates in some other form, and the server would still have to 
have the same understanding of the properties of the codecs in order to 
perform the intersection operation.
> So in short, I think that treating the SDP-like as a blob has significant disadvantages.
A point on which we agree .... Yes, I also think we need to have the 
ability to open the blob at the point that makes sense for the 
application - whether that's in the browser, the JS, the server, or 
somewhere else.

---

From: Wolfgang Beck <[email-masked]>
Date: Mon, 24 Oct 2011 09:28:37 +0200

On Fri, Oct 21, 2011 at 1:20 PM, Harald Alvestrand <[email-masked]> wrote:
> Tim Panton wrote:
> A point on which we agree .... Yes, I also think we need to have the ability
> to open the blob at the point that makes sense for the application - whether
> that's in the browser, the JS, the server, or somewhere else.

ROAP only makes sense if the JS application has no full understanding
of the blob. If it can understand everything that's in the blob,
it could just use the ROAP API as a low-level API. Maybe that's the
way forward..

Wolfgang