4 comments on “Project WONDER: showing WebRTC NNI does not need SIP

  1. I am totally missing the point on how WONDER handles inter-domain. In called-party domain hosting (calling-party domain hosting, resp.) Alice (Bob, resp.) is not being authenticated. Since it is inter-domain, I presume the hosting domain can not authenticate the “visitor”.

    I agree that NNI is not needed, but there has to be a way for Bob’s server to authenticate Alice, likely via her server or a 3rd party id provider. That critical piece is missing in your framework. In my app ffonio.in, I am using OpenID or an “unauthenticated, dummy id” for this purpose.

    I probably don’t follow what you mean by “signaling-on-the fly”, but what you are describing is nothing more than what is derived from WebRTC directly.

    • Hi

      the “signaling on-the-fly” leverages existing WebRTC Identity Management concepts from W3C (http://www.w3.org/TR/webrtc/#identity ) and IETF (http://www.ietf.org/id/draft-ietf-rtcweb-security-arch-10.txt). We assume Alice and Bob Identities, including the MessagingStub URL, are asserted by using their own domain IDP or some 3rd party IDP.

      Since WebRTC Identity related functionalities are still not implemented by browsers, we have just used a simple IDP javascript class to handle all Identity management related aspects including the instantiation of an Identity. As soon as the standards, mentioned above are finalized and fully implemented, I’m expecting the browser to natively support Identity management functionalities.

      So, at the end this means, “signaling on-the-fly” does not directly address identity management issues but attempts to be compliant with on-going standardisation activities on this domain, mainly by extending RTCIdentityAssertion to also include the assertion of MessagingStubs. Users Authentication should be done outside “signaling on-the-fly” procedures which are agnostic of the IDP and authentication protocols used.

      The “signaling on-the-fly” only applies WebRTC principles to truly support inter-operability between any WebRTC Application. Lets take as example, a Portugal Telecom WebRTC single-page application featuring presence enriched contact list and audio and video conversations. The “signaling on-the-fly” enables to have in my contact list identities from other domains (eg Google Hangout subscribers) and to setup conversations with them without leaving my web app, ie keeping the user experience designed by my service provider.

      What does it imply? To have a *standard signaling API* used by WebRTC Applications that is able to dinamicaly select and use different signaling protocol stacks according to the domain the peer belongs to i.e. signaling on-the-fly”.

      I hope it is more clear now.

      PCh

  2. Can you help me to understand how WONDER facilitates in setting up “conversations without leaving the web app”. I follow that user can click on the name in the web app’s address book. Subsequent to that the user experience for that session will be determined by the called domain, no? For example, if the called domain is mine, then you will get a pop up text chat window, where both sides have to further agree to which mode to use and only then the media path is setup. Admittedly, another implementation would be different. Still it is likely that in some conversations, the initiators may not be continue to use the same UI/UX provided by their SPs.

    Am I missing something?

  3. Hi

    The dialog user experience for the conversation setup should always be set by your service provider. When you decide to setup a conversation with someone from other domain, you will use the “standard” signaling on the fly API to send your offer: MessagingStub.sendMessage(invitation). The invitation message is described in JSON plus the needed SDP collected from the PeerConnection. Then, the MessagingStub will handle this message and translate it, if needed, to something else (eg SIP INVITE message) according to the signalling protocol used by the remote peer (assuming the remote peer is the conversation host).

    Currently, we are mixing JSON and SDP but hopefully, with ORTC, we will use pure JSON.

    Did I answer your question?

Leave a Reply

Your email address will not be published. Required fields are marked *