[OpenSIPS-Devel] dialog module: dialog not cleaned up when BYE is sent

Herman Bastiaens herman.bastiaens at androme.be
Wed Mar 4 11:53:32 CET 2009


I forgot to answer one of your questions -Also, is the dialog still 
present in the DB?-

I don't save the dialog state to a DB, I could turn this on if that 
would help. If needed, I guess I should use the REALTIME db_mode and a 
db_update_period of 1 second or something?

> Bogdan,
> 
> after the BYE, the dialog state is:
> 
> dialog::  hash=81:1143892611
>     state:: 3
>     timestart:: 1236163488
>     timeout:: 1908
>     callid:: 990261669 at somehost.com
>     from_uri:: sip:intellivic.test1 at demo.intellivic.com
>     from_tag:: 1729043143
>     caller_contact:: sip:me at 172.17.10.44:5070
>     caller_cseq:: 2
>     caller_route_set::
>     caller_bind_addr:: udp:172.17.10.44:5060
>     to_uri:: 
> sip:aa at demo.intellivic.com;x-token=UdivkLQ9ehiLkJ01K1SNwT0ROVoviFIn
>     to_tag:: 1669544808
>     callee_contact:: sip:aa at 193.190.10.203:51571
>     callee_cseq:: 2
>     callee_route_set:: <sip:193.190.155.175:5070;ftag=1729043143;lr=on>
>     callee_bind_addr:: udp:172.17.10.44:5060
> 
> 
> I do the unset_dlg_profile() on a negative reply, because the dialog is 
> not destroyed fast enough. This is the scenario:
>  -- INVITE -->
>    // check that there are no calls active
>  <-- 407 --
>    // the dialog will be destroyed, but this takes some time (perhaps 
> because the transaction is not yet destroyed?)
>  -- ACK -->
>  -- INVITE (with authentication) -->
>    // check that there are no calls active
>    // this check fails if the unset_dlg_profile () is not invoked
> 
>> Herman,
>>
>> So after the BYE, what is the exact dialog state reported by MI cmd? 
>> (please post the output)
>>
>> Also, is the dialog still present in the DB?
>>
>> BTW, you do not have to do unset_dlg_profile() if negative reply is 
>> received - this will happen automatically as the dialog will be 
>> destroyed (theoretically :D)
>>
>> Regards,
>> Bogdan
>>
>> Herman Bastiaens wrote:
>>> Hi bogdan,
>>>
>>> I use the MI dlg_list, the dialog state is not written to DB.
>>>
>>> PS: like Takeshi, I also clear the profile with unset_dlg_profile on 
>>> reception of a 4XX
>>>
>>> Regards,
>>>
>>> Herman
>>>
>>>>> Hi Herman,
>>>>>
>>>>> when you say the dialog is not removed, how do you check ? do you 
>>>>> check
>>>>> with the MI dlg_list command or you look into DB ?
>>>>
>>>> Hello, Bogdan and Herman.
>>>> I am seeing similar thing on kamailio (but I measured the interval as
>>>> 3 to 4 seconds). So this seems to be something inherited from openSER.
>>>> If I understood Herman's description of the problem correctly, he is
>>>> putting the dialog in a profile and then he would expect the dialog to
>>>> be cleared from the profile upon reception of BYE.
>>>> I'm using profile this way too, to control limit of simultaneous calls
>>>> to our subscribers. So if we try to perform consecutive test calls
>>>> using something like SIPp with a max_calls set to 1 in my cfg file, if
>>>> the duration of the call is less than 4 seconds, the subsequent call
>>>> will fail because when we use profile_get_size, it returns 1, instead
>>>> of the expected zero.
>>>>
>>>> For us however, this is not a concern anymore as this is very rare
>>>> situation. And actually, what was causing problem to us was the case
>>>> where the distant end sends a 4XX response within 4 seconds which has
>>>> the same delay to cause the profile to be cleared (I'm not sure if
>>>> this applies to opensips). But this is not a problem as we are forcing
>>>> the clearing using unset_dlg_profile.
>>>>
>>>> regards,
>>>> takeshi
>>>>
>>>>> Herman Bastiaens wrote:
>>>>>> Hi Bodgan,
>>>>>>
>>>>>> that's what I'm seeing, time and time again. I was hoping this might
>>>>>> ring a bell, but from your reply I take that it doesn't :-)
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Herman
>>>>>>
>>>>>>> Hi Herman,
>>>>>>>
>>>>>>> just to copy the reply from the forum :) :
>>>>>>>
>>>>>>> So, let me see if I get it right. With the same configuration, if 
>>>>>>> the
>>>>>>> call is longer than 5 secs, everything is ok (dialog is removed when
>>>>>>> receiving a BYE). But if the call is shorter than 5 secs, the dialog
>>>>>>> is not removed.
>>>>>>> Is this what you say?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Bogdan
>>>>>>>
>>>>>>> Herman Bastiaens wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I've posted this problem on the forum
>>>>>>>> (https://sourceforge.net/forum/message.php?msg_id=6595314), but it
>>>>>>>> doesn't seem to be very active, so I'm posting it here as well.
>>>>>>>>
>>>>>>>> I'm having a problem with the dialog module of opensips 
>>>>>>>> 1.4.2-notls.
>>>>>>>> When a call is set up, and released within five seconds, the dialog
>>>>>>>> is not removed. I am sure the call is set up correctly (INVITE - 
>>>>>>>> 200
>>>>>>>> OK - ACK) and the BYE is sent (with the correct call-id, from 
>>>>>>>> and to
>>>>>>>> tag), but the dialog is not removed.
>>>>>>>>
>>>>>>>> I do a record_route_preset () for the INVITE and a loose_route() 
>>>>>>>> for
>>>>>>>> the BYE.
>>>>>>>>
>>>>>>>> Are there any timers, caching, ... that could explain this 
>>>>>>>> behavior?
>>>>>>>> I have tested a number of times, and the problem only occurs if the
>>>>>>>> call is shut down within the first five seconds, if the call is
>>>>>>>> running longer, the dialog is cleaned up correctly when the BYE is
>>>>>>>> sent.
>>>>>>>>
>>>>>>>> note: a dialog is inserted multiple times in the same profile, but
>>>>>>>> with different values, I don't know if this is relevant for the 
>>>>>>>> issue
>>>>>>>>
>>>>>>>>
>>>>>>> ------------------------------------------------------------------------ 
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> No virus found in this incoming message.
>>>>>>> Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database:
>>>>>>> 270.11.6/1981 - Release Date: 03/03/09 07:25:00
>>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>>>>
>>>>
>>>
>>>
>>
>>
> 
> 
> 




More information about the Devel mailing list