Re: [SR-Users] TLS and SIP

Thank you Klaus, good idea, but I forgot to mention that when I configure the client w/o TLS using regular SIP/UDP/5060 I dont have that problem. When the BYE from the called side comes it is sent to the calling side without any problems. But I do see that the Contact and VIA reach the Proxy with Public IP:Ports (our NAT automatically changes the internal IP/ports by the Public ones really well). The IP:Port in the VIA, CONTACT are the same that the request brings at layer3 and 4 as well. So I don't bother doing the extra NAT configuration in the office. Maybe since the actual content of the TLS SIP call is encrypted the firewall does not change the and then they should reach the proxy with the private IP:Ports, causing this problem.

I will try TCP and also adding some extra NAT handling configuration to the proxy.

thank you again ---------------------------------------- > Date: Wed, 22 May 2013 10:14:15 +0200 From: > klaus.mailinglists(a)pernau.at To: sr-users(a)lists.sip-router.org CC: > fborot(a)hotmail.com Subject: Re: [SR-Users] TLS and SIP > > > > On 21.05.2013 21:54, Fabian Borot wrote: >> Hi >> >> I am using Kamailio 4.0.1 in front of an asterisk servers farm to >> handle TLS with our clients and providers. The idea is to have >> kamailio "talking" SIP/UDP/5060 and TLS/TCP/5061 with the >> customers and providers and regular SIP/UDP/5060 with our >> internal asterisk servers. >> >> So far at least for the customers it looks like it can work. But >> I have a problem, when the call is established and the called >> person hangs up, the BYE from the called person to the calling >> person is ignored. Only when the calling person hangs up first >> the call is terminated properly. >> >> This is what I have been able to see: >> >> 1- Customer starts the TLS handshake/connection. 2- Kamailio >> authenticate it, then routes the call to the asterisk server >> using regular SIP/UDP/5060 but I see that it is inserting 2 >> Record Routes in the INVITE: >> >> Record-Route: <sip:192.168.1.58;r2=on;lr=on> >> >> Record-Route: <sip:192.168.1.58:5061;transport=tls;r2=on;lr=on> >> >> 3- The Contact on that INVITE to the asterisk also comes like >> this: >> >> Contact: <sip:94167032@172.31.196.21:53325;transport=tls> > > Next time please show the whole message (without SDP) as Via would > be interesting too. >> >> 4- The ACK sent to the asterisk once it accepts the call (200 OK) >> also has those 2 Record-Routes: >> >> Record-Route: <sip:192.168.1.58;r2=on;lr=on> >> >> Record-Route: <sip:192.168.1.58:5061;transport=tls;r2=on;lr=on> >> >> 5- The call is established, once the called person decides to >> hang up the BYE looks like this: >> >> BYE sip:94167032@172.31.196.21:53325;transport=tls SIP/2.0 Via: >> SIP/2.0/UDP 192.168.1.59:5060;branch=z9hG4bK40fa1c23;rport Route: >> <sip:192.168.1.58;r2=on;lr=on>,<sip:192.168.1.58:5061;transport=tls;r2=on;lr=on> >> >>

>> From: <sip:3030500@1.2.3.4>;tag=as37953869 To: "kamailio" >> <sip:kamailio@1.2.3.4>;tag=788cd7c892df40f3b1967112395e2ca4 >> Call-ID: f9fe65daf1074219be26cb0c224339f1 CSeq: 102 BYE >> User-Agent: Asterisk PBX 11.3.0 X-Asterisk-HangupCause: Normal >> Clearing X-Asterisk-HangupCauseCode: 16 Content-Length: 0 >> >> My kamailio TLS config is shown below: >> >> enable_tls=yes >> >> loadmodule "tls.so" >> >> # ----- tls params ----- modparam("tls", "config", >> "/usr/local/kamailio-4.1//etc/kamailio/tls.cfg") modparam("tls", >> "private_key", "./privkey.pem") modparam("tls", "certificate", >> "./kamailio1_cert.pem") modparam("tls", "ca_list", >> "./calist.pem") modparam("tls", "verify_certificate", 1) >> modparam("tls", "require_certificate", 1) >> >> The TLS client that I am using is called Blink.At this point I >> don't know whether kamailio is sending the BYE using TLS to the >> customer and waiting for the 200 OK from the customer or whether >> kamailio does not like something in the BYE and that is why is >> ignoring it. >> >> I see some encrypted packets from kamailio to the client but I >> don't know what is inside. Any help would be very appreciated. > > I guess this is a NAT problem (or similar) and the proxy is not > able to signal requests back to the client. When the client sends > the INVITE, the client opens a TLS connection (or uses the one > which was established during REGISTER). This existing TLS > connection must be used by the proxy to send requests to the > client. Therefore you have to use NAT traversal methodes, eg. > add_contact_alias() or the new outbound stuff. > > Anyway - first disable TLS und try TCP. TCP has the exact same > problems but is much easier to debug. Only if TCP work fine, then > try to use TLS. > > regards Klaus