SRTP Support The default sRTP policy used by IPPhones is different from the one published (standard) as part of libSRTP code. libSRTP code is a free download, available at http://srtp.sourceforge.net/download.html. If the correct srtp policy is not used, the end result is no audio at both ends. The srtp_policy is used by media terminating endpoint to create a crypto context. It should match to encrypt and decrypt packets sent/received by IPPhones/CTIPorts. Phone is using one hardcoded srtp_policy for all phone types including sip phones. policy->cipher_type

AES_128_ICM;policy->cipher_key_len

30; policy->auth_type

HMAC_SHA1; policy->auth_key_len

20; policy->auth_tag_len

4 ; // changed to 4 from 10; policy->sec_serv

sec_serv_conf_and_auth; JTAPI clients doing their own media termination with SRTP, must use the above policy to create a crypto context. The default policy published as part of libSRTP (the standard policy documented as part of RFC) is not same as used by Cisco Unified IP Phone. Phones use the modified one to optimize the bandwidth. The sRTP policy must be part of negotiation between the endpoints but right now only one is supported and ccm does not support the negotiation, hence applications need to use the above policy to terminate media. Partition Support When same Directory Number with different partitions exist in a CallManager, getAddress(String number) API in JTAPI normally returns the first matching Address object which has the same Directory Number. This is done to maintain BWC in case of no partitions configured in the system. TLS Security When client certificate is installed, server certificates are also downloaded from CallManager TFTP server. However, server certificate is only verified for currect signature and server trust is not established. Hence it is recomented that first time download of certificate is done in trusted network. CiscoFeatureReason When a call redirectred across a GW is offered at an address, getCiscoFeatureReason() returns REASON_FORWARDNOANSWER. Within the same cluster when a call is redirected, the redirect destination sees REASON_REDIRECT as the CiscoFeatureReason. However, when a call is redirected across a cluster, through a Q.931 trunk, at the redirect destination getCiscoFeatureReason() returns REASON_FORWARDNOANSWER(as per Q.931 standard). Scenario: A, B and C are registered to 3 clusters. A calls B, B answers and redirects the call to C. When call is offered at C, getCiscoFeatureReason() will return REASON_FORWARDNOANSWER. Unicode Issue in Calls Involving SIP Trunks In SIP call scenarios, where the call comes back to the call manager from the SIP proxy over a SIP trunk, since the call manager is totally dependent on the SIP, messages to populate any names and since the SIP protocol has no way of populating both ASCII and Unicode, the passed-in name is just ASCII and the same Cisco Unified JTAPI Developers Guide for Cisco Unified Communications Manager, Release 15 and SUs 1720 Caveats SRTP Support