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 <hbill...@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.tril...@gmail.com> > wrote: > >> $(hdr(Session-Expires){s.select,0,;}{s.int}) >> >> On Fri, Mar 27, 2020, 04:56 harneet singh <hbill...@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 < >>> mico...@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@172.27.44.121 <3-5996@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 < >>>> mico...@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 < >>>>> mico...@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@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@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@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@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@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@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@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@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@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 <hbill...@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@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@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@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 < >>>>>>> mico...@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 < >>>>>>>> mico...@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@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@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@lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> sr-users@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
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users