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]>> Reply-To: OpenSIPS users mailling list <[email protected]<mailto:[email protected]>> Date: Thu, 27 Jan 2011 13:49:44 -0500 To: OpenSIPS users mailling list <[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] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
