Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)

Christer Holmberg <> Fri, 20 September 2013 22:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3211A21F9E8D for <>; Fri, 20 Sep 2013 15:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.685
X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=0.564, 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 QC0-mWkUvKjU for <>; Fri, 20 Sep 2013 15:17:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 671F921F9A1C for <>; Fri, 20 Sep 2013 15:17:28 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-42-523cc9771d37
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E4.A0.03802.779CC325; Sat, 21 Sep 2013 00:17:27 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Sat, 21 Sep 2013 00:17:27 +0200
From: Christer Holmberg <>
To: "Cullen Jennings (fluffy)" <>
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: AQHOti5khdNmMeesKEOgz91K2tbZBJnPLVCA
Date: Fri, 20 Sep 2013 22:17:26 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+JvjW75SZsggxd/TS06JrNZrP3Xzu7A 5DHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZXzvf8xYMEGq4szn60wNjN+Euxg5OSQETCQe nTrNBmGLSVy4tx7I5uIQEjjMKLG6dz47hLOEUWLq5Y+sXYwcHGwCFhLd/7RBGkQEDCWa9sxj ArGZBdQl7iw+xw5SIiwQLfHgdhlESYzErvNfWEDCIgJGEotn8oOYLAKqEvvuK4JU8Ar4Srxa dxpq6wRGifaPF5hBEpxAia/r/4Odxgh02vdTa6A2iUt8OHidGeJkAYkle85D2aISLx//Y4Ww lSQalzxhhajXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDYLydhZSFpmIWmZhaRlASPLKkb2 3MTMnPRyo02MwOg4uOW36g7GO+dEDjFKc7AoifNu1jsTKCSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoHRkCU3eBNf47bJco1T4r7Hpsydpie8dVrVPPX98761G+xrahZcvN9iY2/U0jxhJa3s E/NVHSZdWqDuHGUsuNownudfcrnBce6ON9zl52pOTZsRZH9J6ViBptfPW/vtKmbMvVtee3h6 wofNk9vrqmStLlTMWsk22eGR584O23MJx84/l2/Z1vdGiaU4I9FQi7moOBEAFED71lwCAAA=
Cc: "" <>
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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, 20 Sep 2013 22:17:37 -0000

Hi Cullen,

>> Q_2:      o- line <sess-version> initial value - forking
>> When a new PeerConnection is created due to forking, the <sess-version> value must be based (incremented) on the value associated with the "mother" PeerConnection, for which the initial Offer of the whole communication session was created.
> uh, that is old text sorry. I'm proposing the principal that any time the SDP changes (including new candidate lines) the version gets larger. 

Yes. But keep in mind that this is an Offer created for a new PeerConnection. 


>> Q_4:      BUNDLE
>> The text says:
>> "If a m= section is not being bundled into another m= section, it MUST
>>                generate a unique set of ICE credentials and gather its own set of
>>                candidates.  Otherwise, it MUST use the same ICE credentials and
>>                candidates that were used in the m= section that it is being bundled
>>                into."
>> As, when BUNDLE is used, the initial Offer will contain identical ICE candidates, does that mean that we will also include identical address information in the initial Offer?
> no the initial offer will not have identical stuff other than on lines that "bundle-only" and we still need to add more text on this but idea is to make just like what is in united-plan

Regarding the details (usage of port zero etc) of "bundle-only", that is still something we have to agree upon. But, that discussion belongs to MMUSIC (and, I believe there is a thread about that already :)

But again, in the case of forking, when a new PeerConnection is created, I think we should allow identical stuff in the initial Offer of that PeerConnection. Because, the remote party has already indicated support of BUNDLE, in the Answer that was sent for the "mother" PeerConnection, so the initial Offer for the new PeerConnection will be the second Offer for the remote party.

At some point, we are going to have to add much more details about forking, in the case multiple PeerConnections are used. It is not enough to only say "create a new PeerConnection" :)


>> Section 5.2.2:
>> -----------------
>> Q_5:      Offer when in "local-offer"
>> The text says:
>> "If the initial offer was applied using setLocalDescription, but an
>>                answer from the remote side has not yet been applied, meaning the
>>                PeerConnection is still in the "local-offer" state, the steps for
>>                generating an initial offer should be followed,"
>> I don't understand this. Why would you create a new Offer while you are waiting for an Answer to the previously sent Offer?
> Justin has asked for this in the case when the offer has not been sent to anyone else. This is not going to be useful for typical systems trying to have SIP or Jingle compatible flow but who knows ...

Again, we have consensus to base JSEP on 3264. And, if we are going to deviate from 3264, I'd like to have some discussion and justification for that. 

I'd also have a section somewhere which summarizes *all* 3264 deviations that JSEP makes.