Re: [rtcweb] Agenda requests for Atlanta meeting

[Paul Kyzivat <[e-mail]>]

On 10/10/12 4:03 AM, Christer Holmberg wrote:
> 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.

+1

I'll also observe that you can have early dialogs without reliable 
provisionals. E.g.:

- A sends INIVTE offering codecs C1 and C2
- proxy P forks first to B.
- B sends unreliable 180, tag BBB, with answer selecting codec C1,
   and starts sending media.
- P cancels the invite to B and forwards the invite to C
- C sends unreliable 180, tag CCC, with answer selecting codec C2,
   and starts sending media
- C sends 200 with same answer as before.

Note that A must not invalidate the use of C2 when it receives the 180 
from B, unless it first clones the invite. It must leave it eligible for 
use on other dialogs. And of course while it can manage separate O/A 
state machines per dialog, down at the RTP stack it may not be able to 
correlate the incoming media with a particular one of those O/A state 
machines.

(Consider the example above, but the 180 from B is lost - never received 
by A. Since it isn't reliable, nobody knows this. But the media still 
comes.)

Of course things are a bit different when you layer ICE on top of this. 
I won't try to discuss that.

	Thanks,
	Paul