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

[Saúl Ibarra Corretgé <[e-mail]>]

Hi Tim,

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

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.

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

Notice the MAY ;-) 

--
Saúl Ibarra Corretgé
AG Projects