[SIPForum-techwg] SIPconnect/1.1 v03 onlist - section 7.1.4.1.7"SP-SSE Administratively Disabled or Overloaded"

[Elwell, John]

Spencer,
 
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
7.1.4.1.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.

	 

	John 

	 

	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
interval.

	 

	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. 
	 
	Comments?
	 
	Thanks,
	 
	Spencer

		----- 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 7.1.4.1.6
"Other 4xx Responses"

		The current text in this section says
		 
		

		1.1.1.1.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 7.1.4.1.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.
		 
		Thoughts?
		 
		Thanks,
		 
		Spencer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20090204/fb8eebe6/attachment.html