[OpenSIPS-Users] sst module killing calls

[Ronald Cepres]

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 <rbcepres at 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: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>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
>>> >>
>>> Reply-To: OpenSIPS users mailling list <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>>
>>>
>>> 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
>>> 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
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110306/4bf008ee/attachment.htm>