Adam,
Don't get me wrong. I think this is a problem any way you turn.
I was pretty heavily involved in gruu. It certainly intended to solve a
problem, but it too ended up much more complex than anybody hoped it
would - to the point that I suspect there is a lot of reluctance to
implement it, and a fair amount of potential to implement it wrong. On
top of that, I suspect many feel they haven't needed it so far, and can
get away without it, because the magic of SBCs eliminates the need.
Also, I know of significant deployed uses of dialog sharing, that
probably won't go away any time soon even after deprecation.
If we had it to do over, I would not include dialog sharing in 3261. But
despite the potential problems with it, I think that horse is out of the
barn and will not be put back in, especially since that barn is on fire.
IMO the more likely thing is to encourage everyone who can to put a ;gr
on their contacts, and to make a best practice of using out-of-dialog
subscriptions/refers, etc. whenever the target address has ;gr. But if
it doesn't, then I think one should go ahead and use dialog sharing. Of
course one is free to refrain from carrying out some feature rather than
initiating it via dialog sharing, but if you are on the receiving end,
then I think support is still expected.
Thanks,
Paul
Adam Roach wrote:
Paul Kyzivat wrote:
Adam Roach wrote:
Because of the true interoperability nightmare that has resulted from
dialog sharing, my suggestion would be to disable notifier
functionality on those endpoints under such circumstances (perhaps
with an implementation option to fall back to 3265 behavior for the
truly masochistic).
Can you say more about the "true interoperability nightmare that has
resulted from dialog sharing"?
I understand that there undoubtedly are interop issues due to some UAs
not supporting dialog sharing. There are also interop issues due to
the UAs not supporting an event package, or not supporting GRUU, or
whatever. Is one more of a nightmare than another?
It's not lack of support that worries me -- it's mismatched views of
dialog and usage state between two endpoints who both think they've
implemented dialog sharing. The problem is not that things negotiate
down to a lesser set of capabilities -- it's that things act broken in a
way that exposes this mixed-up view of whether a dialog (and its
associated session/subscription) is active.
Dialog sharing has been a legal possibility since 3261 was published.
So it shouldn't be a surprise to anybody. If somebody didn't implement
support, well, what can you say?
As one of the key perpetrators of that particular aspect of 3261, I'm
comfortable in saying that we added it in a slapdash fashion at the 11th
hour, without sufficient analysis (and I mean this in a self-deprecating
way, without intending to cast aspersions on any of 3261's editors).
Interactions between usages in a dialog were ridiculously
underspecified. Robert spent a long time trying to rationalize this
behavior after the fact, with the result being RFC 5057. And RFC 5057
really helps a lot for the minority of implementors who actually know it
exists. However, the issue is complicated enough that it takes 26 pages
to untangle it, and the rules are a tangle of exceptions. Go read 5057
again, and tell me that people are more likely to get that right than
they are to get confused.
It was used primarily because contacts in dialogs often don't have the
gruu property, and GRUU hasn't been widely implemented. Has that
situation changed? Will 3265bis somehow result in widespread
implementation of GRUU by registrars?
3265bis is less mature than GRUU (in that one is a -00 individual draft,
and the other is in the RFC editor queue). I think it's reasonable to
rely on predecessor technologies.
/a
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
