Re: [SR-Users] Setting up Kamailio IMS in a Box difficulties.

[YASIN CANER]

Hello,

it is shared by Franz Edler as mentioned . Vmbox username and password is 
franz/franz.

I couldnt find any IMS client that support IPsec or all IMS headers. You can 
use sipp for testing but dont have IPsec support.

Best Regards.




From: sr-users  on behalf of Jason Tsay 

Sent: Thursday, January 17, 2019 12:16 AM
To: sr-us...@lists.sip-router.org
Subject: [SR-Users] Setting up Kamailio IMS in a Box difficulties.


Hi miconda,


I am new to the Kamailio and RCS world.


I'm trying to set up an IMS core so I can get two devices communication through 
RCS.


I am trying to set up the Kamailio IMS in a box vmware image, and when I boot 
it up, it asks for the server login information.

​​All parameters and passwords used are documented in the log-file.​

I couldn't find documentation for the username and password. I was wondering if 
there is a new link available or login information where I could see the set up.


These are the things that I have found (to be working)

getting started - 
https://www.kamailio.org/w/2016/02/kamailio-ims-getting-started-box/

configs - 
https://www.dropbox.com/s/nm51v4orxrox4ac/Kamailio-IMS%20config-files.zip?dl%0A=0&file_subpath=%2FKamailio-IMS+config-files

pdf - https://www.kamailio.org/docs/tutorials/ims/Kamailio-IMS-in-a-Box.pdf


I did find the config files in a dropbox but I wanted to get the vmware sandbox 
working so I have a working environment (as I have failed many times to get my 
own instance set up.)


In addition, I was looking for some Android clients or if you could recommend 
some. I've tried rcsjta but I keep getting an API not compatible error (Doesn't 
work on Android Pie (Pixel 3 device) or Android M (6.0.1) Nexus device.)


I also tried IMSdroid, and it looks like it works with Android M (6.0.1) Nexus 
device but not compatible with Android Pie.


Thanks,

Jason
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Setting up Kamailio IMS in a Box difficulties.

[Jason Tsay]

Hi miconda,


I am new to the Kamailio and RCS world.


I'm trying to set up an IMS core so I can get two devices communication through 
RCS.


I am trying to set up the Kamailio IMS in a box vmware image, and when I boot 
it up, it asks for the server login information.

??All parameters and passwords used are documented in the log-file.?

I couldn't find documentation for the username and password. I was wondering if 
there is a new link available or login information where I could see the set up.


These are the things that I have found (to be working)

getting started - 
https://www.kamailio.org/w/2016/02/kamailio-ims-getting-started-box/

configs - 
https://www.dropbox.com/s/nm51v4orxrox4ac/Kamailio-IMS%20config-files.zip?dl%0A=0&file_subpath=%2FKamailio-IMS+config-files

pdf - https://www.kamailio.org/docs/tutorials/ims/Kamailio-IMS-in-a-Box.pdf


I did find the config files in a dropbox but I wanted to get the vmware sandbox 
working so I have a working environment (as I have failed many times to get my 
own instance set up.)


In addition, I was looking for some Android clients or if you could recommend 
some. I've tried rcsjta but I keep getting an API not compatible error (Doesn't 
work on Android Pie (Pixel 3 device) or Android M (6.0.1) Nexus device.)


I also tried IMSdroid, and it looks like it works with Android M (6.0.1) Nexus 
device but not compatible with Android Pie.


Thanks,

Jason
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Problem at Rx Interface - kamailio P-CSCF 5.1.6

[Valentin Christoph]

Hi all,

We are using kamailio 5.1.6, configured as P-CSCF, facing following problem. 
Please refer to the attached tshark trace, too.

If during call setup (by simulated UAs) at the terminating P-CSCF the simulated 
PCRF rejects the Diameter AAR message (frame 46/47 at the attached trace), then 
the kamailio P-CSCF runs into a questionable behaviour.

By calling the Rx_AAR() function in configuration, the processing of the 200 OK 
(frame 45) is suspended (by the ims_qos module) and then resumed with the 
receipt of the AAA message (frame 47).

Now the ims_dialog module is called with the dlg_terminate("all", "reason") 
function, but the 200 OK has not yet been sent. The ims_dialog sends CANCEL 
downstream and 488 upstream. However, the 200 OK is sent additionally. We would 
rather have expected the ims_dialog module should send BYE in both directions.

When we respond the CANCEL with 481 Call/Transaction does not exist (which we 
MUST according to RFC 3261), then we would expect the ims_dialog module at 
least now to react with BYE in both directions.

Could you help? What's our misunderstanding? How could we proceed to get this 
issue fixed?

Kind regards
Christoph



Christoph VALENTIN
Software Developer | R&D
Core / SIP Core

P +43 50 811 3785 | M +43 664 628 3785

christoph.valen...@kapsch.net

Kapsch CarrierCom AG | Lehrbachgasse 11 | 1120 Vienna | Austria
Company Register at: Commercial Court Vienna FN 223804 z | Registered Office 
Vienna | www.kapsch.net

[Kapsch Logo]






The information contained in this e-mail message is privileged and confidential 
and is for the exclusive use of the addressee. The person who receives this 
message and who is not the addressee, one of his employees or an agent entitled 
to hand it over to the addressee, is informed that he may not use, disclose or 
reproduce the contents thereof, and is kindly asked to notify the sender and 
delete the e-mail immediately.



PRM-18-2272-unsuccessful-Rx-diameter_78_filtered.pcap
Description: PRM-18-2272-unsuccessful-Rx-diameter_78_filtered.pcap
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Updating default kamailio.cfg to use rtpengine

[Denys Pozniak]

Karsten, if you use repo for rtpengine, please share the link.

ср, 16 янв. 2019 г. в 19:16, Karsten Horsmann :

> Hello Daniel,
>
> I use rtpengine on Centos 7. It's possible to create an DKMS package
> (automatic rebuild for new Kernel version).
>
> Kind regards
> Karsten
>
> Am Di., 15. Jan. 2019, 10:00 hat Daniel-Constantin Mierla <
> mico...@gmail.com> geschrieben:
>
>> Hello,
>>
>> being discussed at events offline or during irc meetings couple of
>> times, I want to open the discussion about updating the default
>> configuration file to use rtpengine. So far I let rtpproxy because was
>> packaged in many Linux distros, however, given the benefits of rtpengine
>> in terms of performance as well as webrtc support, doubled by the fact
>> that nowadays in the community it seems to be the primary choice of rtp
>> relay, we should decide what to do. I see two options:
>>
>> 1) add a define to allow selection between rtpproxy and rtpengine
>>
>> 2) replace rtpproxy completely with rtpengine
>>
>> I would prefer 2) for simplicity of the configuration file, but the main
>> question for the users community is how easy they find the deploying of
>> rtpengine. Using Debian/Ubuntu should be trivial, there are packages for
>> it, but I do not know about CentOS, Fedora, openSUSE or other Linux/BSD
>> OSes people here are using it.
>>
>> Reply to sr-users if you have an opinion on this matter (I cc-ed sr-dev
>> mainly to make aware the devs, but it is a matter of using kamailio). Of
>> course, other suggestions are welcome as well.
>>
>> Cheers,
>> Daniel
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.com
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
>> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in
>> Washington, DC, USA -- www.asipto.com
>>
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> 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
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 

BR,
Denys Pozniak
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] DMQ tries to resolve dns AAA even when it is disabled in kamailio core config

[Charles Chance]

Hi José,

You are correct in that the DNS cache is not used - however, after the
initial lookup, all discovered nodes are stored as IP addresses. Therefore,
providing at least one other node has been discovered, no further DNS
queries should be required/performed. Are you seeing a DNS lookup for every
DMQ message sent?

Cheers,

Charles


On Wed, 16 Jan 2019 at 09:59, José Seabra  wrote:

> Hi Charles,
> Well its not causing any real problem, but once that it also seems that
> isn't caching the dns results, every time that DMQ needs to send a msg it
> sends a new query to dns server, so its doing unnecessary dns queries.
>
> Thank you for your help.
>
> Best regards
> José
>
> Charles Chance  escreveu no dia terça,
> 15/01/2019 à(s) 21:11:
>
>> Hi José,
>>
>> The DMQ module does not currently observe the dns_try_ipv6 flag when
>> populating the initial node list - is it causing you problems?
>>
>> Cheers,
>>
>> Charles
>>
>> On Tue, 15 Jan 2019 at 14:55, José Seabra  wrote:
>>
>>> Hi all,
>>> I'm using DMQ with multi_notify set to 1, the dns_try_ipv6 is disabled
>>> and  dns_cache_flags is set to 1, but even this way DMQ is making dns AAA
>>> queries.
>>> Once that AAA queries are disabled in core dns config it seems that DMQ
>>> is not respecting those configurations, is that supposed?
>>>
>>> Thank you for your support
>>>
>>> Best Regards
>>> --
>>> Cumprimentos
>>> José Seabra
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>
>>
>>
>> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
>> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
>> Birmingham Science Park, Birmingham B7 4BB.
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
> Cumprimentos
> José Seabra
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
*Charles Chance*
Managing Director

t. 0330 120 1200m. 07932 063 891

-- 
Sipcentric Ltd.
Company registered in England & Wales no. 
7365592. Registered
office: Faraday Wharf, Innovation 
Birmingham Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB.
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] AWS binat external -> internal routing and record_route

[Joel Serrano]

Hello Dmitry,

I was wondering if you got this working? I'm facing a similar scenario and
I don't know if it's worth going this path vs having a second port on
internal IP without advertise just for internal traffic ?

Thanks,
Joel.

On Mon, Dec 17, 2018 at 3:55 AM Dmitry Sytchev  wrote:

> Yes, I'm handling external IP with domain module, so I'm matching it
> as 'myself'.
> I'll try to do it this way.
>
> Thank you, Daniel!
>
> пн, 17 дек. 2018 г. в 14:49, Daniel-Constantin Mierla :
> >
> >
> > On 17.12.18 12:37, Daniel-Constantin Mierla wrote:
> > > Hello,
> > >
> > >
> > > On 17.12.18 11:38, Dmitry Sytchev wrote:
> > >> Hi all!
> > >> I have a question that arises in mailing list sometimes, but it is
> > >> still not clear for me how to work with this.
> > >>
> > >> We have AWS instance with standard Amazon bi-nat, so basically
> > >> communication with external hosts works with
> > >> listen udp:ip:port advertise ip:port
> > >>
> > >> But in case when we need to send external call to internal network by
> > >> internal ip addresses, we want to have internal host in record-route.
> > >> As far as I understand, basic recommendation is to use separate port
> > >> or internal address and select it with appropriate function.
> > >>
> > >> Maybe it is more theoretical question, but can we do something to
> > >> generate correct record-routes and VIA for calls coming from external
> > >> network to make their softswitches happy, and still maintain internal
> > >> address in messages going to internal hosts, using single host and
> > >> port on Kamailio behind nat?
> > > you can do also without setting advertise address for a listen socket.
> > > Just listen on local IP and then you have to use
> > > set_advertise_address(...) to set the IP in Via and
> > > record_route_preset(...) to set the Record-Route header.
> > >
> > > Only that the config becomes a bit more complex, you have to add IF
> > > conditions when to add private or public IP addresses there.
> >
> > One thing I forgot: the public IP has to be treated as local IP (to
> > match against 'myself'), so you have to do conditions on it -- either
> > directly in the config conditions, or adding an alias or using domain
> > module.
> >
> > Cheers,
> > Daniel
> >
> > --
> > Daniel-Constantin Mierla -- www.asipto.com
> > www.twitter.com/miconda -- www.linkedin.com/in/miconda
> > Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> > Kamailio Advanced Training - Mar 4-6, 2019 -- www.asipto.com
> >
>
>
> --
> Best regards,
>
> Dmitry Sytchev,
> IT Engineer
>
> ___
> Kamailio (SER) - Users Mailing List
> 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
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Updating default kamailio.cfg to use rtpengine

[Karsten Horsmann]

Hello Daniel,

I use rtpengine on Centos 7. It's possible to create an DKMS package
(automatic rebuild for new Kernel version).

Kind regards
Karsten

Am Di., 15. Jan. 2019, 10:00 hat Daniel-Constantin Mierla 
geschrieben:

> Hello,
>
> being discussed at events offline or during irc meetings couple of
> times, I want to open the discussion about updating the default
> configuration file to use rtpengine. So far I let rtpproxy because was
> packaged in many Linux distros, however, given the benefits of rtpengine
> in terms of performance as well as webrtc support, doubled by the fact
> that nowadays in the community it seems to be the primary choice of rtp
> relay, we should decide what to do. I see two options:
>
> 1) add a define to allow selection between rtpproxy and rtpengine
>
> 2) replace rtpproxy completely with rtpengine
>
> I would prefer 2) for simplicity of the configuration file, but the main
> question for the users community is how easy they find the deploying of
> rtpengine. Using Debian/Ubuntu should be trivial, there are packages for
> it, but I do not know about CentOS, Fedora, openSUSE or other Linux/BSD
> OSes people here are using it.
>
> Reply to sr-users if you have an opinion on this matter (I cc-ed sr-dev
> mainly to make aware the devs, but it is a matter of using kamailio). Of
> course, other suggestions are welcome as well.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in
> Washington, DC, USA -- www.asipto.com
>
>
> ___
> Kamailio (SER) - Users Mailing List
> 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
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio OPTIONS Round-Trip

[Sergiu Pojoga]

After re-reading the original question, it appears that it isn't about
Asterisk at all, it was a simple reference to it, the actual question being
how to get RTT in Kamailios's usloc.

Apologies for the confusion. Let's carry on with the topic, lol.

Cheers,
--Sergiu

On Wed, Jan 16, 2019 at 9:55 AM Sergiu Pojoga  wrote:

> Correct me if I'm wrong, but wasn't the original poster looking for
> Asterisk (behind Kamailio) to show the round-trip of its peers based on
> qualify OPTIONS requests that Asterisk sends out to the peer?
>
> If so, I'm curious what is the impediment not to accept the previously
> suggested sip PATH approach? Aside from elegance and simplicity to
> implement, it isn't even subject to the UDP limitation you've brought up.
>
> Not that the topic of usrloc qualify isn't of interest, but it just feels
> like we are drifting into another topic, although somehow related to the
> original one.
>
> Best regards,
> --Sergiu
>
> On Wed, Jan 16, 2019 at 7:59 AM Nuno Ferreira  wrote:
>
>> Hello Daniel,
>>
>> I'm reading this thread with some interests. We were planning to use
>> nat_traversal module to do keepalive, but we came across the UDP only
>> limitation. In our use case, we wanted to offload the registrar from doing
>> keepalive. Of course, that's an option, but it has yet another limitation
>> when having active/active registrar servers using dmq_usrloc. If one of the
>> registrars goes down which server will be in charge of doing keepalive for
>> the contacts previously registered on the faulty registrar? That was one of
>> the reasons for us to seek doing keeplive on the edge with nat_traversal,
>> but again it's only valid for UDP.
>> If usrloc/dmq_usrloc provides some automatic election mechanism to
>> keepalive orphan AORs, I would prefer going with it for the task. Another
>> benefit like I read from your words is that we would automatically have
>> available latency/rtt attached to each contact and that is a big plus.
>>
>> Regards,
>>
>> Nuno
>>
>> On Wed, Jan 16, 2019 at 12:26 PM Daniel-Constantin Mierla <
>> mico...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> maybe we can just add this feature to the usrloc module -- right now the
>>> nat keepalive is done from nathelper module, which queries usrloc module to
>>> retrieve the list of the contacts to send OPTIONS to. Of course, the
>>> nathelper has the other variant witj 4-bytes pings, but I expect not many
>>> are using it these days.
>>>
>>> Furthermore, because the nathelper has some options to forge the source
>>> ip address as well as willing to be lightweight, it sends the packets
>>> directly, no relying on tm module.
>>>
>>> However, it seems that it is an increase interest in having more
>>> feedback based on these keepalives. Including the ability to do mirroring
>>> for sipcapture (a feature request being open in the tracker). Other request
>>> in the past was to send OPTIONS also for non-UDP contacts, nathelper does
>>> it only for UDP.
>>>
>>> So we can consider adding a transaction based keepalive layer, which of
>>> course might take a bit more resources that current nathelper
>>> implementation, but can bring extra benefits. I think we can leave
>>> nathelper as it is and add this feature directly in the usrloc module,
>>> avoiding to pass data between modules, but also because we have to
>>> set/updates some fields in the contract structure (like this round trip
>>> time).
>>>
>>> There are other modules that do keepalive, some mentioned dispatcher,
>>> there is a dedicated one named keepalive, and, afaik, also nat_traversal
>>> can do it. I am listing them so others can assert where it would be better
>>> to add the new feature -- as said, I would do it in usrloc, but I am open
>>> for other suggestions as well (eventually accompanied with a pull request).
>>>
>>> Cheers,
>>> Daniel
>>> On 15.01.19 21:12, Julien Chavanton wrote:
>>>
>>> Depending on the use case, you could use the dispatcher module latency
>>> stats.
>>>
>>>
>>> https://kamailio.org/docs/modules/devel/modules/dispatcher.html#dispatcher.p.ds_ping_latency_stats
>>>
>>> Regards
>>>
>>> On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba  wrote:
>>>
 On Sun, Jan 13, 2019 at 10:08:31PM +0300, Soltanici Ilie wrote:
 > With Asterisk, we are able to get some peer round-trip connection
 statistic by setting qualify=yes for the specified peer.
 > It sends periodic OPTIONS to the peer and calculates the time round
 trip time.
 > It's something like - "Status: OK (30 ms)".
 > Is there any way to achieve this in Kamailio by using
 nathelper??module, or any other?

 I think the only way to do this is to make this yourself (tm). In your
 favorite scripting language, query the locations and fire OPTIONS and
 measure the time for a response (if any) on basis of the "random" callid
 you create. If you route these requests through kamailio you will
 prevent any NAT problems or connection with TCP endpoints.

 _

Re: [SR-Users] Kamailio OPTIONS Round-Trip

[Sergiu Pojoga]

Correct me if I'm wrong, but wasn't the original poster looking for
Asterisk (behind Kamailio) to show the round-trip of its peers based on
qualify OPTIONS requests that Asterisk sends out to the peer?

If so, I'm curious what is the impediment not to accept the previously
suggested sip PATH approach? Aside from elegance and simplicity to
implement, it isn't even subject to the UDP limitation you've brought up.

Not that the topic of usrloc qualify isn't of interest, but it just feels
like we are drifting into another topic, although somehow related to the
original one.

Best regards,
--Sergiu

On Wed, Jan 16, 2019 at 7:59 AM Nuno Ferreira  wrote:

> Hello Daniel,
>
> I'm reading this thread with some interests. We were planning to use
> nat_traversal module to do keepalive, but we came across the UDP only
> limitation. In our use case, we wanted to offload the registrar from doing
> keepalive. Of course, that's an option, but it has yet another limitation
> when having active/active registrar servers using dmq_usrloc. If one of the
> registrars goes down which server will be in charge of doing keepalive for
> the contacts previously registered on the faulty registrar? That was one of
> the reasons for us to seek doing keeplive on the edge with nat_traversal,
> but again it's only valid for UDP.
> If usrloc/dmq_usrloc provides some automatic election mechanism to
> keepalive orphan AORs, I would prefer going with it for the task. Another
> benefit like I read from your words is that we would automatically have
> available latency/rtt attached to each contact and that is a big plus.
>
> Regards,
>
> Nuno
>
> On Wed, Jan 16, 2019 at 12:26 PM Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> maybe we can just add this feature to the usrloc module -- right now the
>> nat keepalive is done from nathelper module, which queries usrloc module to
>> retrieve the list of the contacts to send OPTIONS to. Of course, the
>> nathelper has the other variant witj 4-bytes pings, but I expect not many
>> are using it these days.
>>
>> Furthermore, because the nathelper has some options to forge the source
>> ip address as well as willing to be lightweight, it sends the packets
>> directly, no relying on tm module.
>>
>> However, it seems that it is an increase interest in having more feedback
>> based on these keepalives. Including the ability to do mirroring for
>> sipcapture (a feature request being open in the tracker). Other request in
>> the past was to send OPTIONS also for non-UDP contacts, nathelper does it
>> only for UDP.
>>
>> So we can consider adding a transaction based keepalive layer, which of
>> course might take a bit more resources that current nathelper
>> implementation, but can bring extra benefits. I think we can leave
>> nathelper as it is and add this feature directly in the usrloc module,
>> avoiding to pass data between modules, but also because we have to
>> set/updates some fields in the contract structure (like this round trip
>> time).
>>
>> There are other modules that do keepalive, some mentioned dispatcher,
>> there is a dedicated one named keepalive, and, afaik, also nat_traversal
>> can do it. I am listing them so others can assert where it would be better
>> to add the new feature -- as said, I would do it in usrloc, but I am open
>> for other suggestions as well (eventually accompanied with a pull request).
>>
>> Cheers,
>> Daniel
>> On 15.01.19 21:12, Julien Chavanton wrote:
>>
>> Depending on the use case, you could use the dispatcher module latency
>> stats.
>>
>>
>> https://kamailio.org/docs/modules/devel/modules/dispatcher.html#dispatcher.p.ds_ping_latency_stats
>>
>> Regards
>>
>> On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba  wrote:
>>
>>> On Sun, Jan 13, 2019 at 10:08:31PM +0300, Soltanici Ilie wrote:
>>> > With Asterisk, we are able to get some peer round-trip connection
>>> statistic by setting qualify=yes for the specified peer.
>>> > It sends periodic OPTIONS to the peer and calculates the time round
>>> trip time.
>>> > It's something like - "Status: OK (30 ms)".
>>> > Is there any way to achieve this in Kamailio by using
>>> nathelper??module, or any other?
>>>
>>> I think the only way to do this is to make this yourself (tm). In your
>>> favorite scripting language, query the locations and fire OPTIONS and
>>> measure the time for a response (if any) on basis of the "random" callid
>>> you create. If you route these requests through kamailio you will
>>> prevent any NAT problems or connection with TCP endpoints.
>>>
>>> ___
>>> 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
>>
>> --
>> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.

Re: [SR-Users] Kamailio OPTIONS Round-Trip

[Nuno Ferreira]

Hello Daniel,

I'm reading this thread with some interests. We were planning to use
nat_traversal module to do keepalive, but we came across the UDP only
limitation. In our use case, we wanted to offload the registrar from doing
keepalive. Of course, that's an option, but it has yet another limitation
when having active/active registrar servers using dmq_usrloc. If one of the
registrars goes down which server will be in charge of doing keepalive for
the contacts previously registered on the faulty registrar? That was one of
the reasons for us to seek doing keeplive on the edge with nat_traversal,
but again it's only valid for UDP.
If usrloc/dmq_usrloc provides some automatic election mechanism to
keepalive orphan AORs, I would prefer going with it for the task. Another
benefit like I read from your words is that we would automatically have
available latency/rtt attached to each contact and that is a big plus.

Regards,

Nuno

On Wed, Jan 16, 2019 at 12:26 PM Daniel-Constantin Mierla 
wrote:

> Hello,
>
> maybe we can just add this feature to the usrloc module -- right now the
> nat keepalive is done from nathelper module, which queries usrloc module to
> retrieve the list of the contacts to send OPTIONS to. Of course, the
> nathelper has the other variant witj 4-bytes pings, but I expect not many
> are using it these days.
>
> Furthermore, because the nathelper has some options to forge the source ip
> address as well as willing to be lightweight, it sends the packets
> directly, no relying on tm module.
>
> However, it seems that it is an increase interest in having more feedback
> based on these keepalives. Including the ability to do mirroring for
> sipcapture (a feature request being open in the tracker). Other request in
> the past was to send OPTIONS also for non-UDP contacts, nathelper does it
> only for UDP.
>
> So we can consider adding a transaction based keepalive layer, which of
> course might take a bit more resources that current nathelper
> implementation, but can bring extra benefits. I think we can leave
> nathelper as it is and add this feature directly in the usrloc module,
> avoiding to pass data between modules, but also because we have to
> set/updates some fields in the contract structure (like this round trip
> time).
>
> There are other modules that do keepalive, some mentioned dispatcher,
> there is a dedicated one named keepalive, and, afaik, also nat_traversal
> can do it. I am listing them so others can assert where it would be better
> to add the new feature -- as said, I would do it in usrloc, but I am open
> for other suggestions as well (eventually accompanied with a pull request).
>
> Cheers,
> Daniel
> On 15.01.19 21:12, Julien Chavanton wrote:
>
> Depending on the use case, you could use the dispatcher module latency
> stats.
>
>
> https://kamailio.org/docs/modules/devel/modules/dispatcher.html#dispatcher.p.ds_ping_latency_stats
>
> Regards
>
> On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba  wrote:
>
>> On Sun, Jan 13, 2019 at 10:08:31PM +0300, Soltanici Ilie wrote:
>> > With Asterisk, we are able to get some peer round-trip connection
>> statistic by setting qualify=yes for the specified peer.
>> > It sends periodic OPTIONS to the peer and calculates the time round
>> trip time.
>> > It's something like - "Status: OK (30 ms)".
>> > Is there any way to achieve this in Kamailio by using
>> nathelper??module, or any other?
>>
>> I think the only way to do this is to make this yourself (tm). In your
>> favorite scripting language, query the locations and fire OPTIONS and
>> measure the time for a response (if any) on basis of the "random" callid
>> you create. If you route these requests through kamailio you will
>> prevent any NAT problems or connection with TCP endpoints.
>>
>> ___
>> 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
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- 
> www.linkedin.com/in/miconda
> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
> Washington, DC, USA -- www.asipto.com
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 

*Nuno Ferreira* | Architect, CoreUC | nferre...@fuze.com | +351 308805903
Rua Carlos Silva Melo Guimarães 23, 3800-126 Aveiro, Portugal

   






-- 
*Confiden

Re: [SR-Users] Kamailio OPTIONS Round-Trip

[Daniel-Constantin Mierla]

Hello,

maybe we can just add this feature to the usrloc module -- right now the
nat keepalive is done from nathelper module, which queries usrloc module
to retrieve the list of the contacts to send OPTIONS to. Of course, the
nathelper has the other variant witj 4-bytes pings, but I expect not
many are using it these days.

Furthermore, because the nathelper has some options to forge the source
ip address as well as willing to be lightweight, it sends the packets
directly, no relying on tm module.

However, it seems that it is an increase interest in having more
feedback based on these keepalives. Including the ability to do
mirroring for sipcapture (a feature request being open in the tracker).
Other request in the past was to send OPTIONS also for non-UDP contacts,
nathelper does it only for UDP.

So we can consider adding a transaction based keepalive layer, which of
course might take a bit more resources that current nathelper
implementation, but can bring extra benefits. I think we can leave
nathelper as it is and add this feature directly in the usrloc module,
avoiding to pass data between modules, but also because we have to
set/updates some fields in the contract structure (like this round trip
time).

There are other modules that do keepalive, some mentioned dispatcher,
there is a dedicated one named keepalive, and, afaik, also nat_traversal
can do it. I am listing them so others can assert where it would be
better to add the new feature -- as said, I would do it in usrloc, but I
am open for other suggestions as well (eventually accompanied with a
pull request).

Cheers,
Daniel

On 15.01.19 21:12, Julien Chavanton wrote:
> Depending on the use case, you could use the dispatcher module latency
> stats.
>
> https://kamailio.org/docs/modules/devel/modules/dispatcher.html#dispatcher.p.ds_ping_latency_stats
>
> Regards
>
> On Tue, Jan 15, 2019 at 2:29 AM Daniel Tryba  > wrote:
>
> On Sun, Jan 13, 2019 at 10:08:31PM +0300, Soltanici Ilie wrote:
> > With Asterisk, we are able to get some peer round-trip
> connection statistic by setting qualify=yes for the specified peer.
> > It sends periodic OPTIONS to the peer and calculates the time
> round trip time.
> > It's something like - "Status: OK (30 ms)".
> > Is there any way to achieve this in Kamailio by using
> nathelper??module, or any other?
>
> I think the only way to do this is to make this yourself (tm). In your
> favorite scripting language, query the locations and fire OPTIONS and
> measure the time for a response (if any) on basis of the "random"
> callid
> you create. If you route these requests through kamailio you will
> prevent any NAT problems or connection with TCP endpoints.
>
> ___
> Kamailio (SER) - Users Mailing List
> 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
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
Washington, DC, USA -- www.asipto.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio on Kubernetes

[Sergey Safarov]

All available modules you can check by listing kamailio modules dir.
If you want build own image you can use this resources as start point
1) for debian dist https://github.com/kamailio/pkg-kamailio-docker
2)  for alpine dist
https://github.com/kamailio/kamailio-ci/tree/master/alpine

Also you can use prebuild docker images
1) debian based
https://cloud.docker.com/u/kamailio/repository/docker/kamailio/kamailio
2) alpine based
https://cloud.docker.com/u/kamailio/repository/docker/kamailio/kamailio-ci

Sergey

ср, 16 янв. 2019 г. в 13:02, Amar Tinawi :

> Hello all
>
> i'm wondering if Kamailio docker file is ready to be built over kubernetes
> i haven't try it yet, but don't know if it is available with all kamailio
> modules?
> does the database included or should be on different containers?
>
>
> Thanks in advance
> Regads
> ___
> Kamailio (SER) - Users Mailing List
> 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
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio v5.2.1 Released

[Daniel-Constantin Mierla]

Hello,

Kamailio SIP Server v5.2.1 stable release is out.

This is a maintenance release of the latest stable branch, 5.2, that
includes fixes since the release of v5.2.0. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.2.x. Deployments running previous v5.2.x
versions are strongly recommended to be upgraded to v5.2.1.

For more details about version 5.2.1 (including links and guidelines to
download the tarball or from GIT repository), visit:

* https://www.kamailio.org/w/2019/01/kamailio-v5-2-1-released/

RPM, Debian/Ubuntu packages will be available soon as well.

Many thanks to all contributing and using Kamailio!

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
Washington, DC, USA -- www.asipto.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Overhead of health check with dispatcher

[Mack Hendricks]

Hey Jesse,

I would create a simple web service that resides on the Kamailio instances.   
Have the IVR’a call this web service when that spin up.  The web service will 
take the ip as a parameter and add the ip to the dispatcher table.  Likewise, 
you can call the web service to remove it from the list when you spin it down

Mack Hendricks
dOpenSource.com

Sent from my iPhone

> On Jan 15, 2019, at 10:31 AM, Jesse Strahn  wrote:
> 
> Hi all,
> 
> I'm new to Kamailio. I am using Kamailio/dispatcher to distribute calls to 
> several SIP IVRs. I'm trying to determine the best solution to autoscale in 
> AWS when call capacity of the IVRs is reached.
> 
> The most straight forward solution is to spin up a new IVR on a dedicated 
> subnet when required. I would configure dispatcher such that the whole IP 
> range of this subnet is in the dispatcher.list so that once a new instance 
> becomes available, Kamailio starts sending calls there.
> 
> My question is, how much overhead would this add as Kamailio/dispatcher would 
> be polling the IPs in the subnet that were not yet active. The plan would be 
> to have a /28 subnet with 16 IPs. To start, there would be 2 active IVRs up 
> and responding and 14 IPs in dispatcher.list that would not be responding.
> 
> Appreciate any insight.
> 
> Thanks,
> Jesse
> ___
> Kamailio (SER) - Users Mailing List
> 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
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Planning Fosdem 2019

[Daniel-Constantin Mierla]

Hello,

soon we will have to do the reservation, so here is a reminder for those
that plan to join the dinner, but they haven't announced it, do it as
soon as possible to count you in and be sure we have enough seats.

Cheers,
Daniel

On 08.01.19 16:28, Daniel-Constantin Mierla wrote:
> Hello,
>
> Fosdem 2019 is approaching, so I am writing to see if any of you plans
> to go to the event. If there is interest, we can try to organize again a
> dinner on Saturday evening, a tradition for our project at the past 10
> editions or even more.
>
> Henning Westerholt will give a presentation about Kamailio in the RTC
> Devroom, I will be around as well. I know few more developers that plan
> to go to the event, so let's see who else from the community wants to
> join us. As usual, at Fosdem will be developers from other VoIP
> projects, like Asterisk, Janus, CGRates, Homer, Jitsi, ...
>
> At the past editions we typically had two "kamailio" events:
>
>   1)  an "ad-hoc" developers meeting in the cantina (or other available
> room around) to discuss about short term plans for Kamailio -- time and
> place being decided as we meet there between us (expected in the
> afternoon of Saturday or during Sunday).
>
>   2) a dinner at a place nearby, with other VoIP folks joining us
>
> Reply if you plan to go to Fosdem and say if you want to join for a
> dinner. Just be aware that you have to pay for your food and drinks at
> the dinner, unless we are going to be surprised again by a generous
> sponsor that covers partially or completely to dinner.
>
> If you need more details about Fosdem, the website is:
>
>   - https://fosdem.org
>
> Cheers,
> Daniel
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
Washington, DC, USA -- www.asipto.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio on Kubernetes

[Amar Tinawi]

Hello all

i'm wondering if Kamailio docker file is ready to be built over kubernetes
i haven't try it yet, but don't know if it is available with all kamailio
modules?
does the database included or should be on different containers?


Thanks in advance
Regads
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] DMQ tries to resolve dns AAA even when it is disabled in kamailio core config

[José Seabra]

Hi Charles,
Well its not causing any real problem, but once that it also seems that
isn't caching the dns results, every time that DMQ needs to send a msg it
sends a new query to dns server, so its doing unnecessary dns queries.

Thank you for your help.

Best regards
José

Charles Chance  escreveu no dia terça,
15/01/2019 à(s) 21:11:

> Hi José,
>
> The DMQ module does not currently observe the dns_try_ipv6 flag when
> populating the initial node list - is it causing you problems?
>
> Cheers,
>
> Charles
>
> On Tue, 15 Jan 2019 at 14:55, José Seabra  wrote:
>
>> Hi all,
>> I'm using DMQ with multi_notify set to 1, the dns_try_ipv6 is disabled
>> and  dns_cache_flags is set to 1, but even this way DMQ is making dns AAA
>> queries.
>> Once that AAA queries are disabled in core dns config it seems that DMQ
>> is not respecting those configurations, is that supposed?
>>
>> Thank you for your support
>>
>> Best Regards
>> --
>> Cumprimentos
>> José Seabra
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
>
> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered
> office: Faraday Wharf, Innovation Birmingham Campus, Holt Street,
> Birmingham Science Park, Birmingham B7 4BB.
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
Cumprimentos
José Seabra
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users