21 Mar
2008
21 Mar
'08
5:21 p.m.
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