/mcpsource transport information, so the binding gets created between the device ID and the transport information. The transport information that is used differs for UDP and TCP. For UDP, the system creates the binding between the device ID and the IP address and port number in the Contact header. After the first REGISTER message is sent, all subsequent requests must use the same IP address and port number in the Contact header. If it changes, a 5xx error response gets returned because Unified CM cannot route the message. For TCP, the system uses a combination of Contact binding and TCP connection binding. When a device registers over a TCP connection, Unified CM cannot determine whether the TCP connection will be transient (a new connection gets used for each transaction) or persistent. Therefore, Unified CM initially binds the device ID to the Contact IP address and port number. After several transactions get sent over the same TCP connection, the system considers it as proved-in and marks it as persistent. At this point, a binding gets created between the device ID and the TCP connection. Multiple Bindings for the Same AOR Unified Communications Manager includes a minor deviation from RFC3261 for the case of multiple registration bindings for a single address of record. Under the Unified CM architecture, if three devices are configured to have a shared line at 321-1000, each registers a contact in the form of 3211000@ip:port for that line. Each device has its own unique IP address and thus have a unique contact for that line. RFC3261 states that, upon registration, all known contact bindings shall be returned to the registering entity in the 200 OK response. Unified CM will only return the contact binding of the registering device during each registration; it will not enumerate other bindings that it knows about for a given AOR during registration. A registering endpoint should not rely on the binding list that is returned in the 200 OK response as an exhaustive list for all bindings that are associated with the AOR. In addition, an endpoint cannot modify bindings for another device through Unified CM; it can only refresh or delete its own binding. Contact: * Unified Communications Manager deviates from RFC3261 in that it does not support the Contact: * format. This format is often used to unregister all contacts currently associated with an AOR. However Unified CM requires that the Contact header in each REGISTER message must contain the SIP URI identifying the device, and the unregister message (REGISTER with Expires: 0) must contain the same Contact header as the original REGISTER message. This restriction occurs because Unified CM must be able to identify the source device for each incoming SIP message, and it uses the Contact header for that purpose. Unified CM cannot use the AOR in the To header because the shared line feature allows multiple different source devices to have the same AOR; thus, it is not unique to a specific device. Basic Call Unified Communications Manager follows the procedures that are described in RFC 3261, 3262, and 3264 to establish and clear down basic SIP calls. Often, on the outgoing side, Unified CM will send out INVITE without SDP. This allows Unified CM to discover the capabilities of both sides and provide media services in between if necessary (for example, transcoding). Simple Hold and Resume Unified CM SIP line side supports simple media hold as per RFC 2543 (a.k.a. c = 0) or as per RFCs 3261 and 3264 (a = sendonly or a = inactive). SIP Line Messaging Guide (Standard Edition) for Cisco Unified Communications Manager 27 SIP Standard Line Interface Multiple Bindings for the Same AOR