Re: [rtcweb] Agenda requests for Atlanta meeting

[Paul Kyzivat <[e-mail]>]

On 10/12/12 11:59 AM, Cullen Jennings (fluffy) wrote:
>
> On Oct 9, 2012, at 4:58 PM, Martin Thomson <[e-mail]> wrote:
>
>> On 9 October 2012 13:05, Cullen Jennings (fluffy) <[e-mail]> wrote:
>>> 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. 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.
>>
>> That's a consistent and logical view.  It is not what RFC 3264 says.
>> It may even be the only reasonable solution.
>>
>>> 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 [...]
>>
>> Quit beating around the bush: it's me you are talking about.
>>
>> It's not a complex weird argument, it's this:
>>   PRANSWER is not described in RFC 3264.
>>
>> draft-*-jsep might say something about it, but I'd have to guess about
>> what to do if I were to implement the feature and that doesn't help
>> with interoperation.
>>
>> If there was text that described the above, plus the implications in
>> some detail (including what resources can be released as they relate
>> to the SDP), then we're good.  I don't even think that writing this is
>> especially hard.
>
> Agree that text has to be a clear. But provision is a term from 3261 which is referenced from 3264 and bunch of this also relies on SDP RFC too. Some of the key information about it is 3262. This is all intertwined but my key point is that I don't think we are trying to do anything that was not part of 3264 offer / answer. This is more or less a SIP 180.

I am trying to follow this argument, but am having difficulty, even 
though I agree with much of what has been said by those who seem to be 
on different sides of the "argument".

There is much about what needs to be done in presence of forking that is 
not written, but which is a corollary to what is specified. Most of what 
Christer described falls into this category. Implementations that don't 
do this will fail on some cases.

The problem I have with PRANSWER is that I don't if it ever applies when 
sip is at one end, and if so, how it applies. IMO the simple answer is 
that it is an extension that should not be used when gatewaying to sip. 
But now I think I see people saying it is only there for gatewaying to 
sip. If so, then I want to see a specification for how this maps.

	Thanks,
	Paul