Also, is there a way to get the dialog module to match subsequent in-dialog requests (i.e. re-INVITEs, ACKs, BYEs) without using the dialog correlator field that gets stamped into the Route: header, and therefore requiring the use of loose_route() to read and consume?
I thought that switching the matching mode to pure SIP attributes only would do the trick, but it doesn't. They won't match.
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov abalashov@evaristesys.com wrote:
Also, is there a way to get the dialog module to match subsequent in-dialog requests (i.e. re-INVITEs, ACKs, BYEs) without using the dialog correlator field that gets stamped into the Route: header, and therefore requiring the use of loose_route() to read and consume?
I thought that switching the matching mode to pure SIP attributes only would do the trick, but it doesn't. They won't match.
I'm using the dialog module in match mode 2: modparam("dialog", "dlg_match_mode", 2) and all my in dialog requests are matched.
How do you know that you don't have a match?
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov abalashov@evaristesys.com wrote:
Also, is there a way to get the dialog module to match subsequent in-dialog requests (i.e. re-INVITEs, ACKs, BYEs) without using the dialog correlator field that gets stamped into the Route: header, and therefore requiring the use of loose_route() to read and consume?
I thought that switching the matching mode to pure SIP attributes only would do the trick, but it doesn't. They won't match.
I'm using the dialog module in match mode 2: modparam("dialog", "dlg_match_mode", 2) and all my in dialog requests are matched.
How do you know that you don't have a match?
Because the profile count stays the same based on $fU and increases with every call, and doesn't get torn down when the dialogs end.
On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov abalashov@evaristesys.com wrote:
Also, is there a way to get the dialog module to match subsequent in-dialog requests (i.e. re-INVITEs, ACKs, BYEs) without using the dialog correlator field that gets stamped into the Route: header, and therefore requiring the use of loose_route() to read and consume?
I thought that switching the matching mode to pure SIP attributes only would do the trick, but it doesn't. They won't match.
I'm using the dialog module in match mode 2: modparam("dialog", "dlg_match_mode", 2) and all my in dialog requests are matched.
How do you know that you don't have a match?
Because the profile count stays the same based on $fU and increases with every call, and doesn't get torn down when the dialogs end.
Is the BYE going through your server? I don't have this issue.
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov abalashov@evaristesys.com wrote:
Also, is there a way to get the dialog module to match subsequent in-dialog requests (i.e. re-INVITEs, ACKs, BYEs) without using the dialog correlator field that gets stamped into the Route: header, and therefore requiring the use of loose_route() to read and consume?
I thought that switching the matching mode to pure SIP attributes only would do the trick, but it doesn't. They won't match.
I'm using the dialog module in match mode 2: modparam("dialog", "dlg_match_mode", 2) and all my in dialog requests are matched.
How do you know that you don't have a match?
Because the profile count stays the same based on $fU and increases with every call, and doesn't get torn down when the dialogs end.
Is the BYE going through your server? I don't have this issue.
Yes.
On Thu, Oct 16, 2008 at 12:02 AM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov abalashov@evaristesys.com wrote:
Also, is there a way to get the dialog module to match subsequent in-dialog requests (i.e. re-INVITEs, ACKs, BYEs) without using the dialog correlator field that gets stamped into the Route: header, and therefore requiring the use of loose_route() to read and consume?
I thought that switching the matching mode to pure SIP attributes only would do the trick, but it doesn't. They won't match.
I'm using the dialog module in match mode 2: modparam("dialog", "dlg_match_mode", 2) and all my in dialog requests are matched.
How do you know that you don't have a match?
Because the profile count stays the same based on $fU and increases with every call, and doesn't get torn down when the dialogs end.
Is the BYE going through your server? I don't have this issue.
Yes.
Enable debug logs and check what's going on when the BYE is received.
Ovidiu Sas wrote:
On Thu, Oct 16, 2008 at 12:02 AM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov abalashov@evaristesys.com wrote:
Also, is there a way to get the dialog module to match subsequent in-dialog requests (i.e. re-INVITEs, ACKs, BYEs) without using the dialog correlator field that gets stamped into the Route: header, and therefore requiring the use of loose_route() to read and consume?
I thought that switching the matching mode to pure SIP attributes only would do the trick, but it doesn't. They won't match.
I'm using the dialog module in match mode 2: modparam("dialog", "dlg_match_mode", 2) and all my in dialog requests are matched.
How do you know that you don't have a match?
Because the profile count stays the same based on $fU and increases with every call, and doesn't get torn down when the dialogs end.
Is the BYE going through your server? I don't have this issue.
Yes.
Enable debug logs and check what's going on when the BYE is received.
I did. The debug logs from the dialog module, even with maximum verbosity turned on, are not very insightful. The dialog is not correlated.
On Thu, Oct 16, 2008 at 12:06 AM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
On Thu, Oct 16, 2008 at 12:02 AM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov abalashov@evaristesys.com wrote: > > Also, is there a way to get the dialog module to match subsequent > in-dialog requests (i.e. re-INVITEs, ACKs, BYEs) without using the > dialog correlator field that gets stamped into the Route: header, and > therefore requiring the use of loose_route() to read and consume? > > I thought that switching the matching mode to pure SIP attributes > only > would do the trick, but it doesn't. They won't match.
I'm using the dialog module in match mode 2: modparam("dialog", "dlg_match_mode", 2) and all my in dialog requests are matched.
How do you know that you don't have a match?
Because the profile count stays the same based on $fU and increases with every call, and doesn't get torn down when the dialogs end.
Is the BYE going through your server? I don't have this issue.
Yes.
Enable debug logs and check what's going on when the BYE is received.
I did. The debug logs from the dialog module, even with maximum verbosity turned on, are not very insightful. The dialog is not correlated.
Post your config and the trace of a bad call (ngrep + kamailio logs).
Post your config and the trace of a bad call (ngrep + kamailio logs).
Config: http://pastebin.com/f28051a5
My debug output: http://pastebin.com/d2f667520 (The profile size just keeps incrementing with every call that I make from 7709600101)
Kamailio debug logs for dialog module: http://pastebin.com/d75721f2b
My debug output with loose routing: http://pastebin.com/d2b0fb533
Packet trace: http://pastebin.com/d77297606
On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov abalashov@evaristesys.com wrote:
Post your config and the trace of a bad call (ngrep + kamailio logs).
Config: http://pastebin.com/f28051a5
My debug output: http://pastebin.com/d2f667520 (The profile size just keeps incrementing with every call that I make from 7709600101)
Kamailio debug logs for dialog module: http://pastebin.com/d75721f2b
My debug output with loose routing: http://pastebin.com/d2b0fb533
Packet trace: http://pastebin.com/d77297606
Your config is bogus. You are not doing proper record-routing (you commented out that section). In-dialog requests are matched during record-route handling, regardless of the dialog match mode.
On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas osas@voipembedded.com wrote:
On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov abalashov@evaristesys.com wrote:
Post your config and the trace of a bad call (ngrep + kamailio logs).
Config: http://pastebin.com/f28051a5
My debug output: http://pastebin.com/d2f667520 (The profile size just keeps incrementing with every call that I make from 7709600101)
Kamailio debug logs for dialog module: http://pastebin.com/d75721f2b
My debug output with loose routing: http://pastebin.com/d2b0fb533
Packet trace: http://pastebin.com/d77297606
Your config is bogus. You are not doing proper record-routing (you commented out that section). In-dialog requests are matched during record-route handling, regardless of the dialog match mode.
The documentation is a little bit fuzzy about this, but here's the hint: http://kamailio.org/docs/modules/1.4.x/dialog#id2507978 http://kamailio.org/docs/modules/1.4.x/dialog#id2508031
<quote> This PV will be available only for sequential requests, after doing loose_route(). </quote>
So it means that you must perform loose_route() if you want to catch in-dialog request and have a consistent dialog state. With your config, all the dialogs will just time out ...
Ovidiu Sas wrote:
On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas osas@voipembedded.com wrote:
On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov abalashov@evaristesys.com wrote:
Post your config and the trace of a bad call (ngrep + kamailio logs).
Config: http://pastebin.com/f28051a5
My debug output: http://pastebin.com/d2f667520 (The profile size just keeps incrementing with every call that I make from 7709600101)
Kamailio debug logs for dialog module: http://pastebin.com/d75721f2b
My debug output with loose routing: http://pastebin.com/d2b0fb533
Packet trace: http://pastebin.com/d77297606
Your config is bogus. You are not doing proper record-routing (you commented out that section). In-dialog requests are matched during record-route handling, regardless of the dialog match mode.
The documentation is a little bit fuzzy about this, but here's the hint: http://kamailio.org/docs/modules/1.4.x/dialog#id2507978 http://kamailio.org/docs/modules/1.4.x/dialog#id2508031
<quote> This PV will be available only for sequential requests, after doing loose_route(). </quote>
So it means that you must perform loose_route() if you want to catch in-dialog request and have a consistent dialog state. With your config, all the dialogs will just time out ...
What? I did not commend out the record_route section:
if(!is_method("REGISTER|OPTIONS")) record_route();
The reason I commented out the loose_route() section was specifically to illustrate that dialog correlation does not occur _without_ it. I normally have it enabled.
That was the topic of my original post: how to correlate dialogs purely based on SIP attributes without the use of loose-routing.
It would seem to follow from what you are saying, from the documentation hint you reference (which I read before), and from my examination of the source code to see how the dialog correlation works that the only way it could possibly work is through the use of a dialog correlate attribute in the Route: header. That is why a call to loose_route() is necessary, and that is why subsequent in-dialog requests do not get correlated without it.
-- Alex
On Thu, Oct 16, 2008 at 1:13 PM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas osas@voipembedded.com wrote:
On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov abalashov@evaristesys.com wrote:
Post your config and the trace of a bad call (ngrep + kamailio logs).
Config: http://pastebin.com/f28051a5
My debug output: http://pastebin.com/d2f667520 (The profile size just keeps incrementing with every call that I make from 7709600101)
Kamailio debug logs for dialog module: http://pastebin.com/d75721f2b
My debug output with loose routing: http://pastebin.com/d2b0fb533
Packet trace: http://pastebin.com/d77297606
Your config is bogus. You are not doing proper record-routing (you commented out that section). In-dialog requests are matched during record-route handling, regardless of the dialog match mode.
The documentation is a little bit fuzzy about this, but here's the hint: http://kamailio.org/docs/modules/1.4.x/dialog#id2507978 http://kamailio.org/docs/modules/1.4.x/dialog#id2508031
<quote> This PV will be available only for sequential requests, after doing loose_route(). </quote>
So it means that you must perform loose_route() if you want to catch in-dialog request and have a consistent dialog state. With your config, all the dialogs will just time out ...
What? I did not commend out the record_route section:
if(!is_method("REGISTER|OPTIONS")) record_route();The reason I commented out the loose_route() section was specifically to illustrate that dialog correlation does not occur _without_ it. I normally have it enabled.
That was the topic of my original post: how to correlate dialogs purely based on SIP attributes without the use of loose-routing.
It would seem to follow from what you are saying, from the documentation hint you reference (which I read before), and from my examination of the source code to see how the dialog correlation works that the only way it could possibly work is through the use of a dialog correlate attribute in the Route: header. That is why a call to loose_route() is necessary, and that is why subsequent in-dialog requests do not get correlated without it.
It seems that I misunderstood your initial question ... You must use loose_route because this will trigger the dialog callback. Now how you match your dialog, it's a different story.
I thought that you were complaining about db_dialog_match_mode 2.
Yep. That was the conclusion I came to as well; even though dlg_match_mode insinuates that the cookie attribute is optional, implying there are other ways to match subsequent requests as well, it is actually not.
On Thu, October 16, 2008 1:45 pm, Ovidiu Sas wrote:
That was the topic of my original post: how to correlate dialogs purely based on SIP attributes without the use of loose-routing.
short answer: you can't (and the matching method doesn't matter). proper loose-routing is a must.
The cookie attribute is not used at all in mode 2. Inspect your traffic and you will see that there are no rr coockes and the dialog matching is working ok (in mode 2). The record-route mechanism is used as a _hook_ by the dialog module to intercept in dialog requests. I don't know how to put this better in words ... Hope that this clarifies your dialog matching issue.
So ... the dlg_match_mode works as advertised in the doc as long as you have a proper implementation of the record rote mechanism. For mode 0 and 1 you will have cookies in the Record-Route headers. For mode 2 you will have no cookies in the Record-Route headers and the matching will still work.
Regards, Ovidiu Sas
On Thu, Oct 16, 2008 at 1:58 PM, Alex Balashov abalashov@evaristesys.com wrote:
Yep. That was the conclusion I came to as well; even though dlg_match_mode insinuates that the cookie attribute is optional, implying there are other ways to match subsequent requests as well, it is actually not.
On Thu, October 16, 2008 1:45 pm, Ovidiu Sas wrote:
That was the topic of my original post: how to correlate dialogs purely based on SIP attributes without the use of loose-routing.
short answer: you can't (and the matching method doesn't matter). proper loose-routing is a must.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
That's what I thought too, looking at the traffic. My guess is it correlates by to-tag and/or Call-ID GUID.
Are you using "record-route mechanism" and "loose-routing" interchangeably? To me, they are very different things. Record-route causes the subsequent in-dialog requests from both ends to be routed through the server, which is something that I did have applied in my configuration. Loose routing does what RFC 3261 says it does, and specifically in this case, it processes the Route: header and modifies the RURI if necessary.
What I commented out was loose-routing, and with that, request correlation broke - even in dlg_match_mode 2. So, what I am assuming is that loose routing is still necessary for the correlation to work, with or without the cookie.
My question was why that was so, as there appeared to be no obvious reason for this as long as record-routing is turned on.
-- Alex
Ovidiu Sas wrote:
The cookie attribute is not used at all in mode 2. Inspect your traffic and you will see that there are no rr coockes and the dialog matching is working ok (in mode 2). The record-route mechanism is used as a _hook_ by the dialog module to intercept in dialog requests. I don't know how to put this better in words ... Hope that this clarifies your dialog matching issue.
So ... the dlg_match_mode works as advertised in the doc as long as you have a proper implementation of the record rote mechanism. For mode 0 and 1 you will have cookies in the Record-Route headers. For mode 2 you will have no cookies in the Record-Route headers and the matching will still work.
And specifically, the ambiguity I am referring to in your narrative is the following:
1) In your first reply to me after I posted the configs, you said:
"Your config is bogus. You are not doing proper record-routing (you commented out that section). In-dialog requests are matched during record-route handling, regardless of the dialog match mode."
2) In your subsequent reply to yourself and clarification of the issue with reference to the dialog docs, you say:
"The documentation is a little bit fuzzy about this, but here's the hint: http://kamailio.org/docs/modules/1.4.x/dialog#id2507978 http://kamailio.org/docs/modules/1.4.x/dialog#id2508031
<quote> This PV will be available only for sequential requests, after doing loose_route(). </quote>
So it means that you must perform loose_route() if you want to catch in-dialog request and have a consistent dialog state. With your config, all the dialogs will just time out ..."
3) So, which one is it? If I need to record_route(), that is obvious; you cannot monitor dialogs if subsequent in-dialog requests do not pass through the proxy. I am doing that.
If it is loose_route() that I need to correlate subsequent in-dialog requests, why? As you said, if no RR cookies are being used, why should the proxy care about the Route: header?
Thanks,
-- Alex
Ovidiu Sas wrote:
The cookie attribute is not used at all in mode 2. Inspect your traffic and you will see that there are no rr coockes and the dialog matching is working ok (in mode 2). The record-route mechanism is used as a _hook_ by the dialog module to intercept in dialog requests. I don't know how to put this better in words ... Hope that this clarifies your dialog matching issue.
So ... the dlg_match_mode works as advertised in the doc as long as you have a proper implementation of the record rote mechanism. For mode 0 and 1 you will have cookies in the Record-Route headers. For mode 2 you will have no cookies in the Record-Route headers and the matching will still work.
Regards, Ovidiu Sas
On Thu, Oct 16, 2008 at 1:58 PM, Alex Balashov abalashov@evaristesys.com wrote:
Yep. That was the conclusion I came to as well; even though dlg_match_mode insinuates that the cookie attribute is optional, implying there are other ways to match subsequent requests as well, it is actually not.
On Thu, October 16, 2008 1:45 pm, Ovidiu Sas wrote:
That was the topic of my original post: how to correlate dialogs purely based on SIP attributes without the use of loose-routing.
short answer: you can't (and the matching method doesn't matter). proper loose-routing is a must.
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
If it is loose_route() that I need to correlate subsequent in-dialog requests, why? As you said, if no RR cookies are being used, why should the proxy care about the Route: header?
I don't know how to put it better in other words :( The proxy doesn't care about the Route header. The proxy uses the record routing mechanism as a hook into the dialog internals and the matching is done inside the dialog module. After that, the dialog module will chose the matching mechanism.
Regards, Ovidiu Sas
Ovidiu Sas wrote:
If it is loose_route() that I need to correlate subsequent in-dialog requests, why? As you said, if no RR cookies are being used, why should the proxy care about the Route: header?
I don't know how to put it better in other words :( The proxy doesn't care about the Route header. The proxy uses the record routing mechanism as a hook into the dialog internals and the matching is done inside the dialog module. After that, the dialog module will chose the matching mechanism.
I got that.
So, why does matching not work unless I call loose_route(), regardless of match mode? :-)
Now I didn't get it ... lol
On Thu, Oct 16, 2008 at 3:07 PM, Alex Balashov abalashov@evaristesys.com wrote:
Ovidiu Sas wrote:
If it is loose_route() that I need to correlate subsequent in-dialog requests, why? As you said, if no RR cookies are being used, why should the proxy care about the Route: header?
I don't know how to put it better in other words :( The proxy doesn't care about the Route header. The proxy uses the record routing mechanism as a hook into the dialog internals and the matching is done inside the dialog module. After that, the dialog module will chose the matching mechanism.
I got that.
So, why does matching not work unless I call loose_route(), regardless of match mode? :-)
-- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599
On 10/16/08 22:07, Alex Balashov wrote:
Ovidiu Sas wrote:
If it is loose_route() that I need to correlate subsequent in-dialog requests, why? As you said, if no RR cookies are being used, why should the proxy care about the Route: header?
I don't know how to put it better in other words :( The proxy doesn't care about the Route header. The proxy uses the record routing mechanism as a hook into the dialog internals and the matching is done inside the dialog module. After that, the dialog module will chose the matching mechanism.
I got that.
So, why does matching not work unless I call loose_route(), regardless of match mode? :-)
the matching is triggered by execution of Route processing callbacks that happen only by calling loose_route().
The dialog module registers a function to be called when the Route header is processed. In this function the dialog module does the matching algorithm. To get independent of that, for matching mode 2, a function should be exported by dialog for explicit call in the script, something like:
if(dialog_match()) { .... }
Cheers, Daniel
Daniel-Constantin Mierla wrote:
On 10/16/08 22:07, Alex Balashov wrote:
Ovidiu Sas wrote:
If it is loose_route() that I need to correlate subsequent in-dialog requests, why? As you said, if no RR cookies are being used, why should the proxy care about the Route: header?
I don't know how to put it better in other words :( The proxy doesn't care about the Route header. The proxy uses the record routing mechanism as a hook into the dialog internals and the matching is done inside the dialog module. After that, the dialog module will chose the matching mechanism.
I got that.
So, why does matching not work unless I call loose_route(), regardless of match mode? :-)
the matching is triggered by execution of Route processing callbacks that happen only by calling loose_route().
The dialog module registers a function to be called when the Route header is processed. In this function the dialog module does the matching algorithm. To get independent of that, for matching mode 2, a function should be exported by dialog for explicit call in the script, something like:
if(dialog_match()) { .... }
Cheers, Daniel
That's what I figured; there was something in the callback architecture that caused the module to otherwise not see the requests.
Cool - that explains it!
Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
On 10/16/08 22:07, Alex Balashov wrote:
Ovidiu Sas wrote:
If it is loose_route() that I need to correlate subsequent in-dialog requests, why? As you said, if no RR cookies are being used, why should the proxy care about the Route: header?
I don't know how to put it better in other words :( The proxy doesn't care about the Route header. The proxy uses the record routing mechanism as a hook into the dialog internals and the matching is done inside the dialog module. After that, the dialog module will chose the matching mechanism.
I got that.
So, why does matching not work unless I call loose_route(), regardless of match mode? :-)
the matching is triggered by execution of Route processing callbacks that happen only by calling loose_route().
The dialog module registers a function to be called when the Route header is processed. In this function the dialog module does the matching algorithm. To get independent of that, for matching mode 2, a function should be exported by dialog for explicit call in the script, something like:
if(dialog_match()) { .... }
Cheers, Daniel
That's what I figured; there was something in the callback architecture that caused the module to otherwise not see the requests.
Cool - that explains it!
BTW, I do think it would be a good idea for the dialog module to export these functions directly into the script symbols so they can be called that way. I do not like to do loose routing unnecessarily / when I have no use for it.
-- Alex
Alex Balashov schrieb:
BTW, I do think it would be a good idea for the dialog module to export these functions directly into the script symbols so they can be called that way. I do not like to do loose routing unnecessarily / when I have no use for it.
How does your setup work without loose_route? The proxy sees in-dialog requests only if you record_route. If you do record_route(), you have to use loose_route for correct routing. You can't have one without the other (except you do manual routing also for in-dialog requests)
klaus
-
Alex Balashov -
Daniel-Constantin Mierla -
Klaus Darilion -
Ovidiu Sas