[SIPForum-techwg] SIPconnect/1.1 v03 onlist - section 126.96.36.199.7"SP-SSE Administratively Disabled or Overloaded"
john.elwell at siemens.com
Wed Feb 4 12:42:59 EST 2009
Minor point below.
From: techwg-bounces at sipforum.org
[mailto:techwg-bounces at sipforum.org] On Behalf Of Spencer Dawkins
Sent: 04 February 2009 15:55
To: techwg at sipforum.org
Subject: [SIPForum-techwg] SIPconnect/1.1 v03 onlist - section
188.8.131.52.7"SP-SSE Administratively Disabled or Overloaded"
The current text for this section says
Spencer: MAY seemed awfully weak here.
An SP-SSE which is overloaded or administratively disabled MUST
generate a 503 Service Unavailable response to a REGISTER request,
unless it is silently discarding traffic due to overload, and SHOULD
include a Retry-After header value indicating how long before the
SIP-PBX SHOULD re-attempt the request to the same SP-SSE, unless the
SP-SSE is silently discarding requests due to overload.
[JRE] Change this last SHOULD to "should", because normative
requirements for the SIP-PBX are given in the next paragraph.
An SIP-PBX receiving such a response MUST support the
Retry-After header, and MUST honor the value as follows: if the value is
32 seconds or less, it MUST wait the requested time and retry the
request to the same SP-SSE; if the value is larger, it MUST remember the
value for that SP-SSE address instance, and try any alternate SP-SSE
addresses it can. If an alternate SP-SSE can be successfully reached
and Registration succeeds through the alternate, the SIP-PBX MAY discard
the Retry-After value of the original. Otherwise, it MUST wait to
reattempt Registration to the original SP-SSE for the Retry-After
I had made the change to MUST, with an escape clause for SP-SSEs
that are silently discarding traffic, but wanted to check this change
with the working group before committing it.
----- Original Message -----
From: Spencer Dawkins <mailto:spencer at wonderhamster.org>
To: Spencer Dawkins <mailto:spencer at wonderhamster.org>
; techwg at sipforum.org
Sent: Wednesday, February 04, 2009 9:48 AM
Subject: SIPconnect/1.1 v03 onlist - section 184.108.40.206.6
"Other 4xx Responses"
The current text in this section says
220.127.116.11.1 Other 4xx Responses
Any 4xx-class response to a REGISTER request not
explicitly identified above SHOULD be treated in a similar manner as
section 18.104.22.168.1 unless it can automatically be resolved by the SIP-PBX
internally - i.e., unless it is part of an explicit negotiation
mechanism or procedure. It SHOULD be treated as a delivery failure but
with a higher maximum retry interval of 960 seconds (16 minutes).
Spencer: John pointed out that the one-day maximum retry
interval (for other 4xx responses) is way longer than the 16 minutes for
5xx/6xx specified below. Does this make sense to people? Should 5XX/6XX
also be one-day? Telechat decision was to discuss onlist.
I had made a change for these 4xx responses to be 16
minutes (that's what the text says in my working copy) to match 5xx/6xx,
but people on the call weren't comfortable with that.
I'm not seeing one-day retry intervals for enterprise
PBXes as reasonable, in either case. My inclination is to leave the
current text at 16 minutes for both 4xx and 5xx/6xx responses, but I
wanted to check with the working group before making that decision.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the techwg