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

[Christer Holmberg <[e-mail]>]

Hi,

I do realize that the draft does not represent the complete glare solution.

Paul has raised some issues/questions, and I also have some. I'll leave the SDP low-level ones for now, and only raise a few high-level ones.

Q1: How essential part of the unified plan is having *A* working "partial o/a" solution? TECHNICALLY, the other parts of the unified plan do not depend on having a "partial o/a" solution, but I would like to know whether people (specially the draft authors) would be willing to move ahead with unified plan even if we would not manage to specify a working "partial o/a" solution.

Q2a: When sending a partial offer, the draft says that only the m= line explicitly signaled is affected. Note, however, that you will still signal information (e.g. the SDP version value, the group:BUNDLE attribute etc) which affect the whole SDP, and if you have multiple outstanding partial offers (for different m= lines) that can cause issues.

Q2b: In addition, when using BUNDLE, modifying an m= line might implicitly modify other m= lines, and there are rules (also indicated in the draft) mandating identical SDP attribute values etc. So, if you have multiple outstanding partial offers, you may end up with all kind of different "BUNDLE collisions".

Q3: If I send a partial offer, for a given m= line, can the answer only contain that given m= line? What if the partial offer causes other m= lines to be modified?


Regards,

Christer





Lähettäjä: [e-mail] [mailto:[e-mail]] Puolesta Adam Roach
Lähetetty: 17. heinäkuuta 2013 20:08
Vastaanottaja: Paul Kyzivat
Kopio: [e-mail]
Aihe: Re: [MMUSIC] [rtcweb] Unified Plan for SDP Handling

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