Subject: [rtcweb] Comments on draft-ietf-rtcweb-jsep-02

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 31 Oct 2012 22:38:55 +0000

Hi, 

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