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