The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes a problem encountered where in Multipoint Control Unit (MCU) Version 4.5 and later, MCU converts : in a Session Initiation Protocol (SIP) URI to %3A because it treats : as a special character used to specify passwords. This causes calls to fail when the MCU is registered to a third-party gatekeeper.
MCU converts : in a SIP URI to %3A. The Video Communication Server (VCS) can properly decode the %3A back to : which is why calls from the MCU with : through the VCS work.
However, if the MCU is registered to a third-party gatekeeper, it cannot convert %3A into a :.
MCU Logs for MCU Version 4.4 (3.67) (where MCU does not code : into %3A):
After the upgrade of MCU to Version 4.5, the SIP address is changed from the URI address: record:email@example.com to record%3A97055@domain.com.
Instead of a : MCU sends %3A, which the third-party gatekeeper does not recognize and this causes the call to fail.
The solution is to either create a transform on the third-party gatekeeper to convert %3A to : or to not use : in SIP URIs.
There was a bug to track this issue CSCur46154 on the MCU side; however, this bug is now closed because MCU follows this RFC:
The RFC explains:
password: A password associated with the user. While the SIP and SIPS URI syntax allows this field to be present, its use is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URIs) has proven to be a security risk in almost every case where it has been used. For instance, transporting a PIN number in this field exposes the PIN.
Note that the password field is just an extension of the user portion. Implementations not wishing to give special significance to the password portion of the field MAY simply treat "user:password" as a single string.
Hence, it is up to the decoder to decode it as a single string user or a password (: is a special character), and MCU treats the : as a special character.