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

[Iñaki Baz Castillo <[e-mail]>]

2011/10/21 Tim Panton <[e-mail]>:
> 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.

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).



> 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.

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
<[e-mail]>