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