Re: [rtcweb] WebRTC service between SPs

<> Mon, 01 July 2013 15:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5134111E811F for <>; Mon, 1 Jul 2013 08:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 52kg3Nv4OWGx for <>; Mon, 1 Jul 2013 08:00:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8195911E80D7 for <>; Mon, 1 Jul 2013 08:00:37 -0700 (PDT)
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 01 Jul 2013 17:00:35 +0200
Received: from HE111644.EMEA1.CDS.T-INTERNAL.COM ([]) by ([::1]) with mapi; Mon, 1 Jul 2013 17:00:35 +0200
Date: Mon, 01 Jul 2013 17:00:34 +0200
Thread-Topic: [rtcweb] WebRTC service between SPs
Thread-Index: Ac50szvNguxJUjrOSEG4KWKY26t8fQBtu+4w
Message-ID: <AAE428925197FE46A5F94ED6643478FEAC99A4C7C6@HE111644.EMEA1.CDS.T-INTERNAL.COM>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: de-DE
Content-Language: de-DE
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_AAE428925197FE46A5F94ED6643478FEAC99A4C7C6HE111644EMEA1_"
MIME-Version: 1.0
Subject: Re: [rtcweb] WebRTC service between SPs
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Jul 2013 15:00:44 -0000

If your WEBRTC service accepts 3rd party auth from Google, FB, Twitter, a *lot* of people can use it and you don't have to worry about
legacy interconnection concepts using SIP or XMPP. There is no longer the need for a single, global signalling protocol that covers all possible use-cases. We only need a way to authenticate callers, and perhaps their URL to reach them for a return call. Both can be done with 3rd party authentication protocols. Today.

Wolfgang Beck

Deutsche Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Wolfgang Beck
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 581 2832 (Tel.)<>

Erleben, was verbindet.

Deutsche Telekom Technik GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft Bonn
USt-IdNr. DE 814645262

Von: [] Im Auftrag von Barry Dingle
Gesendet: Samstag, 29. Juni 2013 12:27
An: Wangyahui (Yahui)
Betreff: Re: [rtcweb] WebRTC service between SPs

I had assumed that a DNS NAPTR record could be used to provide all the alternate "user id's". Am I right?


Barry Dingle
Fixed - +61(0)3-9725-3937    Mob - +61(0)41-911-7578
Fellow of University of Melbourne, Electrical and Electronic Eng., Australia
> Linux + Android + Apple + Open Source software

On Sat, Jun 29, 2013 at 7:29 PM, Wangyahui (Yahui) <<>> wrote:
Thanks for your comments.
Yes, we can implement the federation between SPs through using the same signaling protocol (e.g. SIP) or deploying a gateway.

But what I concern is how to compatible with the existing various user id from different SPs. For example, if Google provides WebRTC client, then the users should be able to login using their Gmail address. In the same way, Facebook support the users using FacebookId. So the format of identification may be number, string or email and so on.

The problem is how to handle addressing users of different SPs. Should it be standardized to a unified WebRTC URI?


发件人: Hrishikesh Kulkarni [<>]
发送时间: 2013年6月29日 14:18
收件人: Moises Silva
抄送: Jim Barnett; Wangyahui (Yahui);<>
主题: Re: [rtcweb] WebRTC service between SPs

SIP is an established standard to interoperate domains. We at developed a video/audio bridging service for WebRTC. Although it uses JS/JSON signaling for web based clients. Our server could very well federate with any other service using SIP. What does need to be discussed on app to app basis is what kind of federation you are looking for?
In case of bridging service we could merge calls from both servers or redirect all the calls to the host service.


On Fri, Jun 28, 2013 at 11:55 PM, Moises Silva <<>> wrote:

On Fri, Jun 28, 2013 at 12:03 PM, Jim Barnett <<>> wrote:
As I understand it, it’s not just a problem of identities.  WebRTC does not define the signaling protocol, but leaves it  up to the application.  If two users download their applications/JavaScript from the same site, it won’t be a problem, because the same application is handling both ends of the call.  But if one user is on site A while the other is on site B, there is no guarantee that either site’s application will understand the signaling from the other.

Unless websites agree to use something standard such as SIP/Jingle for federation (inter website/domain communication).


rtcweb mailing list<>

rtcweb mailing list<>