SIP-TLS with the Panasonic TGP600

The Panasonic TGP-600 DECT phone supports encryption of SIP signalling and audio (RTP) using the common SIP-TLS and SRTP methods supported by many VoIP platforms.

Configuration is very simple.  In the SIP Settings page:

Important settings are:

  • Proxy Server Port, Registrar Server Port, Presence Server Port.  The standard port for encrypted SIP is 5061 (rather than 5060 for normal plain-text SIP).  This depends on your SIP platform.
  • Transport Protocol. Set this to TLS
  • TLS Mode.  Depends on your platform but SIP-TLS is what I am using with an Asterisk PBX

All other settings on that page are the as normal.  You might need to alter some of the SRTP settings for voice encryption, on the VoIP Settings page:

  • SRTP Mode. This also depends on your SIP platform but Asterisk doesn’t handle negotiation of encryption so if it is being used at all, you need to get the phone to always use it, not attempt to negotiate.  In that case, this setting is set to “SRTP”


By default the Panasonic phone is set to accept all certificates (meaning that self-signed certificates will work OK).  You can provision the phones to verify the certificate if you want to using the setting SIP_TLS_VERIFY_1_=”1″.  You need to ensure that you have loaded the necessary root certificate beforehand.

Why use TLS & SRTP?

Security:  If you are able to sniff the traffic on someone’s network (e.g. using Wireshark or tcpdump) then you will capture any VoIP calls going on.  A tool such as Wireshark can be used to extract the audio from the RTP packets on the network.  The SIP packets can be read in plain-English and can be used to ascertain certain things such as what extension numbers there are, who is phoning different numbers etc…

If the SIP traffic is encrypted then no-one can see it other than the telephone and the SIP server at the other end (much like HTTPS used by secure websites).

If the RTP stream is encrypted then the audio cannot be extracted from the network without access to the SRTP keys generated on each call.  If you try this using Wireshark, the audio file you’ll get out of it will contain only white-noise.  Because the encryption keys for SRTP are generated on each call and send within the SIP packets, it would make no sense to use SRTP without encrypting the SIP packets as well.

Hiding SIP from Application Layer Gateways:  Routers with SIP-ALGs built into them are the biggest single cause of issues with SIP, things such as one-way audio, calls cutting out, calls failing to connect etc…. can all be caused by a SIP-ALG on a router.  The job of the ALG is to keep an eye out for SIP packets going past and then to modify them in an attempt to fix them up to work through NAT.  But they nearly always cause more problems than they solve.  A less obvious attraction to SIP-TLS is that if the SIP traffic is encrypted, then a SIP-ALG cannot possibly see any SIP traffic going through it and much less, make any modifications to it.  This can be very useful for remote phones talking to a hosted PBX or a central office PBX.

The latter advantage is the main reason I am seeing people interested in SIP-TLS or already using it, rather than it’s intended use which is for secure calling.