| This interface is the super interface of all SIP headers supported explicitly
by this specification. Extension Headers can be supported by this specification as required
by extending the
ExtensionHeader assuming other endpoints understand
the Header. This specification supports the following headers not defined in
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 |