[reSIProcate] reply: about failover!

[Dario Bozzali]

Hi all,
I have some doubt/question regarding failover.
In RFC3261 I read the following information about transaction transaport errors:

17.1 Client Transaction
17.1.4 Handling Transport Errors
[...]
   The client transaction SHOULD inform the TU that a transport failure
   has occurred, and the client transaction SHOULD transition directly
   to the "Terminated" state.  The TU will handle the failover
   mechanisms described in [4].

17.2 Server Transaction
17.2.4 Handling Transport Errors
[...]
   First, the procedures in [4] are followed, which attempt to deliver
   the response to a backup.  If those should all fail, based on the
   definition of failure in [4], the server transaction SHOULD inform
   the TU that a failure has occurred, and SHOULD transition to the
   terminated state.

DUM provide automatic error handling for REGISTER message through setDefaultRegistrationRetryTime() in profile (used by class ClientRegistration), but there is not similar mechanism for ClientInviteSession.
Should the application (TU) start failover procedure on 408 Request Timeout response code for INVITE and stop it on 503 Service Unavailable?
If this is not correct, how to handle failover in TU?

Thank you in advance and best regards,
Dario.

________________________________


-----Original Message-----
From: resiprocate-devel-bounces at resiprocate.org [mailto:resiprocate-devel-bounces at resiprocate.org] On Behalf Of hongsion
Sent: mercoledì 17 dicembre 2008 6.40
To: 'Byron Campen'
Cc: resiprocate-devel at resiprocate.org
Subject: [reSIProcate] reply: about failover!

Hi byron,
	Would you like share with me how failing over on Timer B work. From resip source code, I can only see failing over is implemented in function TransactionState::processTransportFailure(), and this function is called only when TransactionState::isTransportError( ) return true. But when timer B  Time out, where this function is called? Thanks!

Regards,
/hongsion

---original-----
sender: Byron Campen [mailto:bcampen at estacado.net]
time: 2008-12-17  0:54
receiver: hongsion
forward: resiprocate-devel at resiprocate.org
subject: Re: [reSIProcate] about failover!

	Can anyone explain why we don't fail over on Timer B? I can see why

we should not fail-over on Timer F (NIT timeout), but it seems that failing over on Timer B should be ok.

	As for resetting the branch param, there is a transport sequence number in the branch param that we increment every time we fail-over.  
So, the branch param is different, _but_ since resip ignores this on incoming requests, you could end up with a situation where two requests with different transport sequences show up at the same resip instance, causing strange behavior.

Best regards,
Byron Campen

> Hi all,
> 	According to RFC3263 4.3, when timer B times out, UA should 
> reconstruct new transaction and send request. But from 
> TransactionState.cxx, when Timer B is time out, seems only 408 
> response sent to Transaction user, no continue action is done. Please 
> check. Also, when failure occurs, should create new request with 
> different branch ID, seems in
> TransactionState::
> processTransportFailure, only original request is sent, I am referring 
> resip
> 1.4.1 version.
>
> Regards,
> /hongsion
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel


_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel