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

Hadriel Kaplan <> Fri, 23 September 2011 06:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C59AB21F8A71 for <>; Thu, 22 Sep 2011 23:21:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.529
X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6e58dVtt6tJ1 for <>; Thu, 22 Sep 2011 23:21:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1075C21F8B2B for <>; Thu, 22 Sep 2011 23:21:49 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 23 Sep 2011 02:24:21 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Fri, 23 Sep 2011 02:24:21 -0400
From: Hadriel Kaplan <>
To: Christer Holmberg <>
Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
Thread-Index: AQHMebluA6nZhH7+dkWMXmflLs0yGA==
Date: Fri, 23 Sep 2011 06:24:21 +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: Fri, 23 Sep 2011 06:21:50 -0000

On Sep 23, 2011, at 1:06 AM, Christer Holmberg wrote:

> Sure, but it would be good if network applications, that provide the early media, could make assumptions on how the end user is going to process it. It would make life easier both for the network application designer and the client application designer - AND the SBC designer, btw, if the SBC will have to make decisions on which media to forward towards the user :)

If the "network application" you're talking about is provided by the same domain that runs the rtcweb server, then obviously they can "control" it, since they wrote the JS script.

If you're talking about when rtcweb domain A calls SIP/rtcweb domain B, and domain B wants to control it, then obviously they can because domain B can use an SBC, or control the offer/answer and media on their side some similar way, and we don't need to say anything about that.

But that wasn't my point... the discussion was around whether the rtcweb system as a whole (browser or browser+JS) had to be able to support media forking cases, or not.  And my point was yes, they do, because if they talk SIP to domain B then they cannot *mandate* B not media fork calls, because that's like mandating B not send re-INVITEs.  It's part of basic SIP, part of its base spec.  Even from a practical standpoint it's not something imaginary like S/MIME; media forking happens in practice all the time.

Obviously my employer would be better off if SBCs were mandated for all SIP communications, but it's not right to require them in an IETF spec/architecture.  People should use them if they have a need to, not just because browsers are too lazy to handle real SIP scenarios. 

Imagine if Google deployed rtcweb, and Columbia University deployed a SIP service for all their students, with multiple contacts, forking, etc.  Columbia goes to Google and says "can we peer using SIP"?  And Google says "sure, but you'll have to deploy something to hide media forking, re-INVITEs, etc."  Columbia says "but I thought you guys peer with SIP?" and Google says "oh we do, but it's a lighter SIP granted to us by the IETF, because we use browsers".  Do you see how crazy that would be?

> The browser doesn't need to keep state - it only does what the JS app tells it to do. 
> But, the JS app needs to keep state, so that it can then provide the SDP answer associated with Bob to the browser when the 200 OK comes.

I'm with you there, but methinks we've lost that battle already.  The browser's going to be the SDP offer/answer engine, so now I'm at least hoping it's a real/full one and not some hybrid.

As a side note, I'm not actually sure what would happen to ICE processing with peers if the browser only has one media state at a given time, and switches from Robert's SDP to Bob's and back to Robert's.  Someone should try it with the chromium prototype, in different timing scenarios.  Like what happens if the browser's ICE to Robert gets to a completed state, then the browser switches to Bob, and later back to Robert and the browser thinks ICE starts again with Robert but Robert thinks it's over.