[SR-Users] Problem faced when Using Kamaiio as Session Refresher
harneet singh
hbilling at gmail.com
Fri Mar 27 18:04:52 CET 2020
Thanks Daniel/Bastian.
The change suggested works for me. :)
Regards,
Harneet
On Fri, Mar 27, 2020 at 1:28 PM Bastian Triller <bastian.triller at gmail.com>
wrote:
> $(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
>>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
--
"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/20200327/ea448e57/attachment.html>
More information about the sr-users
mailing list