[SR-Users] Problem faced when Using Kamaiio as Session Refresher
Daniel-Constantin Mierla
miconda at gmail.com
Fri Mar 27 08:49:03 CET 2020
Hello,
try to use:
$(hdr(Session-Expires){s.select,0,;}{s.int});
It should work even when there is only the expires value, with no
parameters.
Cheers,
Daniel
On 27.03.20 04:53, harneet singh 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 <http://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 <mailto: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 <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 <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/20200327/cfad499f/attachment.html>
More information about the sr-users
mailing list