[OpenSIPS-Users] sst module killing calls

Bogdan-Andrei Iancu bogdan at opensips.org
Tue Mar 8 17:54:25 CET 2011


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:NXXNXXXXXX at 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
> 7fcf80a53e41f75c431e5b7d0300c238 at 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 
> <bogdan at opensips.org <mailto:bogdan at 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 <jpyle at fidelityvoice.com
>         <mailto:jpyle at fidelityvoice.com>
>         <mailto:jpyle at fidelityvoice.com <mailto:jpyle at fidelityvoice.com>>>
>         Reply-To: OpenSIPS users mailling list
>         <users at lists.opensips.org <mailto:users at lists.opensips.org>
>         <mailto:users at lists.opensips.org
>         <mailto:users at lists.opensips.org>>>
>
>         Date: Thu, 27 Jan 2011 13:49:44 -0500
>         To: OpenSIPS users mailling list <users at lists.opensips.org
>         <mailto:users at lists.opensips.org>
>         <mailto:users at lists.opensips.org
>         <mailto:users at 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 at lists.opensips.org <mailto:Users at 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 at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


-- 
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 28th February 2011
OpenSIPS solutions and "know-how"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dialog.patch
Type: text/x-diff
Size: 836 bytes
Desc: not available
URL: <http://lists.opensips.org/pipermail/users/attachments/20110308/3a92a041/attachment.patch>


More information about the Users mailing list