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

From: [email-masked] (Dale R. Worley)
Date: Fri, 2 Nov 2012 11:52:08 -0400 (EDT)

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

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 2 Nov 2012 18:30:52 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dale R. Worley
> Sent: Friday, November 2, 2012 3:52 PM
> To: [email-masked]
> Subject: Re: [rtcweb] #3: JSEP-02 Review (from Andy Hutton)
> 
> > 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.

And if one *is* familiar with how offer/answer works in SIP, one might easily assume that media can be successfully received and played out by the offering side if the answering side were to send some before sending an answer. An assumption which often holds in SIP but which I believe cannot hold in RTCWEB. While you can create the unidirectional *sending* MediaStreams and hook them up, there is no way for the receive MediaStreams to "pop out" of the RTCPeerConnection prior to an answer (provisional or final) being received, and thus no way to "hook up" the video and audio tags in advance of those RTP packets potentially arriving from the answering side.

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

Standard Answer #22 applies.

Matthew Kaufman

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sat, 3 Nov 2012 14:54:28 +0100

On 2012-11-02 19:30, Matthew Kaufman wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Dale R. Worley Sent:
>> Friday, November 2, 2012 3:52 PM To: [email-masked] Subject: Re:
>> [rtcweb] #3: JSEP-02 Review (from Andy Hutton)
>>
>>> "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.
>
> And if one *is* familiar with how offer/answer works in SIP, one
> might easily assume that media can be successfully received and
> played out by the offering side if the answering side were to send
> some before sending an answer. An assumption which often holds in SIP
> but which I believe cannot hold in RTCWEB. While you can create the
> unidirectional *sending* MediaStreams and hook them up, there is no
> way for the receive MediaStreams to "pop out" of the
> RTCPeerConnection prior to an answer (provisional or final) being
> received, and thus no way to "hook up" the video and audio tags in
> advance of those RTP packets potentially arriving from the answering
> side.

I have the same understanding. But I have also been told that the DTLS 
handshake cannot complete until the answer is provided to the offering 
side RTCPeerConnection, so the media could anyway not be decoded before 
the answer is available. I might have gotten this wrong though.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 3 Nov 2012 23:32:57 +0000

> I have the same understanding. But I have also been told that the DTLS
handshake cannot complete until the answer is provided to the offering side
RTCPeerConnection, so the media could anyway not be decoded before the
answer is available. I might have gotten this wrong though.

That is correct. It is also true that candidate pair nomination cannot
complete until the answer arrives too.  The answer includes the ICE
password. But that is just because ICE is back to front.

Not a problem with security descriptions, though. Not does it require extra
round trips. Pity that is can't do peer authentication.