Re: [rtcweb] jsep 01 comments

Justin Uberti <> Fri, 27 July 2012 00:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FBFF21F85F2 for <>; Thu, 26 Jul 2012 17:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.352
X-Spam-Status: No, score=-102.352 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b+O0s9lPXuzT for <>; Thu, 26 Jul 2012 17:08:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F03DA21F85F1 for <>; Thu, 26 Jul 2012 17:07:59 -0700 (PDT)
Received: by qaea16 with SMTP id a16so1562508qae.10 for <>; Thu, 26 Jul 2012 17:07:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=ZKAccs3pff6WosHhNSaqosxNqdeZOtG388lYQKPdZFc=; b=HCl9zrRdonvu2/7liL+Vs3D+7dIq2pHQUK/zyegY1nPRR7zYp148csTFJIiLuSh0l7 cHUdDYMMu58/UeKtZ66LozZvBX1M2cVYnqUWtyN+CNzxE5mmT8VnaHAewqenf3ALK7jA bZy/l6v8mldOzVGTOAN9ckp/xkkQvHI6FUa3bg57X7gdKm4XTeg17Z7hb4N8X+TnKxgL OL/DyyPOppwclE3lOkeSOGht/W/TdJIu3mIj8oZdWKyw34TnkL7LhAkrECM0G4ze/HAA J6oFZCUqqDItJt8Ttgxxq7x3+LL9vowaiec6P0+b40xgp38rVqVdPj/vnfeH3Tm1tPiA 7iHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=ZKAccs3pff6WosHhNSaqosxNqdeZOtG388lYQKPdZFc=; b=OUiUh9zdOCpZll5xkllOJZTDH0teZ2I+3IKqJelLqop/a9P5d6br0ESOaEfpVBy+4I dz0MO0L6f7dmhSMpJt69m3UgwrRaaSIlunfvRpWEM+btkZbeA1sxI7YfWAwzXwn+3Wmj lJ7hInLWxzu8BJ94JVeRNdE3XmNjCQgAWw8oeXv6oTf+dxjmSatZeAHeHrWvqy7e7vXh 7xwvf5rLHIFuzFEvC2tWdNEGOwifHOy4rgBz3pav7Pg4CVog5dKmDG/9XEdbZv5Js2Om GL1MA5Zeem5oPdsNGCJGECXLPWI0SEbtPk/v8UUFnuH+aG7KJ5lru5/ZsVnzq6v6aj9u tGfA==
Received: by with SMTP id k10mr291621qct.71.1343347679183; Thu, 26 Jul 2012 17:07:59 -0700 (PDT)
Received: by with SMTP id k10mr291616qct.71.1343347679034; Thu, 26 Jul 2012 17:07:59 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 26 Jul 2012 17:07:38 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Justin Uberti <>
Date: Thu, 26 Jul 2012 17:07:38 -0700
Message-ID: <>
To: "Ejzak, Richard P (Richard)" <>
Content-Type: multipart/alternative; boundary=00248c71181537fe6004c5c481f9
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmL6Zrdla7ywvvfOT7yvqZZXfj/YEWnPMR96Ojum2CjNhDlO28iHsF0u4kwvTAr/k0qGIfwNFJgNQp8itqwotk45fz+PQOx+Ccg+TCGVvQG2Cp+vAJ+1tMEN4ekIHgSI69ye5IC3ev1I5Q39F8KHL0aLbEPA0fHP52krieuM4oDBlaljfo=
Cc: "" <>
Subject: Re: [rtcweb] jsep 01 comments
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, 27 Jul 2012 00:08:01 -0000


Thanks for your detailed review. I've been preoccupied with vacation and
relocation, but we'll work on addressing these comments shortly.

On Thu, Jul 5, 2012 at 12:42 PM, Ejzak, Richard P (Richard) <> wrote:

>  I agreed to review jsep 01 during the interim.  Please see my comments
> below against version 01 of the jsep draft.****
> ** **
> In the paragraph before figure 2 in section 4.2, the text justifies the
> notion of multiple outstanding offers and answers based on RFC 3264.  This
> is incorrect.  RFC 3264 very clearly describes (in section 4) how each
> offer cannot be updated until an answer is received and that an answer is
> final.  This should be made clear in jsep.  The actual justifications for
> multiple outstanding offers and answers should be made clear and their use
> within the context of RFC 3264 needs to be made clear.  Specifically within
> the context of SIP, there is no justification or support for multiple
> offers, and the only justification for multiple answers is to provide a
> limited mechanism for dealing with some SIP forking cases.****
> ** **
> The 2nd paragraph of section 4.5 should make clear that XMPP is an
> example application supporting the capability (ICE trickling) and SIP is
> not.****
> ** **
> In section 4.7, it should be made clear that SIP forking is being
> considered (with clear references) and any XMPP analogs, if they exist.
> Obviously section 4.7.2 should indicate cloning as a possible strategy to
> fully address parallel forking that is not currently supported.  The text
> should describe that in the absence of cloning ICE and DTLS may not begin
> until a “winning” target is selected, thus potentially delaying the start
> of media flow, whereas ICE and DTLS could occur in parallel were cloning
> supported.****
> ** **
> Section 4.8 needs updating.  It is not clear from the description if a new
> PeerConnection needs to be established (or how to re-establish the old one)
> and how to ensure that the new PeerConnection will be compatible with the
> old LocalDescription.  I think the description should say that
> PeerConnection is recreated using the old parameters and (reconstructed?)
> MediaStreams.  Something is also needed to describe how to ensure the
> continued availability of the old MediaStreams.  Rehydration will require
> end-to-end offer/answer to recreate the PeerConnection anyway, and I’m not
> sure of the value of attempting to reuse the old LocalDescription since it
> may not make sense to force some of the old attributes.  Some discussion of
> how to ensure this is needed if the concept of reusing the old
> LocalDescription (and MediaStreams) is retained.****
> ** **
> In section 5.1.1, the first paragraph describes createOffer the first time
> it is invoked but not necessarily its behavior for subsequent invocations.
>  The last sentence of the 2nd paragraph is inconsistent with the last
> sentence of the first paragraph under some circumstances.  The local
> description used to populate the offer once the session is established, but
> may come in three flavors (noting that an offerer may later become an
> answerer for the same PeerConnection and vice versa): 1) the local
> description set by the prior offerer before receiving a final answer (thus
> reflecting all supported codecs and capabilities according to the
> constraints); 2) the local description set by the prior answerer (thus
> reflecting only the selected codecs and capabilities); and 3) the local
> description set by the prior offerer but where createOffer occurs after
> receiving final answer to the previous offer (in this case the offer may
> include codecs and capabilities already released by the browser).****
> ** **
> The last paragraph of section 5.1.1 describes that in case 3) the offer
> should be modified to reflect the “current state of the system”.  It’s not
> completely clear if this is intended to describe the current resources
> allocated to the PeerConnection or the potential resources that could be
> allocated (i.e., the full set of available codecs and capabilities).  It is
> similarly unclear for case 2) if the offer is to be changed and how.****
> ** **
> The last sentence of the second paragraph of section 5.1.1 is also
> inconsistent with the last paragraph of the section and it is not clear
> which one takes precedence.****
> ** **
> This potential inconsistency in the behavior of createOffer is problematic
> to an application since the range of capabilities reflected in the SDP is
> state dependent.  The result of createOffer should not depend on whether
> the browser was previously offerer or answerer and it should be possible to
> request either current capabilities or the complete list of potential
> capabilities for each unchanged m line in the offer using the constraints
> parameter.****
> ** **
> I was asked during the interim to justify the need for a “full” offer as
> compared to an offer that just reflects the current capabilities.  There
> are many examples in SIP where a node is sent an “empty re-INVITE” or a
> “REFER with REPLACES” during a session to trigger the node to send a new
> SDP offer to renegotiate media.  This may be triggered due to an interface
> change, a network server (e.g., acting as B2BUA) moving the media to
> another endpoint such as a conference server, etc.  In all these cases
> there is no guarantee that the new target will support the same codecs or
> have the same capabilities, so the best way forward is to create a “full”
> offer to make it most likely that an acceptable media configuration can be
> achieved in a single offer/answer transaction.  There are other cases where
> it may be acceptable to send a “minimal” offer, but only the application
> can determine which one is needed.****
> ** **
> The 3rd paragraph of 5.1.2 says that createAnswer should also reflect the
> “current state” of the system.  It is very confusing to use the same words
> to describe createOffer and createAnswer since they should not mean the
> same thing.  The text should be clarified to distinguish between these two
> cases.****
> ** **
> There is a great need for a new section (possibly a subsection of 4) that
> describes the relationship between MediaStreams and media lines.  An rtcweb
> MediaStream is not the same as an RFC 3264 media stream, thus causing
> endless potential for confusion (I admit to being one of the victims).  An
> RFC 3264 media stream is more akin to a MediaStreamTrack, and even that is
> not completely accurate since we will allow multiple MediaStreamTracks per
> m line.  How does the browser decide how to allocate MediaStreamTracks to m
> lines?  The easy solution is to assign each track to a separate m line but
> this is wasteful when multiple tracks carry the same media type.  But not
> all tracks of the same media type should be forced to use the same m line
> since it may be necessary to negotiate different capabilities for these
> tracks.  It must somehow be made clear to the browser which tracks can be
> combined on an m line and which cannot so that it can generate an
> appropriate offer with the proper number of m lines.****
> ** **
> In section 5.1.4, it should be pointed out that the need to support both
> old and new local descriptions means that the PeerConnection must in some
> sense be “cloned” since there may be completely different remote candidates
> and codecs selected for use with the new description and both
> configurations need to be simultaneously supported for an interim period.
>  It is also not explained how to remove the new configuration if the 2ndoffer/answer fails.  I do not think that the state diagram supports a
> transition from offer state or pranswer state back to stable state without
> processing a valid answer.  Note this is also another implicit meaning of
> pranswer that should be described for subsequent offer/answer transactions
> – both the old and new configurations need to be supported until receipt of
> final answer or failure is indicated.****
> ** **
> Sections 5.1.6 and 5.1.7 should clarify the relationship between the
> local/remote description and the actual resources allocated.  One of them
> usually reflects the configured resources while the other is generally a
> superset.  If this is not the intended semantic, then that should also be
> clarified.****
> ** **
> In section 5.2, I believe the RTP header extension attribute in RFC 5285
> is a=extmap rather than a=rtphdr-ext.****
> ** **
> Richard****
> _______________________________________________
> rtcweb mailing list