[SR-Users] Problem faced when Using Kamaiio as Session Refresher

Bastian Triller bastian.triller at gmail.com
Fri Mar 27 08:47:56 CET 2020


$(hdr(Session-Expires){s.select,0,;}{s.int})

On Fri, Mar 27, 2020, 04:56 harneet singh <hbilling at gmail.com> wrote:

> Hi Daniel,
> The following code works if the Session-Expires comes WITHOUTa refresher
> parameter.
>
> if(is_present_hf("Session-Expires")) {
>
>    $avp(...) = $(hdr(Session-Expires){s.int});
>
> }
>
> If however, The session expires comes like below, there is an error in
> parsing
> Session-Expires: 200;refresher=uac
>
> Is there a way we can fetch just the value, ignoring the refresher
> parameter? I believe the refresher parameter is not required to be picked
> up from the INVITE by Kamailio for the working of SST Module.
>
> Regards,
> Harneet Singh
>
> On Tue, Mar 24, 2020 at 7:11 PM Daniel-Constantin Mierla <
> miconda at gmail.com> wrote:
>
>> Hello,
>>
>> probably you can use an htable to store that the ds_load_remove() was
>> called for a specific call id, but we can make that error log message to
>> debug level, there can be cross BYEs at the end of a call resulting in same
>> situation.
>>
>> Cheers,
>> Daniel
>> On 24.03.20 13:55, harneet singh wrote:
>>
>> Thanks Daniel,
>>
>> Your suggestion was very helpful. I am now able to see the dialog load go
>> down on Dispatcher as expected in case of session expiry.
>> Just an extra error log is what I keep getting per occurrence. I believe
>> the reason for this is that the event_route[tm:local-request] will be
>> called twice per call since BYE is sent to two sides.
>>
>> The log is :
>> Mar 24 17:23:59 CPaaSVM kamailio: 25(7499) DEBUG: sst
>> [sst_handlers.c:405]: sst_dialog_terminate_CB(): Terminating DID
>> 0x7fd847a50340 session
>> Mar 24 17:23:59 CPaaSVM kamailio: 25(7499) DEBUG: sst
>> [sst_handlers.c:412]: sst_dialog_terminate_CB(): freeing the sst_info_t
>> from dialog 0x7fd847a50340
>> Mar 24 17:23:59 CPaaSVM kamailio: 25(7499) ALERT: <script>:
>> [tm:local-request] RSYS: BYE Sent. Updating Load...
>> Mar 24 17:23:59 CPaaSVM kamailio: 25(7499) ALERT: <script>:
>> [tm:local-request] RSYS: BYE Sent. Updating Load...
>> *Mar 24 17:23:59 CPaaSVM kamailio: 25(7499) ERROR: dispatcher
>> [dispatch.c:1664]: ds_load_remove(): cannot find load for
>> (3-5996 at 172.27.44.121 <3-5996 at 172.27.44.121>)*
>>
>> Is there a way I can avoid calling the ds_load_update from
>> event_route[tm:local-request] by somehow figuring out that it has been
>> accounted for once, for this dialog? I understand that the dialog event end
>> route might be the most appropriate path to call this as that would
>> probably be called once for a dialog, but in case you have any
>> recommendations to circumvent the error code seen above?
>>
>> Thanks & Regards,
>> Harneet
>>
>> On Tue, Mar 24, 2020 at 4:02 PM Daniel-Constantin Mierla <
>> miconda at gmail.com> wrote:
>>
>>> 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});
>>>
>>> }
>>>
>>> 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
>>>
>>> --
>>> 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
>>
>>
>
> --
> "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
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200327/69d54eef/attachment.html>


More information about the sr-users mailing list