Thanks for the keen observation. You're right that the TVS service does get activated on every installed node. However, this service will only be accessed on the nodes that are in the CUCM CallManager Group of the phone (and in some cases TFTP).   The phone logic on searching for a TVS server works like this: 1. First CUCM Server 2. Second CUCM Server (if present) 3. Third CUCM Server (if present) 4. TFTP Server - last resort   I'll reword the document accordingly. ... View more

I had this problem and fixed it. We were absolutely positive that the FQDN configuration on the OpenAM server was correct. Certainly verify that first on your server, but it's not the ONLY thing that throws this error. Looking at the OpenAM debug logs set at the Message level in the Authentication file, I was able to see numerous failed authentication attempts for the "demo" user when I tried to enable SSO. We had earlier removed the demo user because it shouldn't be really needed for any production OpenAM deployments. We were wrong. I added the demo user back to the OpenDJ embedded database "Access Control > Top Level Realm > Subjects" and then I was able to enable SSO on my CUCM server. The UserID is "demo" the password is "changeit" and all fields are mandatory, even thought First Name doesn't always have the * that indicates it is mandatory.   Hopefully there will be either a documentation defect or a code defect coming out of this recent discovery. ... View more

SBD only provides the three functions mentioned above: Security By Default provides these three functions for supported IP Phones: Default authentication of TFTP downloaded files (configuration, locale, ringlist, etc) using a signing key. Optional encryption of TFTP configuration files using a signing key. Certificate  verification for phone initiated HTTPS connections using a remote  certificate trust store on Communications Manager (Trust Verification  Service). For voice payload authentication and encryption you need to use the CTL and USB eToken based security that I describe in my other document. https://supportforums.cisco.com/docs/DOC-18834 ... View more

Carlos, The 7975 and 9971 will work without any problem. The 7940 will need to have the CTL deleted OR you will need to update their CTL file to add in the new address of the TFTP server in the old cluster's CTL file. This is because the older 7940 and 7960 phones have a strict requirement where they ONLY trust TFTP servers if the address of the server is inside the CTL file. Newer model phones got rid of this requirement and will trust a TFTP server at any address as long as the certificate signature matches. ... View more

Carlos, It sounds like you're missing the Cisco Root CA 2048. ... View more

dsdavid@trends.com , 9369: WRN 23:16:12.863676 VPNC: protocol_handler: connect : err: SSL success DTLS fail I think the answer is written in the trace line above. Phone VPN requires both a TLS and a DTLS session to function properly. Make sure that you have TCP and UDP connectivity on port 443 from the phone to the ASA, and that DTLS is enabled. ... View more

Anas, In regards to your question "What will be the impact on network devices when we deploy SRTP?", Akhil mentioned the impact of the encrypted signaling to your UC devices such as CUCM. There should be no big impact for any network device that has to pass the SRTP payload data because there is really isn't much increase in payload size for the SRTP authentication material. Here's a common caluclation that would be performed to check your QoS settings: G711 RTP @ 20 msec packetization = 160 byte payload @ 50 packets per second = 80 kbps of payload With L2 + L3 overhead this is ~88kbps http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml When you enable SRTP we add 4 bytes to the payload G711 SRTP @ 20 mseco packetization = 164 byte payload @ 50 pps = 82 kbps payload or 90 kbps assuming Ethernet and IP overhead. This is a negligible increase in bandwidth per call. Endpoints that have to process the SRTP packets on the other hand such as transcoders, conference bridges, and any CUBE endpoints will have additional resource requirements to perform the encryption and decryption as Akhil mentioned. ... View more

When you make a change to the phone's configuration (even things like an upgrade) this should work over the VPN tunnel. It sounds like you're having some other problem, either with the TFTP / HTTP download of the phone's configuration file (UDP 69 or TCP 6970 to TFTP Server), or with the TVS authentication of the downloaded configuration (TCP 2445 to CUCM Server). I'd take a look at the phone's web page for "Debug Display", "Status Messages", and "Console Logs". The phone may tell you what it's having a problem performing. ... View more

You can change the Tomcat certificate with no impact to the phones. This gets a little more complicated if you're using CUCM 8.X and above. You can still change the Tomcat certificate with no problem, but you have to make sure you restart TVS and TFTP afterward because the new HTTPS and TVS services are going to rely on the Tomcat certificate when the phone goes to a secure service URL. If you start talking about changing certs OTHER than Tomcat I'd recommend caution and searching for my other document on Security By Default. ... View more

Nirmal, Functionally there is no impact of this expired certificate. The session is still HTTPS / SSL encrypted. The only problem is that you will keep getting that warning, and might not notice if a REAL warning shows up about the site's authenticity. Hope this helps! -Jason ... View more

Verifying that the voice packets are SRST is a little more difficult.  The encrypted RTP packets will have the same payload type as the  unencrypted RTP packets, but they won't decode properly when you try to  play them back. They'll just be static. You can check the signaling to  ensure that SCCP or SIP or H.323 or MGCP negotiated SRTP, and then when  looking at the packet capture make sure that the RTP (SRTP after  encryption) is unable to be played back in any audio tools. For instance, G.711 RTP packets will have 7F7F7F7F7F7F in the RTP payload whenever silence is on the line. When you turn on SRTP and have silence you will see random encrypted data instead of the repeating 7F pattern. Another giveaway is that the RTP payload will be slightly larger when SRTP is in use. For example G.711u @ 20msec packetization has a payload size of 160bytes per packet. Looking at G.711ulaw in an RTP packet capture will show 160 bytes payload. In an SRTP stream the payload will show 164 bytes for each packet. ... View more

Cyprien, Each node will have an entry in the ITL file, yes that's true. The phone will only use those entires that exist in the phone configuration file though. Remember that the phone config file keeps a list of TVS servers that is an exact copy of the CallManager Group. This means a max of three entries. There is a special case though where the phone will use the 3 entries from the CallManager group first. As a last resort the phone attempts to use the TFTP server for TVS. If the TFTP server was not in the CM Group then this gives a maximum of 4 servers that any given phone could try for TVS. -Jason ... View more

Thanks so much for translating this document! ... View more

Luis, It sounds like you might be using CTL security if you are talking about certificates. I wrote another document for that: https://supportforums.cisco.com/docs/DOC-18834 The rest of your questions might be better answered by posting onto the IP Telephony forums. ... View more

Luis, This feature was introduced in 8.0. It did not exist before 8.0, so you will not be able to use it in 6.x or 7.x. -Jason ... View more