I can confirm this behaviour - in my case I have been able to solve / avoid it as the 60x-sending device is also being managed by myself.
Nonetheless I agree with Taisto - if one branch is telling me that he can provide me a definitive answer for his point of view this doesn't have to be something I can trust while forking, do I?
Allowing me to configure this (or even better: to set it at runtime) would be great. I'm not 100% sure about the canceling part, as I didn't re-test it right now - so I'm just telling what I can remember from my last tests...
Kind regards, Thomas Gelf
Taisto Qvist schrieb:
Hi folks,
When I am doing forking I am getting a puzzling result concerning forwarding of responses, and I'm wondering how script needs tweaking.
When recieving a 6xx on one branch, the TM-module automatically generates CANCEL to cancel the remaining branches(I wouldnt mind if this was configurable), but the puzzling thing is that it forwards the 603 _before_ it has terminated the remaining client transactions. (It sends cancel but it doesnt wait for final responses of the invites its cancelling, just forwards 6xx directly.)
A similar scenario happends when I let Timer C pop. My TM-module will send a final response on the server-side at the same time as it starts to cancel the client side.
But since one of the client txns just might result in a 2xx(INV) I cant forward the final response until ALL client txns are done, if I am going to follow the rfc properly.
I thought the TM module would keep track of all client txns for "me", but it seems it isnt, so is this something I should "manually" handle in my script?
Regards Taisto Qvist