Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling

[Adam Roach <[e-mail]>]

On 7/17/13 11:38, Paul Kyzivat wrote:
> Adam,
>
> While I see there can be some value to extending O/A to allow for 
> smaller critical sections, I fear that it is going to be very messy to 
> get "right". Some messy things:
>
> - Glare between a partial O/A and a full O/A

...is glare. Resolve as normal. For SIP, that means timers.

> - Is a partial O/A permitted in a sip reINVITE? Can you have
>   an offerless reINVITE where the response contains a partial offer?
>   Or can these only be done in UPDATE?

No, no, and no. In SIP, the protocol machinery would not allow INVITE or 
UPDATE to complete concurrently in opposite directions for any amount of 
overlap. We aren't proposing a change to SIP state machines here, only 
to the offer/answer model. This necessarily means that we need to carry 
partial offers and partial answers in something else -- probably INFO.

> - In SIP, processing of concurrent reINVITEs/UPDATEs containing
>   partial SDP updates. This seems to already be a

You left this unfinished, but I *think* it was going to make the same 
point I did in my response above.

> - How to assign version numbers to the full SDP as a result
>   of partial updates

Section 3.4.1: "... the SDP version is incremented by one..."


> - I'm not sure your algorithm for resolving glare when adding
>   streams works in all cases. (More below on this.)
>
> These (and ones I haven't thought of) *may* all be resolvable. But 
> this certainly complicates the already complex O/A process - maybe to 
> the point that many get it wrong. (I don't want to write rfc6337bis!)
>
> My concern with the glare resolution algorithm is that for it to work 
> both sides must realize that glare occurred. And I think there are 
> common sequences when one side won't realize it.

I'm not saying I didn't miss it, but I did work through as many 
permutations as I could think of, and none of them are left out by the 
algorithm described in section 3.4.1.

That said, I did my analysis in the context of WebRTC, and assumed a 
reliable, in-order delivery channel for messages. I recognize that we 
don't have that for SIP, and that messages in the same direction can be 
reordered. I admit that this does raise some interesting scenarios that 
may require additional work to resolve.

> I'm reluctant to buy into a scheme that depends on this without 
> knowing it it will be implementable.

I understand your reluctance, and don't want to gloss over it. This is 
but one plank in the overall plan, and it represents what we think is 
the best (but not only) solution to this specific requirement. If the 
issues prove intractable, we could fall back to an alternate scheme, 
such as the designated-offerer I describe in 
draft-roach-rtcweb-glareless-add-00, or the token-passing scheme 
described by Ted Hardie (cf. 
http://www.ietf.org/mail-archive/web/rtcweb/current/msg07361.html).

/a