Re: [rtcweb] jsep 01 comments

[Justin Uberti <[e-mail]>]

Richard,

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) <
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>