Hadriel Kaplan wrote:
If the most common use-case for dialog-reuse of SUB/NOT is within INVITE dialogs, then what you're really saying is all INVITE-receiving or INVITE-creating UA's which also support receiving SUBSCRIBE must use GRUU's for the *INVITE* dialog to begin with. That way the SUBSCRIBE can be sent to the same far-end UA, right?
That's the important part, yes.
Do you really think it's realistic to make such a requirement, to require changes in INVITE-dialogs, for an update to rfc3265 Sub/Not that ostensibly is to fix found issues and provide better interop?
Yep. We knew, when we put dialog sharing in, that it was a horrible hack. I can probably even dig up the fossil record where we explicitly agreed (prior to 3265's publication) to go forward with what we acknowledged it to be a horrible hack, and further agreed to try to come up with a better way to do this in the future. I concede that consensus reached eight years ago can be overturned if we have new technical information, but this really *has* been the plan all along.
In fact, getting GRUU in the editor's queue was one of the key triggers that led me to believe that we finally have the tools necessary to issue a bis, since dialog sharing was a known (and necessary) flaw at the time of publication.
GRUU is not what one would call a wildly successful mechanism, yet
Of course it's not. It's not an RFC yet. After the whole multi-year TURN whipsaw experience, I'm stunned anyone bothers to implement anything before it has an RFC number assigned any more. But, suprisingly, they do: more than one in every eight implementations at SIPit 22 implemented GRUU.
And, while I'm flattered that you think that the publication and/or the implementation of 3265bis will somehow outrun a document that's effectively at the finish line already, I think you are being somewhat over-optimistic in your evaluation. By the time 3265bis is an RFC, implementations will be further along.
/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
