[SR-Users] Problem faced when Using Kamaiio as Session Refresher
Daniel-Constantin Mierla
miconda at gmail.com
Tue Mar 24 11:32:40 CET 2020
Hello,
we have to update the docs for timeout_avp in sst module to reflect this
behaviour.
Related to the dispatcher load, try using the
event_route[tm:local-request], inside it you can catch the BYE generated
by Kamailio.
It could be a good addition to make dispatcher decrease the load also
from dialog end event route. I can look into it when I find some spare
time, if nobody else wants to do it meanwhile.
Cheers,
Daniel
On 24.03.20 10:23, harneet singh wrote:
> 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 <http://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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <http://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 <mailto: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 <mailto: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 <mailto: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
>> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 List
>>>>> sr-users at lists.kamailio.org <mailto:sr-users at lists.kamailio.org>
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>> --
>>>> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>>>> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://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.com <http://www.asipto.com>
>>> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
>> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://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.com <http://www.asipto.com>
> www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://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.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200324/09c969fa/attachment.html>
More information about the sr-users
mailing list