anybody play with SRTP in kazoo platform?

If I setting up kamailio TLS, do I need to change freeswitch config as well?

or just a kamailio?

mentax_: Usually you don't need to change Freeswitch. If I remember correctly it wll accept SRTP by default, and offer it if you have it specified on the resource. So for most cases you only need to mess with Kamailio config.

The exception is if you have to have client verification by the server, in which case you do need to mess with FS settings for TLS.

Thanks lvlinux.

I'm little bit confused, on the client site, google voice working all the time, but kazoo having all kind of issues

I hear that google voice use SRTP for all clients

so, wonder if it will help to make systemc work better

No, it will not make things work better. SRTP is not a problem solver, it is a feature option. :)

Now, using SIP over TLS _can_ help with a lot of issues related to NAT and ALGs and network type stuff, but that is a separate thing really than SRTP.

SRTP is media encryption, whereas SIP-TLS is signaling encryption.

lvlinux if I enable TLS role in kamailio it will start to to SIP-TLS?

It will allow it, yes. Then if you set either your phones or your DNS (if the phones are using NAPTR/SRV) they will start using it.

lvlinux thanks, will try to setup it

mentax_: defining "all kinds of issues" might allow you to receive some more specific help. :)

lvlinux, yesterday was interested. I setup one Grandstream phone, call from this phone to my cell, kamfs server drop connection for 10-15 second. Can't ping from anywhere

15 seconds after it go back

and every time when I tried to call in and out to this device, the server get disconnected... Nothing on the logs except no database servers available from haproxy

the phone itself ring for 3 seconds and get disconnected since server drop all connections

On customer site I have one way audio and very bad noise

Sounds kindof like you have a network issue on the server, or CPU lockup or something. Clearly unrelated to Kazoo, but definitely something you'll want to diagnose and fix.

One way audio sounds like a SIP ALG or some network junk going on probably at client side.

SIP-TLS might fix that, since SIP-TLS bypasses ALGs.

lvlinux, I have a blade server over there, other servers in the same switch was available all the time... After I restart the kazoo server everything back to normal

srv point phones to port 7000 and the phones register to port 7000 so, not sure if it was ALG issue

So, I'm setup kamailio to accept TLS, phone is registered on port 7001, but when I trying to call to voicemail (*98) it return "DELAYED NEGOTIATION"

Feb 1 19:48:44 s4mco 2600hz[1602]: |1028129773-5060-5⊙BBC|cf_flow:70(<0.1383.10>) searching for callflow in account%2Ffb%2F43%2F1f4ff21861b1ce1790f0b2bab871 to satisfy '*98'

Feb 1 19:48:44 s4mco 2600hz[1602]: |1028129773-5060-5⊙BBC|cf_flow:103(<0.1383.10>) can't use no_match: number not all digits: *98

Feb 1 19:48:44 s4mco 2600hz[1602]: |1028129773-5060-5⊙BBC|cf_route_req:51(<0.1383.10>) unable to find callflow not_found

Feb 1 19:48:46 s4mco 2600hz[1571]: |1028129773-5060-5⊙BBC|ecallmgr_fs_router_util:51(<0.31594.4>) did not receive route response for request 5058f2e5-3506-4188-9429-ac65e2ae18bd: timeout

mentax_: So that shows you haven't created a callflow to handle *98. When you setup a main number in SmartPBX, it creates commonly used callflows like that one; otherwise you have to do it manually.

It trying to use the "no_match" callflow means there wasn't another callflow that matched the dialed extension.

I did not add main number to this account

let me add and check again

lvlinux nope, same result =(((

I was able to call from my cell to this newly assigned number

a=crypto:1 AEAD_AES_256_GCM inline:3AhZS/3OucMw+JmQxwBeg4wcJ9YKzfqhNy1qz2mAx0WIIJCF7kpIH0Lhrwn=|2^32

lvlinux funny enough, I call to assigned number, answer it, one way audio over TLS... put my cell to hold in grandstrea phone, return to the call and can hear both way

mentax__: same result in logs? You'll need to check your callflows then and set one for *98.

On the one way audio---it may be working both directions but taking a long time to start on one side. What happens when you make the call and just sit on the line for 30 seconds or so---does the other side audio eventually come in or never?

mentax__: I would check your firewall---if you haven't properly allowed the UDP RTP ports range used by freeswitch, then that can happen.