Jeroen van Bemmel wrote:
Paul,
I don't see any reason why *proxy* middle boxes need to know anything
about this. B2BUAs will need to know, but then they will know.
There are (as always) subtle differences. NOTIFY for SUBSCRIBE is needed
to handle forking (proxies pass at most 1 2xx response for SUBSCRIBE),
while NOTIFY for INVITE would not be needed for this reason. Proxies
Record-Route NOTIFY due to the above reason, they could avoid doing that
for INVITE-NOTIFYs.
I don't follow. If the proxy was going to R-R, it needed to do so in the
SUBSCRIBE. (Or it wouldn't even see the NOTIFY.) If its doing asymmetric
R-R then it may need to update the R-R entry, but that is conditional on
the entry it put there in the SUBSCRIBE. The UAS for the NOTIFY needs to
recognize if it establishes a new dialog and if so remember the R-R, but
again that doesn't impact a proxy.
Record-Routing INFO is useless and somewhat
wasteful, so well designed proxies don't do that.
Also, I assume there will be no need to "immediately send NOTIFY" for
INVITE-based events.
True. But that again is a matter for the UAC and UAS, not the proxies.
All in all, IMO using INFO instead of NOTIFY here is preferrable (also
given that existing implementations already use INFO within INVITE
dialogs).
No matter what we do, the existing standardized uses of INFO will remain.
And I think it is safe to assume that the existing *unstandardized* uses
of INFO will not do the kind of negotiation we are talking about, so
they won't carry over directly.
So we are really only talking about new things.
If we use NOTIFY, then existing, already standardized event packages can
(hopefully) be easily adapted to support the new technique as well as
the old. Because the semantics of the package wouldn't change, I would
hope that it would be easy to get those changes adopted.
If we use INFO, then I guess we can hopefully easily adapt existing
non-standard INFO usages. But because they haven't been standardized,
that may be more difficult.
I suppose one could adapt existing event packages to use INFO for this
style and NOTIFY for freestanding subscriptions. Mechanically its not a
big deal, but it certainly seems odd.
Thanks,
Paul
_______________________________________________
Sip mailing list https://www1.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
