Re: [rtcweb] Agenda requests for Atlanta meeting

[Christer Holmberg <[e-mail]>]

Hi,

>>>> I have not seen any reason to relax 3264 yet but if something comes up, agree we should carefully look at the cases. I think we can just do straight up 3264.
>>> 
>>> RFC 3264 doesn't describe PRANSWER.  The concept is entirely absent.
>>> 
>>>  The offerer MAY immediately cease listening for media formats that  
>>> were listed in the initial offer, but not present in the answer.
>>> 
>>> "the" answer.
>> 
>> I agree with Martin. 3264 O/A is always per dialog, and forking is supported by generating multiple dialogs. JSEP, OTOH, in order to support forking with a 
>> single "dialog" (peerConnection local descriptor), now defines O/A as offer+any number of pranswers + answer.
>> 
>> So, we would e.g. have to define what happens if a new offer is received from the remote side while the browser is in pranswer-received state (see my call flow in another reply).
>
> 3264, SDP, 3261, and related documents are dealing with a bunch of things including what happens at media plane and signaling plane. 
>
> I'll note that though O/A is per dialog, there is only one O shared across multiple legs and when you create the O you don't know how many dialogs there will be.

The *initial* O is shared across multiple legs. Once a dialog has been created, O/A transactions on that leg will not affect other legs.

> So from the media point of view (covered more in SDP spec than 3264) there is one O with a bunch of A. From signaling point of view there are a bunch of O/A pairs). 
>
> The dialog is SIP signaling concept not a media plane level concept. We moved the signaling part out of the browser and into the JS. But the media part is still in the 
> browser. So as 3264 says, after the offer is constructed, we have to be willing to receive media for all the codec type in the offer. When we get the answer 3264 makes 
> it clear that one MAY stop receiving the codecs that were in the offer but not selected in the answer. However, this can not be done until the signaling layer is sure that 
> no more offers will be honored. Since that signalling part of Offer/Answer is in the JS, the API need to to have a way to signal what the MAY part should do and that is 
> the PRANSWER vs ANSWER. 
>
> People keep trying to make this some complex weird argument invoking the SIP deities of the past and quoting incomprehensible phrases from various RFC caved in 
> stone but the bottom line in the code is very simple to understand. When creating the offer you alloced some resources ( like a port to receive video on ). When you
> get an answer that does not use that resource, you need to tell the media stack if it should free the resources or not. O/A has situation where you need to keep the 
> resources available (like there are more dialogs coming) and situation where you need to free the resource.  Since we split the signalling out of the browser and left 
> the media in the browser, we need be able to allow the JS that is dealing with signaling to tell the browser when to free the resource. 

I don't know who "people" is, but at least I have only been talking about the O/A *signaling* :) Media is a separate issue.

Regards,

Christer