Re: [rtcweb] jsep 01 comments

[Stefan Hakansson LK <[e-mail]>]

On 07/05/2012 09:42 PM, Ejzak, Richard P (Richard) wrote:
...
> 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.

I agree, those things should be clarified. I am especially interested in 
that the following is clearly described:

* "OFFER-OFFER" which can be used to avoid glare (according to [1]) when 
both sides add/remove streams simultaneously. This seems like a really 
useful technique as the number of potential glare situations can be 
reduced. However, I can't find any info on in what circumstances it is 
possible, and it also seems to violate the state diagram in [2] 
(basically the browser would be in two states at the same time: 
sentOffer and receviedOffer).

* The possibility to update certain parts of the session without an 
offer/answer that Justing mentioned in the rtcweb session 
Monday/Vancouver. It was specifically mentioned in the context of 
sending updated imageattributes without waiting for the answer of the 
previous one sent. This seems to be applicable to certain parts of the 
session and not others, and this should be described (so that apps can 
utilize this, and so that different implementations are working the same 
in this respect).

[1] http://www.ietf.org/proceedings/83/slides/slides-83-rtcweb-8.pdf, 
slide 16
[2] 
https://docs.google.com/document/d/13TYiNSEmFkB7IeNLEJFxI0xMNk8q_LhXE_hbvFbXRTU/edit#

Stefan


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 2^nd 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 2^nd 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 3^rd 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 2^nd offer/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
>