Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient]

Silvia Pfeiffer <> Thu, 08 September 2011 01:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6459421F8CD9 for <>; Wed, 7 Sep 2011 18:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0oGASuy9dsqa for <>; Wed, 7 Sep 2011 18:14:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7BB2621F8CAF for <>; Wed, 7 Sep 2011 18:14:15 -0700 (PDT)
Received: by gwb17 with SMTP id 17so359874gwb.15 for <>; Wed, 07 Sep 2011 18:16:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=g2IMd7YZznr/NZ2UJYBuPhHTNsqJpfHX2CyG/Any9Ks=; b=rjqZRUQTYqSpK8kqB39WpVMkSxB+w+ZqOaVr27WWq8/C5V14pjNYw3t0wdFVr5ZolX D7rqJRCf33fX/msuhwr1FCMsEQ/XYwbBzh2nCotJhld2YNH+ZKasxFWmTw3uGDCd9mYu VlSRh46ohC72lDGjZds2DDSSeCXmJp+3gHqrQ=
Received: by with SMTP id b61mr337228yhe.92.1315444566066; Wed, 07 Sep 2011 18:16:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 7 Sep 2011 18:15:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Silvia Pfeiffer <>
Date: Thu, 8 Sep 2011 11:15:46 +1000
Message-ID: <>
To: Matthew Kaufman <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] SIP MUST NOT be used in browser?[was RE: Remoterecording - RTC-Web client acting as SIPREC session recordingclient]
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: Thu, 08 Sep 2011 01:14:16 -0000

If implementations count for anything, check out:

They use SIP with web sockets.


On Thu, Sep 8, 2011 at 8:30 AM, Matthew Kaufman
<> wrote:
> On 9/7/11 12:20 PM, Randell Jesup wrote:
>> I also started from the same point - assume SIP.  SIP gives you all the
>> things that the zillions of hours and emails to define it and define
>> extensions and secure it provides, without having to reinvent all those
>> wheels (or ask app developers to reinvent them).  Why go through the
>> horrible pain of choosing something else, or why throw the app developers to
>> the wolves to fend for themselves?
>> However...
>> Two things have swayed me.  The primary one is the suggestion of
>> Offer/Answer in the browser.  This breaks out the important negotiation
>> piece that almost any application would need, and while not perfect, SDP O/A
>> is a zillion times simpler than SIP with all the extensions one could use.
> I agree with this. While I am also opposed to SDP O/A, these are two
> unrelated arguments to have... and not baking a SIP phone into the browser
> is *more* important than avoiding a repeat of the offer/answer problems.
>> The other thing that swayed me was thinking about federation and the apps
>> that will be built with this.  A webrtc app talks to its (web)server, other
>> webrtc clients running the app that talk to the server, and to other webrtc
>> applications/networks that federate with it (and their clients).
>> Federation is in the same hands as the person who provides/wrote the app.
>>  If they have no interest in federation you can't force it, and they may
>> have no use for all the fancy SIP standards.
> And for numerous types of apps (think: server-based augmented reality
> systems), "federation" doesn't even make sense.
>> On the other hand, if they *want* to either provide access to the wider
>> communication net that is the PSTN network, now or in the future, or they
>> want easy federation with other networks, it behooves them to use SIP or
>> something very close to it or equivalent/convertible (at a basic level at
>> least) to it.
>> So what conclusions do I draw from this?
>> 1) O/A via SDP in the browser simplifies a lot of things (including
>> handling new codecs, etc).  It doesn't extremely limit an application,
>> though we should think about how an application can interact with the
>> fmtp/etc parameters used.
> I agree that it would simplify some interop cases, but at an unfortunate
> cost in lack of flexibility and functionality. Still not nearly as bad as if
> we put a full SIP stack in there though.
>> 2) SIP as a *separate* item that can be cleanly and easily *added* to a
>> webrtc app to handle the call setup/etc is a good idea.
> I would be open to looking at this again, *after* RTC is already in browsers
> and successful, to see if it actually solves a real use case.
> Matthew Kaufman
> _______________________________________________
> rtcweb mailing list