I agree with Maxim here. You should try to classify traffic to various
destinations and configure application timers (possibly in a table) to these
destinations.A logging mechanism can help you fine tune these values and
find new destinations that have high RTT and hence are timing out.
2009/1/3 M
8 5:40 PM
>> To: sip-implementors
>> Subject: [Sip-implementors] Retry intervals
>>
>> How should we handle retry intervals for resending SIP requests which
>> have received no response? RFC 3261 prescribes doubling the retry
>> interval each time, starting with an
See below.
Thanks,
Neel.
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Dale Worley
> Sent: Wednesday, December 31, 2008 5:40 PM
> To: sip-implementors
> Subject: [Sip-i
Dale Worley wrote:
> On Thu, 2009-01-01 at 13:15 -0800, Maxim Sobolev wrote:
>> It allows you to have different failover timeouts within the same
>> application and select particular one depending on destination.
>
> And interesting idea. My application is a SIP proxy, which will send to
> many
On Thu, 2009-01-01 at 13:15 -0800, Maxim Sobolev wrote:
> It allows you to have different failover timeouts within the same
> application and select particular one depending on destination.
And interesting idea. My application is a SIP proxy, which will send to
many destinations, some of which i
Dale Worley wrote:
> On Wed, 2008-12-31 at 15:54 -0800, Maxim Sobolev wrote:
>> I believe you are using the wrong tool to implement the required
>> functionality. You should really use application level timeouts to do
>> failover (i.e. cancel call in one UAC and make a new UAC instance to
>> alt
On Wed, 2008-12-31 at 15:54 -0800, Maxim Sobolev wrote:
> I believe you are using the wrong tool to implement the required
> functionality. You should really use application level timeouts to do
> failover (i.e. cancel call in one UAC and make a new UAC instance to
> alternative destination) ins
Daler Worley wrote:
> How should we handle retry intervals for resending SIP requests which
> have received no response? RFC 3261 prescribes doubling the retry
> interval each time, starting with an interval (T1) which is an estimate
> of the round-trip time of the network, and ending with 32 time
How should we handle retry intervals for resending SIP requests which
have received no response? RFC 3261 prescribes doubling the retry
interval each time, starting with an interval (T1) which is an estimate
of the round-trip time of the network, and ending with 32 times that,
for 6 retries total.
