[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