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

[Vlad Paiu]

Hello Brett,

Yes, I'm quite positive that's your issue, and that rev >= 9382 has it 
fixed.

Regards,
Vlad

Pe 11/23/2012 5:50 PM, Brett Nemeroff a scris:
> Vlad,
> This is actually 8772. There is no question the CANCEL has a to-tag 
> and no Route headers. So I suppose that would be the issue?
>
> Thanks,
> Brett
>
>
> On Wed, Nov 21, 2012 at 4:15 PM, Vlad Paiu <vladpaiu at opensips.org 
> <mailto:vladpaiu at opensips.org>> wrote:
>
>     Hello,
>
>     What is the OpenSIPS SVN version and revision that you are using ?
>     There was recently a bug found, where dialogs would get stuck for
>     Cancels that had a To-Tag, and it was fixed in rev 9382 .
>
>     Regards,
>     Vlad
>
>     Pe 11/21/2012 9:19 PM, Brett Nemeroff a scris:
>>     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
>>     <mailto:69126-1353462109-9996 at 1.2.3.4>
>>
>>     from_uri:: sip:14387649628 at 1.2.3.4:5060
>>     <http://sip:14387649628@1.2.3.4:5060>
>>
>>     to_uri:: sip:50931111111 at 5.6.7.8 <mailto:sip%3A50931111111 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 <http://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
>>
>>
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.opensips.org  <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20121123/ae3a3cf5/attachment-0001.htm>