SIP URL Comparison

When a URL is received, the URLs are compared for equality. URL comparison can be done between two From SIP URLs, or it can be done between two To SIP URLs. For two URLs to be equal, the user, password, host, and port parameters must match. The order of the parameters does not to match.

The SIP: Core SIP Technology Enhancements feature changes the parameters allowed in SIP URLs. The maddr parameter and the transport parameter are not allowed in Cisco SIP gateway implementations. The user-param parameter is now the parameter for comparison.

If a compared parameter is omitted or not present, it is matched on the basis of its default value. The table below shows a list of SIP URL compared parameters and their default values.

The following is an example of equivalent URLs:

Original URL:

sip:36602@172.18.193.120

Equivalent URLs:

sip:36602@172.18.193.120:

sip:36602@172.18.193.120;tag=499270-A62;pname=pvalue

sip:36602@172.18.193.120;user=ip

sip:36602@172.18.193.120:5060

487 Sent for BYE Requests

RFC 2543-bis-04 requires that a user agent server (UAS) that receives a BYE request first send a response to any pending requests for that call before disconnecting. The SIP: Core SIP Technology Enhancements feature recommends that after receiving a BYE request the UAS respond with a 487 (Request Cancelled) status message.

3xx Redirection Responses

The processing of 3xx redirection responses was updated in the SIP: Core SIP Technology Enhancements feature as follows:

• The Uniform Resource Identifier (URI) of the redirected INVITE is updated to contain the new contact information provided by the 3xx redirect message.

• The transmitted CSeq number found in the CSeq header is increased by one. The new INVITE includes the updated CSeq.

• The To, From, and Call ID headers that identify the call leg remain the same. The same Call ID gives consistency when capturing billing history.

• The user agent client (UAC) retries the request at the new address given by the 3xx Contact header field.

See the Examples for a sample call flow that shows the updated CSeq numbers.

DNS SRV Query Procedure

When a Request URI or the session target in the dial peer contains a fully qualified domain name (FQDN), the UAC needs to determine the protocol, port, and IP address of the endpoint before it forwards the request. SIP on Cisco gateways uses a Domain Name System Server (DNS SRV) query to determine the protocol, port, and IP address of the user endpoint.

Before the SIP: Core SIP Technology Enhancements feature, the DNS query procedure did not take into account the destination port.

CANCEL Request Route Header

The SIP: Core SIP Technology Enhancements feature does not allow a CANCEL message sent by a UAC on an initial INVITE request to have a Route header. Route headers cannot appear in a CANCEL message because they take the same path as INVITE requests, and INVITE requests cannot contain Route headers.

Interpret User Parameters

Telephone-subscriber or user parameters in an incoming INVITE message may contain extra characters to incorporate space, control characters, quotation marks, hash marks, and other characters. The SIP: Core SIP Technology Enhancements feature allows, the telephone-subscriber or user parameter to be interpreted before dial-peer matching is done. For example, the telephone number in an incoming INVITE message may appear as:

-%32%32%32

Although 222 is a valid telephone number, it requires interpretation. If the interpretation is not done, the call attempt fails when the user parameter is matched with the dial-peer destination pattern.

user=phone Parameter

A SIP URL identifies a user’s address, whose appearance is similar to that of an e-mail address. The form of the user’s address is user@host where user is the user identification and host is either a domain name or a numeric network address. For example, the request line of an outgoing INVITE request might appear as:

INVITE sip:5550002@companyb.com

With the SIP: Core SIP Technology Enhancements feature.The user=phone parameter formerly required in a SIP URL is no longer necessary. However, if an incoming SIP message has a SIP URL with user=phone, user=phone is parsed and used in the subsequent messages of the transaction.

303 and 411 SIP Cause Codes

The SIP: Core SIP Technology Enhancements feature obsoletes the SIP cause codes 303 Redirection: See Other and 411 Client Error: Length required .

Flexibility of Content-Type Header

The SIP: Core SIP Technology Enhancements feature allows the Content-Type header, which specifies the media type of the message body, to have an empty Session Description Protocol (SDP) body.

Optional SDP s= Line

The SIP: Core SIP Technology Enhancements feature accepts the "s=" line in SDP as optional. The "s=" line describes the reason or subject for SDP information. Cisco SIP gateways can create messages with an "s=" line in SDP bodies and can accept messages that have no "s=" line.

Allow Header Addition to INVITEs and 2xx Responses

The SIP: Core SIP Technology Enhancements feature enables the use of the Allow header in an initial or re-INVITE request or in any 2xx class response to an INVITE. The Allow header lists the set of methods supported by the user agent that is generating the message. Because it advertises what methods should be invoked on the user agent sending the message, it avoids congesting the message traffic unnecessarily. The Allow header can contain any or all of the following: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, NOTIFY, INFO, SUBSCRIBE.