Something that needs to be looked into; I think one of the interworking
specs to ISUP uses the 503 response code as well to map to certain PSTN
failure cases. Those need to be looked at to make sure they still fit
with the proposed new definition.
The draft implies that the Retry-After mechanism provides too
coarse-grained solution for overload control, and finer-grained controls
are needed. As you know, some of the solutions being investigated for
overload algorithms still use on/off behavior but just tune the
Retry-After more algorithmically. So your statements about this need to
be tempered a bit.
I'm really unsure about whether this is an essential correction or not.
Its not a functional bug, but a performance bug. So a system based on
rfc3261 works, but just not that well under load. I'm a bit worried
that, in an attempt to squeeze this in as an essential correction, we
may define the wrong thing so as to minimize change. In particular I
don't like alternative 2 and think we probably need a new response code.
The other big question is, is it worth defining a new response code now,
and then later on basically updating it with the right overload handling
behavior, or do it all at once. I think that requires some discussion.
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 499 Thornall St.
Cisco Fellow Edison, NJ 08837
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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
