Hi Bogdan, yes, I see these messages in the log. You can also find them in the log I've sent you on monday (09-03). Because the DID was not present (due to the record_route_preset bug), the matching mode falls back to matching based on SIP elements.
Best Regards, Herman Bogdan-Andrei Iancu wrote: > Hi Herman, > > yes, that is correct. When you use mode 2 (no did), for ACK and BYE, do > you get something like this in the logs: "no dialog callid=" ? > > Regards, > Bogdan > > Herman Bastiaens wrote: >> Hi Bogdan, >> >> the issue is resolved when using the DID for dialog matching, but if I >> use dlg_match_mode 2, the error still occurs. Is there a problem with >> the matching of messages to dialogs if there is no DID present? >> >> Best Regards, >> >> Herman >> >> Bogdan-Andrei Iancu wrote: >>> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -- Best regards, Herman ------------------------------------------------------------ Herman Bastiaens Tel: (+32) 11 30 13 30 ANDROME NV Fax: (+32) 11 30 13 31 Wetenschapspark 4 mailto:hbastia...@androme.be B-3590 Diepenbeek, Belgium http://www.androme.be _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users