I don't think this is a real problem. It is a *change*, no worse than
other changes we make from time to time. It won't bother the sorts of
middleboxes (proxies) that we have clear standards for. If it bothers
B2BUAs then they will need to learn how to deal with it.
Paul
Aki Niemi wrote:
Hi all,
This is a potential show-stopper issue that Rohan brought up in the SIP
WG session last week.
Currently, subnot-etags offers two modes of operation. In the first, the
body of the SUBSCRIBE-generated NOTIFY is suppressed, and in the other,
the entire NOTIFY is suppressed, and a new response 204 (No
Notification) is generated instead.
The latter is a considerable change to how SIP events works, and might
cause a middlebox that tracks the SIP dialog to basically barf, thinking
the dialog expires when it in fact gets refreshed.
Do folks think this is a problem? It would be great if some SBC vendors
could check what their implementation does with SUBSCRIBE dialogs.
Personally, I'd hate to hack around boxes that people claim are doing
something fishy. But if this is a real problem, then subnot-etags would
basically need to be reduced to just suppressing bodies of NOTIFYs.
Cheers,
Aki
_______________________________________________
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
_______________________________________________
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
