> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Adam > Roach > Sent: Sunday, March 22, 2009 7:24 PM > > The intention is that any UA capable of sending a NOTIFY message in any > context will use a GRUU for all dialogs. This mechanism is to be used > instead of dialog re-use. The most common case of dialog re-use right > now is sending a SUBSCRIBE down an existing dialog that was initially > established by an INVITE. So, for current use cases, using GRUU in > INVITE dialogs is the most important thing. For future-proofing, we need > to require GRUU for all dialogs. 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?
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? GRUU is not what one would call a wildly successful mechanism, yet, and we don't yet know what all of its deployment issues will be using it in INVITEs. And the most popular implementation we've seen using gruu doesn't even use the right param name (it uses an older gruu draft's param name). -hadriel _______________________________________________ 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
