Re: [reSIProcate] reply: about failover!
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@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of hongsion
Sent: mercoledì 17 dicembre 2008 6.40
To: 'Byron Campen'
Cc: resiprocate-devel@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxx]
time: 2008-12-17 0:54
receiver: hongsion
forward: resiprocate-devel@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel