[OpenSIPS-Users] CANCELd dialogs with top-hiding hanging

[Brett Nemeroff]

Hey All,
I'm doing simple dialog based topo hiding and I noticed that CANCELd
dialogs are hanging around in state 5. They are starting to stack up.

Here's an example of one of the dialogs.. I kind of thought that when the
timeout ran down, the dialog would disappear, but it's not:

dialog::  hash=1645:1160860947

state:: 5

user_flags:: 0

timestart:: 0

timeout:: 0

callid:: 69126-1353462109-9996 at 1.2.3.4

from_uri:: sip:14387649628 at 1.2.3.4:5060

to_uri:: sip:50931111111 at 5.6.7.8

caller_tag:: 201142122000875167015

caller_contact:: sip:1.2.3.4:5060;transport=udp

callee_cseq:: 0

caller_route_set::

caller_bind_addr:: udp:5.6.7.8:5060

callee_tag:: 2011411220122012615936129

callee_contact:: sip:9.8.7.6:5060;transport=udp

caller_cseq:: 1


This has been around for about 18 hours! SIP Trace looks pretty normal
really.


To properly support topo hiding, I've got this at the top of the route
processing:


        if (has_totag()) {

                if(is_method("INVITE|ACK|BYE|UPDATE|CANCEL")) {

                        if(match_dialog()) {

                                t_relay();

                                exit;

                        }

                }


I originally didn't include CANCEL in the method check, but it caused
CANCELs to be ignored by one of the endpoints. Granted, I know the
endpoints are using switches that arn't known for being very compliant.
When I added in CANCEL in this check, the sip traces now look proper and
both sides are happy with the request being terminated, but the dialog
persists in memory.


Any ideas why these dialogs are not clearing out of opensips?



Thanks,

Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121121/8e36ac33/attachment.htm>