[SR-Users] Problem faced when Using Kamaiio as Session Refresher
harneet singh
hbilling at gmail.com
Tue Mar 24 10:23:37 CET 2020
Hi Daniel,
Your timely response is much appreciated. I was able to fetch the
Session-Expires value from the INVITE's SE header, albeit with a minor
modification. I guess there were missing "(Double Quotes)" in the argument
to is_present_hf. After fixing that, things worked and the Dialog Expiry is
triggered at the correct time, and hence the BYE is sent from Kamailio to
UAC and UAS as expected.
if(is_present_hf("Session-Expires")) {
$avp(...) = $(hdr(Session-Expires){s.int});
}
However, there is still a concern from the earlier email that is
unresolved. We are using Call Load Based Dispatching Algorithm(Algorithm
10) and here's teh observation:
1. When a BYE is initiated by either UAC or UAS, the dialog load is reduced
by 1, since we call ds_load_update
# Dispatcher load updation
if (is_method("BYE|CANCEL")){
ds_load_update();
}
2. When however, the BYE is initiated by Kamailio towards UAC and UAS as a
result of session-Expiry, the load is NOT reduced. I am looking at this
parameter from the output of "kamcmd dispatcher.list" command.
RUNTIME: {
DLGLOAD: 1
}
I did go through the ds_load_update() API at
https://github.com/kamailio/kamailio/blob/master/src/modules/dispatcher/dispatch.c
file and seems like the ds_load_remove() which probably reduces the load
gets called only for a BYE or CANCEL that is received. Since clearing by
kamailio in case of Session-Expiry is done by sending the BYE out of
Kamailio, the load might not be getting removed.
In addition to the above, I also tried adding the below code where the
ds_load_update() gets called when the dialog ends, but still the dispatcher
load is not removed, despite this piece of code getting called.
event_route[dialog:end] {
xlog("L_ALERT", '[DIALOG:END] : Dialog ENDING NOW....' + "\n");
ds_load_update();
}
What would be your recommend to circumvent/fix the issue?
Regards,
Harneet
On Mon, Mar 23, 2020 at 7:21 PM Daniel-Constantin Mierla <miconda at gmail.com>
wrote:
> Hello,
>
> looking at logs, the callback functions from sst modules are for requests
> within dialog, not for initial request. It looks like the update is
> expected to be done when the request refreshing the session is done (the
> reinvite), therefore for initial INVITE the avp is not set.
>
>
> Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
> 1-5214 at 172.27.44.121} sst [sst_handlers.c:988]: setup_dialog_callbacks():
> Adding callback DLGCB_FAILED|DLGCB_TERMINATED|DLGCB_EXPIRED
> Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
> 1-5214 at 172.27.44.121} sst [sst_handlers.c:992]: setup_dialog_callbacks():
> Adding callback DLGCB_REQ_WITHIN
> Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
> 1-5214 at 172.27.44.121} sst [sst_handlers.c:1002]:
> setup_dialog_callbacks(): Adding callback DLGCB_RESPONSE_FWDED
> Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
> 1-5214 at 172.27.44.121} sst [sst_handlers.c:1006]:
> setup_dialog_callbacks(): Adding rpc handler
>
> There are callbacks for the response as well, and they seem to be
> executed, avp attempted to be set, but already having the same value:
>
> Mar 23 15:14:39 CPaaSVM kamailio: 37(4284) DEBUG: {2 1 INVITE
> 1-5214 at 172.27.44.121} sst [sst_handlers.c:520]:
> sst_dialog_response_fwded_CB(): Dialog seen REPLY 200 OK
> Mar 23 15:14:39 CPaaSVM kamailio: 37(4284) DEBUG: {2 1 INVITE
> 1-5214 at 172.27.44.121} sst [sst_handlers.c:870]: set_timeout_avp():
> Current timeout value already set to 200
>
> A solution you can try for now would be to set the avp explicitly for the
> first invite, like:
>
> if(is_present_hf(Session-Expires)) {
>
> $avp(...) = $(hdr(Session-Expires){s.int});
>
> }
>
> Cheers,
> Daniel
> On 23.03.20 11:29, harneet singh wrote:
>
> Hi Daniel,
>
> I have shared the logs at debug=3 level. Location:
> https://justpaste.it/6xmum
> I do see the sst and dialog module are loaded at startup and Even that
> the sst module sees the Session-Expires value. But somehow the dialog
> module doesn't seem to recognize it.
>
> Please see the excerpts from the log below:
> Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
> 1-5214 at 172.27.44.121} sst [sst_handlers.c:668]: ki_sst_check_min():
> Session-Expires: 200; MIN-SE: 100
> Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
> 1-5214 at 172.27.44.121} sst [sst_handlers.c:692]: ki_sst_check_min(): Done
> returning false (-1)
> ............
> .............
> Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
> 1-5214 at 172.27.44.121} dialog [dlg_handlers.c:681]: get_dlg_timeout():
> invalid AVP value, using default timeout
>
> Can you please take a look?
>
> Regards,
> Harneet
>
> On Mon, Mar 23, 2020 at 3:42 PM harneet singh <hbilling at gmail.com> wrote:
>
>> Hi Daniel,
>>
>> I have attached here the logs at debug=3 level. I do see the sst and
>> dialog module are loaded at startup and Even that the sst module sees the
>> Session-Expires value. But somehow the dialog module doesn't seem to
>> recognize it.
>>
>> Please see the excerpts from the log below:
>> Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
>> 1-5214 at 172.27.44.121} sst [sst_handlers.c:668]: ki_sst_check_min():
>> Session-Expires: 200; MIN-SE: 100
>> Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
>> 1-5214 at 172.27.44.121} sst [sst_handlers.c:692]: ki_sst_check_min(): Done
>> returning false (-1)
>> ............
>> .............
>> Mar 23 15:14:39 CPaaSVM kamailio: 1(4248) DEBUG: {1 1 INVITE
>> 1-5214 at 172.27.44.121} dialog [dlg_handlers.c:681]: get_dlg_timeout():
>> invalid AVP value, using default timeout
>>
>> Can you please take a look?
>>
>> Regards,
>> Harneet
>>
>> On Mon, Mar 23, 2020 at 3:02 PM Daniel-Constantin Mierla <
>> miconda at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> also check if code from sst module is executing when processing the
>>> dialog. Maybe the callback functions from sst are not called when dialog is
>>> handling the sip traffic. You should run with debug=3 and look at the debug
>>> messages to see if there are some printed from sst module. Watch also for
>>> other error or warning log messages, they may indicate that some processing
>>> could not be done.
>>>
>>> Eventually you can make the debug messages (from kamailio start to
>>> processing of the dialog) available somewhere online (e.g., pastebin) so we
>>> can look at them and analyze.
>>>
>>> Cheers,
>>> Daniel
>>> On 22.03.20 15:23, Daniel-Constantin Mierla wrote:
>>>
>>> Hello,
>>>
>>> ah, ok, I misunderstood.
>>>
>>> Is the INVITE received with the header Session-Expires?
>>>
>>> And remove the line:
>>>
>>> #!define DLG_TIMEOUT_AVP "i:1"
>>>
>>> It does not replaces the token inside strings, like inside the last
>>> parameter of the line:
>>>
>>> modparam("dialog", "timeout_avp", "$avp(DLG_TIMEOUT_AVP)")
>>>
>>> and if you use in config expressions $avp(DLG_TIMEOUT_AVP), then its
>>> name is replaced. So overall it can be two avp names, although when reading
>>> looks like one.
>>>
>>> Cheers,
>>> Daniel
>>> On 22.03.20 14:40, harneet singh wrote:
>>>
>>> Hi Daniel,
>>>
>>> Thanks for the confirmation. Your point confirms the same as I
>>> interpreted from the documentation, that Kamailio would not send refresh
>>> INVITEs. I am not expecting to achieve that. However, if i understand
>>> correctly, Kamailio can look into the "Session-Expires" header from UAC/UAS
>>> and set the timeout_avp based on that.
>>> In effect, Kamailio should ideally *tear down the call (Send a BYE to
>>> UAC and UAS)*, if it doesn't see any signalling(may it be
>>> session-refresh INVITE/UPDATE or any other mid-dialog messages). This i
>>> believe can be done by using the SST Module in conjunction with the Dialog
>>> Module.
>>> I am also using the SST Module and the Dialog Module, however have the
>>> following issues.
>>>
>>> 1. I am seeing the following message when sending Session-Expires: 200 .
>>> ""dialog [dlg_handlers.c:681]: *get_dlg_timeout(): invalid AVP
>>> value, using default timeout*"
>>>
>>> Not sure what is causing this.
>>>
>>> 2. If i try to hardcode the session-expires to a certain value, the
>>> Kamailio DOES send a BYE to UAC and UAS on the timer expiry if no signaling
>>> seen during that time. However, as pointed earlier, the Dialog Load on the
>>> Kamailio DOES NOT go down, as shown in the last email.
>>>
>>> FWIW, here's the config snippet from the Kamailio cfg i am using.
>>>
>>> ==========================================================================
>>> #!define *DLG_TIMEOUT*_AVP "i:1"
>>>
>>> # ----------- dialog params -----------
>>> modparam("dialog", "send_bye", 1)
>>> *modparam("dialog", "timeout_avp", "$avp(DLG_TIMEOUT_AVP)")*
>>> modparam("dialog", "dlg_flag", 5)
>>>
>>> # ----------- sst params -----------
>>> modparam("sst", "enable_stats", 1)
>>> modparam("sst", "min_se", 150)
>>> # Set the sst modules timeout_avp to be the same value
>>> *modparam("sst", "timeout_avp", "$avp(DLG_TIMEOUT_AVP)")*
>>> #modparam("sst", "reject_to_small", 1)
>>> modparam("sst", "sst_flag", 6)
>>>
>>>
>>> request_route {
>>> .......
>>> .......
>>> # account only INVITEs
>>> if (is_method("INVITE")) {
>>> setflag(FLT_ACC); # do accounting
>>>
>>> setflag(5); # set the dialog flag
>>> setflag(6); # Set the sst flag
>>> $dlg_ctx(timeout_bye)=1;
>>>
>>> if (sstCheckMin("1")) {
>>> xlog("L_ERR", "422 Session Timer Too Small reply
>>> sent.\n");
>>> exit;
>>> }
>>>
>>> }
>>> .....
>>> ......
>>> }
>>>
>>>
>>>
>>> ==========================================================================
>>>
>>> From the SST documentation, it pretty much seems like the only config to
>>> do. Am I missing something. If you have a working config for the Kamailio
>>> tuned in this manner using the SST and Dialog Module, could you share the
>>> same?
>>> Any pointers to make it work are most welcome.
>>>
>>> Regards,
>>> Harneet
>>>
>>>
>>>
>>> On Sun, Mar 22, 2020 at 3:01 PM Daniel-Constantin Mierla <
>>> miconda at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> are you looking for Kamailio to send re-INVITEs? If yes, that is not
>>>> available as a feature of dialog module.
>>>>
>>>> Cheers,
>>>> Daniel
>>>> On 21.03.20 10:39, harneet singh wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am fairly new to Kamailio and had a question regarding how to use
>>>> Kamailio to enable Session refresh functionality when Kamailio is acting as
>>>> Sip Stateful Proxy.
>>>> Kamailio Version used: *5.3.2* with *Call Load based routing* using
>>>> the *dispatcher *module.
>>>>
>>>>
>>>> * From what i understand from the documentation, Kamailio will probably
>>>> not be acting as a session refresher, but Kamailio can tear down the call
>>>> in case session refresh is negotiated, between the caller and the
>>>> callee(via Kamailio Sip Proxy), and no message exchange happens in the
>>>> duration set in Session-Expires header. *Is my understanding correct?*
>>>>
>>>> ** *I believe the above functionality is possible by using the *sst*
>>>> and *dialog* module. I have set the same according to the
>>>> documentation but I keep getting the following error:
>>>> "dialog [dlg_handlers.c:681]: *get_dlg_timeout(): invalid AVP value,
>>>> using default timeout*"
>>>> Can someone share a working example?
>>>>
>>>> * When i tried hardcoding the timeout value by setting the timeout_avp
>>>> to a specific value, Kamailio did sense a timeout and hence sent a BYE
>>>> towards the caller and the Callee side both(which is what the requirement
>>>> is), however, i do see the *dialog is still not cleared* in the
>>>> "kamcmd dispatcher.list". Output excerpt below for reference:
>>>>
>>>> [root at CPaaSVM ~]# kamcmd dispatcher.list
>>>> {
>>>> NRSETS: 1
>>>> RECORDS: {
>>>> SET: {
>>>> ID: 1
>>>> TARGETS: {
>>>> DEST: {
>>>> URI:
>>>> sip:172.27.44.121:5080;transport=tcp
>>>> FLAGS: AP
>>>> PRIORITY: 0
>>>> ATTRS: {
>>>> BODY:
>>>> duid=sample-cas;maxload=1000
>>>> DUID: sample-cas
>>>> MAXLOAD: 1000
>>>> WEIGHT: 0
>>>> RWEIGHT: 0
>>>> SOCKET:
>>>> }
>>>> LATENCY: {
>>>> AVG: 111.304000
>>>> STD: 1042.193000
>>>> EST: 2.385000
>>>> MAX: 9999
>>>> TIMEOUT: 1
>>>> }
>>>> RUNTIME: {
>>>> DLGLOAD: *1*
>>>> }
>>>> }
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
>>>> It is noteworthy that in case the BYE is initiated by either the caller
>>>> or the callee, the dialog is cleared properly and the DLGLOAD is set to 0
>>>> on call termination.
>>>>
>>>> Any pointers for the above questions would be highly appreciated.
>>>>
>>>> Regards,
>>>> Harneet
>>>>
>>>> --
>>>> "Once you eliminate the impossible, whatever remains, no matter how
>>>> improbable, must be the truth" - Sir Arthur Conan Doyle
>>>>
>>>> _______________________________________________
>>>> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>> --
>>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>>
>>>>
>>>
>>> --
>>> "Once you eliminate the impossible, whatever remains, no matter how
>>> improbable, must be the truth" - Sir Arthur Conan Doyle
>>>
>>> --
>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>
>>> --
>>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>
>>>
>>
>> --
>> "Once you eliminate the impossible, whatever remains, no matter how
>> improbable, must be the truth" - Sir Arthur Conan Doyle
>>
>
>
> --
> "Once you eliminate the impossible, whatever remains, no matter how
> improbable, must be the truth" - Sir Arthur Conan Doyle
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
>
>
--
"Once you eliminate the impossible, whatever remains, no matter how
improbable, must be the truth" - Sir Arthur Conan Doyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200324/ebb97df6/attachment.html>
More information about the sr-users
mailing list