Hi Herman,
sorry for delay - please apply the attached patch and run again the call
- send me the debug log.
Thanks and regards,
Bogdan
Herman Bastiaens wrote:
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
Index: modules/dialog/dlg_hash.c
===================================================================
--- modules/dialog/dlg_hash.c (revision 5441)
+++ modules/dialog/dlg_hash.c (working copy)
@@ -395,8 +395,17 @@
dlg_lock( d_table, d_entry);
+ LM_DBG("input ci=<%.*s>(%d), tt=<%.*s>(%d), ft=<%.*s>(%d)\n",
+ callid->len,callid->s, callid->len,
+ ftag->len, ftag->s, ftag->len,
+ ttag->len, ttag->s, ttag->len);
+
for( dlg = d_entry->first ; dlg ; dlg = dlg->next ) {
/* Check callid / fromtag / totag */
+ LM_DBG("DLG: ci=<%.*s>(%d), tt=<%.*s>(%d), ft=<%.*s>(%d)\n",
+ dlg->callid.len,dlg->callid.s, dlg->callid.len,
+ dlg->tag[0].len,dlg->tag[0].s, dlg->tag[0].len,
+ dlg->tag[1].len,dlg->tag[1].s, dlg->tag[1].len);
if (match_dialog( dlg, callid, ftag, ttag, dir)==1) {
if (dlg->state==DLG_STATE_DELETED) {
dlg_unlock( d_table, d_entry);
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
