[OpenSIPS-Users] CANCELd dialogs with top-hiding hanging
Vlad Paiu
vladpaiu at opensips.org
Fri Nov 23 19:24:17 CET 2012
Hello Brett,
Yes, I'm quite positive that's your issue, and that commit should
definitely fix it.
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/288619bc/attachment.htm>
More information about the Users
mailing list