Dear sr-users I need to save cdrs of calls and messages can you help me please
On Thu, Jun 27, 2019 at 1:09 PM ali mahfouz <[email protected]> wrote: > if I send my kamailio.cfg file can you edit it to me please because it is > so urgent > > > On Thu, Jun 27, 2019 at 1:06 PM <[email protected]> > wrote: > >> Send sr-users mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of sr-users digest..." >> >> >> Today's Topics: >> >> 1. Re: TOPOS uid in contact param instead of username >> (Daniel-Constantin Mierla) >> 2. Kamailio 5.x and Call_control module (Efelin Novak) >> 3. Re: Kamailio 5.x and Call_control module >> (Daniel-Constantin Mierla) >> 4. Statistics for locally generated replies (Duarte Rocha) >> 5. Re: Kamailio 5.x and Call_control module >> (Daniel-Constantin Mierla) >> 6. Re: Kamailio 5.x and Call_control module (Efelin Novak) >> 7. Re: kamailio as UAC and NAPTR / sendsocket question >> (Karsten Horsmann) >> 8. MongoDB for Kamailio (Gaurav Bmotra) >> 9. Presence publish manipulation (Gertjan Wolzak) >> 10. Re: Question about registrar behavior >> (Володимир Іванець) >> 11. Re: MongoDB for Kamailio (Henning Westerholt) >> 12. Re: DMQ: dmq_t_replicate() (Henning Westerholt) >> 13. Re: does kamailio support graph database ?? (Henning Westerholt) >> 14. Re: Question about registrar behavior (Henning Westerholt) >> 15. Need help with "no branches for forwarding" message (Andrew Chen) >> 16. Topos / Remove HF_re (Nicolas Breuer) >> 17. Re: Kamailio 5.x and Call_control module (Efelin Novak) >> 18. Re: Question about registrar behavior >> (Володимир Іванець) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 26 Jun 2019 12:52:05 +0200 >> From: Daniel-Constantin Mierla <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: Re: [SR-Users] TOPOS uid in contact param instead of username >> Message-ID: >> < >> cafrry4vmjd9aaj_tewd3e-cyg-o9k+qutw699n9gdc9is7w...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hello, >> ok, feel free to ask question if something is not clear ... and I think >> topoh might help looking at its code, iirc, it uses uri param for contact >> masking ... >> >> Anyhow, there is no better fun that C coding ;-) ... >> Cheers, >> Daniel >> >> On Wed, Jun 26, 2019 at 10:12 AM Thomas Weber <[email protected]> >> wrote: >> >> > Hello, >> > >> > thank you for your opinions. >> > >> > So i will give it a try throughout the next weeks because we have some >> > customer pressure here. >> > Didn't do a C project since some 10 years, so it could be fun to "learn >> it >> > again". >> > >> > Cheers, >> > >> > >> > Thomas >> > >> > _______________________________________________ >> > Kamailio (SER) - Users Mailing List >> > [email protected] >> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > >> >> >> -- >> Daniel-Constantin Mierla - http://www.asipto.com >> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/f3d6e4f2/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 26 Jun 2019 13:44:40 +0200 >> From: Efelin Novak <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: [SR-Users] Kamailio 5.x and Call_control module >> Message-ID: >> < >> cabktgaorur8sw37v+mkaz9c0b__altcbchx2dtoe6hfgknd...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Folks, >> >> I'm migrating to Kamailio 5.2.x from 4.4.x. Everything seems to be fine, >> however I have came to an issue with call_control module as this one is >> still using old MI interface. >> >> Standard situations work nice (maximum debit, prepaid, "CDRs") however >> when >> call_control needs to kill a call (credit is gone), it tries to send >> dlg_end_dlg over MI and it fails. >> >> Question are: >> Is call_control still supported? I haven't found any note about it. >> Is there any workaround from Kamailio point of view? >> >> I'm running last versions of both applications. I'm also rising a ticket >> at >> ag-projects side. >> >> Thanks >> >> Efelin >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/cd9ad900/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 26 Jun 2019 14:20:24 +0200 >> From: Daniel-Constantin Mierla <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: Re: [SR-Users] Kamailio 5.x and Call_control module >> Message-ID: >> < >> cafrry4wp24kbu1qy876wwongxdgtxsgkmph3no-3c1vptux...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hello, >> >> are you saying that the call_control module in kamailio is still using MI >> in version 5.2.x? The code related to MI was removed, should not be any >> use >> of it, can you point in the code where that happens? It can be migrated to >> RPC if is some raw MI operation ... >> >> Cheers, >> Daniel >> >> On Wed, Jun 26, 2019 at 1:45 PM Efelin Novak <[email protected]> >> wrote: >> >> > Hi Folks, >> > >> > I'm migrating to Kamailio 5.2.x from 4.4.x. Everything seems to be fine, >> > however I have came to an issue with call_control module as this one is >> > still using old MI interface. >> > >> > Standard situations work nice (maximum debit, prepaid, "CDRs") however >> > when call_control needs to kill a call (credit is gone), it tries to >> send >> > dlg_end_dlg over MI and it fails. >> > >> > Question are: >> > Is call_control still supported? I haven't found any note about it. >> > Is there any workaround from Kamailio point of view? >> > >> > I'm running last versions of both applications. I'm also rising a ticket >> > at ag-projects side. >> > >> > Thanks >> > >> > Efelin >> > _______________________________________________ >> > Kamailio (SER) - Users Mailing List >> > [email protected] >> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > >> >> >> -- >> Daniel-Constantin Mierla - http://www.asipto.com >> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/4000ec7e/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 4 >> Date: Wed, 26 Jun 2019 13:31:26 +0100 >> From: Duarte Rocha <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: [SR-Users] Statistics for locally generated replies >> Message-ID: >> < >> caajjhzjfjbw9atpbsthduvcsikc85komcimtxru+y1urfpx...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Greetings, >> >> Does the statistics command "kamcmd tm.stats" has an argument or a way to >> only list locally generated replies? >> >> As far as i know, sl.stats only lists local generated replies. Can tm work >> the same way? >> >> Best Regards, >> >> Duarte Rocha >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/5390ae52/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 5 >> Date: Wed, 26 Jun 2019 14:39:58 +0200 >> From: Daniel-Constantin Mierla <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: Re: [SR-Users] Kamailio 5.x and Call_control module >> Message-ID: >> <CAFRry4X5= >> [email protected]> >> Content-Type: text/plain; charset="utf-8" >> >> Hello, >> I looked a bit over the code and actually it is not any MI code there, >> there is a different control socket (unix file) specific for the module, >> not having to deal with Kamailio's RPC interface. Likely it is the control >> socket for an external application, so it should not be a problem from >> Kamailio point of view, that has not been changed from 4.x to 5.x. Not >> using that module myself, but it should work unless the external app using >> that control socket has changed, but the code in Kamailio in v4.x should >> be >> the same as in v5.x. >> >> Cheers, >> Daniel >> >> On Wed, Jun 26, 2019 at 2:20 PM Daniel-Constantin Mierla < >> [email protected]> >> wrote: >> >> > Hello, >> > >> > are you saying that the call_control module in kamailio is still using >> MI >> > in version 5.2.x? The code related to MI was removed, should not be any >> use >> > of it, can you point in the code where that happens? It can be migrated >> to >> > RPC if is some raw MI operation ... >> > >> > Cheers, >> > Daniel >> > >> > On Wed, Jun 26, 2019 at 1:45 PM Efelin Novak <[email protected]> >> > wrote: >> > >> >> Hi Folks, >> >> >> >> I'm migrating to Kamailio 5.2.x from 4.4.x. Everything seems to be >> fine, >> >> however I have came to an issue with call_control module as this one is >> >> still using old MI interface. >> >> >> >> Standard situations work nice (maximum debit, prepaid, "CDRs") however >> >> when call_control needs to kill a call (credit is gone), it tries to >> send >> >> dlg_end_dlg over MI and it fails. >> >> >> >> Question are: >> >> Is call_control still supported? I haven't found any note about it. >> >> Is there any workaround from Kamailio point of view? >> >> >> >> I'm running last versions of both applications. I'm also rising a >> ticket >> >> at ag-projects side. >> >> >> >> Thanks >> >> >> >> Efelin >> >> _______________________________________________ >> >> Kamailio (SER) - Users Mailing List >> >> [email protected] >> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> > >> > >> > -- >> > Daniel-Constantin Mierla - http://www.asipto.com >> > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> > >> >> >> -- >> Daniel-Constantin Mierla - http://www.asipto.com >> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/c8abe627/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 6 >> Date: Wed, 26 Jun 2019 14:45:39 +0200 >> From: Efelin Novak <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: Re: [SR-Users] Kamailio 5.x and Call_control module >> Message-ID: >> <CABKTgArTSMfPKc=xHJa3LyTatrg7eRd= >> [email protected]> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Daniel, >> >> thanks for a reply. No, the module is not using an MI. The Python >> application call-control is using the MI to end the calls using >> dlg_end_dlg. I see it like this: the communication from Kamailio to >> Call-control works, however the communication from Call-Control to >> Kamailio >> (I think this is only used to kill a call - >> http://callcontrol.ag-projects.com/images/prepaid-engine.png) does not. >> It >> is using an MI (CallControl -> Kamailio). >> >> I understand this is not your problem (that is why I also post a message >> to >> the developer list), but call_control module without call-control >> application is useless (as far as I understand). >> >> Is there any workaround how to turn the MI on or to have some interface >> separately, to do MI <-> JSON-RPC? >> >> I want to switch to Evapi and CGRateS, however in a meanwhile I wanted to >> have both systems running simultaneously. >> >> Again thanks >> >> Efelin >> >> st 26. 6. 2019 o 14:21 Daniel-Constantin Mierla <[email protected]> >> napísal(a): >> >> > Hello, >> > >> > are you saying that the call_control module in kamailio is still using >> MI >> > in version 5.2.x? The code related to MI was removed, should not be any >> use >> > of it, can you point in the code where that happens? It can be migrated >> to >> > RPC if is some raw MI operation ... >> > >> > Cheers, >> > Daniel >> > >> > On Wed, Jun 26, 2019 at 1:45 PM Efelin Novak <[email protected]> >> > wrote: >> > >> >> Hi Folks, >> >> >> >> I'm migrating to Kamailio 5.2.x from 4.4.x. Everything seems to be >> fine, >> >> however I have came to an issue with call_control module as this one is >> >> still using old MI interface. >> >> >> >> Standard situations work nice (maximum debit, prepaid, "CDRs") however >> >> when call_control needs to kill a call (credit is gone), it tries to >> send >> >> dlg_end_dlg over MI and it fails. >> >> >> >> Question are: >> >> Is call_control still supported? I haven't found any note about it. >> >> Is there any workaround from Kamailio point of view? >> >> >> >> I'm running last versions of both applications. I'm also rising a >> ticket >> >> at ag-projects side. >> >> >> >> Thanks >> >> >> >> Efelin >> >> _______________________________________________ >> >> Kamailio (SER) - Users Mailing List >> >> [email protected] >> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> > >> > >> > -- >> > Daniel-Constantin Mierla - http://www.asipto.com >> > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> > _______________________________________________ >> > Kamailio (SER) - Users Mailing List >> > [email protected] >> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/84064943/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 7 >> Date: Wed, 26 Jun 2019 14:50:22 +0200 >> From: Karsten Horsmann <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: Re: [SR-Users] kamailio as UAC and NAPTR / sendsocket >> question >> Message-ID: >> < >> cafarqsbhwbvyxp-wzlrgoq2_uqjwvdcwtmbrz3ecqrcuubk...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hello Daniel >> >> >> i verifed that can send tcp with that public ip (used nc for that). >> Hopefully the linux-networking is not the problem. >> >> I tried method $fs="212.xx.xx.xx"; and force_send_socket("212.xx.xx.xx"); >> Both versions (with and without transport=tcp param) but kamailio sends >> out >> via UDP. >> >> Any ideas? >> >> event_route[tm:local-request] { >> if(!is_method("OPTIONS")) { >> xlog("L_INFO", "[tm:local-request] request rm:[$rm] from fu:[$fu] >> to ru:[$ru] rP:[$rP] sut:[$sut] du:[$du] dP:[$dP] sas:[$sas]\n"); >> } >> if(is_method("REGISTER")) { >> xlog("its [$rm] [$ru] sas:[$sas]\n"); >> >> #$fs="$sas"; >> add_uri_param("transport=tcp"); >> # First try >> # $fs="212.xx.xx.xx"; >> # Second try >> # force_send_socket("212.xx.xx.xx"); >> } >> } >> >> tcpdump to see TCP or UDP outgoing: >> >> 212.xx.xx.xx.sip > 217.0.15.67.sip: [bad udp cksum 0xe921 -> 0x39df!] >> SIP, length: 459 >> REGISTER sip:sip-trunk.telekom.de;transport=tcp SIP/2.0 >> Via: SIP/2.0/UDP >> 212.xx.xx.xx;branch=z9hG4bKa4e7.2adf59a7000000000000000000000000.0;i=0 >> To: <sip:[email protected]> >> From: <sip:[email protected] >> >;tag=4f1676d5afd8e4fcf22b77a7b449c44f-8d04 >> CSeq: 10 REGISTER >> Call-ID: [email protected] >> Max-Forwards: 70 >> Content-Length: 0 >> User-Agent: SBC-OS >> Contact: <sip:[email protected]> >> Expires: 360 >> >> <script>: [tm:local-request] request rm:[REGISTER] from fu:[ >> sip:[email protected]] to ru:[sip:sip-trunk.telekom.de] >> rP:[UDP] sut:[sip:212.xx.xx.xx:5060;transport=tcp] du:[sip: >> reg.sip-trunk.telekom.de] dP:[UDP] sas:[tcp:212.xx.xx.xx:5060] >> <script>: its [REGISTER] [sip:sip-trunk.telekom.de] >> sas:[tcp:212.xx.xx.xx:5060] >> >> >> Cheers >> Karsten >> >> Am Mi., 26. Juni 2019 um 10:15 Uhr schrieb Daniel-Constantin Mierla < >> [email protected]>: >> >> > Hello, >> > >> > does it happen for both UDP and TCP? Or only for TCP is the private >> > interface used? Normally should work no matter the transport, try to >> force >> > only ip with force_send_sock("x.y.z.w"). >> > >> > I assume that the IP routing rules allow traffic from private IP to >> public >> > addresses. >> > >> > Cheers, >> > Daniel >> > >> > On Fri, Jun 21, 2019 at 5:49 PM Karsten Horsmann <[email protected]> >> > wrote: >> > >> >> Hi List, >> >> >> >> after reading the corebook in the wiki and some issue reports (1), I >> >> think it's not possible to force the outgoing ip for uac.so >> registration. >> >> >> >> I saw traffic with >> >> 172.20.120.53:45689 - - - > reg.sip-trunk.telekom.de >> >> >> >> So that's random highport generated traffic tcp traffic on the first >> >> interface ip. >> >> >> >> AFAIK this behavior could not change, right? >> >> >> >> (1) >> >> https://github.com/kamailio/kamailio/issues/1532 >> >> >> >> >> >> Karsten Horsmann <[email protected]> schrieb am Fr., 21. Juni 2019, >> >> 11:44: >> >> >> >>> Hi List, >> >>> >> >>> >> >>> I try to register to Deutsche Telekom and there product Deutschland >> Lan >> >>> siptrunk. >> >>> >> >>> Thats works find but i see an intressting behaviour on selecting the >> >>> right outgoing interface. >> >>> Kamailio is sending out with tcp the REQUEST via first private ip >> >>> configured on that server (172.20.120.53). >> >>> There is no listen directive for that. >> >>> >> >>> I forced NAPTR to use tcp or udp and i assume that kamailio got the >> >>> right dns answers. >> >>> >> >>> On the list i read also that i can use force_send_socket to force the >> >>> outgoing request. >> >>> >> >>> Now my idea - hey i use the $rP for the outgoing to select the right >> >>> outgoing listen directive. >> >>> $rP - reference to transport protocol of R-URI >> >>> But to my surprise the logfile told me thats "UDP" - it sends out via >> >>> TCP (thats okay). >> >>> >> >>> Whats an good transport selector variable from kamailio that works? >> >>> >> >>> >> >>> event_route[tm:local-request] { >> >>> if(!is_method("OPTIONS")) { >> >>> xlog("L_INFO", "[tm:local-request] request [$rm] from [$fu] to >> >>> [$ru] [$rP]\n"); >> >>> } >> >>> } >> >>> >> >>> INFO: <script>: [tm:local-request] request [REGISTER] from [ >> >>> sip:[email protected]] to [sip:sip-trunk.telekom.de] >> >>> [UDP] >> >>> >> >>> >> >>> listen=tcp:2xx.xx.xx.xx:5060 >> >>> listen=udp:2xx.xx.xx.xx:5060 >> >>> listen=tls:2xx.xx.xx.xx:5061 advertise CFG_EXT_NAME:5061 >> >>> >> >>> >> >>> listen=udp:172.20.120.55:5060 >> >>> listen=udp:172.20.120.56:5060 >> >>> listen=udp:172.20.120.57:5060 >> >>> listen=udp:172.20.120.58:5060 >> >>> listen=tcp:172.20.120.58:5060 >> >>> >> >>> >> >>> use_dns_cache=on # use internal DNS cache >> >>> use_dns_failover=on # depends on internal DNS cache >> >>> dns_srv_loadbalancing=on >> >>> dns_try_naptr=on >> >>> dns_retr_time=1 # seconds before retrying a DNS request >> >>> dns_retr_no=3 # number of DNS retransmissions >> >>> dns_naptr_ignore_rfc=yes # ignore target NAPTR priority >> >>> dns_tcp_pref=30 # TCP has second-highest priority >> >>> dns_udp_pref=10 # use UDP with least priority >> >>> tcp_connection_lifetime=3605 # set higher than registration expires >> >>> >> >>> #dont' restore >> >>> modparam("uac","restore_mode","none") >> >>> modparam("uac","restore_dlg",0) >> >>> >> >>> ## UAC REGISTER >> >>> #!ifdef WITH_UAC_REGISTER >> >>> modparam("uac", "reg_contact_addr", "CFG_PROD_IP") >> >>> modparam("uac", "reg_timer_interval", 10) >> >>> modparam("uac", "reg_retry_interval", 10) >> >>> modparam("uac", "reg_db_url", DBURL) >> >>> modparam("uac", "restore_mode", "none") >> >>> modparam("uac", "auth_username_avp", "$avp(AVP_AUTH_USERNAME)") >> >>> modparam("uac", "auth_password_avp", "$avp(AVP_AUTH_PASSWORD)") >> >>> modparam("uac", "auth_realm_avp", "$avp(AVP_AUTH_REALM)") >> >>> #!endif >> >>> >> >>> >> >>> >> >>> ip a l >> >>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN >> >>> group default qlen 1000 >> >>> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 >> >>> inet 127.0.0.1/8 scope host lo >> >>> valid_lft forever preferred_lft forever >> >>> inet6 ::1/128 scope host >> >>> valid_lft forever preferred_lft forever >> >>> 2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast >> >>> state UP group default qlen 1000 >> >>> link/ether 00:50:56:b5:c1:48 brd ff:ff:ff:ff:ff:ff >> >>> inet 172.20.120.53/24 brd 172.20.120.255 scope global ens192 >> >>> valid_lft forever preferred_lft forever >> >>> inet 2xx.xx.xx.xx/29 scope global ens192 >> >>> valid_lft forever preferred_lft forever >> >>> inet 172.20.120.56/24 scope global secondary ens192 >> >>> valid_lft forever preferred_lft forever >> >>> inet 172.20.120.57/24 scope global secondary ens192 >> >>> valid_lft forever preferred_lft forever >> >>> inet 172.20.120.58/24 scope global secondary ens192 >> >>> valid_lft forever preferred_lft forever >> >>> inet 172.20.120.55/24 brd 172.20.120.255 scope global secondary >> >>> ens192 >> >>> valid_lft forever preferred_lft forever >> >>> inet6 fe80::250:56ff:feb5:c148/64 scope link >> >>> valid_lft forever preferred_lft forever >> >>> >> >>> default via 172.20.120.253 dev ens192 >> >>> 172.20.120.0/24 dev ens192 proto kernel scope link src 172.20.120.53 >> >>> 2xx.xx.xx.xx/29 dev ens192 proto kernel scope link src 2xx.xx.xx.xx >> >>> >> >>> >> >>> -- >> >>> Kind Regards >> >>> Mit freundlichen Grüßen >> >>> *Karsten Horsmann* >> >>> >> >> _______________________________________________ >> >> Kamailio (SER) - Users Mailing List >> >> [email protected] >> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> > >> > >> > -- >> > Daniel-Constantin Mierla - http://www.asipto.com >> > http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> > _______________________________________________ >> > Kamailio (SER) - Users Mailing List >> > [email protected] >> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > >> >> >> -- >> Mit freundlichen Grüßen >> *Karsten Horsmann* >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/eecdb198/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 8 >> Date: Wed, 26 Jun 2019 18:23:31 +0530 >> From: Gaurav Bmotra <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: [SR-Users] MongoDB for Kamailio >> Message-ID: >> < >> cahemqfqpmmvtcccuyfywaubtbqv_zzw5h2uvikq5-adsunv...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> hi >> i m using kamailio 5.1 , on Ubuntu 18.4 >> and right now i m using Maria DB for kamailio , but i want to migrate my >> Maria data to MingoDB ,, plz help me how can i use MOngoDB with kamailio >> >> thanks >> >> -- >> >> >> >> >> >> >> >> >> *Regards:* >> Gaurav Kumar >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/3c74d17c/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 9 >> Date: Wed, 26 Jun 2019 15:34:24 +0200 >> From: Gertjan Wolzak <[email protected]> >> To: [email protected] >> Subject: [SR-Users] Presence publish manipulation >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> Hello Kamailions, >> >> I'm running into the following challenge. >> >> A kamailio setup where phones register with their mac address as uid and >> a password. >> >> Users have to login to the system by dialing a special number where they >> have to enter their internal extension and a pin code. >> >> Now the system knows which extension(number) is logged in on which >> phone(macaddress). This is done with from updates, just a type of >> hotdesking. >> >> Now I want to use presence.... >> >> When a phone makes a phone call, kamailio generates a publish message >> where the "local" part of the xml code contains the mac address. >> >> How can I manipulate the Publish xml information? I mean the >> manipulation can be done with textops, but which variables to use and >> where in the configuration? >> >> Im asking because when I disable the presence route and do not call it >> in my configuration, but with presence enabled, I still get Publish >> messages.... >> >> I have tried adding a Sender header which contains the "extension" of >> the phone and then call the publish in the PRESENCE route like this: >> handle_publish("$hdr(Sender)"); >> >> But this does not change the xml information. >> >> Am I doing things wrong? >> >> Below the first publish message that is send, where 10.88.77.172 is the >> kamailio server. >> >> U 2019/06/26 14:54:37.233345 10.88.77.172:5060 -> 10.88.77.172:5060 #7 >> PUBLISH sip:[email protected]:5060 SIP/2.0. >> Via: SIP/2.0/UDP >> 10.88.77.172;branch=z9hG4bK1a87.5510d093000000000000000000000000.0. >> To: <sip:[email protected]:5060>. >> From: >> <sip:[email protected]:5060 >> >;tag=a2652bb825a097f3b7285d4c70edd51a-5c5d. >> CSeq: 10 PUBLISH. >> Call-ID: [email protected]. >> Content-Length: 579. >> User-Agent: kamailio (5.1.8 (x86_64/linux)). >> Max-Forwards: 70. >> Event: dialog. >> Expires: 125. >> Content-Type: application/dialog-info+xml. >> . >> <?xml version="1.0"?> >> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" >> state="full" entity="sip:[email protected]:5060"> >> <dialog id="[email protected]" >> call-id="[email protected]" direction="initiator"> >> <state>Trying</state> >> <remote> >> <identity>sip:[email protected]:5060</identity> >> <target uri="sip:[email protected]:5060"/> >> </remote> >> <local> >> <identity>sip:[email protected]:5060</identity> >> <target uri="sip:[email protected]:5060"/> >> </local> >> </dialog> >> </dialog-info> >> >> >> I would like to change the local identity and target uri into the >> extension assigned to that phone, for example 604114.... >> >> So that subscribers to the extension 604114 get informed about the state >> of the phone with the used uid 0015659a9931. >> >> Feedback would be appricated. Pointers to where I am going wrong as >> well, ... that's feedback too. >> >> Rgds, >> >> Gertjan >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ------------------------------ >> >> Message: 10 >> Date: Wed, 26 Jun 2019 17:25:02 +0300 >> From: Володимир Іванець <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: Re: [SR-Users] Question about registrar behavior >> Message-ID: >> <CAOQgkjZ+FcXZ9Zty2MQ8FY64Wvjsm7Z3SPpy92wfzo2XoFR= >> [email protected]> >> Content-Type: text/plain; charset="utf-8" >> >> Hello! >> >> I've just tested this on Kamailio v. 5.3.0-dev6 with *modparam("usrloc", >> "db_mode", 0)* setting. save() return code was 1 too. I'm also interested >> if this behavior is by design. >> >> Thanks. >> >> ср, 26 черв. 2019 о 11:34 Lars Olsson <[email protected]> пише: >> >> > Hi, >> > >> > I have found a behavior in the registrar module that I do have a >> question >> > about. Is the current behavior correct and wanted? >> > >> > Using the save() method in the script I see the following: >> > >> > >> > - Processing a register request for a user gives return code 1 ( or >> 2 ) >> > - Processing a unregister request (expires=0) for registered user >> > gives return code 3 >> > - Processing a unregister request (expires=0) for a user which is NOT >> > registered gives return code 1. Why? >> > >> > What is the reason behind this? >> > No database entry is added which is expected. >> > >> > Test performed on 5.1.4, using DB mode 3. >> > >> > For handling a late unregister request ( where registration has already >> > expired) return code does not reflect the the action. >> > I assume that manually checking $expires(max) is the option to go then >> if >> > I want to detect the unregister request or? >> > >> > Cheers, >> > Lars >> > >> > _______________________________________________ >> > Kamailio (SER) - Users Mailing List >> > [email protected] >> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/b6ac1422/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 11 >> Date: Wed, 26 Jun 2019 16:56:54 +0000 >> From: Henning Westerholt <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]>, Gaurav Bmotra >> <[email protected]> >> Subject: Re: [SR-Users] MongoDB for Kamailio >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="utf-8" >> >> Hello, >> >> using this module for example: >> https://www.kamailio.org/docs/modules/5.2.x/modules/db_mongodb.html >> >> would be a good start. >> >> Cheers, >> >> Henning >> >> Am 26.06.19 um 14:53 schrieb Gaurav Bmotra: >> hi >> i m using kamailio 5.1 , on Ubuntu 18.4 >> and right now i m using Maria DB for kamailio , but i want to migrate my >> Maria data to MingoDB ,, plz help me how can i use MOngoDB with kamailio >> >> thanks >> >> -- >> >> >> >> >> >> >> >> >> Regards: >> Gaurav Kumar >> >> >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected]<mailto:[email protected]> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> -- >> Henning Westerholt - https://skalatan.de/blog/ >> Kamailio services - https://skalatan.de/services >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/190c726d/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 12 >> Date: Wed, 26 Jun 2019 17:39:41 +0000 >> From: Henning Westerholt <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]>, Lars Olsson < >> [email protected]> >> Subject: Re: [SR-Users] DMQ: dmq_t_replicate() >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="windows-1252" >> >> Hello Lars, >> >> >> maybe I did not understood your scenario correctly. >> >> >> But if your use case is just to replicate all registrations to another >> Kamailio instance, you just add the dmq_usrloc module and enable the >> synchronization. It should work right out of the box. >> >> >> Cheers, >> >> >> Henning >> >> >> Am 26.06.19 um 10:39 schrieb Lars Olsson: >> Hi, >> >> I am trying to replicate a REGISTER request between several nodes. >> >> When I am using dmq_t_replicate(), it ends the execution of the script. >> It this correct or I have missed anything? >> I can not find anything in the documentation of the DMQ module the says >> that it will end the script execution. >> >> Is it recommended to use the DMQ module or should I simply forward the >> request instead as described in >> https://medium.com/@tumalevich/kamailio-registration-replication-without-dmq-65e225f9a8a7 >> >> Best Regards, >> Lars >> >> >> >> >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected]<mailto:[email protected]> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> -- >> Henning Westerholt - https://skalatan.de/blog/ >> Kamailio services - https://skalatan.de/services >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/953e1da3/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 13 >> Date: Wed, 26 Jun 2019 17:44:15 +0000 >> From: Henning Westerholt <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]>, Gaurav Bmotra >> <[email protected]> >> Subject: Re: [SR-Users] does kamailio support graph database ?? >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="utf-8" >> >> Hello, >> >> you can find all supported DB in the module docs: >> >> https://www.kamailio.org/docs/modules/5.2.x/ >> >> If your preferred DB is not there, it is not supported. But it can of >> course be added by developing a new module. >> >> Cheers, >> >> Henning >> >> Am 25.06.19 um 08:12 schrieb Gaurav Bmotra: >> hi i m using kamailio 5.1 , >> does kamailio support graph database ?? >> >> thank you >> -- >> >> >> >> >> >> >> >> >> Regards: >> Gaurav Kumar >> >> >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected]<mailto:[email protected]> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> -- >> Henning Westerholt - https://skalatan.de/blog/ >> Kamailio services - https://skalatan.de/services >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/58590ebc/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 14 >> Date: Wed, 26 Jun 2019 20:36:01 +0000 >> From: Henning Westerholt <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]>, Володимир Іванець >> <[email protected]> >> Subject: Re: [SR-Users] Question about registrar behavior >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="utf-8" >> >> Hello, >> >> just briefly looked into the code, but I think the return value is like >> this for the following reasons: >> >> - function update_contacts(..) will skip if a contact is not found and a >> expires=0 is given (it could be also e.g. that the Contact just expired a >> few seconds ago in Kamailio) >> >> - this function will return 0, means success >> >> - the calling function save(..) will then return 1 as the default return >> value >> >> The main question to change this would be how to differentiate between a >> the valid case (just expired in Kamailio) from the other case (simply not >> registered at all). What issues do you experience because of this behaviour? >> >> Cheers, >> >> Henning >> >> Am 26.06.19 um 16:25 schrieb Володимир Іванець: >> Hello! >> >> I've just tested this on Kamailio v. 5.3.0-dev6 with modparam("usrloc", >> "db_mode", 0) setting. save() return code was 1 too. I'm also interested if >> this behavior is by design. >> >> Thanks. >> >> ср, 26 черв. 2019 о 11:34 Lars Olsson <[email protected]<mailto: >> [email protected]>> пише: >> Hi, >> >> I have found a behavior in the registrar module that I do have a question >> about. Is the current behavior correct and wanted? >> >> Using the save() method in the script I see the following: >> >> >> * Processing a register request for a user gives return code 1 ( or 2 >> ) >> * Processing a unregister request (expires=0) for registered user >> gives return code 3 >> * Processing a unregister request (expires=0) for a user which is NOT >> registered gives return code 1. Why? >> >> What is the reason behind this? >> No database entry is added which is expected. >> >> Test performed on 5.1.4, using DB mode 3. >> >> For handling a late unregister request ( where registration has already >> expired) return code does not reflect the the action. >> I assume that manually checking $expires(max) is the option to go then if >> I want to detect the unregister request or? >> >> Cheers, >> Lars >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected]<mailto:[email protected]> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> >> _______________________________________________ >> Kamailio (SER) - Users Mailing List >> [email protected]<mailto:[email protected]> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> -- >> Henning Westerholt - https://skalatan.de/blog/ >> Kamailio services - https://skalatan.de/services >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/34717749/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 15 >> Date: Wed, 26 Jun 2019 13:33:22 -0400 >> From: Andrew Chen <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: [SR-Users] Need help with "no branches for forwarding" >> message >> Message-ID: >> <CAEytwJ247Z+D9zU1x2O2f3Kex= >> [email protected]> >> Content-Type: text/plain; charset="utf-8" >> >> Hey guys, >> >> I need help to identify the cause of this is error: >> >> Jun 26 12:03:53 ashintgtpsg51 /usr/sbin/kamailio[1651]: ERROR: tm >> [t_fwd.c:1728]: t_forward_nonack(): no branches for forwarding >> >> This message was shortly printed after I xlog a message in onsend_route[] >> block. What else is strange is that the dialog continued on with that >> same >> SIP Call-ID. >> >> This is what it looks like in the wireshark flow diagram: >> >> [image: image.png] >> >> The dispatcher entry is an SRV record which lists available hosts. >> >> Any thoughts on how I can identify the cause of this? >> >> Thanks. >> >> -- >> Andy Chen >> Sr. Telephony Lead Engineer >> 415 516 5535 (M) >> achen@ <[email protected]>fuze.com >> >> -- >> *Confidentiality Notice: The information contained in this e-mail and any >> >> attachments may be confidential. If you are not an intended recipient, you >> >> are hereby notified that any dissemination, distribution or copying of >> this >> >> e-mail is strictly prohibited. If you have received this e-mail in error, >> >> please notify the sender and permanently delete the e-mail and any >> >> attachments immediately. You should not retain, copy or use this e-mail or >> >> any attachment for any purpose, nor disclose all or any part of the >> >> contents to any other person. Thank you.* >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/5937fc62/attachment-0001.html >> > >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: image.png >> Type: image/png >> Size: 238445 bytes >> Desc: not available >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190626/5937fc62/attachment-0001.png >> > >> >> ------------------------------ >> >> Message: 16 >> Date: Thu, 27 Jun 2019 08:54:53 +0000 >> From: Nicolas Breuer <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: [SR-Users] Topos / Remove HF_re >> Message-ID: >> < >> am6p192mb0389f1e21b1ed7754512bb9e89...@am6p192mb0389.eurp192.prod.outlook.com >> > >> >> Content-Type: text/plain; charset="utf-8" >> >> Hello, >> >> When using TOPOS module, Kamailio add this header : P-SR-XBranch before >> executing the topos module. >> Doing this "remove_hf_re("P-")" in the scripting seems to bypass the >> addition of the P-SR-XBranch in the sip message. >> >> In my mind, remove header function just remove the headers based on the >> incoming message. >> >> What do you think ? >> >> >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190627/da58903b/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 17 >> Date: Thu, 27 Jun 2019 11:27:41 +0200 >> From: Efelin Novak <[email protected]> >> To: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: Re: [SR-Users] Kamailio 5.x and Call_control module >> Message-ID: >> < >> cabktgapoeceoebuc_0h3raq9rslnepassm6c6k+p2nz03ak...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Daniel, >> >> so ag-projects (Call-control developer) said the Call-control python app >> is >> designed for MI and there is no plan to support anything else ( >> http://lists.opensips.org/pipermail/users/2019-June/041235.html). So this >> makes this project unusable in Kamailio 5.x. >> >> I have hacked call-control module to return something, so the Kamailio >> does >> not error, but this is just a hack, nothing production. >> >> I humbly suggest to remove call-control from modules or at least write in >> documentation, that it does not support ag-projects applications anymore. >> >> Anyway thanks for willingness to help >> >> Kind regards >> >> Efelin >> >> st 26. 6. 2019 o 14:45 Efelin Novak <[email protected]> napísal(a): >> >> > Hi Daniel, >> > >> > thanks for a reply. No, the module is not using an MI. The Python >> > application call-control is using the MI to end the calls using >> > dlg_end_dlg. I see it like this: the communication from Kamailio to >> > Call-control works, however the communication from Call-Control to >> Kamailio >> > (I think this is only used to kill a call - >> > http://callcontrol.ag-projects.com/images/prepaid-engine.png) does not. >> > It is using an MI (CallControl -> Kamailio). >> > >> > I understand this is not your problem (that is why I also post a message >> > to the developer list), but call_control module without call-control >> > application is useless (as far as I understand). >> > >> > Is there any workaround how to turn the MI on or to have some interface >> > separately, to do MI <-> JSON-RPC? >> > >> > I want to switch to Evapi and CGRateS, however in a meanwhile I wanted >> to >> > have both systems running simultaneously. >> > >> > Again thanks >> > >> > Efelin >> > >> > st 26. 6. 2019 o 14:21 Daniel-Constantin Mierla <[email protected]> >> > napísal(a): >> > >> >> Hello, >> >> >> >> are you saying that the call_control module in kamailio is still using >> MI >> >> in version 5.2.x? The code related to MI was removed, should not be >> any use >> >> of it, can you point in the code where that happens? It can be >> migrated to >> >> RPC if is some raw MI operation ... >> >> >> >> Cheers, >> >> Daniel >> >> >> >> On Wed, Jun 26, 2019 at 1:45 PM Efelin Novak <[email protected]> >> >> wrote: >> >> >> >>> Hi Folks, >> >>> >> >>> I'm migrating to Kamailio 5.2.x from 4.4.x. Everything seems to be >> fine, >> >>> however I have came to an issue with call_control module as this one >> is >> >>> still using old MI interface. >> >>> >> >>> Standard situations work nice (maximum debit, prepaid, "CDRs") however >> >>> when call_control needs to kill a call (credit is gone), it tries to >> send >> >>> dlg_end_dlg over MI and it fails. >> >>> >> >>> Question are: >> >>> Is call_control still supported? I haven't found any note about it. >> >>> Is there any workaround from Kamailio point of view? >> >>> >> >>> I'm running last versions of both applications. I'm also rising a >> ticket >> >>> at ag-projects side. >> >>> >> >>> Thanks >> >>> >> >>> Efelin >> >>> _______________________________________________ >> >>> Kamailio (SER) - Users Mailing List >> >>> [email protected] >> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >>> >> >> >> >> >> >> -- >> >> Daniel-Constantin Mierla - http://www.asipto.com >> >> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda >> >> _______________________________________________ >> >> Kamailio (SER) - Users Mailing List >> >> [email protected] >> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190627/7b99c922/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 18 >> Date: Thu, 27 Jun 2019 12:46:16 +0300 >> From: Володимир Іванець <[email protected]> >> To: Henning Westerholt <[email protected]> >> Cc: "Kamailio (SER) - Users Mailing List" >> <[email protected]> >> Subject: Re: [SR-Users] Question about registrar behavior >> Message-ID: >> <CAOQgkjYTrm6X= >> [email protected]> >> Content-Type: text/plain; charset="utf-8" >> >> Hello Henning, >> >> I'm preparing Kamailio configuration that uses save() responce codes for >> additional actions so email from Lars brought my attention. This is not a >> problem since as Lars mentioned I can check expires value. I just was >> curious if this is a correct behavior or not. >> >> Thank you! >> >> ср, 26 черв. 2019 о 23:36 Henning Westerholt <[email protected]> пише: >> >> > Hello, >> > >> > just briefly looked into the code, but I think the return value is like >> > this for the following reasons: >> > >> > - function update_contacts(..) will skip if a contact is not found and a >> > expires=0 is given (it could be also e.g. that the Contact just expired >> a >> > few seconds ago in Kamailio) >> > >> > - this function will return 0, means success >> > >> > - the calling function save(..) will then return 1 as the default return >> > value >> > >> > The main question to change this would be how to differentiate between a >> > the valid case (just expired in Kamailio) from the other case (simply >> not >> > registered at all). What issues do you experience because of this >> behaviour? >> > >> > Cheers, >> > >> > Henning >> > Am 26.06.19 um 16:25 schrieb Володимир Іванець: >> > >> > Hello! >> > >> > I've just tested this on Kamailio v. 5.3.0-dev6 with *modparam("usrloc", >> > "db_mode", 0)* setting. save() return code was 1 too. I'm also >> interested >> > if this behavior is by design. >> > >> > Thanks. >> > >> > ср, 26 черв. 2019 о 11:34 Lars Olsson <[email protected]> пише: >> > >> >> Hi, >> >> >> >> I have found a behavior in the registrar module that I do have a >> question >> >> about. Is the current behavior correct and wanted? >> >> >> >> Using the save() method in the script I see the following: >> >> >> >> >> >> - Processing a register request for a user gives return code 1 ( or >> 2 >> >> ) >> >> - Processing a unregister request (expires=0) for registered user >> >> gives return code 3 >> >> - Processing a unregister request (expires=0) for a user which is >> NOT >> >> registered gives return code 1. Why? >> >> >> >> What is the reason behind this? >> >> No database entry is added which is expected. >> >> >> >> Test performed on 5.1.4, using DB mode 3. >> >> >> >> For handling a late unregister request ( where registration has already >> >> expired) return code does not reflect the the action. >> >> I assume that manually checking $expires(max) is the option to go then >> if >> >> I want to detect the unregister request or? >> >> >> >> Cheers, >> >> Lars >> >> >> >> _______________________________________________ >> >> Kamailio (SER) - Users Mailing List >> >> [email protected] >> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> > >> > _______________________________________________ >> > Kamailio (SER) - Users Mailing [email protected]:// >> lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > >> > -- >> > Henning Westerholt - https://skalatan.de/blog/ >> > Kamailio services - https://skalatan.de/services >> > >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://lists.kamailio.org/pipermail/sr-users/attachments/20190627/ac7b8c4b/attachment-0001.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> sr-users mailing list >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> >> >> ------------------------------ >> >> End of sr-users Digest, Vol 169, Issue 27 >> ***************************************** >> >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
