[SR-Users] sr-users Digest, Vol 169, Issue 27

ali mahfouz arm037 at usal.edu.lb
Fri Jun 28 09:13:11 CEST 2019


Dear sr-users
I need to save cdrs of calls and messages can you help me please

On Thu, Jun 27, 2019 at 1:09 PM ali mahfouz <arm037 at usal.edu.lb> wrote:

> if I send my kamailio.cfg file can you edit it to me please because it is
> so urgent
>
>
> On Thu, Jun 27, 2019 at 1:06 PM <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/20190628/71baecc4/attachment.html>


More information about the sr-users mailing list