[rtcweb] #3: JSEP-02 Review (from Andy Hutton)

["rtcweb issue tracker" <[e-mail]>]

#3: JSEP-02 Review (from Andy Hutton)

 I have read through the latest jsep-02 draft and have the following
 comments/questions.

 1. Section 1 Introduction

 The introduction makes various references to offer/answer but does not
 mention RFC 3264.  It needs such a reference and to explain the relevance
 of RFC 3264 and how JSEP provides the tools to implement a RFC 3264
 conformant application but does not itself implement RFC 3264.


 2. Section 1 Introduction 2nd Para states:

 "The browser environment also has its own challenges that cause problems
 for an embedded signaling state machine.  One of these is that the user
 may reload the web page at any time.  If this happens, and the state
 machine is being run at a server, the server can simply push the current
 state back down to the page and resume the call where it left off".

 The last sentence is an over simplification as there are problems with
 regard to rehydration even when the signaling state machine is run at the
 server. Also the sentence refers to two different types of state as it is
 not the signaling state that is pushed back to the browser.  I suggest
 removing the last sentence or referring to the section on hydration.


 3. Section 1. Introduction 7th Para states:

 "The JSEP approach does come with a minor downside.  As the application
 now is responsible for driving the signaling state  machine, slightly more
 application code is necessary to perform call setup; the application must
 call the right APIs at the right times, and convert the session
 descriptions and ICE information into the  defined messages of its chosen
 signaling protocol, instead of simply forwarding the messages emitted from
 the browser."

 Yes but maybe the introduction should explain that the API will provide
 valid SDP that an application could use within a RFC 3264 based protocol
 without the application needing to understand the syntax of SDP.


 4. Section 1. Intoduction 8th Para states:

 "For example, this library could convert easily adapt the JSEP API..."

 Remove "convert".

 5. Section 4.1. Signaling model 1st Para states:

 "JSEP does not specify a particular signaling model or state machine,
 other than the generic need to exchange RFC 3264 offers and answers in
 order for both sides of the session to know how to conduct the session".

 I think this needs rewording and suggest the following “JSEP does not
 specify a particular signaling model or signalling state machine. JSEP
 provides the means for an application to build a signaling state machine
 which complies with the requirements for offer/answers as specified in RFC
 3264".  This emphasises that JSEP is required to provide the tools to
 enable conformance to 3264 even if it allows some flexibility to diverge
 from 3264.

 6. Section 4.2. Session Descriptions and State Machine states:

 "Lastly, while the exact media parameters are only known only after a
 offer and an answer have been exchanged, it is possible for the offerer to
 receive media after they have sent an offer and before they have received
 an answer. To properly process incoming media in this case, the offerer's
 media handler must be aware of the details of the offerer before the
 answer arrives."

 I don't see the relevance of the statement "it is possible for the offerer
 to receive media after they have sent an offer and before they have
 received an answer". Why is the purpose of this statement?

 7. Section 4.2. Session Descriptions and State Machine states:

 "In [RFC3264], the constraints at the signaling level is that only one
 offer can be outstanding for a given session but from the media stack
 level, a new offer can be generated at any point.  For example, when using
 SIP for signaling, if one offer is sent, then cancelled using a  SIP
 CANCEL, another offer can be generated even though no answer was  received
 for the first offer. To support this, the JSEP media layer  can provide an
 offer whenever the Javascript application needs one for the signaling."

 Regarding the example SIP sequence in this scenario if the CANCEL is used
 to terminate a SIP dialog initiating INVITE I would assume that normally
 the peer connection would be terminated and a new peer connection used for
 any subsequent call so it does not seem to be a good example. If the
 example is meant to indicate that such a sequence could be used whilst
 establishing a SIP dialog it is a really horrible example. If it is
 intended to be an example mid dialog then the offer needs to be cancelled
 and the media state reverted to what it was previously.

 8. Section 4.2. Session Descriptions and State Machine.

 I think that some text is needed to describe how the version number in the
 SDP o line is managed and whether the application has responsibility for
 changing the version number if it changes the SDP between createOffer and
 setLocalDescription etc.


 9. Section 4.6. Session Rehydration states:

 "At this point a new offer can be generated by the new PeerConnection,
 with new ICE and SDES  credentials. This can then be used to re-initiate
 the session with the existing remote endpoint, who simply sees the new
 offer as an in-call renegotiation..."

 Whether this is possible depends on the signalling system used and the
 offer/answer state for example it might not be possible to send another
 offer if there is already an outstanding offer waiting for an answer so
 maybe the session would have to be terminated. This seems to suggest that
 Ekr's idea to somehow maintain the PeerConnection is more attractive.


 10. Section 5.1 SDP Requirements.

 I miss a statement related to the data channel. Mandatory/optional?
 [draft-ietf-rtcweb-data-channel]

 Bundling of media streams is also not mentioned here (bundle/mmt drafts)
 only is mentioned further down in section 6.

 DTLS-SRTP (RFC5763/64)? It's mentioned throughout the text, but not
 spelled out here. DTLS-SRTP would use as transport in the m-line
 DTLS/UDP/RTP/SAVP(F) as specified in RFC 5764.


 11. Section 5.2.1 Create Offer states:

 "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 description".

 What is meant by "compatible with the current session" in these sentence?
 If for example the offer included G.711 and OPUS audio codecs but the
 answer had only G.711 does this mean that any subsequent offer only has
 G.711 if so this I think is the wrong approach as the new offer should
 provide all the capabilities.  Also I assume that a new set of constraints
 could be used on the createOffer for example to change the media direction
 etc.


 12. Section 5.2.1 Create Offer states:

 "Calling this method may do things such as generate new ICE credentials,
 but does not change media state."

 So am I correct in thinking that this method MUST be called. If so given
 the statement in previous drafts that it does not have to be used it would
 be good to make an explicit statement that it must be used.


 13. Section 5.2.2 createAnswer.

 Presumably constraints can also be set on the answer in which case this
 should be stated like in the createOffer section.

 14. Section 5.2.3 SessionDescriptionType

 ""pranswer" indicates that a description should be parsed as an answer,
 but not a final answer, and so should not result in the freeing of
 allocated resources.  It may result in the start of media   transmission,
 if the answer does not specify an inactive media direction".

 Please note that "inactive" still results in the initiating the RTP
 Session and the transmission of RTCP so if you include RTCP as media this
 statement is not strictly correct.


 15. Section 5.2.3.1 creating Answers states:

 "When an endpoint receives an offer with these channels, it could send an
 answer accepting the data channel for two-way data, and accepting the
 audio and video tracks as receive-only".

 Whether “receive-only” can be used depends on the direction in the
 incoming offer and it should be noted that sending an answer with receive-
 only commits the local browser to sending RTCP so I am not sure this
 really works because the answer with receive-only still needs to contain a
 valid transport address.


 16. Section 5.2.4 setLocalDescription states:

 "If setRemoteDescription was previous called with an offer, and
 setLocalDescription is called with an answer (provisional or final), and
 the media directions are compatible this will result in the starting of
 media transmission."

 I assume by compatible that it is meant that the browser will enforce the
 RFC 3264 rules for setting the direction in an answer. If so please make
 this explicit if not what is meant by “compatible”?


 17. Section 5.2.5 setRemoteDescription - Same comment as above.


 Regards
 Andy

-- 
--------------------------------+--------------------------------------
 Reporter:  bernard_aboba@…     |      Owner:  draft-ietf-rtcweb-jsep@…
     Type:  defect              |     Status:  new
 Priority:  major               |  Milestone:  milestone1
Component:  jsep                |    Version:  1.0
 Severity:  Active WG Document  |   Keywords:
--------------------------------+--------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/3>
rtcweb <http://tools.ietf.org/rtcweb/>