On Tue, 2009-07-28 at 15:52 -0400, Dale Worley wrote:
> 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.
I don't think that we need to handle that case at all. RFC 3261 says:
When a server transaction is constructed for a request, it enters the
"Proceeding" state. The server transaction MUST generate a 100
(Trying) response unless it knows that the TU will generate a
provisional or final response within 200 ms, in which case it MAY
generate a 100 (Trying) response.
the softphone is just broken if it misses that requirement by a factor
of more than 20. Whether or not that is the "fault" of the softphone
software or the platform its on isn't relevant to sipXecs.
In the original description, Mark posited that this could have been due
to network delays, but in fact it was not; if someone can show me a
network that VoIP will otherwise work over but that imposes more than a
4 second delay on the first packet, then we can worry about it.
> - 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).
That would be a hideous layer violation, and I don't even want to think
about what would happen if such a parameter were abused.
_______________________________________________
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/
