Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
When a SIP proxy, SIP registrar, or any SIP server compliant with this protocol receives a message that has a Contact header field with the proxy parameter, it MUST perform the following steps in addition to the processing described in the [RFC3261]:
If the server is not the first node after the user agent, it MUST reject the message with a 400 response if the message is a request, and then discard the message if it is a response. The SIP server can determine if it is the first hop by examining the Via header field. More than one value in this field indicates that the SIP server is not the first hop.
If the proxy parameter in the Contact header field has any value other than "replace", the server MUST reject the message with a 400 response if message is a request, and discard the message if it is a response.
If the URI in the Contact header field has a transport parameter and the value of this parameter is not the same as the transport protocol of the connection over which the message was received, the server MUST reject the message with a 400 response if the message is a request, and discard the message if it is a response.
The server MUST remove the proxy parameter and its value from the Contact header field.
If the URI in the Contact header field has a maddr parameter, the server MUST replace its value with the value of the IP address of the far end of the connection on which the message was received.
If the URI in the Contact header field does not have a maddr parameter and the host portion of the URI is not an IP address, such as a host name, the server MUST add a maddr parameter with the value of the IP address of the far end of the connection on which the message was received to the Contact header field.
If the URI in the Contact header field does not have a maddr parameter and the host portion of the URI is an IP address and its value is not the same as the value of the IP address of the far end of the connection on which the message was received, the server MUST replace the host portion of the URI with the value of the IP address of the far end of the connection on which the message was received.
If the URI in the Contact header field does not have a port portion or if the port portion value is not the same as the value of the port of the far end of the connection on which the message was received, the server MUST add the port or replace its value with the value of the port of the far end of the connection on which the message was received.
The server MUST add a parameter with a value that uniquely identifies the connection on which the message was received among all other connections that were or could in the future be established by the server with the same tuple (address, port, and transport) on the far end to the URI of the Contact header field. The server can use the ms-received-cid parameter for this purpose and populate it with the value of the counter described in section 3.5.1.
If the server is a SIP proxy, it MUST insert the Record-Route header field into the message, as described in [RFC3261] section 16, to remain on the path of all the subsequent messages in the dialog that is created by the message.
The syntax for a SIP URI, including host and port portions and a maddr parameter, is defined in [RFC3261] section 25.1.
When a SIP server compliant with this protocol processes a request from another SIP element, it SHOULD save the identification information of the connection on which it received the request in the topmost Via header field. To do this, the server SHOULD use the following Via header field parameter values:
received parameter value, as defined in [RFC3261] section 25.1, to save the IP address of the far end of the connection.
ms-received-port parameter value, as defined in section 2.2.6, to save the port number of the far end of the connection.
ms-received-cid parameter value, defined in section 2.2.6, to save unique connection identifiers, which are values that uniquely identify the connection on which the message was received among all other connections that were or could in the future be established by the server with the same tuple (address, port, and transport. The server can populate ms-received-cid with the value of the counter described in section 3.5.1.