This Annex contains a profile to the IETF specifications which are referenced by this specification, and the PICS proformas underlying profiles do not add requirements to the specifications they are proformas for. This Annex provides a profile specification according to both the current IETF specifications for SIP, SDP and other protocols (as indicated by the "RFC status" column in the Tables in this Annex) which are referenced by this specification and to the 3GPP specifications using SIP (as indicated by the "Profile status" column in the Tables in this Annex. In the "RFC status" column the contents of the referenced specification takes precedence over the contents of the entry in the column. In the "Profile status" column, there are a number of differences from the "RFC status" column. Where these differences occur, these differences take precedence over any requirements of the IETF specifications. Where specification concerning these requirements exists in the main body of the present document, the main body of the present document takes precedence. Where differences occur in the "Profile status" column, the "Profile status" normally gives more strength to a "RFC status" and is not in contradiction with the "RFC status", e.g. it may change an optional "RFC status" to a mandatory "Profile status". If the "Profile status" weakens the strength of a "RFC status" then additionally this will be indicated by further textual description in the present document. For all IETF specifications that are not referenced by this document or that are not mentioned within the 3GPP profile of SIP and SDP, the generic rules as defined by RFC 3261 and in addition the rules in clause 5 and clause 6 of this specification apply, e.g.

• a proxy which is built in accordance to this specification passes on any unknown method, unknown header field or unknown header field parameter after applying procedures such as filtering, insertion of P-Asserted-Identity header field, etc.;
• an UA which is built in accordance to this specification will
  • handle received unknown methods in accordance to the procedures defined in RFC 3261, e.g. respond with a 501 (Not Implemented) response; and
  • handle unknown header fields and unknown header field parameters in accordance to the procedures defined in RFC 3261, e.g. respond with a 420 (Bad Extension) if an extension identified by an option-tag in the Require header field of the received request is not supported by the UA.

This subclause does not reflect dynamic conformance requirements but static ones. In particular, a condition for support of a PDU parameter does not reflect requirements about the syntax of the PDU (i.e. the presence of a parameter) but the capability of the implementation to support the parameter. In the sending direction, the support of a parameter means that the implementation is able to send this parameter (but it does not mean that the implementation always sends it). In the receiving direction, it means that the implementation supports the whole semantic of the parameter that is described in the main part of this specification. As a consequence, PDU parameter tables in this subclause are not the same as the tables describing the syntax of a PDU in the reference specification, e.g. RFC 3261 Tables 2 and 3. It is not rare to see a parameter which is optional in the syntax but mandatory in subclause below. The various statii used in this subclause are in accordance with the rules in Table A.1.

In the context of this specification the "i" status code mandates that the implementation does not change the content of the parameter. It is an implementation option if the implementation acts upon the content of the parameter (e.g. by setting filter criteria to known or unknown parts of parameters in order to find out the route a message has to take). It must be understood, that this 3GPP SIP profile does not list all parameters which an implementation will treat as indicated by the status code "irrelevant". In general an implementation will pass on all unknown messages, header fields and header field parameters, as long as it can perform its normal behaviour. The following additional comments apply to the interpretation of the tables in this Annex. As an example, the profile for the MGCF is found by first referring to clause 4.1, which states "The MGCF shall provide the UA role". Profiles are divided at the top level into the two roles in Table A.2, user agent and proxy. The UA role is defined in clause A.2.1 and the proxy role is defined in clause A.2.2. More specific roles are listed in Table A.3, Table A.3A, Table A.3B and Table A.3C. The MGCF role is item 6 in Table A.3 (the MGCF role is not found in Table A.3A or Table A.3B). Therefore, all profile entries for the MGCF are found by searching for A.3/6 in clause A.2.1. As a further example, to look up support of the Reason header field, Table A.4 item 38 lists the Resaon header field as a major capability that is optional for the user agent role. A subsequent search for A.4/38 in clause A.2.1 shows that the Reason header field is optional for a user agent role to send and receive for ACK, BYE, CANCEL, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE, and UPDATE requests. Also, Table A.162 item 48 lists the Reason header field as a major capability that is optional for the proxy role. A subsequent search for A.162/48 in clause A.2.2 shows that, if supported, the Reason header field is mandatory to send and irrelevant to receive for ACK, BYE, CANCEL, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, PUBLISH, REFER, REGISTER, SUBSCRIBE, and UPDATE requests.