TLS is used only for registration, plain SIP used for call setup; in and around rev 1554

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install a recent nightly build (I've tried both r1544 & r1554)
2. Setup a SIP client, enable TLS for account and in settings
3. Do a wireshark trace*: then register your account and make a call via that 
account.
4. You'll see the first few packets are TLSv1 (when you register) via 5061, the 
following packets are plain SIP on port 5060.

Note 1: If you revert to revision r1493 (for example), you can keep the same 
account settings, and it will work as expected, all packets TLS over 5061.

Note 2: I did not set any ports in the settings, I kept the defaults. When I 
tried to muck with the ports, I wasn't having any better luck.

Note 3: I also have settings for ZRTP set, fwiw. I do believe I tried changing 
this without any different behavior.

* I did mine from the server side.

What is the expected output? What do you see instead?

Expected output: All packets are TCP over port 5061 from cSIPSimple when you 
have TLS enabled (for account and for general settings), for registration and 
call setup.

What I see instead: UDP packets over port 5060, unencrypted SIP messages.

What version of the product are you using? On what operating system?

This happens with rev 1548 (and a few versions nearby it). 
On Samsung Galaxy Nexus with Android ICS 4.0.2

The backend server is an Asterisk box, I'm happy to provide any other 
information about this setup if it's useful for debugging, however, I don't 
believe the server configuration is directly in the mix on this one.

Original issue reported on code.google.com by douglask...@gmail.com on 24 May 2012 at 1:18

[GoogleCodeExporter]

Did you configured the proxy to be your sip server?

If not what you observe is absolutely normal.

Keep in mind that if you call 
sip:alice@domain.com using an account (that has *only* a registrar), the fact 
you set transport for this account to TLS, is just ignored ! You are making a 
direct call, announcing yourself with a special aor.
In this case the sip stack will choose the relevant transport (it's described 
in pjsip docs). And the method match exactly rfcs... scheme, extra transport 
arg.... nothing... so UDP...

In this case you should dial
sips:alice@domain.com;transport=tls (note the sip*s* in scheme).

It's exactly the same with TCP. If you set one account TCP with *only* 
registrar setup, and make a call, it will use UDP (or TCP if packet size is too 
big). 

Usually, a better way to do that, is just to set your sip server as a proxy for 
your requests. 
It's easier for a sip client to have a sip proxy on the other side. It has a 
lot of benefit, and when using it in mobile context it make even more sense. 
And in your case you seems to have hand on the server, so no reason to not use 
it as proxy.

Original comment by r3gis...@gmail.com on 24 May 2012 at 10:58

• Changed state: WrongConfig

[GoogleCodeExporter]

r3gis: Thank you very much :) My apologies for filing it as a bug, I only did 
so as I noticed the difference between versions. I appreciate your assistance. 

Once I set the "Proxy -> Proxy URI" to the same value as my server (plus 
":5061"), it sent the packets as I expected them, and as you described, as it 
fits the SIP stack. 

For any others googling this and finding this page... While asterisk is many 
things, it is not technically a proxy, for reference my asterisk server is 
Asterisk 1.8.11-cert1. 

Original comment by douglask...@gmail.com on 25 May 2012 at 1:24

[GoogleCodeExporter]

No problem it's very legitimate question and I also get lost with that first.
It makes sense once understood, but is not obvious when starting working with 
tls+sip. 

I'm wondering how I could add a wizard for secured server. But that's pretty 
complicate to not pollute mainstream interface. I hope that OSTel project will 
help with that. 

You're right about the proxy point and Asterisk. 
However, most of the time when using one account to get a gateway to standard 
phone network, it's still good to use it as proxy in the application 
configuration. It ensures that it will keep sending packets to this server when 
trying to call with this account.
In this particular case, if you want an account to be able to do sip calls to 
other domains one solution is to create a "Local" account. As anyway, it will 
just be used the exact same way, and that remote party will have a relevant 
info as your SIP address. Since if you use your asterisk account -without proxy 
config- and try to call somebody on another domain, the remote side will have 
as your sip address the one of your sip server. If they try to call you back 
using sip, there is chances it will fail :).

Another solution is to add a real SIP proxy in front (such as a freeswitch). Or 
to get an account to a free provider that allows sip trunking/redirects (such 
as pbxes.org). So that if you call somebody on another SIP domain he will be 
able to have one relevant info as your sip address.

Original comment by r3gis...@gmail.com on 25 May 2012 at 3:04

[GoogleCodeExporter]

Issue 2832 has been merged into this issue.

Original comment by r3gis...@gmail.com on 29 Dec 2014 at 6:08