Hi,
Normally with serial forking, the first branch ID corresponds to $T_branch_idx == 0, i.e.
Via: SIP/2.0/UDP 172.30.110.4;branch=z9hG4bK7f3d.57593ee3a139f0ae6c4a8a0f531e342c.0
In the event of failure, a second branch attempt has a branch index of 1 and so on:
Via: SIP/2.0/UDP 172.30.110.4;branch=z9hG4bK7f3d.57593ee3a139f0ae6c4a8a0f531e342c.1
However, when I use asynchronous processing with t_suspend() / t_continue(), resuming the transaction in an rtimer process, I notice that the $T_branch_idx of the first branch is 1, then 2.
Where did 0 go? Is this a normal effect of TM suspend/continue?
Thanks!
-- Alex
Hello,
On 11/12/15 02:33, Alex Balashov wrote:
Hi,
Normally with serial forking, the first branch ID corresponds to $T_branch_idx == 0, i.e.
Via: SIP/2.0/UDP 172.30.110.4;branch=z9hG4bK7f3d.57593ee3a139f0ae6c4a8a0f531e342c.0
In the event of failure, a second branch attempt has a branch index of 1 and so on:
Via: SIP/2.0/UDP 172.30.110.4;branch=z9hG4bK7f3d.57593ee3a139f0ae6c4a8a0f531e342c.1
However, when I use asynchronous processing with t_suspend() / t_continue(), resuming the transaction in an rtimer process, I notice that the $T_branch_idx of the first branch is 1, then 2.
Where did 0 go? Is this a normal effect of TM suspend/continue?
yes, this is the normal. Suspending a transaction means using a branch which is not sent out, just the timer is started for it (in case is not resumed during retransmission timeout interval, it will be replied with 408 (or failure route executed), to avoid long lasting/memory leak by improper config suspend-resume logic).
At some point in time there was an attempt to reuse the suspended branch, but it didn't prove to be reliable, as some internal flags/attributes could get overwritten there.
Cheers, Daniel