Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism

Hadriel Kaplan <> Thu, 22 September 2011 14:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3754321F8BFE for <>; Thu, 22 Sep 2011 07:02:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.526
X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zru2UccxtcVG for <>; Thu, 22 Sep 2011 07:02:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7062521F8BC5 for <>; Thu, 22 Sep 2011 07:02:15 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 22 Sep 2011 10:04:46 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 10:04:46 -0400
From: Hadriel Kaplan <>
To: Cullen Jennings <>
Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
Thread-Index: AQHMeTCVYKm8GHKucEylDB38nl0SPA==
Date: Thu, 22 Sep 2011 14:04:45 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" <>
Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
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, 22 Sep 2011 14:02:16 -0000

On Sep 22, 2011, at 9:17 AM, Cullen Jennings wrote:

> I'll note that Cary and my draft has been putting serious limitation on SIP since the beginning and we have yet to receive a comment on that. You do realize the outcome of this decision would be that you needed an SBC between the SIP to WEB Gateway and any SIP network that forked so that SBC could isolate the other side from the forks. As full disclosure, really, I don't own any ACME stock :-) 

Oh, I think we'll be busy enough. ;)

Choosing the right fork is really hard. (or so it seems when I sit down at fancy restaurants)

> Clearly one could support forking in the browsers and equally obviously, that complicates things fairly significantly. The question will be if the complexity is worth the end user gain in functionality. 

Ignoring the issue of not being SIP anymore, I think you'll want forking in the end.  Even in XMPP people have asked for it now and then.

But anyway sorry I didn't read Cary and your draft before.  Would you like comments now?  :)
First, I assume you mean draft-cbran-rtcweb-protocols-00.

You have the following as optional:
   o  INVITEs without an offer
   o  re-INVITEs
   o  forking
   o  S/MIME
   o  SIPS URI Scheme

My comments:
S/MIME has never seen the light of day and would be removed if we ever raised 3261 to the soon-to-be-second-and-final level of maturity, so sure.
INVITEs without offers can be ignored in terms of generating them from rtcweb, but rtcweb has to be able to receive them. (I would think Cisco in particular would demand this ;)
Re-INVITEs again may not need to be generated by rtcweb, but have to be able to be received. (it's not hard is it?)
Forking is needed to eat our own dogfood with.
SIPS is sadly rare, but ironically I would think the rtcweb model is one we'd actually want and use it in (because we could require HTTPS be used, and it probably would even happen!).

Last comment: you gave me a good chuckle, making 4474/4916 required.  :)