etf.org/rfc/rfc3261.txt">RFC3261 documented in the following standards track RFCs:
- RAckHeader - this header is specific to the reliability of provisional Responses. This functionality is defined in RFC3262.
- RSeqHeader - this header is specific to the reliability of provisional Responses. This functionality is defined in RFC3262.
- AllowEventsHeader - this header is specific to the event notification framework. This functionality is defined in RFC3265.
- EventHeader - this header is specific to the event notification framework. This functionality is defined in RFC3265.
- SubscriptionStateHeader - this header is specific to the event notification framework. This functionality is defined in RFC3265.
- ReasonHeader - The Reason Header provides information on why a SIP request was issued, often useful when creating services and used to encapsulate a final status code in a provisional response. This functionality is defined in RFC3326.
SIP header fields are similar to HTTP header fields in both syntax and semantics. Some header fields only make sense in requests or responses. These are called request header fields and response header fields, respectively. If a header field appears in a message not matching its category (such as a request header field in a response), it MUST be ignored.
Header Handling:
Any SIP header whose grammar is of the form:
header = "header-name" HCOLON header-value *(COMMA header-value) allows for combining header fields of the same name into a comma-separated list. In this specification each Header object has a single value or attribute pair. For example a Header whose grammer is of the form:
Allow: Invite, Bye; would be represented in a SIP message with two AllowHeader objects each containing a single attribute, Invite and Bye respectively. Implementations MUST be able to parse multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms and translate them into the relevent Header objects defined in this specification.
The relative order of header objects within messages is not significant. However, it is RECOMMENDED that required header and headers which are needed for proxy processing (Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example) appear towards the top of the message to facilitate rapid parsing.
The relative order of header objects with the same field name is important. Multiple headers with the same name MAY be present in a message if and only if the entire field-value for that header field can be defined as a comma-separated list as defined by RFC 3261. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy-Authenticate, and Proxy-Authorization header fields. Multiple header objects with these names MAY be present in a message, but since their grammar does not follow the general form listed above, they MUST NOT be combined into a single header field row when sent over the network.
Even though an arbitrary number of parameter pairs may be attached to a header object, any given parameter-name MUST NOT appear more than once.
@author BEA Systems, NIST
@version 1.2