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

[Paul Kyzivat <[e-mail]>]

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 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?
- In SIP, processing of concurrent reINVITEs/UPDATEs containing
   partial SDP updates. This seems to already be a
- How to assign version numbers to the full SDP as a result
   of partial updates
- 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 reluctant to buy into a scheme that depends on this without knowing 
it it will be implementable.

	Thanks,
	Paul