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 > _______________________________________________ Users mailing list [email protected] http://lists.openser.org/cgi-bin/mailman/listinfo/users
