[SR-Users] Problem faced when Using Kamaiio as Session Refresher
Daniel-Constantin Mierla
miconda at gmail.com
Tue Mar 24 14:41:46 CET 2020
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 <mailto: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 <mailto: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 <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 <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/d1a1c86f/attachment.html>
More information about the sr-users
mailing list