[SR-Users] Problem faced when Using Kamaiio as Session Refresher
harneet singh
hbilling at gmail.com
Sat Mar 28 11:11:13 CET 2020
Hi Daniel,
I am observing a behavior after we have started fetching the
Session-Expires Header Value from the initial INVITE.
1. If the 200 OK(to the initial INVITE) from the UAS contains a lesser
value of Session-Expires, than the one advertised in the initial INVITE,
the session termination(by SST/Dialog Module) in case no refresh INVITE is
sent, happens at the value sent in the Initial INVITE only. ie. a lower
Session-Expires value in 200OK does not seem to be taking effect.
2. If the subsequent in-dialog INVITEs contain a different(lower) Session
refresh value, than the one advertised in the initial INVITE, the $avp(..)
seems to be getting updated, but the session termination still happens at
the end of initial INVITE;s Session Expires value.
Is this as per implementation, or should the timeout be updated based on
the 200OK response and other in-dialog REINVITEs as well?
Regards,
Harneet Singh
On Fri, Mar 27, 2020 at 10:34 PM harneet singh <hbilling at gmail.com> wrote:
> 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
>
--
"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/20200328/d4baea6e/attachment.html>
More information about the sr-users
mailing list