[SR-Users] Problem faced when Using Kamaiio as Session Refresher
harneet singh
hbilling at gmail.com
Tue Mar 24 13:55:17 CET 2020
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200324/235ca359/attachment.html>
More information about the sr-users
mailing list