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

Christer Holmberg <> Fri, 23 September 2011 10:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69AA921F8A62 for <>; Fri, 23 Sep 2011 03:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.531
X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xecI5Oc2dAao for <>; Fri, 23 Sep 2011 03:47:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3E48B21F8531 for <>; Fri, 23 Sep 2011 03:47:43 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-71-4e7c64688737
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B8.40.20773.8646C7E4; Fri, 23 Sep 2011 12:50:16 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Fri, 23 Sep 2011 12:50:15 +0200
From: Christer Holmberg <>
To: Hadriel Kaplan <>
Date: Fri, 23 Sep 2011 12:50:14 +0200
Thread-Topic: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
Thread-Index: AQHMebluA6nZhH7+dkWMXmflLs0yGJVaxZmA
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
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 10:47:44 -0000


>> 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.

Sure, you can control the offer/answer. My point was that it would be good if everyone had a common understanding on how the offer/answers will be controlled.

But, of course, as long as the JS app and the network application is provided by the same provider, things would work.

> 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.

I agree that we somehow need to support forking, meaning that we on the signalling level need to be able to handle multiple early dialogs.

On the media plane, we also need to be able to switch from one remote media source to another, but the question is still whether the browser, and the PeerConnection API, needs to support *simultanous* media from multiple remote sources.

> 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?

Yes, and I am not suggesting anything like that :)

>>  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.

I am not sure I understand what you mean by the browser being the SDP offer/answer engine.

Just because we would use offer/answer between the browser and the JS app, it doesn't mean we have to support multiple dialogs on that interface.

>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.

ICE is one of the impacts that we would need to consider, because what might happen is that when you switch from one remote media source to another everything (ICE, media security etc) is lost.

...unless, of course, the gateway relays all media, and handles the switching between remote media sources.