Re: [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 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Klaus Darilion wrote: 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) That's generally what I always do - manual routing for in-dialog requests. I was not aware that loose_route() is required for correct routing of in-dialog requests when they are record-routed back through the proxy. I think one of the reasons why this may not be much of an issue for me is because my proxy applications generally always have the proxy as the URI domain - I won't relay for !uri == myself. So, after the initial INVITE is rewritten, the UAC/UAS cores on either side send subsequent in-dialog requests to the same URI they sent the INVITE to. I would, of course, be eager to hear any methodological insights you may offer about what I'm doing incorrectly. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
I guess as long as all the clients are loose_routers (final target in the RURI) it will work even without loose_route, if you only have 1 proxy between the clients. Of course the forwarded in-dialgo requests will still have an Route header which is actually not RFC conform but ignored by allmost all SIP clients. I would say: dirty but it works in closed setups (no public Internet telephony) klaus Alex Balashov schrieb: Klaus Darilion wrote: So do you perform lookup() also for in_dialog requests? When necessary. Otherwise, A endpoint just provides the URI of the Z-end of the signaling path for the domain and I make special exceptions to relay that as long as I have the Call-ID stored somewhere, which I do. ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Klaus Darilion wrote: I guess as long as all the clients are loose_routers (final target in the RURI) it will work even without loose_route, if you only have 1 proxy between the clients. Of course the forwarded in-dialgo requests will still have an Route header which is actually not RFC conform but ignored by allmost all SIP clients. So, you're saying it's better to run loose_route() to have it consume this extraneous Route: header? -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Alex Balashov schrieb: Klaus Darilion wrote: I guess as long as all the clients are loose_routers (final target in the RURI) it will work even without loose_route, if you only have 1 proxy between the clients. Of course the forwarded in-dialgo requests will still have an Route header which is actually not RFC conform but ignored by allmost all SIP clients. So, you're saying it's better to run loose_route() to have it consume this extraneous Route: header? Better? hard to say But at least more elegant and standard conform klaus ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Klaus Darilion wrote: Alex Balashov schrieb: Klaus Darilion wrote: I guess as long as all the clients are loose_routers (final target in the RURI) it will work even without loose_route, if you only have 1 proxy between the clients. Of course the forwarded in-dialgo requests will still have an Route header which is actually not RFC conform but ignored by allmost all SIP clients. So, you're saying it's better to run loose_route() to have it consume this extraneous Route: header? Better? hard to say But at least more elegant and standard conform Well, thank you, I appreciate the insight. :) -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov [EMAIL PROTECTED] 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. ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas [EMAIL PROTECTED] wrote: On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov [EMAIL PROTECTED] 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 ... ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On Thu, Oct 16, 2008 at 1:13 PM, Alex Balashov [EMAIL PROTECTED] wrote: Ovidiu Sas wrote: On Thu, Oct 16, 2008 at 12:23 PM, Ovidiu Sas [EMAIL PROTECTED] wrote: On Thu, Oct 16, 2008 at 12:49 AM, Alex Balashov [EMAIL PROTECTED] 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. ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
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. ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [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: 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 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
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 [EMAIL PROTECTED] 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 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [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 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [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 [EMAIL PROTECTED] 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 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
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 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Now I didn't get it ... lol On Thu, Oct 16, 2008 at 3:07 PM, Alex Balashov [EMAIL PROTECTED] 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 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
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
http://www.asipto.com
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
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
Evariste Systems
Web: http://www.evaristesys.com/
Tel: (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
___
Users mailing list
Users@lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov [EMAIL PROTECTED] 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? ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Ovidiu Sas wrote: On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov [EMAIL PROTECTED] 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. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov [EMAIL PROTECTED] wrote: Ovidiu Sas wrote: On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov [EMAIL PROTECTED] 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. ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Ovidiu Sas wrote: On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov [EMAIL PROTECTED] wrote: Ovidiu Sas wrote: On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov [EMAIL PROTECTED] 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. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On Thu, Oct 16, 2008 at 12:02 AM, Alex Balashov [EMAIL PROTECTED] wrote: Ovidiu Sas wrote: On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov [EMAIL PROTECTED] wrote: Ovidiu Sas wrote: On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov [EMAIL PROTECTED] 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. ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
Ovidiu Sas wrote: On Thu, Oct 16, 2008 at 12:02 AM, Alex Balashov [EMAIL PROTECTED] wrote: Ovidiu Sas wrote: On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov [EMAIL PROTECTED] wrote: Ovidiu Sas wrote: On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov [EMAIL PROTECTED] 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. -- Alex Balashov Evariste Systems Web: http://www.evaristesys.com/ Tel: (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [Kamailio-Users] In-dialog request correlation without loose routing?
On Thu, Oct 16, 2008 at 12:06 AM, Alex Balashov [EMAIL PROTECTED] wrote: Ovidiu Sas wrote: On Thu, Oct 16, 2008 at 12:02 AM, Alex Balashov [EMAIL PROTECTED] wrote: Ovidiu Sas wrote: On Wed, Oct 15, 2008 at 11:46 PM, Alex Balashov [EMAIL PROTECTED] wrote: Ovidiu Sas wrote: On Wed, Oct 15, 2008 at 10:25 PM, Alex Balashov [EMAIL PROTECTED] 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). ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
Re: [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 ___ Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
