Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

Christer Holmberg <> Fri, 05 October 2012 07:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 848F421F8602 for <>; Fri, 5 Oct 2012 00:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.11
X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dzK7J-cvlnV4 for <>; Fri, 5 Oct 2012 00:39:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 269E321F85F3 for <>; Fri, 5 Oct 2012 00:39:18 -0700 (PDT)
X-AuditID: c1b4fb2d-b7fea6d000002ccb-e6-506e8ea53926
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 80.CC.11467.5AE8E605; Fri, 5 Oct 2012 09:39:18 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Fri, 5 Oct 2012 09:39:18 +0200
From: Christer Holmberg <>
To: Martin Thomson <>
Date: Fri, 5 Oct 2012 09:39:16 +0200
Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules?
Thread-Index: Ac2iYDVKE9KFhrq+Ri+b5tNOgTV0GwAAPI1f
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: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre6yvrwAg5kreC2O9XWxWVw784/R Yu2/dnYHZo8rE66weuycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGV82LGUsOCZW0TJZqoHx pmAXIyeHhICJxMq+nawQtpjEhXvr2boYuTiEBE4xSnyc+wzKmc8o0XrhO0sXIwcHm4CFRPc/ bZAGEQFdiUVnH7CD2MwCwRK9XZPBBrEIqEi8PXCbBcQWFjCW6Px8jAmi3kRizY41LBC2kcSZ nnmMIDavQLjE15U3WSF2bWCR+HLgKBtIglMgUOLvzTVgRYxA130/tYYJYpm4xK0n85kgrhaQ WLLnPDOELSrx8vE/Voh6UYk77esZIep1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis1CMnYW kpZZSFpmIWlZwMiyilE4NzEzJ73cUC+1KDO5uDg/T684dRMjMJ4Obvmtu4Px1DmRQ4zSHCxK 4rxcSfv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXAC40K49GaFi8YOywlhcmdeW39yXb+4o685 vq5coi4q5OWTGOZv+/wF/1u/yXlS/K2tx/rmoufOf/fEFTptzJyY4qx/XiPZdBpHoWxM4Wu1 LTMXH9CV3Hl4wiGh01KRe0u3bdC6bFP/k0mX4/mXyKr41IlpR1OsM/Rr5RKPSTXb5MXoH0s5 MuGLjBJLcUaioRZzUXEiAFMrEtB1AgAA
Cc: "" <>
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?
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, 05 Oct 2012 07:39:24 -0000


>> I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking.
> Not my point.  My point is that the desired functionality (apply the
> answer without invalidating the offer) cannot be easily provided using
> SDP O/A.  Most scenarios leave the possibility that the offerer sends
> the (provisional) answerer stuff that the answerer doesn't want.
>> If you want to support parallel forking, you need to be able to simultanously perform ICE etc with all remote peers.
> Right.  You can almost get that by pretending that it's just one
> remote peer with lots of candidates.  You can at least get to the
> consent point by doing that.  But you aren't going to nominate more
> than one pair.  Similarly, this will only generate a single DTLS
> session.

I was thinking about the same once, but I think I found some issues (unfortunately they don't come to my mind at the moment).

But, it's for sure an alternative we could look into.

That would allow ICE to take place during the early session, but media might be more tricky - unless you also add the m- lines of each remote peer to the "pretended" single peer.

> Media is a complete mess if you manage to get that far.  Unless you
> like scenarios were A and hear B and C, but B and C can't hear each
> other and other such joys (there's a consent issue too, but it's a
> minor issue of scale).
>>>Both of these complicate the API significantly.  I'd rather see the
>>>complexity pushed to the applications that need this complexity.
>> I want to be able to support forking. Exactly HOW it's done can be discussed.
> One approach is to create as many RTCPeerConnection objects as you
> feel might be needed.  Then it becomes YOUR problem, not our problem.
> And those are the sorts of problem I like ;)  (I might be interested
> in forking too, but I'm happy to keep my problems private.)
>> Also, I can live without support of parallel forking, and I don't really care if serial forking support is provided using cloning or being able to update the remote descriptor (using PRANSWER, or something else).
> Serial forking is potentially far easier to support by doing a series
> of O/A exchanges:
> 10: setLocal(offer)
> 20: get next answer
> 30: setRemote(answer)
> 40: goto 10
> There's the small matter of having no guarantee that the offer will
> set successfully, but I'd consider that an unlikely scenario in
> practice.

Can I use the same local descriptor for every setLocal() call?

>>>That is, unless you are willing to consider a better API that makes
>>>these issues SEP.
>> You have one in mind? ;)
> I am not at liberty to disclose that information.

Can you then at least tell me when I'll be able to buy the Microsoft Surface? :)