Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
Christer Holmberg <christer.holmberg@ericsson.com> Sat, 19 July 2014 18:59 UTC
Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BADF1B2A73; Sat, 19 Jul 2014 11:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kv9b58s9ELJ6; Sat, 19 Jul 2014 11:59:05 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD241B2A29; Sat, 19 Jul 2014 11:59:03 -0700 (PDT)
X-AuditID: c1b4fb3a-f79a36d000000ffa-a0-53cabff562de
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7A.CD.04090.5FFBAC35; Sat, 19 Jul 2014 20:59:01 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Sat, 19 Jul 2014 20:59:01 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "kiran.guduru@samsung.com" <kiran.guduru@samsung.com>, "rtcweb-request@ietf.org" <rtcweb-request@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
Thread-Index: AQHPo1ZRB4ao1PZKb02IVbig7HO8LZunv/+Q
Date: Sat, 19 Jul 2014 18:59:00 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3CB4E6@ESESSMB209.ericsson.se>
References: <58.C9.03708.ACAD9C35@epcpsbgx1.samsung.com> <53CA7426.6030602@alum.mit.edu>
In-Reply-To: <53CA7426.6030602@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvje7X/aeCDTqWmFucbHzLYrFiwwFW i5sTtrBZrP3Xzu7A4vH3/QcmjyVLfjJ59G1ZxRjAHMVlk5Kak1mWWqRvl8CV0bP7AlvBVZeK 0209zA2MU0y7GDk5JARMJBac/MACYYtJXLi3nq2LkYtDSOAoo8TmfedYIJxFjBJ3Lh5n7mLk 4GATsJDo/qcNEhcR2Mso8WH9KyaQbmEBS4kTr86D2SICVhK/G9czQthGEsf774LZLAKqEivX /2MHsXkFfCXW3G9jA7GFBKIkNu/pALM5BXQknk3vZQWxGYEu+n5qDdhMZgFxiVtP5jNBXCog sWTPeWYIW1Ti5eN/rBC2ksSi25+h6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzkIydhaS lllIWmYhaVnAyLKKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzCODm75bbWD8eBzx0OMAhyM Sjy8CxJOBguxJpYVV+YeYpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkYH V8am6RffJk8/N3Wr99PYPl3zGMF+o71Wus5rXksz57v9kC02OyXdaLiBq7ChU/5Ef9Ub+Uru tG+/PJ898l7xTDdc6IG0+LnD1Va5yyMPuJ37ITnlm0PWY0X5yfMWPvKdY/v53S23c+dmnOmf vGZJyBLfk5PnZxh8+Hbwn8S8XvslnCnXV5QosRRnJBpqMRcVJwIAVA0zx4QCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/amDodMMUMCy8ZPROpihmsCZmHJo
Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 19 Jul 2014 18:59:07 -0000
Hi, >My need won't be satisfied by plausible constraints. >For instance, to interwork with CLUE it will be necessary to add an "a=group:clue" and include in it >those m-lines that are to be "clue controlled". And that is needed in both offer and answer >processing. I agree with Paul. The same applies if someone implements an JavaScript IMS client, in which case the JavaScript app very likely will add stuff to SDP. Regards, Christer On 7/18/14 10:41 PM, Kiran Kumar Guduru wrote: > Dear Paul, > > My comment is only regarding the comments on section 6 of the JSEP draft. > > The sdp mangling described in section 6 may result in various error > scenarios. > > In that section, it is described like most of the parameters can be > modified thorugh constraints. > > The required modification, I found, which cannot not be done by the > constraints is "Remove or reorder of codecs (m=)" > > In order to avoid the SDP mangling at Java Script application level, I > submitted a draft for changing the codec preferences > http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01. > (Please review it). > > If this proposal is acceptable to the group, I hope we can remove > section 6 from JSEP draft. > > (Expecting that we can find alternatives for adding extra attributes > like CLUE as identified by you, for example by extending the proposed > RTCRTPSender/Receiver by adding a generic setSdPAttribute (key, > value) method). > > Thanks, > > Kiran. > > > > -------Original Message-------- > Sent: Paul Kyzivat > Date: Fri, 18 Jul 2014 14:32:24 -0400 > Subject: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 > > I just did my first thorough read-through of JSEP in quite some time. > I came away with a number of concerns: > > Section 1.1: > > When describing offers, modification by the application is mentioned: > > JSEP's handling of session descriptions is simple and > straightforward. Whenever an offer/answer exchange is needed, the > initiating side creates an offer by calling a createOffer() API. The > application *optionally modifies that offer*, and then uses it to set > up its local config via the setLocalDescription() API. > > but when describing answers it is not: > > When the call is accepted, the callee uses the createAnswer() API to > generate an appropriate answer, applies it using > setLocalDescription(), and sends the answer back to the initiator > over the signaling channel. When the offerer gets that answer, it > installs it using setRemoteDescription(), and initial setup is > complete. > > And Section 6 only talks about changing offers, not answers. It is > equally important to be able to modify answers. (More on this in later > comment on section 6.) > > Section 4.1.4: > > The only difference between a provisional and final answer is that > the final answer results in the freeing of any unused resources that > were allocated as a result of the offer. As such, the application > can use some discretion on whether an answer should be applied as > provisional or final, and can change the type of the session > description as needed. For example, in a serial forking scenario, an > application may receive multiple "final" answers, one from each > remote endpoint. The application could choose to accept the initial > answers as provisional answers, and only apply an answer as final > when it receives one that meets its criteria (e.g. a live user > instead of voicemail). > > Issue: in this forking case, until the final selection is made it is > unclear which one will need ICE completed. Only when a setlocal is > done on one of the answers will ICE begin to be performed. Then, if > another answer is provisionally set, won't that stop ICE for the prior > one? And won't it require new candidates? What if one of the earlier > ones is eventually chosen as final? > > And what if ICE completes for one of the candidates? Can't media start > to flow? Then what if a different candidate is set as the final answer? > > Section 4.1.4.1: > > I question the following: > > ... While it is good practice to send an immediate > response to an "offer", in order to warm up the session transport and > prevent media clipping, the preferred handling for a web application > would be to create and send an "inactive" final answer immediately > after receiving the offer. Later, when the called user actually > accepts the call, the application can create a new "sendrecv" offer > to update the previous offer/answer pair and start the media flow. > > This is very unfriendly when receiving calls that might be forked. By > immediately "answering" a call before knowing if the user will accept > it, you preempt the possibility that it will be answered on some other fork. > > For instance, if a call could come to your browser, or be sent to an > answering service, and your broswer is on but you aren't present to > accept the call, then the call will be accepted and then dropped > rather than sent to the answering machine. > > So this technique should not be used if there is any possibility that > the request could be coming from a source that might try other > possibilities. > > Section 5.2.1: > > When createOffer is called for the first time, the result is known as > the initial offer. > > By this definition, if a peer connection initially *received* an offer > and sent an answer, and then it later sends an offer then that offer > would be considered an initial offer. > > I think perhaps what is intended is: > > When createOffer is called before setLocal has been called with > an offer, the result is known as the initial offer. > > The following doesn't support the "balanced" BUNDLE policy: > > Once all m= sections have been generated, a session-level "a=group" > attribute MUST be added as specified in [RFC5888]. This attribute > MUST have semantics "BUNDLE", and MUST include the mid identifiers of > each m= section. The effect of this is that the browser offers all > m= sections as one BUNDLE group. However, whether the m= sections > are bundle-only or not depends on the BUNDLE policy. > > Section 5.2.2 says: > > o If any MediaStreamTracks have been added, and there exist recvonly > m= sections of the appropriate media type with no associated > MediaStreamTracks, or rejected m= sections of any media type, > those m= sections MUST be recycled, and a local MediaStreamTrack > associated with these recycled m= sections until all such existing > m= sections have been used. This includes any recvonly or > rejected m= sections created by the preceding paragraph. > > This fails to say anything about codec compatibility. SDP O/A requires > the answer to be a subset of the offer in terms of PT/codec > configuration. You should not use the same m-line unless there is a > desire to use the same settings for the new track as are currently in > use in the other direction. > > Section 5.3.1: > > When createAnswer is called for the first time after a remote > description has been provided, the result is known as the initial > answer. > > By this definition, if a peer connection initially sent an offer and > received an answer, and then it later receives an offer then the > answer to that first *received* offer would be considered an Initial Answer. > > I think perhaps what is intended is: > > When createAnswer is called before setLocal has been called with > an offer, the result is known as the initial answer. > > When specifying the mapping of local tracks to m-lines in a received > offer, there is again no discussion of codec compatibility. It is > quite possible that the m-line chosen by the algorithm in this section > won't have compatible codec attributes, but some other m-line will. > > Sections 5.3.2, 5.3.3, and 5.4-5.7: > > Are these empty because the content is yet to be written? > > Section 6: > > Other likely changes are addition of extra attributes and maybe other > parameters. For instance, CLUE will want to add another grouping construct. > > Thanks, > Paul > > _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Paul Kyzivat
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Kiran Kumar Guduru
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Paul Kyzivat
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Christer Holmberg
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Kiran Kumar Guduru
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Kevin Dempsey
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Justin Uberti
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Christian Groves
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Justin Uberti
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Paul Kyzivat
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Paul Kyzivat
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Stefan HÃ¥kansson LK
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Justin Uberti
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Paul Kyzivat
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Justin Uberti
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Paul Kyzivat
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Justin Uberti
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Paul Kyzivat
- Re: [rtcweb] Review of draft-ietf-rtcweb-jsep-07 Jonathan Lennox