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

[Bogdan-Andrei Iancu]

Hi Herman,

Thanks for the files you sent me. I found out that the problem was in 
record_route_preset() - the function was simply ignoring whatever 
parameter you were adding from script or from other modules. This is why 
the  DIALOG module was not recognizing the sequential requests.

The fix is available on 1.5 - if you could give it another try and let 
me know, it will be great.

Regards,
Bogdan

Herman Bastiaens wrote:
> Hi Bogdan,
>
> xxxxx
>
> The problem only occurs:
> - if there is another server in the loop, if I test with a client 
> that's registered to xxxxxx (instead of the demo server), the issue 
> does not occur
> - if I record_route_preset instead of record_route. As you'll see, 
> when I record_route_preset, there is no did present in the route 
> header. I believe it should fall back to "default" dialog matching, 
> but perhaps there's a problem with this mechanism?
>
> Hope we can sort this out. Thanks for your replies!
>
> Bogdan-Andrei Iancu wrote:
>> Hi Herman,
>>
>> Sorry for the mixing :).
>>
>> Please get the logs (with debug=6) and the SIP trace (ngrep) for such 
>> a call and sent them to me (you can send them off-list if larger than 
>> 40K).
>>
>> I cannot make any assumption yet without first looking at the logs.
>>
>> Thanks and regards,
>> Bogdan
>>
>> Herman Bastiaens wrote:
>>> Bogdan,
>>>
>>> I didn't post the log on the forum, that was someone else. I just 
>>> added my comment to the thread because it seemed like the same 
>>> problem. I can get a log of the scenario tomorrow if that's helpful.
>>>
>>> Do you have any idea why the record_route_preset could by messing up 
>>> this scenario?
>>> Do you have any idea what could explain the 5 second threshold?
>>>
>>> Thanks a lot for your replies, hope we can sort this out.
>>>
>>>> Herman,
>>>>
>>>> The log you posted on the forum did not show any usage of 
>>>> loose_route() - if you look on the log, for ACK and BYE there is no 
>>>> mesage from "rr" or "dialog" module. Can you confirm this?
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>> Herman Bastiaens wrote:
>>>>> Hi Bogdan,
>>>>>
>>>>> I'm pretty sure I do a loose_route for the ACK and BYE, but I'm 
>>>>> still seeing this error.
>>>>>
>>>>> I've tested the most basic scenario, starting from an example, and 
>>>>> this problem seems to occur when I start using a 
>>>>> record_route_preset("..."). Perhaps the dialog module can't handle 
>>>>> this? (just to be clear, the bug is still only occurring if the 
>>>>> call is shut down during the first few seconds after the ACK).
>>>>>
>>>>> I've attached the script in which I see the error occurring. The 
>>>>> IP of my server is 172.17.10.44
>>>>>
>>>>>> Hi Herman,
>>>>>>
>>>>>> And the bell rang! :)
>>>>>>
>>>>>> I went over the logs you posted on the forum and I noticed (both 
>>>>>> script and logs) that you are not using loose_route() for 
>>>>>> sequential requests. You do record_route() for the initial 
>>>>>> INVITE, but no loose_route for ACK, BYE. And loose_route() is the 
>>>>>> function that updates the dialog state.
>>>>>>
>>>>>> So, in your case, the dialog does not "see" the ACK and BYE and 
>>>>>> still keeps in the CONFIRMED_NA (not acknowledged) state. This  
>>>>>> is way it is not removed.
>>>>>>
>>>>>> See the default opensips.cfg file to see how to use the 
>>>>>> loose_route(). I beat it will work after that ;)
>>>>>>
>>>>>> Regards,
>>>>>> Bogdan
>>>>>>
>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 
>>>> 270.11.8/1985 - Release Date: 03/05/09 07:54:00
>>>>
>>>
>>>
>>
>>
>
>