Hi Ronald, Hi Jeff,
Ronald - thanks for the debug output - really useful.
Can you check the attached patch to see if it fixes the problem (if not,
post again the output).
Regards,
Bogdan
Ronald Cepres wrote:
Hi Bogdan,
I get a very similar behavior as what Jeff gets. I can see the
re-INVITE coming and I'm sure that it goes through loose_route block.
I can also see the "Update by a REQUEST" log. Here's a snippet of the
logs after getting the re-INVITE:
DBG:dialog:dlg_onroute: route param is '04e.1dc98a86' (len=12)
DBG:dialog:lookup_dlg: ref dlg 0x780a4fe0 with 1 -> 3
DBG:dialog:lookup_dlg: dialog id=1755880657 found on entry 3648
DBG:core:parse_headers: flags=48
DBG:core:parse_to_param: tag=9979
DBG:core:parse_to: end of header reached, state=29
DBG:core:parse_to: display={}, ruri={sip:[email protected]:5060}
DBG:dialog:next_state_dlg: dialog 0x780a4fe0 changed from state 4 to
state 4, due event 8
DBG:dialog:dlg_onroute: sequential request successfully processed
(dst_leg=0)
DBG:dialog:get_dlg_timeout: invalid AVP value, use default timeout
DBG:dialog:dlg_update_cseq: dlg 0x780a4fe0[0]: cseq is 1
DBG:dialog:run_dlg_callbacks: dialog=0x780a4fe0, type=16
DBG:sst:sst_dialog_request_within_CB: Update by a REQUEST. INVITE
DBG:core:parse_headers: flags=ffffffffffffffff
[email protected]: entering loose_route block..
Dialogs still expire after the timeout set by sst module. What else
can I check to see where might probably be wrong?
Thanks!
Regards,
Ronald
On Thu, Feb 3, 2011 at 6:23 AM, Bogdan-Andrei Iancu
<[email protected] <mailto:[email protected]>> wrote:
Hi Jeff,
are you sure your re-INVITE is going through loose_route() and
attached to the dialog context (to update it) ?
if running in debug mode, at re-INVITE time you could see a log
from SST module like "Update by a REQUEST..."
Regards,
bogdan
Jeff Pyle wrote:
And another issue…
With a call that went to a carrier that does support sst, I
see they refreshed the call at 15 seconds into it. Or, 15
seconds before the session expired. You can look at it either
way. They included the following in their refresher INVITE:
Session-Expires: 90;refresher=uac
Min-SE: 90
So they've bumped the timer to 90 seconds from my 30. Cool. It
seems the sst module doesn't see this refresh, and the dialog
module still doinks the call at 30 seconds into it. Bummer. Is
this normal?
On the initial INVITE I create the dialog with create_dialog()
then set the flag for the sst module.
- Jeff
From: Jeff Pyle <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
Reply-To: OpenSIPS users mailling list
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
Date: Thu, 27 Jan 2011 13:49:44 -0500
To: OpenSIPS users mailling list <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
Subject: [OpenSIPS-Users] sst module killing calls
Hello,
I'm experimenting with the sst module once again. It's
configured as follows:
modparam("dialog|sst", "timeout_avp", "$avp(s:dialog_timeout)")
modparam("sst", "sst_flag", 6)
modparam("sst", "min_se", 30)
Dialogs are set for all calls.
Calls I sent contain the following header:
Session-Expires: 30
So far, so good. When I get a 200 OK from a carrier that
supports sst, I see the following headers:
Supported: timer
Session-Expires: 30;refresher=uas
(The 30 second expiration is an experimentally low value.)
When I get a 200 OK from a carrier that doesn't support sst, I
don't see those two headers. In this case it seems the sst
module still sets the dialog expiration to 30 seconds, after
which the call goes poof.
Is that correct behavior? If neither end advertise support for
sst, and neither side is going to refresh it, it seems a bit
strange the sst module would still cause the dialog to expire
at the expiration time.
- Jeff
------------------------------------------------------------------------
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS Event - expo, conf, social, bootcamp
2 - 4 February 2011, ITExpo, Miami, USA
OpenSIPS solutions and "know-how"
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
------------------------------------------------------------------------
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 28th February 2011
OpenSIPS solutions and "know-how"
Index: modules/dialog/dlg_handlers.c
===================================================================
--- modules/dialog/dlg_handlers.c (revision 7768)
+++ modules/dialog/dlg_handlers.c (working copy)
@@ -907,6 +907,10 @@
&& new_state==DLG_STATE_CONFIRMED) {
LM_DBG("sequential request successfully processed (dst_leg=%d)\n",
dst_leg);
+
+ /* within dialog request */
+ run_dlg_callbacks( DLGCB_REQ_WITHIN, dlg, req, dir, 0);
+
timeout = get_dlg_timeout(req);
/* update timer during sequential request? */
if (timeout!=default_timeout) {
@@ -924,9 +928,6 @@
}
}
- /* within dialog request */
- run_dlg_callbacks( DLGCB_REQ_WITHIN, dlg, req, dir, 0);
-
if ( (event!=DLG_EVENT_REQACK) &&
(dlg->cbs.types)&DLGCB_RESPONSE_WITHIN ) {
/* ref the dialog as registered into the transaction callback.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
