I also tried parsing the Session-Expires header value and re-set the timeout_avp to this value during re-INVITE. The results are still the same. Has anyone encountered this problem and fixed it?
Any help would be appreciated. Thanks! Regards, Ronald On Thu, Mar 3, 2011 at 2:58 AM, Ronald Cepres <rbcep...@gmail.com> 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:nxxnxxx...@opensips.ip: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 > 7fcf80a53e41f75c431e5b7d0300c...@opensips.ip: 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 > <bog...@opensips.org>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 <jp...@fidelityvoice.com <mailto:jp...@fidelityvoice.com >>> >> >>> Reply-To: OpenSIPS users mailling list <users@lists.opensips.org<mailto: >>> users@lists.opensips.org>> >>> >>> Date: Thu, 27 Jan 2011 13:49:44 -0500 >>> To: OpenSIPS users mailling list <users@lists.opensips.org <mailto: >>> users@lists.opensips.org>> >>> >>> 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 >>> Users@lists.opensips.org >>> 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 >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users