[rtcweb] Question about JSEP createOffer

"Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> Sun, 06 May 2012 18:40 UTC

Return-Path: <richard.ejzak@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 517D921F8549 for <rtcweb@ietfa.amsl.com>; Sun, 6 May 2012 11:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.932
X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id h-WeRDhriFkh for <rtcweb@ietfa.amsl.com>; Sun, 6 May 2012 11:40:37 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com []) by ietfa.amsl.com (Postfix) with ESMTP id 26BF921F8548 for <rtcweb@ietf.org>; Sun, 6 May 2012 11:40:36 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com []) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q46IeXV7004410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <rtcweb@ietf.org>; Sun, 6 May 2012 13:40:33 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com []) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q46IeXiK029483 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <rtcweb@ietf.org>; Sun, 6 May 2012 13:40:33 -0500
Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([]) with mapi; Sun, 6 May 2012 13:40:33 -0500
From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Sun, 06 May 2012 13:40:31 -0500
Thread-Topic: [rtcweb] Question about JSEP createOffer
Thread-Index: Ac0rt7b2MPjJPIJiSxe9o1wlRksHCA==
Message-ID: <6F428EFD2B8C2F49A2FB1317291A76C11364EC0288@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_6F428EFD2B8C2F49A2FB1317291A76C11364EC0288USNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
Subject: [rtcweb] Question about JSEP createOffer
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 May 2012 18:40:38 -0000

I have a question about something I came across in the JSEP draft.

6.1.2 of JSEP draft 0 has the following text regarding "createOffer":

   As an offer, the generated SDP will contain the full set of

   capabilities supported by the session (as opposed to an answer, which

   will include only a specific negotiated subset to use); for each SDP

   line, the generation of the SDP must follow the appropriate process

   for generating an offer. In the event createOffer is called after the

   session is established, createOffer will generate an offer that is

   compatible with the current session, incorporating any changes that

   have been made to the session since the last complete offer-answer

   exchange, such as addition or removal of streams. If no changes have

   been made, the offer will be identical to the current local


The first and last sentences might conflict if the SDP Answerer later wants to create a new Offer.  The local configuration based on the first offer/answer will contain only the selected media configuration, whereas it is desirable for the new Offer to contain the full set of capabilities of the (new) Offerer.  I think this text needs to change to reflect this case.  Am I missing something?