16 Oct
2008
16 Oct
'08
5:25 a.m.
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.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
16 Oct
16 Oct
6:26 a.m.
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov
<abalashov(a)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?
6:46 a.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
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?
6:51 a.m.
On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Ovidiu Sas wrote:
Is the BYE going through your server?
I don't have this issue.
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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.
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?
7:02 a.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
Ovidiu Sas wrote:
On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Yes.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
Ovidiu Sas wrote:
Is the BYE going through your server?
I don't have this issue. On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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.
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?
7:05 a.m.
On Thu, Oct 16, 2008 at 12:02 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Ovidiu Sas wrote:
Enable debug logs and check what's going on when the BYE is received.
On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Yes.
Ovidiu Sas wrote:
Is the BYE going through your server?
I don't have this issue.
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov
<abalashov(a)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.
7:06 a.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
Ovidiu Sas wrote:
On Thu, Oct 16, 2008 at 12:02 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
I did. The debug logs from the dialog module, even with maximum
verbosity turned on, are not very insightful. The dialog is not correlated.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
Ovidiu Sas wrote:
Enable debug logs and check what's going on when the BYE is received. On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Yes.
Ovidiu Sas wrote:
> On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov
> <abalashov(a)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.
7:09 a.m.
On Thu, Oct 16, 2008 at 12:06 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Ovidiu Sas wrote:
Post your config and the trace of a bad call (ngrep + kamailio logs).
On Thu, Oct 16, 2008 at 12:02 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
I did. The debug logs from the dialog module, even with maximum verbosity
turned on, are not very insightful. The dialog is not correlated.
Ovidiu Sas wrote:
Enable debug logs and check what's going on when the BYE is received.
On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
>
> Ovidiu Sas wrote:
>>
>> On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov
>> <abalashov(a)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.
7:49 a.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
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
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
7:23 p.m.
On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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.
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
7:29 p.m.
On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas <osas(a)voipembedded.com> wrote:
On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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 ...
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
8:13 p.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
Ovidiu Sas wrote:
On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas
<osas(a)voipembedded.com> wrote:
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
--
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 Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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 ... 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
8:38 p.m.
On Thu, Oct 16, 2008 at 1:13 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Ovidiu Sas wrote:
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.
On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas <osas(a)voipembedded.com>
wrote:
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.
On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
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 ... >
> 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.
8:58 p.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
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:
--
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 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.
9:31 p.m.
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(a)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:
--
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 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.
9:53 p.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
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.
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
9:59 p.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
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(a)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
>
>
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
10:06 p.m.
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
10:07 p.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
Ovidiu Sas wrote:
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
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.
10:13 p.m.
Now I didn't get it ...
lol
On Thu, Oct 16, 2008 at 3:07 PM, Alex Balashov
<abalashov(a)evaristesys.com> wrote:
Ovidiu Sas wrote:
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
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. 
10:15 p.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
On 10/16/08 22:07, Alex Balashov wrote:
Ovidiu Sas wrote:
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
http://www.asipto.com
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.
10:27 p.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
Daniel-Constantin Mierla wrote:
On 10/16/08 22:07, Alex Balashov wrote:
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
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
Ovidiu Sas wrote:
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 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.
10:34 p.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
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
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:
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!
Ovidiu Sas wrote:
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 > 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? :-)
17 Oct
17 Oct
10:54 a.m.
New subject: [Kamailio-Users] In-dialog request correlation without loose routing?
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
5880
days inactive
5881
days old
24 comments
4 participants
participants (4)
-
Alex Balashov -
Daniel-Constantin Mierla -
Klaus Darilion -
Ovidiu Sas