BYE not sent through proxy under ACK-BYE due to cancel race condition

[danieludy]

In SipDialogController::notifyTerminateStaleDialog when calling nta_outgoing_tcreate the dialog routeUri is not used and instead null is just passed in.
I was able to correct it by setting the routeUri within notifyTerminateStaleDialog using dlg->getRouteUri(routeUri) and then replacing the null with routeUri.empty() ? NULL : URL_STRING_MAKE(routeUri.c_str()) as you had used in other places.
I would have submitted a fix myself for you to take but I have to get those approved and thought this would be simple enough.

[davehorton]

worry what is the impact of this bug? How does it affect calls?

[danieludy]

In my environment it results in a dead air call to the far end because we ack the 200OK (which follows the proxy path) and the immediate BYE is send trying to bypass the proxy resulting in it never reaching the far end so they just sit there on a dead call until they disconnect

[davehorton]

how would I recreate this in a test case?

[danieludy]

not sure off hand. I had to set my Kamailio box (proxy) to sleep on passing the 200OK so that I could cancel the A leg of the B2BUA and have the cancel pass through...
I tried with SIPP outside the Kam box and just receiving the cancel and responding with a 200 OK but it wasn't working

[danieludy]

If you were looking for the specific scenario that we have it is Kamailio on the edge with Drachtio behind. Call comes in through Kam to Drachtio, we then make a B2BUA using the same Kam as a proxy out to another destination. Drachtio doesn't have external access directly and has to go through Kam to get to the outside.

[davehorton]

The reason I ask is that the function notifyTerminateStaleDialog is only called in two instances:

• the far end failed to refresh the dialog in accordance with the negotiated session timer, or
• we sent a 200 OK to an INVITE to the UAC and got a CANCEL (race condition)

It should not be called in the normal course of things. Are either of those the scenario you are seeing? If not I would be interested to see the drachtio log file containing an example call

[danieludy]

It would take me quite a while to scrub the logs to send.
Yes I am seeing this happen when the cancel from DS is sent just prior to receiving the 200OK in a B2BUA scenario.
So invite comes in from A leg and B2BUA invite is generated by Drachtio for B leg. 100/180 pass through. Now A leg sends a cancel to which DS/SRF respond with a 487. The cancel is then forwarded to the B leg which crosses with the 200OK in the proxy. Drachtio receives the 200OK for the invite followed by a 200 OK for the cancel. Drachtio then sends an ACK for the invite 200 OK followed quickly by the BYE that is attempting to bypass the proxy.

[davehorton]

I think a quick PR would certainly be the fastest way forward. Is there a reason you can't do that?

[danieludy]

I haven't been able to reproduce under test, timing is too tight... Let me see what I can sort out for tomorrow

[danieludy]

actually yeah, I should be able to do that

[danieludy]

#256