Hi,
Am I not allowed to call dlg_manage() and add a dialog to a profile inside a request_route that is called out of a failure_route?
The sequence of events is like this:
1. INVITE ----------------> 2. <---------- 302 redirect 3. ACK -------------------> 4. INVITE (new branch) --->
It's in #4 that I add the dialog to a profile and call dlg_manage(). There's a slight ambiguity because I am calling in a request_route, but the request_route is really called from a failure_route that catches the 302. It contains common logic that is used in both #1 and #4. So, the message being processed is 302, but the execution context is request_route.
The docs say that dlg_manage() can be used in a request_route, and that set_dlg_profile() can be called from request/branch/reply/failure routes. But, I suppose it's logical that dlg_manage() ought to operate on the initial dialog-opening request. However, since the 302 is part of the same transaction as the initial INVITE, I would think that's okay. Is it?
Anyway, I get these messages a lot:
Apr 28 17:41:04 p01 /usr/local/sbin/kamailio[8581]: CRITICAL: dialog [dlg_profile.c:444]: set_dlg_profile(): BUG - dialog not found in a non REQUEST route (1) Apr 28 17:41:04 p02 /usr/local/sbin/kamailio[8581]: ERROR: dialog [dialog.c:800]: w_set_dlg_profile(): failed to set profile
At no point am I actually calling set_dlg_profile() outside of a request_route, but the request_route might be called from a failure_route.
So, the question is, am I doing something wrong? What's the best way to accommodate this scenario? I don't know if I want to track the dialog or add it to a profile until after I get the 302.
Thanks,
On 04/28/2014 01:49 PM, Alex Balashov wrote:
Hi,
[SNIP] So, the question is, am I doing something wrong? What's the best way to accommodate this scenario? I don't know if I want to track the dialog or add it to a profile until after I get the 302.
Out of curiosity, if you call set_dlg_profile() at the initial invite and then so something with this in event_route[dialog:failed], does it still error?
Fred Posner The Palner Group, Inc. fred@palner.com @fredposner
Good. Fast. Cheap. <- pick two
I don't think that will work, because no dialog is created by the 302 redirect.
On 29 April 2014 02:48:23 GMT+04:00, Fred Posner fred@palner.com wrote:
On 04/28/2014 01:49 PM, Alex Balashov wrote:
Hi,
[SNIP] So, the question is, am I doing something wrong? What's the
best way to
accommodate this scenario? I don't know if I want to track the dialog
or
add it to a profile until after I get the 302.
Out of curiosity, if you call set_dlg_profile() at the initial invite and then so something with this in event_route[dialog:failed], does it still error?
Fred Posner The Palner Group, Inc. fred@palner.com @fredposner
Good. Fast. Cheap. <- pick two
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from my mobile, and thus lacking in the refinement one might expect from a fully fledged keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0671 Web: http://www.evaristesys.com/, http://www.alexbalashov.com
On 04/28/2014 08:04 PM, Fred Posner wrote:
On 04/28/2014 06:54 PM, Alex Balashov wrote:
I don't think that will work, because no dialog is created by the 302 redirect.
11.3. event_route[dialog:failed]
Executed when dialog is not completed (+300 reply to INVITE).
Oh. I thought it required the construction of at least an early dialog in order to work. That's clever!
On 28/04/14 19:49, Alex Balashov wrote:
Hi,
Am I not allowed to call dlg_manage() and add a dialog to a profile inside a request_route that is called out of a failure_route?
The sequence of events is like this:
- INVITE ---------------->
- <---------- 302 redirect
- ACK ------------------->
- INVITE (new branch) --->
It's in #4 that I add the dialog to a profile and call dlg_manage(). There's a slight ambiguity because I am calling in a request_route, but the request_route is really called from a failure_route that catches the 302. It contains common logic that is used in both #1 and #4. So, the message being processed is 302, but the execution context is request_route.
The docs say that dlg_manage() can be used in a request_route, and that set_dlg_profile() can be called from request/branch/reply/failure routes. But, I suppose it's logical that dlg_manage() ought to operate on the initial dialog-opening request. However, since the 302 is part of the same transaction as the initial INVITE, I would think that's okay. Is it?
Anyway, I get these messages a lot:
Apr 28 17:41:04 p01 /usr/local/sbin/kamailio[8581]: CRITICAL: dialog [dlg_profile.c:444]: set_dlg_profile(): BUG - dialog not found in a non REQUEST route (1) Apr 28 17:41:04 p02 /usr/local/sbin/kamailio[8581]: ERROR: dialog [dialog.c:800]: w_set_dlg_profile(): failed to set profile
At no point am I actually calling set_dlg_profile() outside of a request_route, but the request_route might be called from a failure_route.
So, the question is, am I doing something wrong? What's the best way to accommodate this scenario? I don't know if I want to track the dialog or add it to a profile until after I get the 302.
I guess dialog has to be created in main request_route (or sub-route block executed from there) as it relies on some tm callbacks that could be related to transaction creation and first time forwarding.
Cheers, Daniel
Hi Daniel,
On 04/29/2014 09:03 AM, Daniel-Constantin Mierla wrote:
I guess dialog has to be created in main request_route (or sub-route block executed from there) as it relies on some tm callbacks that could be related to transaction creation and first time forwarding.
So, do you suppose I could achieve my objective by tracking every dialog--that is, by calling dlg_manage() in the initial request route for every call, and then calling set_dlg_profile() out of a failure route conditionally?
On 04/30/2014 04:16 AM, Alex Balashov wrote:
So, do you suppose I could achieve my objective by tracking every dialog--that is, by calling dlg_manage() in the initial request route for every call, and then calling set_dlg_profile() out of a failure route conditionally?
Wouldn't you need to set it within the original invite and then "do something" with it in the event_route[dialog:failed]?
Fred Posner The Palner Group, Inc. 503-914-0999 (direct) 954-472-2896 (fax)
Good. Fast. Cheap. <- Pick two.
On 04/30/2014 08:02 AM, Fred Posner wrote:
On 04/30/2014 04:16 AM, Alex Balashov wrote:
So, do you suppose I could achieve my objective by tracking every dialog--that is, by calling dlg_manage() in the initial request route for every call, and then calling set_dlg_profile() out of a failure route conditionally?
Wouldn't you need to set it within the original invite and then "do something" with it in the event_route[dialog:failed]?
Let's assume I don't want to use the event routes.
-
Alex Balashov -
Daniel-Constantin Mierla -
Fred Posner