Elwell, John wrote:
I found little to comment on, apart from the following:
In 4.5.1:
"Notifiers MUST implement the GRUU extension defined in
[I-D.ietf-sip-gruu], and MUST use a GRUU as their local target."
1. Is this just for a SUBSCRIBE-initiated dialog or for any dialog?
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.
2. Should this be package-dependent? For example, there may be some
event packages for which there is no need for subscribing to a resource
on the same device.
I think it's likely to be too difficult to guess, ahead of time, which
packages will never need to target the same device as another dialog.
It's far too easy to envision a circumstance in which we say, "I can't
think of any reason someone would need to target a specific device for
package foo," only to discover a really clever usage several years later
that we have accidentally precluded.
3. What if the registrar doesn't support GRUU, and therefore the
notifier is unable to obtain a GRUU?
Note, first of all, that this constraint is placed on notifiers, and not
on subscribers. For the vast majority of notifiers, a self-made GRUU
(which requires no registrar support) is appropriate.
However, your point is taken, and we should discuss circumstances in
which registering clients that send NOTIFY messages request a GRUU from
their registrar, yet receive none. 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).
And by the way, in appendix C I didn't see a mention of changes relating
to the use of GRUU.
Sorry about that. My intention was to include that as part of C.1.21,
but I left it out.
/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
