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

Hi folks,

I sent the below issue a while a go, and I got some responses indicating support for my suggestion/bug-report, but I never understood wether I am suppose to "fix" this through script-modifications, or wether this is accepted as being a bug in the TM module.

I recently downloaded the latest code for 1.3.x and it still behaves the same way, regarding 6xx. The timer-c issue seems to have been fixed though.

Should I test 1.4? Should I file a bugreport myself? Or should I just fix my script in some way? (How?)

If need be, I can send a wireshark trace to clearly indicate the issue.

Kind Regards Taisto Qvist

Taisto Qvist wrote:

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