tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2543


SIP: Session Initiation Protocol

Part 5 of 6, p. 104 to 133
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 104 
13 Security Considerations

13.1 Confidentiality and Privacy: Encryption

13.1.1 End-to-End Encryption

   SIP requests and responses can contain sensitive information about
   the communication patterns and communication content of individuals.
   The SIP message body MAY also contain encryption keys for the session
   itself. SIP supports three complementary forms of encryption to
   protect privacy:

        o  End-to-end encryption of the SIP message body and certain
          sensitive header fields;

Top      Up      ToC       Page 105 
        o  hop-by-hop encryption to prevent eavesdropping that tracks
          who is calling whom;

        o  hop-by-hop encryption of Via fields to hide the route a
          request has taken.

   Not all of the SIP request or response can be encrypted end-to-end
   because header fields such as To and Via need to be visible to
   proxies so that the SIP request can be routed correctly.  Hop-by-hop
   encryption encrypts the entire SIP request or response on the wire so
   that packet sniffers or other eavesdroppers cannot see who is calling
   whom. Hop-by-hop encryption can also encrypt requests and responses
   that have been end-to-end encrypted. Note that proxies can still see
   who is calling whom, and this information is also deducible by
   performing a network traffic analysis, so this provides a very
   limited but still worthwhile degree of protection.

   SIP Via fields are used to route a response back along the path taken
   by the request and to prevent infinite request loops. However, the
   information given by them can also provide useful information to an
   attacker. Section 6.22 describes how a sender can request that Via
   fields be encrypted by cooperating proxies without compromising the
   purpose of the Via field.

   End-to-end encryption relies on keys shared by the two user agents
   involved in the request. Typically, the message is sent encrypted
   with the public key of the recipient, so that only that recipient can
   read the message. All implementations SHOULD support PGP-based
   encryption [33] and MAY implement other schemes.

   A SIP request (or response) is end-to-end encrypted by splitting the
   message to be sent into a part to be encrypted and a short header
   that will remain in the clear. Some parts of the SIP message, namely
   the request line, the response line and certain header fields marked
   with "n" in the "enc." column in Table 4 and 5 need to be read and
   returned by proxies and thus MUST NOT be encrypted end-to-end.
   Possibly sensitive information that needs to be made available as
   plaintext include destination address (To) and the forwarding path
   (Via) of the call. The Authorization header field MUST remain in the
   clear if it contains a digital signature as the signature is
   generated after encryption, but MAY be encrypted if it contains
   "basic" or "digest" authentication. The From header field SHOULD
   normally remain in the clear, but MAY be encrypted if required, in
   which case some proxies MAY return a 401 (Unauthorized) status if
   they require a From field.

Top      Up      ToC       Page 106 
   Other header fields MAY be encrypted or MAY travel in the clear as
   desired by the sender. The Subject, Allow and Content-Type header
   fields will typically be encrypted. The Accept, Accept-Language,
   Date, Expires, Priority, Require, Call-ID, Cseq, and Timestamp header
   fields will remain in the clear.

   All fields that will remain in the clear MUST precede those that will
   be encrypted. The message is encrypted starting with the first
   character of the first header field that will be encrypted and
   continuing through to the end of the message body. If no header
   fields are to be encrypted, encrypting starts with the second CRLF
   pair after the last header field, as shown below. Carriage return and
   line feed characters have been made visible as "$", and the encrypted
   part of the message is outlined.

     INVITE SIP/2.0$
     Via: SIP/2.0/UDP$
     To: T. A. Watson <>$
     From: A. Bell <>$
     Encryption: PGP version=5.0$
     Content-Length: 224$
     CSeq: 488$
   * Subject: Mr. Watson, come here.$                    *
   * Content-Type: application/sdp$                      *
   * $                                                   *
   * v=0$                                                *
   * o=bell 53655765 2353687637 IN IP4$        *
   * c=IN IP4$                            *
   * m=audio 3456 RTP/AVP 0 3 4 5$                       *

   An Encryption header field MUST be added to indicate the encryption
   mechanism used. A Content-Length field is added that indicates the
   length of the encrypted body. The encrypted body is preceded by a
   blank line as a normal SIP message body would be.

   Upon receipt by the called user agent possessing the correct
   decryption key, the message body as indicated by the Content-Length
   field is decrypted, and the now-decrypted body is appended to the
   clear-text header fields. There is no need for an additional
   Content-Length header field within the encrypted body because the
   length of the actual message body is unambiguous after decryption.

Top      Up      ToC       Page 107 
   Had no SIP header fields required encryption, the message would have
   been as below. Note that the encrypted body MUST then include a blank
   line (start with CRLF) to disambiguate between any possible SIP
   header fields that might have been present and the SIP message body.

     INVITE SIP/2.0$
     Via: SIP/2.0/UDP$
     To: T. A. Watson <>$
     From: A. Bell <>$
     Encryption: PGP version=5.0$
     Content-Type: application/sdp$
     Content-Length: 107$
   * $                                             *
   * v=0$                                          *
   * o=bell 53655765 2353687637 IN IP4$  *
   * c=IN IP4$                      *
   * m=audio 3456 RTP/AVP 0 3 4 5$                 *

13.1.2 Privacy of SIP Responses

   SIP requests can be sent securely using end-to-end encryption and
   authentication to a called user agent that sends an insecure
   response.  This is allowed by the SIP security model, but is not a
   good idea.  However, unless the correct behavior is explicit, it
   would not always be possible for the called user agent to infer what
   a reasonable behavior was. Thus when end-to-end encryption is used by
   the request originator, the encryption key to be used for the
   response SHOULD be specified in the request. If this were not done,
   it might be possible for the called user agent to incorrectly infer
   an appropriate key to use in the response. Thus, to prevent key-
   guessing becoming an acceptable strategy, we specify that a called
   user agent receiving a request that does not specify a key to be used
   for the response SHOULD send that response unencrypted.

   Any SIP header fields that were encrypted in a request SHOULD also be
   encrypted in an encrypted response. Contact response fields MAY be
   encrypted if the information they contain is sensitive, or MAY be
   left in the clear to permit proxies more scope for localized

Top      Up      ToC       Page 108 
13.1.3 Encryption by Proxies

   Normally, proxies are not allowed to alter end-to-end header fields
   and message bodies. Proxies MAY, however, encrypt an unsigned request
   or response with the key of the call recipient.

        Proxies need to encrypt a SIP request if the end system
        cannot perform encryption or to enforce organizational
        security policies.

13.1.4 Hop-by-Hop Encryption

   SIP requests and responses MAY also be protected by security
   mechanisms at the transport or network layer. No particular mechanism
   is defined or recommended here. Two possibilities are IPSEC [34] or
   TLS [35]. The use of a particular mechanism will generally need to be
   specified out of band, through manual configuration, for example.

13.1.5 Via field encryption

   When Via header fields are to be hidden, a proxy that receives a
   request containing an appropriate "Hide: hop" header field (as
   specified in section 6.22) SHOULD encrypt the header field. As only
   the proxy that encrypts the field will decrypt it, the algorithm
   chosen is entirely up to the proxy implementor. Two methods satisfy
   these requirements:

        o  The server keeps a cache of Via header fields and the
          associated To header field, and replaces the Via header field
          with an index into the cache. On the reverse path, take the
          Via header field from the cache rather than the message.

        This is insufficient to prevent message looping, and so an
        additional ID MUST be added so that the proxy can detect loops.
        This SHOULD NOT normally be the address of the proxy as the goal
        is to hide the route, so instead a sufficiently large random
        number SHOULD be used by the proxy and maintained in the cache.

        It is possible for replies to get directed to the wrong
        originator if the cache entry gets reused, so great care needs
        to be taken to ensure this does not happen.

        o  The server MAY use a secret key to encrypt the Via field, a
          timestamp and an appropriate checksum in any such message with
          the same secret key. The checksum is needed to detect whether
          successful decoding has occurred, and the timestamp is

Top      Up      ToC       Page 109 
          required to prevent possible replay attacks and to ensure that
          no two requests from the same previous hop have the same
          encrypted Via field.  This is the preferred solution.

13.2 Message Integrity and Access Control: Authentication

   Protective measures need to be taken to prevent an active attacker
   from modifying and replaying SIP requests and responses. The same
   cryptographic measures that are used to ensure the authenticity of
   the SIP message also serve to authenticate the originator of the
   message.  However, the "basic" and "digest" authentication mechanism
   offer authentication only, without message integrity.

   Transport-layer or network-layer authentication MAY be used for hop-
   by-hop authentication. SIP also extends the HTTP WWW-Authenticate
   (Section 6.42) and Authorization (Section 6.11) header field and
   their Proxy counterparts to include cryptographically strong
   signatures. SIP also supports the HTTP "basic" and "digest" schemes
   (see Section 14) and other HTTP authentication schemes to be defined
   that offer a rudimentary mechanism of ascertaining the identity of
   the caller.

        Since SIP requests are often sent to parties with which no
        prior communication relationship has existed, we do not
        specify authentication based on shared secrets.

   SIP requests MAY be authenticated using the Authorization header
   field to include a digital signature of certain header fields, the
   request method and version number and the payload, none of which are
   modified between client and called user agent. The Authorization
   header field is used in requests to authenticate the request
   originator end-to-end to proxies and the called user agent, and in
   responses to authenticate the called user agent or proxies returning
   their own failure codes. If required, hop-by-hop authentication can
   be provided, for example, by the IPSEC Authentication Header.

   SIP does not dictate which digital signature scheme is used for
   authentication, but does define how to provide authentication using
   PGP in Section 15. As indicated above, SIP implementations MAY also
   use "basic" and "digest" authentication and other authentication
   mechanisms defined for HTTP. Note that "basic" authentication has
   severe security limitations. The following does not apply to these

   To cryptographically sign a SIP request, the order of the SIP header
   fields is important. When an Authorization header field is present,
   it indicates that all header fields following the Authorization

Top      Up      ToC       Page 110 
   header field have been included in the signature.  Therefore, hop-
   by-hop header fields which MUST or SHOULD be modified by proxies MUST
   precede the Authorization header field as they will generally be
   modified or added-to by proxy servers.  Hop-by-hop header fields
   which MAY be modified by a proxy MAY appear before or after the
   Authorization header. When they appear before, they MAY be modified
   by a proxy. When they appear after, they MUST NOT be modified by a
   proxy. To sign a request, a client constructs a message from the
   request method (in upper case) followed, without LWS, by the SIP
   version number, followed, again without LWS, by the request headers
   to be signed and the message body.  The message thus constructed is
   then signed.

   For example, if the SIP request is to be:

   Via: SIP/2.0/UDP
   Authorization: PGP version=5.0, signature=...
   From: A. Bell <>
   To: T. A. Watson <>
   Subject: Mr. Watson, come here.
   Content-Type: application/sdp
   Content-Length: ...

   o=bell 53655765 2353687637 IN IP4
   c=IN IP4
   m=audio 3456 RTP/AVP 0 3 4 5

   Then the data block that is signed is:

   INVITESIP/2.0From: A. Bell <>
   To: T. A. Watson <>
   Subject: Mr. Watson, come here.
   Content-Type: application/sdp
   Content-Length: ...

   o=bell 53655765 2353687637 IN IP4
   c=IN IP4
   m=audio 3456 RTP/AVP 0 3 4 5

Top      Up      ToC       Page 111 
   Clients wishing to authenticate requests MUST construct the portion
   of the message below the Authorization header using a canonical form.
   This allows a proxy to parse the message, take it apart, and
   reconstruct it, without causing an authentication failure due to
   extra white space, for example. Canonical form consists of the
   following rules:

        o  No short form header fields

        o  Header field names are capitalized as shown in this document

        o  No white space between the header name and the colon

        o  A single space after the colon

        o  Line termination with a CRLF

        o  No line folding

        o  No comma separated lists of header values; each must appear
          as a separate header

        o  Only a single SP between tokens, between tokens and quoted
          strings, and between quoted strings; no SP after last token or
          quoted string

        o  No LWS between tokens and separators, except as described
          above for after the colon in header fields

   Note that if a message is encrypted and authenticated using a digital
   signature, when the message is generated encryption is performed
   before the digital signature is generated. On receipt, the digital
   signature is checked before decryption.

   A client MAY require that a server sign its response by including a
   Require: org.ietf.sip.signed-response request header field. The
   client indicates the desired authentication method via the WWW-
   Authenticate header.

   The correct behavior in handling unauthenticated responses to a
   request that requires authenticated responses is described in section

Top      Up      ToC       Page 112 
13.2.1 Trusting responses

   There is the possibility that an eavesdropper listens to requests and
   then injects unauthenticated responses that terminate, redirect or
   otherwise interfere with a call. (Even encrypted requests contain
   enough information to fake a response.)

   Clients need to be particularly careful with 3xx redirection
   responses.  Thus a client receiving, for example, a 301 (Moved
   Permanently) which was not authenticated when the public key of the
   called user agent is known to the client, and authentication was
   requested in the request SHOULD be treated as suspicious. The correct
   behavior in such a case would be for the called-user to form a dated
   response containing the Contact field to be used, to sign it, and
   give this signed stub response to the proxy that will provide the
   redirection. Thus the response can be authenticated correctly. A
   client SHOULD NOT automatically redirect such a request to the new
   location without alerting the user to the authentication failure
   before doing so.

   Another problem might be responses such as 6xx failure responses
   which would simply terminate a search, or "4xx" and "5xx" response

   If TCP is being used, a proxy SHOULD treat 4xx and 5xx responses as
   valid, as they will not terminate a search. However, fake 6xx
   responses from a rogue proxy terminate a search incorrectly. 6xx
   responses SHOULD be authenticated if requested by the client, and
   failure to do so SHOULD cause such a client to ignore the 6xx
   response and continue a search.

   With UDP, the same problem with 6xx responses exists, but also an
   active eavesdropper can generate 4xx and 5xx responses that might
   cause a proxy or client to believe a failure occurred when in fact it
   did not. Typically 4xx and 5xx responses will not be signed by the
   called user agent, and so there is no simple way to detect these
   rogue responses. This problem is best prevented by using hop-by-hop
   encryption of the SIP request, which removes any additional problems
   that UDP might have over TCP.

   These attacks are prevented by having the client require response
   authentication and dropping unauthenticated responses. A server user
   agent that cannot perform response authentication responds using the
   normal Require response of 420 (Bad Extension).

Top      Up      ToC       Page 113 
13.3 Callee Privacy

   User location and SIP-initiated calls can violate a callee's privacy.
   An implementation SHOULD be able to restrict, on a per-user basis,
   what kind of location and availability information is given out to
   certain classes of callers.

13.4 Known Security Problems

   With either TCP or UDP, a denial of service attack exists by a rogue
   proxy sending 6xx responses. Although a client SHOULD choose to
   ignore such responses if it requested authentication, a proxy cannot
   do so. It is obliged to forward the 6xx response back to the client.
   The client can then ignore the response, but if it repeats the
   request it will probably reach the same rogue proxy again, and the
   process will repeat.

14 SIP Authentication using HTTP Basic and Digest Schemes

   SIP implementations MAY use HTTP's basic and digest authentication
   mechanisms to provide a rudimentary form of security. This section
   overviews usage of these mechanisms in SIP. The basic operation is
   almost completely identical to that for HTTP [36]. This section
   outlines this operation, pointing to [36] for details, and noting the
   differences when used in SIP.

14.1 Framework

   The framework for SIP authentication parallels that for HTTP [36]. In
   particular, the BNF for auth-scheme, auth-param, challenge, realm,
   realm-value, and credentials is identical. The 401 response is used
   by user agent servers in SIP to challenge the authorization of a user
   agent client. Additionally, registrars and redirect servers MAY make
   use of 401 responses for authorization, but proxies MUST NOT, and
   instead MAY use the 407 response. The requirements for inclusion of
   the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and
   Authorization in the various messages is identical to [36].

   Since SIP does not have the concept of a canonical root URL, the
   notion of protections spaces are interpreted differently for SIP. The
   realm is a protection domain for all SIP URIs with the same value for
   the userinfo, host and port part of the SIP Request-URI. For example:

      INVITE SIP/2.0
      WWW-Authenticate:  Basic realm="business"

Top      Up      ToC       Page 114 

      INVITE SIP/2.0
      WWW-Authenticate: Basic realm="business"

   define different protection realms according to this rule.

   When a UAC resubmits a request with its credentials after receiving a
   401 or 407 response, it MUST increment the CSeq header field as it
   would normally do when sending an updated request.

14.2 Basic Authentication

   The rules for basic authentication follow those defined in [36], but
   with the words "origin server" replaced with "user agent server,
   redirect server , or registrar".

   Since SIP URIs are not hierarchical, the paragraph in [36] that
   states that "all paths at or deeper than the depth of the last
   symbolic element in the path field of the Request-URI also are within
   the protection space specified by the Basic realm value of the
   current challenge" does not apply for SIP. SIP clients MAY
   preemptively send the corresponding Authorization header with
   requests for SIP URIs within the same protection realm (as defined
   above) without receipt of another challenge from the server.

14.3 Digest Authentication

   The rules for digest authentication follow those defined in [36],
   with "HTTP 1.1" replaced by "SIP/2.0" in addition to the following

        1.   The URI included in the challenge has the following BNF:

             URI  =  SIP-URL

        2.   The BNF for digest-uri-value is:

             digest-uri-value  =  Request-URI ; a defined in Section

Top      Up      ToC       Page 115 
        3.   The example procedure for choosing a nonce based on Etag
             does not work for SIP.

        4.   The Authentication-Info and Proxy-Authentication-Info
             fields are not used in SIP.

        5.   The text in [36] regarding cache operation does not apply
             to SIP.

        6.   [36] requires that a server check that the URI in the
             request line, and the URI included in the Authorization
             header, point to the same resource. In a SIP context, these
             two URI's may actually refer to different users, due to
             forwarding at some proxy. Therefore, in SIP, a server MAY
             check that the request-uri in the Authorization header
             corresponds to a user that the server is willing to accept
             forwarded or direct calls for.

14.4 Proxy-Authentication

   The use of the Proxy-Authentication and Proxy-Authorization parallel
   that as described in [36], with one difference. Proxies MUST NOT add
   the Proxy-Authorization header. 407 responses MUST be forwarded
   upstream towards the client following the procedures for any other
   response. It is the client's responsibility to add the Proxy-
   Authorization header containing credentials for the proxy which has
   asked for authentication.

        If a proxy were to resubmit a request with a Proxy-
        Authorization header field, it would need to increment the
        CSeq in the new request. However, this would mean that the
        UAC which submitted the original request would discard a
        response from the UAS, as the CSeq value would be

   See sections 6.26 and 6.27 for additional information on usage of
   these fields as they apply to SIP.

15 SIP Security Using PGP

15.1 PGP Authentication Scheme

   The "pgp" authentication scheme is based on the model that the client
   authenticates itself with a request signed with the client's private
   key. The server can then ascertain the origin of the request if it
   has access to the public key, preferably signed by a trusted third

Top      Up      ToC       Page 116 
15.1.1 The WWW-Authenticate Response Header

        WWW-Authenticate =  "WWW-Authenticate" ":" "pgp" pgp-challenge
        pgp-challenge    =  * (";" pgp-params )
        pgp-params       =  realm | pgp-version | pgp-algorithm | nonce
        realm            =  "realm" "=" realm-value
        realm-value      =  quoted-string
        pgp-version      =  "version" "="
                             <"> digit *( "." digit ) *letter <">
        pgp-algorithm    =  "algorithm" "=" ( "md5" | "sha1" | token )
        nonce            =  "nonce" "=" nonce-value
        nonce-value      =  quoted-string

   The meanings of the values of the parameters used above are as

   realm: A string to be displayed to users so they know which identity
        to use. This string SHOULD contain at least the name of the host
        performing the authentication and MAY additionally indicate the
        collection of users who might have access. An example might be "
        Users with call-out privileges ".

   pgp-algorithm: The value of this parameter indicates the PGP message
        integrity check (MIC) to be used to produce the signature. If
        this not present it is assumed to be "md5". The currently
        defined values are "md5" for the MD5 checksum, and "sha1" for
        the SHA.1 algorithm.

   pgp-version: The version of PGP that the client MUST use. Common
        values are "2.6.2" and "5.0". The default is 5.0.

   nonce: A server-specified data string which should be uniquely
        generated each time a 401 response is made. It is RECOMMENDED
        that this string be base64 or hexadecimal data.  Specifically,
        since the string is passed in the header lines as a quoted
        string, the double-quote character is not allowed. The contents
        of the nonce are implementation dependent. The quality of the
        implementation depends on a good choice. Since the nonce is used
        only to prevent replay attacks and is signed, a time stamp in
        units convenient to the server is sufficient.

Top      Up      ToC       Page 117 
        Replay attacks within the duration of the call setup are of
        limited interest, so that timestamps with a resolution of a
        few seconds are often should be sufficient. In that case,
        the server does not have to keep a record of the nonces.


   WWW-Authenticate: pgp ;version="5.0"
     ;realm="Your Startrek identity, please" ;algorithm=md5

15.1.2 The Authorization Request Header

   The client is expected to retry the request, passing an Authorization
   header line, which is defined as follows.

        Authorization  =  "Authorization" ":" "pgp" *( ";" pgp-response )
        pgp-response   =  realm | pgp-version | pgp-signature
                          | signed-by | nonce
        pgp-signature  =  "signature" "=" quoted-string
        signed-by      =  "signed-by" "=" <"> URI <">

   The client MUST increment the CSeq header before resubmitting the
   request. The signature MUST correspond to the From header of the
   request unless the signed-by parameter is provided.

   pgp-signature: The PGP ASCII-armored signature [33], as it appears
        between the "BEGIN PGP MESSAGE" and "END PGP MESSAGE"
        delimiters, without the version indication. The signature is
        included without any linebreaks.

   The signature is computed across the nonce (if present), request
   method, request version and header fields following the Authorization
   header and the message body, in the same order as they appear in the
   message. The request method and version are prepended to the header
   fields without any white space. The signature is computed across the
   headers as sent, and the terminating CRLF. The CRLF following the
   Authorization header is NOT included in the signature.

   A server MAY be configured not to generate nonces only if replay
   attacks are not a concern.

Top      Up      ToC       Page 118 
        Not generating nonces avoids the additional set of request,
        401 response and possibly ACK messages and reduces delay by
        one round-trip time.

        Using the ASCII-armored version is about 25% less space-
        efficient than including the binary signature, but it is
        significantly easier for the receiver to piece together.
        Versions of the PGP program always include the full
        (compressed) signed text in their output unless ASCII-
        armored mode ( -sta ) is specified.  Typical signatures are
        about 200 bytes long. -- The PGP signature mechanism allows
        the client to simply pass the request to an external PGP
        program. This relies on the requirement that proxy servers
        are not allowed to reorder or change header fields.

   realm: The realm is copied from the corresponding WWW-Authenticate
        header field parameter.

   signed-by: If and only if the request was not signed by the entity
        listed in the From header, the signed-by header indicates the
        name of the signing entity, expressed as a URI.

   Receivers of signed SIP messages SHOULD discard any end-to-end header
   fields above the Authorization header, as they may have been
   maliciously added en route by a proxy.


   Authorization: pgp version="5.0"
     ;realm="Your Startrek identity, please"

15.2 PGP Encryption Scheme

   The PGP encryption scheme uses the following syntax:

        Encryption    =  "Encryption" ":" "pgp" pgp-eparams
        pgp-eparams   =  1# ( pgp-version | pgp-encoding )
        pgp-encoding  =  "encoding" "=" "ascii" | token

Top      Up      ToC       Page 119 
   encoding: Describes the encoding or "armor" used by PGP. The value
        "ascii" refers to the standard PGP ASCII armor, without the
        lines containing "BEGIN PGP MESSAGE" and "END PGP MESSAGE" and
        without the version identifier. By default, the encrypted part
        is included as binary.


   Encryption: pgp version="2.6.2", encoding="ascii"

15.3 Response-Key Header Field for PGP

        Response-Key  =  "Response-Key" ":" "pgp" pgp-eparams
        pgp-eparams   =  1# ( pgp-version | pgp-encoding | pgp-key)
        pgp-key       =  "key" "=" quoted-string

   If ASCII encoding has been requested via the encoding parameter, the
   key parameter contains the user's public key as extracted from the
   pgp key ring with the "pgp -kxa user ".


   Response-Key: pgp version="2.6.2", encoding="ascii",

16 Examples

   In the following examples, we often omit the message body and the
   corresponding Content-Length and Content-Type headers for brevity.

16.1 Registration

   A user at host registers on start-up, via
   multicast, with the local SIP server named In the
   example, the user agent on saturn expects to receive SIP requests on
   UDP port 3890.

Top      Up      ToC       Page 120 
         Via: SIP/2.0/UDP
         CSeq: 1 REGISTER
         Contact: <;transport=udp>
         Expires: 7200

   The registration expires after two hours. Any future invitations for arriving at will now be
   redirected to, UDP port 3890.

   If Watson wants to be reached elsewhere, say, an on-line service he
   uses while traveling, he updates his reservation after first
   cancelling any existing locations:

         Via: SIP/2.0/UDP
         CSeq: 2 REGISTER
         Contact: *
         Expires: 0

         Via: SIP/2.0/UDP
         CSeq: 3 REGISTER

   Now, the server will forward any request for Watson to the server at, using the Request-URI For the
   server at to reach Watson, he will need to send a
   REGISTER there, or inform the server of his current location through
   some other means.

   It is possible to use third-party registration. Here, the secretary
   jon.diligent registers his boss, T. Watson:

Top      Up      ToC       Page 121 
         Via: SIP/2.0/UDP
         CSeq: 1 REGISTER

   The request could be sent to either the registrar at or
   the server at In the latter case, the server at would proxy the request to the address indicated in the
   Request-URI. Then, Max-Forwards header could be used to restrict the
   registration to that server.

16.2 Invitation to a Multicast Conference

   The first example invites to a multicast
   session. All examples use the Session Description Protocol (SDP) (RFC
   2327 [6]) as the session description format.

16.2.1 Request

   C->S: INVITE SIP/2.0
         Via: SIP/2.0/UDP;branch=8348
         Via: SIP/2.0/UDP
         From: Mark Handley <>
         To: Eve Schooler <>
         CSeq: 1 INVITE
         Subject: SIP will be discussed, too
         Content-Type: application/sdp
         Content-Length: 187

         o=user1 53655765 2353687637 IN IP4
         s=Mbone Audio
         i=Discussion of Mbone Engineering Issues
         c=IN IP4
         t=0 0
         m=audio 3456 RTP/AVP 0

Top      Up      ToC       Page 122 
   The From request header above states that the request was initiated
   by and addressed to (From header
   fields). The Via fields list the hosts along the path from invitation
   initiator (the last element of the list) towards the callee. In the
   example above, the message was last multicast to the administratively
   scoped group with a ttl of 16 from the host The second Via header field indicates that it
   was originally sent from the host The Request-URI
   indicates that the request is currently being being addressed to, the local address that csvax looked up for
   the callee.

   In this case, the session description is using the Session
   Description Protocol (SDP), as stated in the Content-Type header.

   The header is terminated by an empty line and is followed by a
   message body containing the session description.

16.2.2 Response

   The called user agent, directly or indirectly through proxy servers,
   indicates that it is alerting ("ringing") the called party:

   S->C: SIP/2.0 180 Ringing
         Via: SIP/2.0/UDP;branch=8348
         Via: SIP/2.0/UDP
         From: Mark Handley <>
         To: Eve Schooler <> ;tag=9883472
         CSeq: 1 INVITE

   A sample response to the invitation is given below. The first line of
   the response states the SIP version number, that it is a 200 (OK)
   response, which means the request was successful. The Via headers are
   taken from the request, and entries are removed hop by hop as the
   response retraces the path of the request. A new authentication field
   MAY be added by the invited user's agent if required. The Call-ID is
   taken directly from the original request, along with the remaining
   fields of the request message. The original sense of From field is
   preserved (i.e., it is the session initiator).

   In addition, the Contact header gives details of the host where the
   user was located, or alternatively the relevant proxy contact point
   which should be reachable from the caller's host.

Top      Up      ToC       Page 123 
   S->C: SIP/2.0 200 OK
         Via: SIP/2.0/UDP;branch=8348
         Via: SIP/2.0/UDP
         From: Mark Handley <>
         To: Eve Schooler <> ;tag=9883472
         CSeq: 1 INVITE

   The caller confirms the invitation by sending an ACK request to the
   location named in the Contact header:

   C->S: ACK SIP/2.0
         Via: SIP/2.0/UDP
         From: Mark Handley <>
         To: Eve Schooler <> ;tag=9883472
         CSeq: 1 ACK

16.3 Two-party Call

   For two-party Internet phone calls, the response must contain a
   description of where to send the data. In the example below, Bell
   calls Watson. Bell indicates that he can receive RTP audio codings 0
   (PCMU), 3 (GSM), 4 (G.723) and 5 (DVI4).

   C->S: INVITE SIP/2.0
         Via: SIP/2.0/UDP
         From: A. Bell <>
         To: T. Watson <>
         CSeq: 1 INVITE
         Subject: Mr. Watson, come here.
         Content-Type: application/sdp
         Content-Length: ...

         o=bell 53655765 2353687637 IN IP4
         s=Mr. Watson, come here.
         c=IN IP4
         m=audio 3456 RTP/AVP 0 3 4 5

Top      Up      ToC       Page 124 
   S->C: SIP/2.0 100 Trying
         Via: SIP/2.0/UDP
         From: A. Bell <>
         To: T. Watson <> ;tag=37462311
         CSeq: 1 INVITE
         Content-Length: 0

   S->C: SIP/2.0 180 Ringing
         Via: SIP/2.0/UDP
         From: A. Bell <>
         To: T. Watson <> ;tag=37462311
         CSeq: 1 INVITE
         Content-Length: 0

   S->C: SIP/2.0 182 Queued, 2 callers ahead
         Via: SIP/2.0/UDP
         From: A. Bell <>
         To: T. Watson <> ;tag=37462311
         CSeq: 1 INVITE
         Content-Length: 0

   S->C: SIP/2.0 182 Queued, 1 caller ahead
         Via: SIP/2.0/UDP
         From: A. Bell <>
         To: T. Watson <> ;tag=37462311
         CSeq: 1 INVITE
         Content-Length: 0

   S->C: SIP/2.0 200 OK
         Via: SIP/2.0/UDP
         From: A. Bell <>
         To: <> ;tag=37462311
         CSeq: 1 INVITE
         Content-Type: application/sdp
         Content-Length: ...

         o=watson 4858949 4858949 IN IP4
         s=I'm on my way
         c=IN IP4
         m=audio 5004 RTP/AVP 0 3

Top      Up      ToC       Page 125 
   The example illustrates the use of informational status responses.
   Here, the reception of the call is confirmed immediately (100), then,
   possibly after some database mapping delay, the call rings (180) and
   is then queued, with periodic status updates.

   Watson can only receive PCMU and GSM. Note that Watson's list of
   codecs may or may not be a subset of the one offered by Bell, as each
   party indicates the data types it is willing to receive. Watson will
   send audio data to port 3456 at, Bell will send to
   port 5004 at

   By default, the media session is one RTP session. Watson will receive
   RTCP packets on port 5005, while Bell will receive them on port 3457.

   Since the two sides have agreed on the set of media, Bell confirms
   the call without enclosing another session description:

   C->S: ACK SIP/2.0
         Via: SIP/2.0/UDP
         From: A. Bell <>
         To: T. Watson <> ;tag=37462311
         CSeq: 1 ACK

16.4 Terminating a Call

   To terminate a call, caller or callee can send a BYE request:

   C->S: BYE SIP/2.0
         Via: SIP/2.0/UDP
         From: A. Bell <>
         To: T. A. Watson <> ;tag=37462311
         CSeq: 2 BYE

   If the callee wants to abort the call, it simply reverses the To and
   From fields. Note that it is unlikely that a BYE from the callee will
   traverse the same proxies as the original INVITE.

Top      Up      ToC       Page 126 
16.5 Forking Proxy

   In this example, Bell ( (C), currently seated
   at host wants to call Watson ( At
   the time of the call, Watson is logged in at two workstations, (X) and (Y), and has
   registered with the IEEE proxy server (P) called The
   IEEE server also has a registration for the home machine of Watson,
   at (H), as well as a permanent registration at (A). For brevity, the examples omit the session
   description and Via header fields.

   Bell's user agent sends the invitation to the SIP server for the domain:

   C->P: INVITE SIP/2.0
         Via:     SIP/2.0/UDP
         From:    A. Bell <>
         To:      T. Watson <>
         CSeq:    1 INVITE

   The SIP server at tries the four addresses in parallel.  It
   sends the following message to the home machine:

   P->H: INVITE SIP/2.0
         Via:     SIP/2.0/UDP ;branch=1
         Via:     SIP/2.0/UDP
         From:    A. Bell <>
         To:      T. Watson <>
         CSeq:    1 INVITE

   This request immediately yields a 404 (Not Found) response, since
   Watson is not currently logged in at home:

   H->P: SIP/2.0 404 Not Found
         Via:     SIP/2.0/UDP ;branch=1
         Via:     SIP/2.0/UDP
         From:    A. Bell <>
         To:      T. Watson <>;tag=87454273

Top      Up      ToC       Page 127 
         CSeq:    1 INVITE

   The proxy ACKs the response so that host H can stop retransmitting

   P->H: ACK SIP/2.0
         Via:     SIP/2.0/UDP ;branch=1
         From:    A. Bell <>
         To:      T. Watson <>;tag=87454273
         CSeq:    1 ACK

   Also, P attempts to reach Watson through the ACM server:

   P->A: INVITE SIP/2.0
         Via:     SIP/2.0/UDP ;branch=2
         Via:     SIP/2.0/UDP
         From:    A. Bell <>
         To:      T. Watson <>
         CSeq:    1 INVITE

   In parallel, the next attempt proceeds, with an INVITE to X and Y:

   P->X: INVITE SIP/2.0
         Via:     SIP/2.0/UDP ;branch=3
         Via:     SIP/2.0/UDP
         From:    A. Bell <>
         To:      T. Watson <>
         CSeq:    1 INVITE

   P->Y: INVITE SIP/2.0
         Via:     SIP/2.0/UDP ;branch=4
         Via:     SIP/2.0/UDP
         From:    A. Bell <>
         To:      T. Watson <>
         CSeq:    1 INVITE

Top      Up      ToC       Page 128 
   As it happens, both Watson at X and a colleague in the other lab at
   host Y hear the phones ringing and pick up. Both X and Y return 200s
   via the proxy to Bell.

   X->P: SIP/2.0 200 OK
         Via:      SIP/2.0/UDP ;branch=3
         Via:      SIP/2.0/UDP
         From:     A. Bell <>
         To:       T. Watson <> ;tag=192137601
         CSeq:     1 INVITE

   Y->P: SIP/2.0 200 OK
         Via:      SIP/2.0/UDP ;branch=4
         Via:      SIP/2.0/UDP
         From:     A. Bell <>
         To:       T. Watson <> ;tag=35253448
         CSeq:     1 INVITE

   Both responses are forwarded to Bell, using the Via information.  At
   this point, the ACM server is still searching its database. P can now
   cancel this attempt:

   P->A: CANCEL SIP/2.0
         Via:     SIP/2.0/UDP ;branch=2
         From:    A. Bell <>
         To:      T. Watson <>
         CSeq:    1 CANCEL

   The ACM server gladly stops its neural-network database search and
   responds with a 200. The 200 will not travel any further, since P is
   the last Via stop.

   A->P: SIP/2.0 200 OK
         Via:     SIP/2.0/UDP ;branch=2
         From:    A. Bell <>
         To:      T. Watson <>

Top      Up      ToC       Page 129 
         CSeq:    1 CANCEL

   Bell gets the two 200 responses from X and Y in short order. Bell's
   reaction now depends on his software. He can either send an ACK to
   both if human intelligence is needed to determine who he wants to
   talk to or he can automatically reject one of the two calls. Here, he
   acknowledges both, separately and directly to the final destination:

   C->X: ACK SIP/2.0
         Via:      SIP/2.0/UDP
         From:     A. Bell <>
         To:       T. Watson <>;tag=192137601
         CSeq:     1 ACK

   C->Y: ACK SIP/2.0
         Via:      SIP/2.0/UDP
         From:     A. Bell <>
         To:       T. Watson <>;tag=35253448
         CSeq:     1 ACK

   After a brief discussion between Bell with X and Y, it becomes clear
   that Watson is at X. (Note that this is not a three-way call; only
   Bell can talk to X and Y, but X and Y cannot talk to each other.)
   Thus, Bell sends a BYE to Y, which is replied to:

   C->Y: BYE SIP/2.0
         Via:      SIP/2.0/UDP
         From:     A. Bell <>
         To:       T. Watson <>;tag=35253448
         CSeq:     2 BYE

   Y->C: SIP/2.0 200 OK
         Via:      SIP/2.0/UDP
         From:     A. Bell <>
         To:       T. Watson <>;tag=35253448
         CSeq:     2 BYE

Top      Up      ToC       Page 130 
16.6 Redirects

   Replies with status codes 301 (Moved Permanently) or 302 (Moved
   Temporarily) specify another location using the Contact field.
   Continuing our earlier example, the server P at decides to
   redirect rather than proxy the request:

   P->C: SIP/2.0 302 Moved temporarily
         Via:     SIP/2.0/UDP
         From:    A. Bell <>
         To:      T. Watson <>;tag=72538263
         CSeq:    1 INVITE
         CSeq: 1 INVITE

   As another example, assume Alice (A) wants to delegate her calls to
   Bob (B) while she is on vacation until July 29th, 1998. Any calls
   meant for her will reach Bob with Alice's To field, indicating to him
   what role he is to play. Charlie (C) calls Alice (A), whose server

   A->C: SIP/2.0 302 Moved temporarily
         From: Charlie <>
         To: Alice <> ;tag=2332462
         Expires: Wed, 29 Jul 1998 9:00:00 GMT
         CSeq: 1 INVITE

   Charlie then sends the following request to the SIP server of the domain. Note that the server at forwards
   the request to Bob based on the Request-URI.

   C->B: INVITE SIP/2.0
         CSeq: 2 INVITE

Top      Up      ToC       Page 131 
   In the third redirection example, we assume that all outgoing
   requests are directed through a local firewall F at, with
   Charlie again inviting Alice:

   C->F: INVITE SIP/2.0
         To: Alice <>
         CSeq: 1 INVITE

   The local firewall at happens to be overloaded and thus
   redirects the call from Charlie to a secondary server S:

   F->C: SIP/2.0 302 Moved temporarily
         To: Alice <>
         CSeq: 1 INVITE
         Contact: <;>

   Based on this response, Charlie directs the same invitation to the
   secondary server at port 5080, but maintains the
   same Request-URI as before:

   C->S: INVITE SIP/2.0
         To: Alice <>
         CSeq: 2 INVITE

16.7 Negotiation

   An example of a 606 (Not Acceptable) response is:

   S->C: SIP/2.0 606 Not Acceptable
         To: <> ;tag=7434264

Top      Up      ToC       Page 132 
         CSeq: 1 INVITE
         Warning: 370 "Insufficient bandwidth (only have ISDN)",
           305 "Incompatible media format",
           330 "Multicast not available"
         Content-Type: application/sdp
         Content-Length: 50

         s=Let's talk
         c=IN IP4
         m=audio 3456 RTP/AVP 5 0 7
         m=video 2232 RTP/AVP 31

   In this example, the original request specified a bandwidth that was
   higher than the access link could support, requested multicast, and
   requested a set of media encodings. The response states that only 128
   kb/s is available and that (only) DVI, PCM or LPC audio could be
   supported in order of preference.

   The response also states that multicast is not available.  In such a
   case, it might be appropriate to set up a transcoding gateway and
   re-invite the user.

16.8 OPTIONS Request

   A caller Alice can use an OPTIONS request to find out the
   capabilities of a potential callee Bob, without "ringing" the
   designated address. Bob returns a description indicating that he is
   capable of receiving audio encodings PCM Ulaw (payload type 0), 1016
   (payload type 1), GSM (payload type 3), and SX7300/8000 (dynamic
   payload type 99), and video encodings H.261 (payload type 31) and
   H.263 (payload type 34).

   C->S: OPTIONS SIP/2.0
         From: Alice <>
         To: Bob <>
         CSeq: 1 OPTIONS
         Accept: application/sdp

   S->C: SIP/2.0 200 OK
         From: Alice <>
         To: Bob <> ;tag=376364382

Top      Up      ToC       Page 133 
         Content-Length: 81
         Content-Type: application/sdp

         m=audio 0 RTP/AVP 0 1 3 99
         m=video 0 RTP/AVP 31 34
         a=rtpmap:99 SX7300/8000

Next RFC Part