[reSIProcate] reply: about failover!

[hongsion]

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