[SR-Users] sr-users Digest, Vol 169, Issue 27
ali mahfouz
arm037 at usal.edu.lb
Thu Jun 27 12:09:33 CEST 2019
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 <sr-users-request at lists.kamailio.org> wrote:
> Send sr-users mailing list submissions to
> sr-users at lists.kamailio.org
>
> 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
> sr-users-request at lists.kamailio.org
>
> You can reach the person managing the list at
> sr-users-owner at lists.kamailio.org
>
> 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 <miconda at gmail.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] TOPOS uid in contact param instead of username
> Message-ID:
> <
> CAFRry4VMJd9aaJ_teWd3E-CYg-O9K+qutW699n9GDc9is7wAxQ at 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 <thomas.weber at pascom.net>
> 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
> > sr-users at lists.kamailio.org
> > 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 <efelin.novak at gmail.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: [SR-Users] Kamailio 5.x and Call_control module
> Message-ID:
> <
> CABKTgAorur8sw37v+mKAZ9C0b__ALtCbChX2DTOe6HFGknDMHg at 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 <miconda at gmail.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] Kamailio 5.x and Call_control module
> Message-ID:
> <
> CAFRry4WP24kBu1Qy876WWONGXdGTXsGkmPh3NO-3c1VpTUx9+w at 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 <efelin.novak at gmail.com>
> 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
> > sr-users at lists.kamailio.org
> > 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 <duarterocha91 at gmail.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: [SR-Users] Statistics for locally generated replies
> Message-ID:
> <
> CAAJJHZjFjBW9ATPbsthDUvcSikc85KOMciMtXRu+Y1urfpX6YA at 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 <miconda at gmail.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] Kamailio 5.x and Call_control module
> Message-ID:
> <CAFRry4X5=
> HqLxN9uZC6Na9utk--m0AtmUmw3T5UHvv0YH1s24Q at mail.gmail.com>
> 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 <
> miconda at gmail.com>
> 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 <efelin.novak at gmail.com>
> > 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
> >> sr-users at lists.kamailio.org
> >> 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 <efelin.novak at gmail.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] Kamailio 5.x and Call_control module
> Message-ID:
> <CABKTgArTSMfPKc=xHJa3LyTatrg7eRd=
> yP4n-5ZQUAxkesPeGw at mail.gmail.com>
> 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 <miconda at gmail.com>
> 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 <efelin.novak at gmail.com>
> > 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
> >> sr-users at lists.kamailio.org
> >> 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
> > sr-users at lists.kamailio.org
> > 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 <khorsmann at gmail.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] kamailio as UAC and NAPTR / sendsocket
> question
> Message-ID:
> <
> CAFArqsbHWBVyxP-wZLrgOq2_uqjwvdcwtmbrZ3ECQRCuuBkx9A at 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:+49xxxxxx0 at sip-trunk.telekom.de>
> From: <sip:+49xxxxxx at sip-trunk.telekom.de
> >;tag=4f1676d5afd8e4fcf22b77a7b449c44f-8d04
> CSeq: 10 REGISTER
> Call-ID: 17110ff874fd4810-19875 at 212.xx.xx.xx
> Max-Forwards: 70
> Content-Length: 0
> User-Agent: SBC-OS
> Contact: <sip:49xxxxxx at xx.xx.xx.xx>
> Expires: 360
>
> <script>: [tm:local-request] request rm:[REGISTER] from fu:[
> sip:+49xxxxxx at sip-trunk.telekom.de] 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 <
> miconda at gmail.com>:
>
> > 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 <khorsmann at gmail.com>
> > 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 <khorsmann at gmail.com> 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:+49XXXXXXXX at sip-trunk.telekom.de] 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
> >> sr-users at lists.kamailio.org
> >> 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
> > sr-users at lists.kamailio.org
> > 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 <saigauravmehra91 at gmail.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: [SR-Users] MongoDB for Kamailio
> Message-ID:
> <
> CAHeMQFqpMMVtCCcUYFYWaUbtBqV_ZZW5h2UViKQ5-adsunVtqg at 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 <g.wolzak at kazlow.nl>
> To: sr-users at lists.kamailio.org
> Subject: [SR-Users] Presence publish manipulation
> Message-ID: <d4b0068f-10a1-7094-83d1-be5a88412afb at kazlow.nl>
> 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:0015659a9931 at 10.88.77.172:5060 SIP/2.0.
> Via: SIP/2.0/UDP
> 10.88.77.172;branch=z9hG4bK1a87.5510d093000000000000000000000000.0.
> To: <sip:0015659a9931 at 10.88.77.172:5060>.
> From:
> <sip:0015659a9931 at 10.88.77.172:5060
> >;tag=a2652bb825a097f3b7285d4c70edd51a-5c5d.
> CSeq: 10 PUBLISH.
> Call-ID: 173009c21f4e3c77-94480 at 10.88.77.172.
> 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:0015659a9931 at 10.88.77.172:5060">
> <dialog id="0_2285997339 at 10.88.77.184"
> call-id="0_2285997339 at 10.88.77.184" direction="initiator">
> <state>Trying</state>
> <remote>
> <identity>sip:604113 at 10.88.77.172:5060</identity>
> <target uri="sip:604113 at 10.88.77.172:5060"/>
> </remote>
> <local>
> <identity>sip:0015659a9931 at 10.88.77.172:5060</identity>
> <target uri="sip:0015659a9931 at 10.88.77.172: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: Володимир Іванець <volodyaivanets at gmail.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] Question about registrar behavior
> Message-ID:
> <CAOQgkjZ+FcXZ9Zty2MQ8FY64Wvjsm7Z3SPpy92wfzo2XoFR=
> eA at mail.gmail.com>
> 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 <lars.olsson at optimobile.se> пише:
>
> > 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
> > sr-users at lists.kamailio.org
> > 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 <hw at skalatan.de>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>, Gaurav Bmotra
> <saigauravmehra91 at gmail.com>
> Subject: Re: [SR-Users] MongoDB for Kamailio
> Message-ID: <fd3e7664-bd61-c17b-34e3-a7e5a4a2091a at skalatan.de>
> 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
> sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
> 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 <hw at skalatan.de>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>, Lars Olsson <
> lars.olsson at optimobile.se>
> Subject: Re: [SR-Users] DMQ: dmq_t_replicate()
> Message-ID: <516bbb99-191b-bddb-4305-dc507a60b99b at skalatan.de>
> 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
> sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
> 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 <hw at skalatan.de>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>, Gaurav Bmotra
> <saigauravmehra91 at gmail.com>
> Subject: Re: [SR-Users] does kamailio support graph database ??
> Message-ID: <eeda7bb5-0fe4-2777-d320-e45103def217 at skalatan.de>
> 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
> sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
> 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 <hw at skalatan.de>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>, Володимир Іванець
> <volodyaivanets at gmail.com>
> Subject: Re: [SR-Users] Question about registrar behavior
> Message-ID: <b2f5ca2f-59ab-6d7c-e82e-d12f1b37be51 at skalatan.de>
> 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 <lars.olsson at optimobile.se<mailto:
> lars.olsson at optimobile.se>> пише:
> 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
> sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org<mailto:sr-users at lists.kamailio.org>
> 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 <achen at fuze.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: [SR-Users] Need help with "no branches for forwarding"
> message
> Message-ID:
> <CAEytwJ247Z+D9zU1x2O2f3Kex=
> ZzKZco1CX+WuiTitaFD4HtAA at mail.gmail.com>
> 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@ <achen at thinkingphones.com>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 <Nicolas.Breuer at belcenter.biz>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: [SR-Users] Topos / Remove HF_re
> Message-ID:
> <
> AM6P192MB0389F1E21B1ED7754512BB9E89FD0 at 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 <efelin.novak at gmail.com>
> To: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] Kamailio 5.x and Call_control module
> Message-ID:
> <
> CABKTgApOeCEOEBUC_0H3raq9rsLnEpassm6c6K+p2NZ03AkOZw at 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 <efelin.novak at gmail.com> 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 <miconda at gmail.com>
> > 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 <efelin.novak at gmail.com>
> >> 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
> >>> sr-users at lists.kamailio.org
> >>> 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
> >> sr-users at lists.kamailio.org
> >> 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: Володимир Іванець <volodyaivanets at gmail.com>
> To: Henning Westerholt <hw at skalatan.de>
> Cc: "Kamailio (SER) - Users Mailing List"
> <sr-users at lists.kamailio.org>
> Subject: Re: [SR-Users] Question about registrar behavior
> Message-ID:
> <CAOQgkjYTrm6X=
> 80Q3fPBkXvOxHJ9EYFeFzULddiRVmQBbqADmw at mail.gmail.com>
> 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 <hw at skalatan.de> пише:
>
> > 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 <lars.olsson at optimobile.se> пише:
> >
> >> 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
> >> sr-users at lists.kamailio.org
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >>
> >
> > _______________________________________________
> > Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://
> 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
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
> ------------------------------
>
> End of sr-users Digest, Vol 169, Issue 27
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190627/435b0869/attachment.html>
More information about the sr-users
mailing list