[OpenSIPS-Users] sst module killing calls

[Jeff Pyle]

Hi Bogdan,

Here are a few snippits from debug=4:

Call goes 200 OK @ 13:17:46:
 Feb  7 13:17:46 [16868] DBG:sst:sst_dialog_response_fwded_CB: Dialog seen
REPLY 200 OK


re-INVITE session refresh occurs at 13:18:06, 20 seconds after 200 OK, and
20 seconds before expiration:
 Feb  7 13:18:06 [16868] DBG:dialog:run_dlg_callbacks: dialog=0xb5274208,
type=16
 Feb  7 13:18:06 [16868] DBG:sst:sst_dialog_request_within_CB: Update by a
REQUEST. INVITE
 Feb  7 13:18:06 [16868] DBG:core:parse_headers: flags=ffffffffffffffff
 Feb  7 13:18:06 [16868] DBG:dialog:run_dlg_callbacks: dialog=0xb5274208,
type=16
 Feb  7 13:18:06 [16868] DBG:dialog:fetch_dlg_value: looking for
<trace_x00>
 Feb  7 13:18:06 [16868] DBG:dialog:fetch_dlg_value: var NOT found!


Is that "var NOT found!" anything to be concerned about?

At the original dialog expiration time (200 OK + 40 seconds) the call gets
destroyed:

 Feb  7 13:18:26 [16874] DBG:dialog:get_expired_dlgs: start with
tl=0xb5274234 tl->prev=0xb5252a78 tl->next=0xb5252a78 (54) at 54 and end
with end=0xb5252a78 end->prev=0xb5274234 end->next=0xb5274234
 Feb  7 13:18:26 [16874] DBG:dialog:get_expired_dlgs: getting
tl=0xb5274234 tl->prev=0xb5252a78 tl->next=0xb5252a78 with 54
 Feb  7 13:18:26 [16874] DBG:dialog:get_expired_dlgs: end with
tl=0xb5252a78 tl->prev=0xb5274234 tl->next=0xb5274234 and
d_timer->first.next->prev=(nil)
 Feb  7 13:18:26 [16874] DBG:dialog:dlg_timer_routine: tl=0xb5274234
next=(nil)
 Feb  7 13:18:26 [16874] DBG:dialog:send_leg_bye: sending BYE to caller (0)
 Feb  7 13:18:26 [16874] DBG:dialog:ref_dlg: ref dlg 0xb5274208 with 1 -> 3


...and so on.

Also, is it too late to set the SST flag in an onreply_route?  In more
than half of my cases it's going to be the B-side that supports timers,
not my A-side client.


- Jeff



On 2/2/11 5:23 PM, "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