On Mon, 2009-07-06 at 17:01 -0400, Dale Worley wrote:
> On Mon, 2009-07-06 at 12:03 -0400, Gertsvolf, Mark (CAR:9D30) wrote:
> > I raised a ticket (XX-6065) to track this problem.
>
> I looked at XX-6065, and the SMC takes 4.03 seconds to respond in that
> case, which is a rather long time.
>
> Currently, it would be simple to add another retry lengthening the
> fallback to 3.0 seconds, or two more retries, lengthening the fallback
> to 6.0 seconds.
>
> 6 seconds seems like a long time for a fallback. But on the other hand,
> considering the "swapped-out softphone" scenario, response times like
> these seem unavoidable.
As Mark G. points out, we are caught with conflicting goals:
- Because of the "swapped-out softphone" use-case, we need the T1
timeout (between sending a request and expecting a response) to be in
excess of 4 seconds.
- Because of the multiple forwardings of requests within the sipXecs
servers, we want the T1 timeout to be well less than 4 seconds. (As
long as all the servers are operational, this isn't a problem, but in
situations with failed or inaccessible servers (H/A or multi-branch), a
request might be delayed by several times the T1 timeout before reaching
its destination.)
I was thinking that we might be able to finesse this problem by creating
a URI parameter somewhat analogous to "transport" that specifies the T1
timeout (or something that determines T1). The default timeout would be
set to be long enough for "any" UA to respond, which seems to be
something like 5 seconds. But configured URIs that refer to sipX
components would be decorated with smaller timeouts. In the latter
case, the timeout could be considerably smaller than we now allow.
E.g., in forwardingrules.xml:
<!-- All other requests go to the SIP registry service -->
<routeTo><victoria-pingtel-com.us.nortel.com:5070;x-sipx-t1=500;transport=tcp;x-sipx-routetoreg></routeTo>
add------------------------------------------------------^^^^^^^^^^^^^
This parameter could be extracted from the request-URI in the bowels of
SipUserAgent and passed to the transmission-control logic.
Since we do not expect any external system to use this parameter, we can
redefine its syntax and effect at any time.
Dale
_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/
