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
