20.35 Server

   The Server header field contains information about the software used
   by the UAS to handle the request.

   Revealing the specific software version of the server might allow the
   server to become more vulnerable to attacks against software that is
   known to contain security holes.  Implementers SHOULD make the Server
   header field a configurable option.

   Example:

      Server: HomeServer v2

20.36 Subject

   The Subject header field provides a summary or indicates the nature
   of the call, allowing call filtering without having to parse the
   session description.  The session description does not have to use
   the same subject indication as the invitation.

   The compact form of the Subject header field is s.


   Example:

      Subject: Need more boxes
      s: Tech Support

20.37 Supported

   The Supported header field enumerates all the extensions supported by
   the UAC or UAS.

   The Supported header field contains a list of option tags, described
   in Section 19.2, that are understood by the UAC or UAS.  A UA
   compliant to this specification MUST only include option tags
   corresponding to standards-track RFCs.  If empty, it means that no
   extensions are supported.

   The compact form of the Supported header field is k.

   Example:

      Supported: 100rel

20.38 Timestamp

   The Timestamp header field describes when the UAC sent the request to
   the UAS.

   See Section 8.2.6 for details on how to generate a response to a
   request that contains the header field.  Although there is no
   normative behavior defined here that makes use of the header, it
   allows for extensions or SIP applications to obtain RTT estimates.

   Example:

      Timestamp: 54

20.39 To

   The To header field specifies the logical recipient of the request.

   The optional "display-name" is meant to be rendered by a human-user
   interface.  The "tag" parameter serves as a general mechanism for
   dialog identification.

   See Section 19.3 for details of the "tag" parameter.


   Comparison of To header fields for equality is identical to
   comparison of From header fields.  See Section 20.10 for the rules
   for parsing a display name, URI and URI parameters, and header field
   parameters.

   The compact form of the To header field is t.

   The following are examples of valid To header fields:

      To: The Operator <sip:
 This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
 >;tag=287447
      t: sip:+
 This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
 

20.40 Unsupported

   The Unsupported header field lists the features not supported by the
   UAS.  See Section 20.32 for motivation.

   Example:

      Unsupported: foo

20.41 User-Agent

   The User-Agent header field contains information about the UAC
   originating the request.  The semantics of this header field are
   defined in [H14.43].

   Revealing the specific software version of the user agent might allow
   the user agent to become more vulnerable to attacks against software
   that is known to contain security holes.  Implementers SHOULD make
   the User-Agent header field a configurable option.

   Example:

      User-Agent: Softphone Beta1.5

20.42 Via

   The Via header field indicates the path taken by the request so far
   and indicates the path that should be followed in routing responses.
   The branch ID parameter in the Via header field values serves as a
   transaction identifier, and is used by proxies to detect loops.

   A Via header field value contains the transport protocol used to send
   the message, the client's host name or network address, and possibly
   the port number at which it wishes to receive responses.  A Via
   header field value can also contain parameters such as "maddr",
   "ttl", "received", and "branch", whose meaning and use are described
   in other sections.  For implementations compliant to this
   specification, the value of the branch parameter MUST start with the
   magic cookie "z9hG4bK", as discussed in Section 8.1.1.7.

   Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP".
   "TLS" means TLS over TCP.  When a request is sent to a SIPS URI, the
   protocol still indicates "SIP", and the transport protocol is TLS.

Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207
     ;branch=z9hG4bK77asjd

   The compact form of the Via header field is v.

   In this example, the message originated from a multi-homed host with
   two addresses, 192.0.2.1 and 192.0.2.207.  The sender guessed wrong
   as to which network interface would be used.  Erlang.bell-
   telephone.com noticed the mismatch and added a parameter to the
   previous hop's Via header field value, containing the address that
   the packet actually came from.

   The host or network address and port number are not required to
   follow the SIP URI syntax.  Specifically, LWS on either side of the
   ":" or "/" is allowed, as shown here:

      Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16
        ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1

   Even though this specification mandates that the branch parameter be
   present in all requests, the BNF for the header field indicates that
   it is optional.  This allows interoperation with RFC 2543 elements,
   which did not have to insert the branch parameter.

   Two Via header fields are equal if their sent-protocol and sent-by
   fields are equal, both have the same set of parameters, and the
   values of all parameters are equal.

<< Prev - Next >>