Hello,
I am attempting to tear down a call with a BYE packet generated externally (kind of similar to Kamailio fifo dlg_end_dlg).
Let me describe what I am trying to do in more depth and then I will continue to tell you the problem I think I am experiencing.
[PSTN SIP Proxy] -> [CORE SIP Proxy] -> [REGISTRAR] -> [UAC]
So the above layout is the normal call flow / structure of calls (incoming when originating from pstn) (outgoing when originating from uac).
I then have an "external" host - I am attempting to generate a BYE to [CORE SIP Proxy] and have it go both directions [PSTN] + [UAC].
So far I am able to get the call to tear down in only a single direction (only kill call with PSTN) or (only kill call with UAC).
I have not been able to kill both legs of the call.
I have tried sending a single BYE and using some dlg_bye("all") magic.
- does not work, only kills one leg of the call.
I have tried sending a BYE message to SIP Proxy for each leg (two BYE).
- does not work, only kills one leg of the call.
If I alternate the later method's BYE packet and only send A or B and not both Leg A or B will be killed... I think I am running into a race condition where the dialog is destroyed before the 2nd BYE packet is processed.
My Question - what am I doing wrong - or what is the best method to tackle this task?
Thank you for all of your help and time in advance.
Sincerely, Brandon Armstead
Hey Brandon,
Am 01.11.2011 um 22:48 schrieb Brandon Armstead:
[snip]
My Question - what am I doing wrong - or what is the best method to tackle this task?
If I get you right you are trying to emulate Kamailio's dlg_end_dlg functionality without involving Kamailio at all (except for passing forward the BYE requests). This makes your question sort of off-topic as processing BYE requests is a matter of RFC 3261 alone.
Apart from that, what you could do is take a look at the dialog module code and check how it implements dlg_end_dlg. An idea I have what you could possibly be doing wrong is not using the CSeq numbers that each party expects. I don't have the details at hand but if either CSeq number is off your UAs won't accept the BYE request.
Cheers,
--Timo
Timo,
Thank you for the input - I actually just figured out a resolution.
Apparently dlg_bye("all") must be called after dlg_get - so what I'm doing now is simply checking for request with a special request uri with the callid / from tag / to tag in the request that correlates to the call I desire to terminate. I am then feeding $ci, $tt, and $ft into dlg_get and then calling dlg_bye("all") - in which Kamailio then proceeds to send BYE out to both legs of the call.
I think we can mark this as resolved :).
Thanks as always!
Sincerely, Brandon Armstead
On Tue, Nov 1, 2011 at 3:21 PM, Timo Reimann sr@foo-lounge.de wrote:
Hey Brandon,
Am 01.11.2011 um 23:44 schrieb Brandon Armstead:
OK, very good. :)
Let me make sure that this isn't a dialog module bug: You are now calling dlg_get() followed by dlg_bye() with proper parameters from within the Kamailio configuration script? if so, you shouldn't need to call dlg_get() in the first place, at least not if you place dlg_bye() after the call to loose_route(). Contrary, using certain dialog features (including dlg_bye()) from reply routes isn't completely possible yet which could explain your findings.
Cheers,
--Timo
Timo,
Thats correct - however I am calling this before loose_route, perhaps that is my problem and need for calling dlg_get? Let me give this a go - and I will respond back with my findings, thanks!
Sincerely, Brandon Armstead
On Tue, Nov 1, 2011 at 4:21 PM, Timo Reimann sr@foo-lounge.de wrote:
Hey Brandon,
Am 02.11.2011 um 00:32 schrieb Brandon Armstead:
Thats correct - however I am calling this before loose_route, perhaps that is my problem and need for calling dlg_get? Let me give this a go - and I will respond back with my findings, thanks!
Yeah, that should be it -- linking to the currently active dialog is being implemented as a callback to record-routed messages which takes place after a call to loose_route().
Looking forward to hearing your findings. :)
Cheers,
--Timo
Timo,
Some interesting results indeed. If I place the same block of code with or without dlg_get first then dlg_bye AFTER loose_route -- kamailio ignores the packet.
If I place it before loose_route WITH dlg_get FIRST - it works as expected.
Sincerely, Brandon Armstead
On Tue, Nov 1, 2011 at 4:42 PM, Timo Reimann sr@foo-lounge.de wrote:
Hey,
Am 02.11.2011 um 08:24 schrieb Brandon Armstead:
Some interesting results indeed. If I place the same block of code with or without dlg_get first then dlg_bye AFTER loose_route -- kamailio ignores the packet.
If I place it before loose_route WITH dlg_get FIRST - it works as expected.
What do you mean by "kamailio ignores the packet"? Is this equivalent to what you described initially regarding dialogs that were terminated single-sided only?
Cheers,
--Timo
Timo,
It is not equivalent. Essentially what I see happening is the BYE packet just comes in - however Kamailio does nothing with it. It is not relayed - simply nothing at all happens, on a network level I just see the BYE coming into the Kamailio proxy and zero response or reaction from Kamailio.
Sincerely, Brandon Armstead
On Wed, Nov 2, 2011 at 2:04 PM, Timo Reimann sr@foo-lounge.de wrote:
Hey Brandon,
Am 02.11.2011 um 22:13 schrieb Brandon Armstead:
It is not equivalent. Essentially what I see happening is the BYE packet just comes in - however Kamailio does nothing with it. It is not relayed - simply nothing at all happens, on a network level I just see the BYE coming into the Kamailio proxy and zero response or reaction from Kamailio.
So for some reason Kamailio decides that it will not forward the package, possibly because it cannot determine the next hop. Can you increase debug verbosity on the dropping Kamailio and see what it has to say with respect to the scenario in question?
By the way, may I assume that you are sending BYE requests on an established call, i.e., one where the SIP handshake (INVITE/200/ACK) has already concluded successfully?
Cheers,
--Timo
-
Brandon Armstead -
Timo Reimann