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

[[e-mail] (Dale R. Worley)]

> #3: JSEP-02 Review (from Andy Hutton)
> 
>  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?

Unless one is familiar with how offer/answer works in SIP, one might
easily assume that media can only be sent after the offer/answer cycle
is complete.

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

In the language of the quoted passage, in SIP, once a CANCEL has been
sent, the session is ended (at least from this end's point of view).
This end may send another offer, but it will describe a different
session.

If there is some difficulty in the API about this, it is probably
because the API doesn't explicitly allow manipulation of multiple
sessions at once, and leaves the identify of the session that is being
controlled implicit.

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

Do we have any need for "pranswer"?

Dale