home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mmusic-sip-02.txt < prev    next >
Text File  |  1997-03-27  |  82KB  |  2,131 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6. Internet Engineering Task Force                                 MMUSIC WG
  7. Internet Draft                    M. Handley, H. Schulzrinne, E. Schooler
  8. ietf-mmusic-sip-02.txt                            ISI/Columbia U./Caltech
  9. March 27, 1997
  10. Expires: September 25, 1997
  11.  
  12.  
  13.                     SIP: Session Initiation Protocol
  14.  
  15. STATUS OF THIS MEMO
  16.  
  17.    This document is an Internet-Draft. Internet-Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its areas,
  19.    and its working groups.  Note that other groups may also distribute
  20.    working documents as Internet-Drafts.
  21.  
  22.    Internet-Drafts are draft documents valid for a maximum of six months
  23.    and may be updated, replaced, or obsoleted by other documents at any
  24.    time.  It is inappropriate to use Internet-Drafts as reference
  25.    material or to cite them other than as ``work in progress''.
  26.  
  27.    To learn the current status of any Internet-Draft, please check the
  28.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  29.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  30.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  31.    ftp.isi.edu (US West Coast).
  32.  
  33.    Distribution of this document is unlimited.
  34.  
  35.                                  ABSTRACT
  36.  
  37.  
  38.          Many styles of multimedia conferencing are likely to co-
  39.          exist on the Internet, and many of them share the need to
  40.          invite users to participate. The Session Initiation
  41.          Protocol (SIP) is a simple protocol designed to enable
  42.          the invitation of users to participate in such multimedia
  43.          sessions. It is not tied to any specific conference
  44.          control scheme, providing support for either loosely or
  45.          tightly controlled sessions. In particular, it aims to
  46.          enable user mobility by relaying and redirecting
  47.          invitations to a user's current location.
  48.  
  49.          This document is a product of the Multiparty Multimedia
  50.          Session Control (MMUSIC) working group of the Internet
  51.          Engineering Task Force.  Comments are solicited and
  52.          should be addressed to the working group's mailing list
  53.          at confctrl@isi.edu and/or the authors.
  54.  
  55.  
  56.  
  57. M. Handley, H. Schulzrinne, E. Schooler                       [Page 1]
  58.  
  59. Internet Draft                    sip                     March 27, 1997
  60.  
  61.  
  62.    Authors' Note
  63.  
  64.    This document is the result of a merger of the Session Invitation
  65.    Protocol (draft-ietf-mmusic-sip-00.txt) and the Simple Conference
  66.    Invitation Protocol (draft-ietf-mmusic-scip-00.txt), and of an
  67.    attempt to make SIP more generic and to fit into a more flexible
  68.    infrastructure that includes companion protocols including SDP, HTTP
  69.    and RTSP.
  70.  
  71.  
  72.    Changes
  73.  
  74.    Since version -01, the following things have changed:
  75.  
  76.         o CAPABILITIES to OPTIONS for closer alignment with HTTP and
  77.          RTSP;
  78.  
  79.         o Path to Via for closer alignment with HTTP and RTSP;
  80.  
  81.         o Content type meta changed to application, since "meta" doesn't
  82.          exist as a top-level Internet media type.
  83.  
  84.         o Formatting closer to HTTP and RTSP.
  85.  
  86.         o Explain relationship to H.323.
  87.  
  88. 1 Introduction
  89.  
  90.    There are two basic ways to locate and to participate in a multimedia
  91.    session:
  92.  
  93.         o The session is advertised, users see the advertisement, then
  94.          join the session address to participate.
  95.  
  96.         o Users are invited to participate in a session, which may or
  97.          may not already be advertised.
  98.  
  99.    The Session Description Protocol (SDP) [1] together with the Session
  100.    Announcement Protocol (SAP) [2], provide a mechanism for the former.
  101.    This document presents the Session Initiation Protocol (SIP) to
  102.    perform the latter. SIP MAY also use SDP to describe a session.
  103.  
  104.  
  105.                       Figure omitted in ASCII version
  106.  
  107.  
  108.    Figure 1: Session Lifecycle
  109.  
  110.  
  111.  
  112.  
  113. M. Handley, H. Schulzrinne, E. Schooler                       [Page 2]
  114.  
  115. Internet Draft                    sip                     March 27, 1997
  116.  
  117.  
  118.    We make the design decision that how a user discovers that a session
  119.    exists is orthogonal to a session's conference control model.  Figure
  120.    1 shows a potential place for SIP in the lifecycle of both
  121.    lightweight sessions and in more tightly-coupled conferencing. Note
  122.    that the Session Initiation Protocol and the Session Announcement
  123.    Protocol may be invoked or re-invoked at later stages in a session's
  124.    lifecycle.
  125.  
  126.    The Session Initiation Protocol is also intended to be used to invite
  127.    servers into sessions. Examples might be where a recording server can
  128.    be invited to participate in a live multimedia session to record that
  129.    session, or a video-on-demand server can be invited to play a video
  130.    stream into a live multimedia conference. In such cases we would like
  131.    SIP to lead the server gracefully into the control protocol that
  132.    controls the actual recording and playback.
  133.  
  134.    We also make the design decision that inviting a user to participate
  135.    in a session is independent of quality of service (QoS) guarantees
  136.    for that session. Such QoS guarantees (if they are required) may be
  137.    dependent on the full membership of the session, and this may or may
  138.    not be known to the agent performing session invitation.
  139.  
  140.    SIP offers some of the same functionality as H.323, but can also be
  141.    used in conjunction with it. In this mode, SIP is used to locate the
  142.    appropriate terminal, where the terminal is identified by its H.245
  143.    address [TBD: what does this look like?]. An H.323-capable terminal
  144.    then proceeds with a normal H.323/H.245 invitation [3].
  145.  
  146. 1.1 Requirements
  147.  
  148.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  149.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  150.    document are to be interpreted as described in RFC xxxx [4].
  151.  
  152. 1.2 Terminology
  153.  
  154.    This specification uses a number of terms to refer to the roles
  155.    played by participants in SIP communications. The definitions of
  156.    client, server and proxy are similar to those used by HTTP.
  157.  
  158.    Client: An application program that establishes connections for the
  159.         purpose of sending requests. Clients may or may not interact
  160.         directly with a human user.
  161.  
  162.    Initiator: The party initiating a conference invitation. Note that
  163.         the calling party does not have to be the same as the one
  164.         creating a conference.
  165.  
  166.  
  167.  
  168.  
  169. M. Handley, H. Schulzrinne, E. Schooler                       [Page 3]
  170.  
  171. Internet Draft                    sip                     March 27, 1997
  172.  
  173.  
  174.    Invitation: A request sent to attempt to contact a user (or service)
  175.         to request that they participate in a session.
  176.  
  177.    Invitee, Invited User: The person or service that the calling party
  178.         is trying to invite to a conference.
  179.  
  180.    Location server: A program that is contacted by a client and that
  181.         returns one or more possible locations for the user or service
  182.         without contacting that user or service directly.
  183.  
  184.    Location service: A service used by a location server to obtain
  185.         information about a user's possible location.
  186.  
  187.    Proxy, Proxy server: An intermediary program that acts as both a
  188.         server and a client for the purpose of making requests on behalf
  189.         of other clients. Requests are serviced internally or by passing
  190.         them on, possibly after translation, to other servers. A proxy
  191.         must interpret, and, if necessary, rewrite a request message
  192.         before forwarding it.
  193.  
  194.    Server: An application program that accepts connections in order to
  195.         service requests by sending back responses. A server may be the
  196.         called user agent, a proxy server, or a location server.
  197.  
  198.    User Agent, Called User Agent: The server application which contacts
  199.         the invitee to inform them of the invitation, and to return a
  200.         reply.
  201.  
  202.    Any given program may be capable of acting both as a client and a
  203.    server. A typical multimedia conference controller would act as a
  204.    client to initiate calls or to invite others to conferences and as a
  205.    server to accept invitations.
  206.  
  207. 1.3 General Requirements
  208.  
  209.    SIP is a Session Initiation Protocol. It is not a conference control
  210.    protocol. SIP can be used to perform a search for a user or service
  211.    and to request that that user or service participate in a session.
  212.  
  213.    Once SIP has been used to initiate a multimedia session SIP's task is
  214.    finished. There is no concept of a SIP session (as opposed to a SIP
  215.    search for a user or service). If whatever conference control
  216.    mechanism is used in the session needs to add or remove a media
  217.    stream, SIP may be used to perform this task, but again, once the
  218.    information has been successfully conveyed to the participants, SIP
  219.    is then no longer involved.
  220.  
  221.    SIP must be able to utilize both UDP and TCP as transport protocols.
  222.  
  223.  
  224.  
  225. M. Handley, H. Schulzrinne, E. Schooler                       [Page 4]
  226.  
  227. Internet Draft                    sip                     March 27, 1997
  228.  
  229.  
  230.    From a performance point of view, UDP is preferable as it allows the
  231.    application to more carefully control the timing of messages, it
  232.    allows parallel searches without requiring connection state for each
  233.    outstanding request, and allows the use of multicast.
  234.  
  235.    From a pragmatic point of view, TCP allows easier passage through
  236.    existing firewalls, and with appropriate protocol design, allows
  237.    common SIP, HTTP and RTSP servers.
  238.  
  239.    When TCP is used, SIP can use either one or more than one connection
  240.    to attempt to contact a user or to modify parameters of an existing
  241.    session. The concept of a session is not implicitly bound to a TCP
  242.    connection, so the initial SIP request and a subsequent SIP request
  243.    may use different TCP connections or a single persistent connection
  244.    as appropriate.
  245.  
  246.    SIP is text based. This allows easy implementation in languages such
  247.    as TCL and Perl, allows easy debugging, and most importantly, makes
  248.    SIP flexible and extensible. As SIP is only used for session
  249.    initiation, it is believed that the additional overhead of using a
  250.    text-based protocol is not significant.
  251.  
  252.    Unlike control protocols, there is minimal shared-state in SIP -- in
  253.    a minimal implementation the initiator maintains all the state about
  254.    the current attempt to locate and contact a user or service - servers
  255.    or proxies can be stateless (although they don't have to be). All the
  256.    state needed to get a response back from a server to the initiator is
  257.    carried in the SIP request itself - this is also necessary for loop
  258.    prevention.
  259.  
  260.  
  261.         Whilst redesigning SIP, we have attempted to ensure that it
  262.         has a clear interaction with the currently evolving Real-
  263.         Time Stream Control Protocol.
  264.  
  265. 1.4 Addressing
  266.  
  267.    SIP is a protocol that exchanges messages between peer user agents or
  268.    proxies for user agents. We assume the user agent is an application
  269.    that acts on behalf of the user it represents (thus it is sometimes
  270.    described as a client of the user) and that is co-resident with that
  271.    user. A proxy for a user agent serves as a forwarding mechanism or
  272.    bridge to the actual location of the user agent. We also refer to
  273.    such proxies as location server
  274.  
  275.    In the computer realm, the equivalent of a personal telephone number
  276.    combines the user's login id ( mjh ) with a machine host name (
  277.    metro.isi.edu ) or numeric network address ( 128.16.64.78 ). A user's
  278.  
  279.  
  280.  
  281. M. Handley, H. Schulzrinne, E. Schooler                       [Page 5]
  282.  
  283. Internet Draft                    sip                     March 27, 1997
  284.  
  285.  
  286.    location-specific address can be obtained out-of-band, can be learned
  287.    via existing media agents, can be included in some mailers' message
  288.    headers, or can be recorded during previous invitation interactions.
  289.  
  290.    However, users also publish several well-known addresses that are
  291.    relatively location-independent, such as email or web home-page
  292.    addresses. Rather than require that users provide their specific
  293.    network locales, we can take advantage of email and web addresses as
  294.    being (relatively) memorable, and also leverage off the Domain Name
  295.    Service (DNS) to provide a first stage location mechanism. Note that
  296.    an email address ( M.Handley@cs.ucl.ac.uk ) is usually different from
  297.    the combination of a specific machine name and login name (
  298.    mjh@mercury.lcs.mit.edu ). SIP should allow both forms of addressing
  299.    to be used, with the former requiring a location server to locate the
  300.    user.
  301.  
  302.    One perceived problem of email addressing is that it is possible to
  303.    guess peoples' addresses and thus the system of unlisted (in the
  304.    telephone directory) numbers is more of a problem. However, this
  305.    really only provides security through obscurity, and real security is
  306.    better provided through authentication and call screening.
  307.  
  308. 1.5 Call Setup
  309.  
  310.    Call setup is a multi-phase procedure. In the first phase, the
  311.    requesting client tries to ascertain the address where it should
  312.    contact the remote user agent or user agent proxy. The local client
  313.    checks if the user address is location-specific. If so, then that is
  314.    the address used for the remote user agent. If not, the requesting
  315.    client looks up the domain part of the user address in the DNS. This
  316.    provides one or more records giving IP addresses. If a new service
  317.    (SRV) resource record [5] is returned giving a location server, then
  318.    that is the address to contact next. If no relevant resource record
  319.    is returned, but an A record is returned, then that is the address to
  320.    contact next. If neither a resource record or an A record is
  321.    returned, but an MX record is returned, then the mail host is the
  322.    address to contact next.
  323.  
  324.    Presuming an address for the invitee is found from the DNS, the
  325.    second and subsequent phases basically implement a request-response
  326.    protocol.  A session description (typically using SDP format) is sent
  327.    to the contact address with an invitation for the user to join the
  328.    session.
  329.  
  330.    This request may be sent over a TCP connection or as a single UDP
  331.    datagram (the format of both is the same and is described later), and
  332.    is sent to a well-known port.
  333.  
  334.  
  335.  
  336.  
  337. M. Handley, H. Schulzrinne, E. Schooler                       [Page 6]
  338.  
  339. Internet Draft                    sip                     March 27, 1997
  340.  
  341.  
  342.    If a user agent or conference server is listening on the relevant
  343.    port, it can send one of the responses below. If no server or agent
  344.    is listening, an ICMP port-unreachable response will be triggered
  345.    which should cause the TCP connection setup to fail or cause a UDP
  346.    send failure on retransmissions.
  347.  
  348. 1.6 Locating a User
  349.  
  350.    It is expected that a user is situated at one of several frequented
  351.    locations. These locations can be dynamically registered with a
  352.    location server for a site (for a local area network or
  353.    organization), and incoming connections can be routed simultaneously
  354.    to all of these locations if so desired. It is entirely up to the
  355.    location server whether the server issues proxy requests for the
  356.    requesting user, or if the server instructs the client to redirect
  357.    the request.
  358.  
  359.    In general a reply MUST be sent by the same mechanism that the
  360.    request was sent by. Hence, if a request was unicast, then the reply
  361.    MUST be unicast back to the requester; if the request was multicast,
  362.    the reply MUST be multicast to the same group to which the request
  363.    was sent; if the request was sent by TCP, the reply MUST be sent by
  364.    TCP.
  365.  
  366.    In all cases where a request is forwarded onwards, each host relaying
  367.    the message SHOULD add its own address to the path of the message so
  368.    that the replies can take the same path back, thus ensuring correct
  369.    operation through compliant firewalls and loop-free requests. On the
  370.    reply path, these routing headers MUST be removed as the reply
  371.    retraces the path, so that routing internal to sites is hidden. When
  372.    a multicast request is made, first the host making the request, then
  373.    the multicast address itself are added to the path.
  374.  
  375. 2 Notational Conventions and Generic Grammar
  376.  
  377.    Since many of the definitions and syntax are identical to HTTP/1.1,
  378.    this specification only points to the section where they are defined
  379.    rather than copying it. For brevity, [HX.Y] is to be taken to refer
  380.    to Section X.Y of the current HTTP/1.1 specification (RFC 2068).
  381.  
  382.    All the mechanisms specified in this document are described in both
  383.    prose and an augmented Backus-Naur form (BNF) similar to that used in
  384.    RFC 2068 [H2.1]. It is described in detail in [6].
  385.  
  386.    In this draft, we use indented and smaller-type paragraphs to provide
  387.    background and motivation.
  388.  
  389. 3 Protocol Parameters
  390.  
  391.  
  392.  
  393. M. Handley, H. Schulzrinne, E. Schooler                       [Page 7]
  394.  
  395. Internet Draft                    sip                     March 27, 1997
  396.  
  397.  
  398. 3.1 SIP Version
  399.  
  400.    applies, with HTTP replaced by SIP.
  401.  
  402.    Applications sending Request or Response messages, as defined by this
  403.    specification, MUST include an SIP-Version of "SIP/2.0". Use of this
  404.    version number indicates that the sending application is at least
  405.    conditionally compliant with this specification.
  406.  
  407. 3.2 UCI: Universal Communication Identifier
  408.  
  409.    [TBD: describe all legal address formats.]
  410.  
  411. 4 SIP Message
  412.  
  413.    All messages are text-based, using the conventions of HTTP/1.1
  414.    [H4.1], except for the additional ability of SIP to use UDP. When
  415.    sent over TCP or UDP, multiple requests can be carried in a single
  416.    TCP connection or UDP datagram. UDP Datagrams should not normally
  417.    exceed the path MTU in size if it is known, or 1,000 bytes if the MTU
  418.    is unknown.
  419.  
  420. 4.1 Message Types
  421.  
  422.    SIP messages consist of requests from client to server and responses
  423.    from server to client.
  424.  
  425.  
  426.      SIP-message = Request | Response     ; HTTP/1.1 messages
  427.  
  428.  
  429.  
  430.    Request (section 5) and response (section 6) messages use the generic
  431.    message format of RFC 822 for transferring entities (the payload of
  432.    the message). Both types of messages consist of a start-line, one or
  433.    more header fields (also known as "headers"), an empty line (i.e., a
  434.    line with nothing preceding the CRLF) indicating the end of the
  435.    header fields, and an optional message-body.
  436.  
  437.  
  438.      generic-message = start-line
  439.                        *message-header
  440.                        CRLF
  441.                        [ message-body ]
  442.  
  443.      start-line      = Request-Line | Status-Line
  444.  
  445.  
  446.  
  447.  
  448.  
  449. M. Handley, H. Schulzrinne, E. Schooler                       [Page 8]
  450.  
  451. Internet Draft                    sip                     March 27, 1997
  452.  
  453.  
  454.    In the interest of robustness, servers SHOULD ignore any empty
  455.    line(s) received where a Request-Line is expected. In other words, if
  456.    the server is reading the protocol stream at the beginning of a
  457.    message and receives a CRLF first, it should ignore the CRLF.
  458.  
  459. 4.2 Message Headers
  460.  
  461.    HTTP header fields, which include general-header (section ),
  462.    request-header (section ), response-header (section ), fields, follow
  463.    the same generic format as that given in Section 3.1 of RFC 822. Each
  464.    header field consists of a name followed by a colon (":") and the
  465.    field value. Field names are case-insensitive. The field value may be
  466.    preceded by any amount of LWS, though a single SP is preferred.
  467.    Header fields can be extended over multiple lines by preceding each
  468.    extra line with at least one SP or HT. Applications SHOULD follow
  469.    "common form" when generating HTTP constructs, since there might
  470.    exist some implementations that fail to accept anything beyond the
  471.    common forms.
  472.  
  473.  
  474.      message-header = field-name ":" [ field-value ] CRLF
  475.  
  476.      field-name     = token
  477.      field-value    = *( field-content | LWS )
  478.      field-content  = <the OCTETs making up the field-value
  479.                       and consisting of either *TEXT or combinations
  480.                       of token, tspecials, and quoted-string>
  481.  
  482.  
  483.  
  484.    The order in which header fields with differing field names are
  485.    received is not significant.
  486.  
  487.    Multiple message-header fields with the same field-name may be
  488.    present in a message if and only if the entire field-value for that
  489.    header field is defined as a comma-separated list (i.e., #(values) ).
  490.    It MUST be possible to combine the multiple header fields into one
  491.    "field-name:  field-value" pair, without changing the semantics of
  492.    the message, by appending each subsequent field-value to the first,
  493.    each separated by a comma. The order in which header fields with the
  494.    same field-name are received is therefore significant to the
  495.    interpretation of the combined field value, and thus a proxy MUST NOT
  496.    change the order of these field values when a message is forwarded.
  497.  
  498. 4.3 Message Body
  499.  
  500.    The rules for when a message-body is allowed in a message differ for
  501.    requests and responses.
  502.  
  503.  
  504.  
  505. M. Handley, H. Schulzrinne, E. Schooler                       [Page 9]
  506.  
  507. Internet Draft                    sip                     March 27, 1997
  508.  
  509.  
  510.    The presence of a message-body in a request is signaled by the
  511.    inclusion of a Content-Length or Transfer-Encoding header field in
  512.    the request's message-headers. A message-body MAY be included in a
  513.    request only when the request method allows an entity-body.
  514.  
  515.    For response messages, whether or not a message-body is included with
  516.    a message is dependent on both the request method and the response
  517.    status code (section ). All 1xx (informational) responses MUST NOT
  518.    include a message-body. All other responses do include a message-
  519.    body, although it may be of zero length.
  520.  
  521. 4.4 Message Length
  522.  
  523.    When a message-body is included with a message, the length of that
  524.    body is determined by one of the following (in order of precedence):
  525.  
  526.         1.   Any response message which MUST NOT include a message-body
  527.              (such as the 1xx responses) is always terminated by the
  528.              first empty line after the header fields, regardless of the
  529.              entity-header fields present in the message.
  530.  
  531.         2.   Otherwise, a  Content-Length header MUST be present. (This
  532.              requirement differs from HTTP/1.1.) Its value in bytes
  533.              represents the length of the message-body.
  534.  
  535.    The "chunked" transfer encoding of HTTP/1.1 MUST NOT be used for SIP.
  536.  
  537. 4.5 General Header Fields
  538.  
  539.    There are a few header fields which have general applicability for
  540.    both request and response messages. These header fields apply only to
  541.    the message being transmitted.
  542.  
  543.  
  544.      general-header = Date                     ; Section
  545.                     | Transfer-Encoding        ; Section
  546.                     | Via                      ; Section
  547.  
  548.  
  549.  
  550.    General-header field names can be extended reliably only in
  551.    combination with a change in the protocol version. However, new or
  552.    experimental header fields may be given the semantics of general
  553.    header fields if all parties in the communication recognize them to
  554.    be general-header fields.
  555.  
  556. 5 Request
  557.  
  558.  
  559.  
  560.  
  561. M. Handley, H. Schulzrinne, E. Schooler                      [Page 10]
  562.  
  563. Internet Draft                    sip                     March 27, 1997
  564.  
  565.  
  566.    The Request-Line begins with a method token, followed by the
  567.    Request-URI and the protocol version, and ending with CRLF. The
  568.    elements are separated by SP characters. No CR or LF are allowed
  569.    except in the final CRLF sequence.
  570.  
  571.  
  572.      Request-Line = Method SP Request-URI SP SIP-Version CRLF
  573.  
  574.  
  575.  
  576.    The method may be either  INVITE or  CAPABILITY. The request ID may
  577.    be any URL encoded string that can be guaranteed to be globally
  578.    unique for the duration of the request. Using the initiator's IP-
  579.    address, process id, and instance (if more than one request is being
  580.    made simultaneously) satisfies this requirement.
  581.  
  582. 6 Response
  583.  
  584.    [H6] applies except that HTTP-Version is replaced by SIP-Version
  585.    define some HTTP codes.
  586.  
  587.    After receiving and interpreting a request message, the recipient
  588.    responds with an SIP response message.
  589.  
  590.  
  591.      Response = Status-Line             ; Section
  592.                 *( general-header       ; Section
  593.                  | response-header      ; Section
  594.                  | entity-header )      ; Section
  595.                 CRLF
  596.                 [ message-body ]        ; Section
  597.  
  598.  
  599.  
  600. 6.1 Status-Line
  601.  
  602.    The first line of a Response message is the Status-Line , consisting
  603.    of the protocol version followed by a numeric status code, the
  604.    sequence number of the corresponding request and the textual phrase
  605.    associated with the status code, with each element separated by SP
  606.    characters. No CR or LF is allowed except in the final CRLF sequence.
  607.    Note that the addition of a
  608.  
  609.  
  610.      Status-Line = SIP-Version SP Status-Code SP seq-no SP Reason-Phrase CRLF
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617. M. Handley, H. Schulzrinne, E. Schooler                      [Page 11]
  618.  
  619. Internet Draft                    sip                     March 27, 1997
  620.  
  621.  
  622. 6.1.1 Status Code and Reason Phrase
  623.  
  624.    The Status-Code element is a 3-digit integer result code of the
  625.    attempt to understand and satisfy the request. These codes are fully
  626.    defined in section10. The Reason-Phrase is intended to give a short
  627.    textual description of the Status-Code. The Status-Code is intended
  628.    for use by automata and the Reason-Phrase is intended for the human
  629.    user. The client is not required to examine or display the Reason-
  630.    Phrase
  631.  
  632.    The first digit of the Status-Code defines the class of response. The
  633.    last two digits do not have any categorization role. There are 5
  634.    values for the first digit:
  635.  
  636.         o 1xx: Informational - Request received, continuing process
  637.  
  638.         o 2xx: Success - The action was successfully received,
  639.          understood, and accepted
  640.  
  641.         o 3xx: Redirection - Further action must be taken in order to
  642.          complete the request
  643.  
  644.         o 4xx: Client Error - The request contains bad syntax or cannot
  645.          be fulfilled
  646.  
  647.         o 5xx: Server Error - The server failed to fulfill an apparently
  648.          valid request
  649.  
  650.    The individual values of the numeric status codes defined for
  651.    SIP/2.0, and an example set of corresponding Reason-Phrase below. The
  652.    reason phrases listed here are only recommended -- they may be
  653.    replaced by local equivalents without affecting the protocol. Note
  654.    that SIP adopts many HTTP/1.1 status codes and adds SIP-specific
  655.    status codes in the starting at 450 to avoid conflicts with newly
  656.    defined HTTP status codes.
  657.  
  658.  
  659.       Status-Code    = "100"   ; Continue
  660.                      | "200"   ; OK
  661.                      | "300"   ; Multiple Choices
  662.                      | "301"   ; Moved Permanently
  663.                      | "302"   ; Moved Temporarily
  664.                      | "303"   ; See Other
  665.                      | "305"   ; Use Proxy
  666.                      | "400"   ; Bad Request
  667.                      | "401"   ; Unauthorized
  668.                      | "402"   ; Payment Required
  669.                      | "403"   ; Forbidden
  670.  
  671.  
  672.  
  673. M. Handley, H. Schulzrinne, E. Schooler                      [Page 12]
  674.  
  675. Internet Draft                    sip                     March 27, 1997
  676.  
  677.  
  678.                      | "404"   ; Not Found
  679.                      | "405"   ; Method Not Allowed
  680.                      | "406"   ; Not Acceptable
  681.                      | "407"   ; Proxy Authentication Required
  682.                      | "408"   ; Request Time-out
  683.                      | "409"   ; Conflict
  684.                      | "410"   ; Gone
  685.                      | "411"   ; Length Required
  686.                      | "412"   ; Precondition Failed
  687.                      | "413"   ; Request Entity Too Large
  688.                      | "414"   ; Request-URI Too Large
  689.                      | "415"   ; Unsupported Media Type
  690.                      | "500"   ; Internal Server Error
  691.                      | "501"   ; Not Implemented
  692.                      | "502"   ; Bad Gateway
  693.                      | "503"   ; Service Unavailable
  694.                      | "504"   ; Gateway Time-out
  695.                      | "505"   ; HTTP Version not supported
  696.                      | extension-code
  697.  
  698.       extension-code = 3DIGIT
  699.  
  700.       Reason-Phrase  = *<TEXT, excluding CR, LF>
  701.  
  702.  
  703.  
  704.  
  705.    SIP status codes are extensible. SIP applications are not required to
  706.    understand the meaning of all registered status codes, though such
  707.    understanding is obviously desirable. However, applications MUST
  708.    understand the class of any status code, as indicated by the first
  709.    digit, and treat any unrecognized response as being equivalent to the
  710.    x00 status code of that class, with the exception that an
  711.    unrecognized response MUST NOT be cached. For example, if an
  712.    unrecognized status code of 431 is received by the client, it can
  713.    safely assume that there was something wrong with its request and
  714.    treat the response as if it had received a 400 status code. In such
  715.    cases, user agents SHOULD present to the user the entity returned
  716.    with the response, since that entity is likely to include human-
  717.    readable information which will explain the unusual status.
  718.  
  719. 6.1.2 Response Header Fields
  720.  
  721.    The response-header fields allow the request recipient to pass
  722.    additional information about the response which cannot be placed in
  723.    the Status-Line server and about further access to the resource
  724.    identified by the Request-URI
  725.  
  726.  
  727.  
  728.  
  729. M. Handley, H. Schulzrinne, E. Schooler                      [Page 13]
  730.  
  731. Internet Draft                    sip                     March 27, 1997
  732.  
  733.  
  734.      response-header = Location              ; Section
  735.                        | Proxy-Authenticate  ; Section
  736.                        | Public              ; Section
  737.                        | Retry-After         ; Section
  738.                        | Server              ; Section
  739.                        | Vary                ; Section
  740.                        | WWW-Authenticate    ; Section
  741.  
  742.  
  743.  
  744.    Response-header field names can be extended reliably only in
  745.    combination with a change in the protocol version. However, new or
  746.    experimental header fields MAY be given the semantics of response-
  747.    header fields if all parties in the communication recognize them to
  748.    be response-header fields. Unrecognized header fields are treated as
  749.    entity-header fields.
  750.  
  751. 7 SIP Message Body
  752.  
  753.    The session description payload gives details of the session the user
  754.    is being invited to join. Its Internet media type MUST be given by
  755.    the "Content-type:" header field, and the payload length in bytes
  756.    MUST be given by the  Content-length header field. If the payload has
  757.    undergone any encoding (such as compression) then this MUST be
  758.    indicated by the  Content-encoding: header field, otherwise Content-
  759.    encoding: MUST be omitted.
  760.  
  761.    The example below is a request message en route from initiator to
  762.    invitee:
  763.  
  764.  
  765.    INVITE 128.16.64.19/65729 SIP/2.0
  766.    Via: SIP/2.0/UDP 239.128.16.254 16
  767.    Via: SIP/2.0/UDP 131.215.131.131
  768.    Via: SIP/2.0/UDP 128.16.64.19
  769.    From: mjh@isi.edu
  770.    To: schooler@cs.caltech.edu
  771.    Content-type: application/sdp
  772.    Content-Length: 187
  773.  
  774.    v=0
  775.    o=user1 53655765 2353687637 IN IP4 128.3.4.5
  776.    s=Mbone Audio
  777.    i=Discussion of Mbone Engineering Issues
  778.    e=mbone@somewhere.com
  779.    c=IN IP4 224.2.0.1/127
  780.    t=0 0
  781.    m=audio 3456 RTP/AVP 0
  782.  
  783.  
  784.  
  785. M. Handley, H. Schulzrinne, E. Schooler                      [Page 14]
  786.  
  787. Internet Draft                    sip                     March 27, 1997
  788.  
  789.  
  790.    The first line above states that this is a SIP version 2.0 request.
  791.  
  792.    The via fields give the hosts along the path from invitation
  793.    initiator (the first element of the list) towards the invitee. In the
  794.    example above, the message was last multicast to the administratively
  795.    scoped group 239.128.16.254 with a ttl of 16 from the host
  796.    131.215.131.131.
  797.  
  798.    The request header above states that the request was initiated by
  799.    mjh@isi.edu (specifically it was initiated from 128.16.64.19, as can
  800.    be seen from the  Via header) and the user being invited is
  801.    schooler@cs.caltech.edu.
  802.  
  803.    In this case, the session description (as stated in the Content-type
  804.    header) is a Session Description Protocol (SDP).
  805.  
  806.    The header is terminated by an empty line and is followed by the
  807.    session description payload.
  808.  
  809.    If required, the session description can be encrypted using public
  810.    key cryptography, and then can also carry private session keys for
  811.    the session. If this is the case, four random bytes are added to the
  812.    beginning of the session description before encryption and are
  813.    removed after decryption but before parsing.
  814.  
  815. 8 Methods
  816.  
  817.    The following methods are defined:
  818.  
  819.    INVITE: The user or service is being invited to participate in the
  820.         session. The session description given must be completely
  821.         acceptable for a "200 OK" response to be given. This method MUST
  822.         be supported by a SIP server.
  823.  
  824.    OPTIONS: The user or service is being queried as to its capabilities.
  825.         A server that believes it can contact the user (such as a user
  826.         agent where the user is logged in and has been recently active)
  827.         MAY respond to this request with a capability set. Support of
  828.         this method is OPTIONAL.
  829.  
  830.    Methods that are not supported by a proxy server SHOULD be treated by
  831.    that proxy as if they were an INVITE method, and relayed through
  832.    unchanged or cause a redirection as appropriate.
  833.  
  834.    Methods that are not supported by a user agent should cause a "501
  835.    Not Implemented" response to be returned.
  836.  
  837. 9 Header Field Definitions
  838.  
  839.  
  840.  
  841. M. Handley, H. Schulzrinne, E. Schooler                      [Page 15]
  842.  
  843. Internet Draft                    sip                     March 27, 1997
  844.  
  845.  
  846.    SIP header fields are similar to HTTP header fields in both syntax
  847.    and semantics. In general the ordering of the header fields is not of
  848.    importance (with the exception of Via fields, see below) but proxies
  849.    MUST NOT reorder or otherwise modify header fields other than by
  850.    adding a new Via field. This allows an authentication field to be
  851.    added after the Via fields that will not be invalidated by proxies.
  852.    Field names are not case-sensitive, although their values may be.
  853.  
  854.    Content-Length,  Content-Type,  To,  From header fields are
  855.    compulsory. Other fields may be added as required. Header fields MUST
  856.    be separated by a single linefeed character. The header MUST be
  857.    separated from the payload by an empty line (two linefeed
  858.    characters).
  859.  
  860.    A compact form of these header fields is also defined in section 10.9
  861.    for use over UDP when the request has to fit into a single packet and
  862.    size is an issue.
  863.  
  864. 9.1 Accept
  865.  
  866.    See [H14.1]. This header field is used only for the  OPTIONS request
  867.    to indicate what description formats are acceptable.
  868.  
  869. 9.2 Accept-Language
  870.  
  871.    See [H14.4]. The  Accept-Language request header can be used to allow
  872.    the client to indicate to the server in which language it would
  873.    prefer to receive reason phrases. This may also be used as a hint by
  874.    the proxy as to which destination to connect the call to (e.g., for
  875.    selecting a human operator).
  876.  
  877. 9.3 Authentication
  878.  
  879.    Authentication fields provide a digital signature of the remaining
  880.    fields for authentication purposes. They are not yet defined The use
  881.    of authentication headers is optional. If used, authentication
  882.    headers MUST be added to the header after the  Via fields and before
  883.    the rest of the fields.
  884.  
  885.  
  886.         HS: Ordering and semantics needs work. Maybe we can recycle
  887.         the S/MIME work?
  888.  
  889. 9.4 Confirm
  890.  
  891.    TBD.
  892.  
  893. 9.5 Contact-Host
  894.  
  895.  
  896.  
  897. M. Handley, H. Schulzrinne, E. Schooler                      [Page 16]
  898.  
  899. Internet Draft                    sip                     March 27, 1997
  900.  
  901.  
  902.    TBD.
  903.  
  904. 9.6 From
  905.  
  906.    The request header MUST contain a  From request-header field,
  907.    indicating the invitation initiator. The field MUST be machine-
  908.    usable, as defined my mailbox in RFC 822 (as updated by RFC 1123).
  909.    Only a single initiator and a single invited user are allowed to be
  910.    specified in a single SIP request.
  911.  
  912. 9.7 Retry-After
  913.  
  914.    The  Retry-After response-header field can be used with a 503
  915.    (Service Unavailable) response to indicate how long the service is
  916.    expected to be unavailable to the requesting client and with a 404
  917.    (Not Found) or 451* (Busy) response to indicate when the called party
  918.    may be available again. The value of this field can be either an
  919.    HTTP-date or an integer number of seconds (in decimal) after the time
  920.    of the response.
  921.  
  922.  
  923.      Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )
  924.  
  925.  
  926.  
  927.    Two examples of its use are
  928.  
  929.  
  930.      Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
  931.      Retry-After: 120
  932.  
  933.  
  934.  
  935.    In the latter example, the delay is 2 minutes.
  936.  
  937. 9.8 Reason
  938.  
  939.    TBD.
  940.  
  941. 9.9 To
  942.  
  943.    The  To request-header field specifies the invited user, with the
  944.    same syntax as the  From field.
  945.  
  946. 9.10 Via
  947.  
  948.    The  Via field indicates the path taken by the request so far.  This
  949.    prevents request looping and ensures replies take the same path as
  950.  
  951.  
  952.  
  953. M. Handley, H. Schulzrinne, E. Schooler                      [Page 17]
  954.  
  955. Internet Draft                    sip                     March 27, 1997
  956.  
  957.  
  958.    the requests, which assists in firewall traversal and other unusual
  959.    routing situations. Initiators MUST add their own Path field to each
  960.    request. This Path field MUST be the first field in the request.
  961.    Subsequent proxies SHOULD each add their own additional Path field
  962.    which MUST be added before any existing Path fields. When a reply
  963.    passes through a proxy on the reverse path, that proxies Path field
  964.    MUST be removed from the reply.
  965.  
  966.    The format for a  Via header is:
  967.  
  968.      Via = "Via" ":" 1#( sent-protocol sent-by [ ttl ] [ comment ] )
  969.      sent-protocol     = [ protocol-name "/" ] protocol-version
  970.                          [ "/" transport ]
  971.      protocol-name     = "SIP" | token
  972.      protocol-version  = token
  973.      transport         = "UDP" | "TCP"
  974.      sent-by           = host [ ":" port ]
  975.      ttl               = *DIGIT
  976.  
  977.  
  978.  
  979.    TTL is included only if the address is a multicast address.
  980.  
  981. 10 Status Code Definitions
  982.  
  983.    The response codes are consistent with, and extend, HTTP/1.1 response
  984.    codes. Not all HTTP/1.1 response codes are appropriate, and only
  985.    those that are appropriate are given here. Response codes not defined
  986.    by HTTP/1.1 are marked with an asterisk, and have codes x50 upwards
  987.    to avoid clashes with future HTTP response codes, or 6xx which are
  988.    not used by HTTP. The default behavior for unknown response codes is
  989.    given for each category of codes.
  990.  
  991. 10.1 Informational 1xx
  992.  
  993.    Informational responses indicate that the server or proxy contacted
  994.    is performing some further action and does not yet have a definitive
  995.    response. The client SHOULD wait for a further response from the
  996.    server, and the server SHOULD send such a response without further
  997.    prompting. If UDP transport is being used, the client SHOULD
  998.    periodically re-send the request in case the final response is lost.
  999.    Typically a server should send a "1xx" response if it expects to take
  1000.    more than one second to obtain a final reply.
  1001.  
  1002. 10.1.1 100 Trying
  1003.  
  1004.    Some further action is being taken (e.g., the request is being
  1005.    forwarded) but the user has not yet been located.
  1006.  
  1007.  
  1008.  
  1009. M. Handley, H. Schulzrinne, E. Schooler                      [Page 18]
  1010.  
  1011. Internet Draft                    sip                     March 27, 1997
  1012.  
  1013.  
  1014. 10.1.2 150 Ringing
  1015.  
  1016.    The user agent or conference server has located a possible location
  1017.    where the user has been recently and is trying to alert them.
  1018.  
  1019. 10.2 Successful 2xx
  1020.  
  1021.    The request was successful and MUST terminate a search.
  1022.  
  1023. 10.2.1 200 OK
  1024.  
  1025.    The request was successful in contacting the user, and the user has
  1026.    agreed to participate.
  1027.  
  1028. 10.3 Redirection 3xx
  1029.  
  1030.    3xx responses give information about the user's new location, or
  1031.    about alternative services that may be able to satisfy the call.
  1032.    They SHOULD terminate an existing search, and MAY cause the initiator
  1033.    to begin a new search if appropriate.
  1034.  
  1035. 10.3.1 300 Multiple Choices
  1036.  
  1037.    The requested resource corresponds to any one of a set of
  1038.    representations, each with its own specific location, and agent-
  1039.    driven negotiation information (section 13) is being provided so that
  1040.    the user (or user agent) can select a preferred representation and
  1041.    redirect its request to that location.
  1042.  
  1043.    The response SHOULD include an entity containing a list of resource
  1044.    characteristics and location(s) from which the user or user agent can
  1045.    choose the one most appropriate. The entity format is specified by
  1046.    the media type given in the Content- Type header field. Depending
  1047.    upon the format and the capabilities of the user agent, selection of
  1048.    the most appropriate choice may be performed automatically. However,
  1049.    this specification does not define any standard for such automatic
  1050.    selection.
  1051.  
  1052.    If the server has a preferred choice, it SHOULD include the specific
  1053.    URL for that representation in the  Location field; user agents MAY
  1054.    use the Location field value for automatic redirection.
  1055.  
  1056. 10.3.2 301 Moved Permanently
  1057.  
  1058.    The requesting client should retry on the new address given by the
  1059.    Location: field because the user has permanently moved and the
  1060.    address this response is in reply to is no longer a current address
  1061.    for the user.  A 301 response MUST NOT suggest any of the hosts in
  1062.  
  1063.  
  1064.  
  1065. M. Handley, H. Schulzrinne, E. Schooler                      [Page 19]
  1066.  
  1067. Internet Draft                    sip                     March 27, 1997
  1068.  
  1069.  
  1070.    the request's path as the user's new location.
  1071.  
  1072. 10.3.3 302 Moved Temporarily
  1073.  
  1074.    The requesting client should retry on the new address(es) given by
  1075.    the Location header. A 302 response MUST NOT suggest any of the hosts
  1076.    in the request's path as the user's new location.
  1077.  
  1078. 10.3.4 350* Alternative Service
  1079.  
  1080.    The call was not successful, but alternative services are possible.
  1081.    The alternative services are described in the body of the reply.
  1082.  
  1083. 10.4 Request Failure 4xx
  1084.  
  1085.    4xx responses are definite failure responses that MUST terminate the
  1086.    existing search for a user or service. They SHOULD NOT be retried
  1087.    immediately without modification.
  1088.  
  1089. 10.4.1 400 Bad Request
  1090.  
  1091.    The request could not be understood due to malformed syntax.
  1092.  
  1093. 10.4.2 401 Unauthorized
  1094.  
  1095.    The request requires user authentication.
  1096.  
  1097. 10.4.3 402 Payment Required
  1098.  
  1099.    Reserved for future use.
  1100.  
  1101. 10.4.4 403 Forbidden
  1102.  
  1103.    The server understood the request, but is refusing to fulfill it.
  1104.    Authorization will not help, and the request should not be repeated.
  1105.  
  1106. 10.4.5 404 Not Found
  1107.  
  1108.    The server has definitive information that the user does not exist at
  1109.    the domain specified.
  1110.  
  1111. 10.4.6 406 Not Acceptable
  1112.  
  1113.    The user's agent was contacted successfully but some aspects of the
  1114.    session profile (the requested media, bandwidth, or addressing style)
  1115.    were not acceptable.
  1116.  
  1117. 10.4.7 450* Decline
  1118.  
  1119.  
  1120.  
  1121. M. Handley, H. Schulzrinne, E. Schooler                      [Page 20]
  1122.  
  1123. Internet Draft                    sip                     March 27, 1997
  1124.  
  1125.  
  1126.    The user's machine was successfully contacted but the user explicitly
  1127.    does not wish to participate.
  1128.  
  1129. 10.4.8 451* Busy
  1130.  
  1131.    The user's machine was successfully contacted but the user is busy,
  1132.    or the user does not wish to participate (the ambiguity is
  1133.    intentional).
  1134.  
  1135. 10.5 Server Failure 5xx
  1136.  
  1137.    5xx responses are failure responses given when a server itself has
  1138.    erred. They are not definitive failures, and SHOULD NOT terminate a
  1139.    search if other possible locations remain untried.
  1140.  
  1141. 10.5.1 500 Server Internal Error
  1142.  
  1143.    The server encountered an unexpected condition that prevented it from
  1144.    fulfilling the request.
  1145.  
  1146. 10.5.2 501 Not implemented
  1147.  
  1148.    The server does not support the functionality required to fulfill the
  1149.    request. This is the appropriate response when the server does not
  1150.    recognize the request method and is not capable of supporting it for
  1151.    any user.
  1152.  
  1153. 10.5.3 503 Service Unavailable
  1154.  
  1155.    The server is currently unable to handle the request due to a
  1156.    temporary overloading or maintenance of the server. The implication
  1157.    is that this is a temporary condition which will be alleviated after
  1158.    some delay. If known, the length of the delay may be indicated in a
  1159.    Retry-After header. If no  Retry-After is given, the client SHOULD
  1160.    handle the response as it would for a 500 response.
  1161.  
  1162.    Note: The existence of the 503 status code does not imply that a
  1163.    server must use it when becoming overloaded. Some servers may wish to
  1164.    simply refuse the connection.
  1165.  
  1166. 10.6 Search Responses 6xx
  1167.  
  1168.    6xx responses are failure responses given whilst trying to locate the
  1169.    specified user or service. They are not definitive failures, and
  1170.    SHOULD NOT terminate the search if other possible locations remain
  1171.    untried.
  1172.  
  1173. 10.6.1 600* Search Failure
  1174.  
  1175.  
  1176.  
  1177. M. Handley, H. Schulzrinne, E. Schooler                      [Page 21]
  1178.  
  1179. Internet Draft                    sip                     March 27, 1997
  1180.  
  1181.  
  1182.    The user agent or proxy server understood the user's address, but the
  1183.    request was unsuccessful in contacting the user. A proxy might return
  1184.    this error towards the initiator if an attempt to contact a server
  1185.    failed for an unknown reason.
  1186.  
  1187. 10.6.2 601* Not known here
  1188.  
  1189.    The call was unsuccessful because the user or service was not known
  1190.    at the address called. This is not a definitive failure; the address
  1191.    may be valid at another server.
  1192.  
  1193. 10.6.3 602* Not currently here
  1194.  
  1195.    The call was unsuccessful because although the the user or service
  1196.    was known at the address called, the user or service is not currently
  1197.    located at this address. This is not a definitive failure; the user
  1198.    may be contactable at another server.
  1199.  
  1200. 10.6.4 603* Alternative Address
  1201.  
  1202.    The call was unsuccessful because the user or service is not
  1203.    available at this location, but one or more alternative non-
  1204.    definitive locations are suggested to try in addition to any that may
  1205.    already be being tried.  A 603 response MUST NOT suggest any of the
  1206.    hosts in the request's path as an alternative location.
  1207.  
  1208. 10.7 Example: Normal Replies
  1209.  
  1210.    An example reply is given below. The first line of the reply states
  1211.    the SIP version number, that it is a "200 OK" reply, which means the
  1212.    request was successful. The  Via header are taken from the request,
  1213.    and entries are removed hop by hop as the reply retraces the
  1214.    request's path. A new authentication field is added by the invited
  1215.    user's agent if required. The session ID is taken directly from the
  1216.    original request, along with the request header. The original sense
  1217.    of From field is preserved (i.e, it's the session originator).
  1218.  
  1219.    In addition, a  Contact-host field is added giving details of the
  1220.    host the user was located on, or alternatively the relevant proxy
  1221.    contact point which should be reachable from the invitation
  1222.    initiator's host.
  1223.  
  1224.  
  1225.    SIP/2.0 200 128.16.64.19/65729
  1226.    Via: SIP/2.0/UDP 239.128.16.254 16
  1227.    Via: SIP/2.0/UDP 131.215.131.131
  1228.    Via: SIP/2.0/UDP 128.16.64.19 1
  1229.    From: mjh@isi.edu
  1230.  
  1231.  
  1232.  
  1233. M. Handley, H. Schulzrinne, E. Schooler                      [Page 22]
  1234.  
  1235. Internet Draft                    sip                     March 27, 1997
  1236.  
  1237.  
  1238.    To: schooler@cs.caltech.edu
  1239.    Contact-host: 131.215.131.147
  1240.  
  1241.  
  1242.  
  1243.    This same format is used for replies for other categories of reply,
  1244.    except that some of then may require payloads to be carried.
  1245.  
  1246.    If the invited user's agent requires confirmation of receipt of a
  1247.    "200 OK" reply, it may optionally add an additional Confirm: required
  1248.    header to the body of the message specifying that an acknowledgment
  1249.    is required. This is only permitted with category 2xx replies. An
  1250.    example is:
  1251.  
  1252.  
  1253.    SIP/2.0 200 128.16.64.19/65729
  1254.    Via: SIP/2.0/UDP 239.128.16.254 16
  1255.    Via: SIP/2.0/UDP 131.215.131.131
  1256.    Via: SIP/2.0/UDP 128.16.64.19
  1257.    From: mjh@isi.edu
  1258.    To: schooler@cs.caltech.edu
  1259.    Contact-host: 131.215.131.147
  1260.    Confirm: required
  1261.  
  1262.  
  1263.  
  1264.    In response to such a request, the invitation initiators agent should
  1265.    retransmit its request with an additional  Confirm header, with the
  1266.    value "true" or "false" stating whether the session still exists or
  1267.    no longer exists respectively (see section 7.1 for details). An
  1268.    example of an confirmation request is:
  1269.  
  1270.  
  1271.    INVITE 128.16.64.19/65729 SIP/2.0
  1272.    Via: SIP/2.0/UDP 239.128.16.254:70 16
  1273.    Via: SIP/2.0/UDP 131.215.131.131
  1274.    Via: SIP/2.0/UDP 128.16.64.19
  1275.    From: mjh@isi.edu
  1276.    To: schooler@cs.caltech.edu
  1277.    Confirm: true
  1278.    Content-type: application/sdp
  1279.    Content-Length: 187
  1280.  
  1281.    v=0
  1282.    o=user1 2353655765 2353687637 IN IP4 128.3.4.5
  1283.    s=Mbone Audio
  1284.    i=Discussion of Mbone Engineering Issues
  1285.    e=mbone@somewhere.com
  1286.  
  1287.  
  1288.  
  1289. M. Handley, H. Schulzrinne, E. Schooler                      [Page 23]
  1290.  
  1291. Internet Draft                    sip                     March 27, 1997
  1292.  
  1293.  
  1294.    c=IN IP4 224.2.0.1/127
  1295.    t=0 0
  1296.    m=audio 3456 RTP/AVP 0
  1297.  
  1298.  
  1299.  
  1300.    Such confirmations are still useful when TCP transport is used as
  1301.    they provide application level confirmation rather than transport
  1302.    level confirmation. If they are not used, it is possible that a "200
  1303.    OK" response may be received after the application making the call
  1304.    has timed out the call and exited.
  1305.  
  1306. 10.7.1 Redirects
  1307.  
  1308.    "603 alternative address" replies and 301 and 302 moved replies
  1309.    should specify another location using the  Location field.
  1310.  
  1311.    An example of a "603 alternative address" reply is:
  1312.  
  1313.  
  1314.    SIP/2.0 603 128.16.64.19/65729
  1315.    Via: SIP/2.0/UDP 131.215.131.131 1
  1316.    Via: SIP/2.0/UDP 128.16.64.19
  1317.    From: mjh@isi.edu
  1318.    To: schooler@cs.caltech.edu
  1319.    Location: 239.128.16.254 16
  1320.    Content-length:0
  1321.  
  1322.  
  1323.  
  1324.    In this example, the proxy (131.215.131.131) is being advised to
  1325.    contact the multicast group 239.128.16.254 with a ttl of 16. In
  1326.    normal situations a server would not suggest a redirect to a local
  1327.    multicast group unless (as in the above situation) it knows that the
  1328.    previous proxy or client is within the scope of the local group.
  1329.  
  1330.    For unicast 603 redirects, a proxy MAY query the suggested location
  1331.    itself or send MAY the redirect on back towards the client. For
  1332.    multicast 603 redirects, a proxy SHOULD query the multicast address
  1333.    itself rather than sending the redirect back towards the client as
  1334.    multicast may be scoped and this allows a proxy within the
  1335.    appropriate scope regions to make the query.
  1336.  
  1337.    For 301 or 302 redirects, a proxy SHOULD send the redirect on back
  1338.    towards the client and terminate any other searches it is performing
  1339.    for the same request. Multicast 301 or 302 redirects MUST NOT be
  1340.    generated.
  1341.  
  1342.  
  1343.  
  1344.  
  1345. M. Handley, H. Schulzrinne, E. Schooler                      [Page 24]
  1346.  
  1347. Internet Draft                    sip                     March 27, 1997
  1348.  
  1349.  
  1350. 10.8 Alternative Services
  1351.  
  1352.    An example of an "350 Alternative Service" reply is:
  1353.  
  1354.    SIP/2.0 350 128.16.64.19/32492/2
  1355.    Via: SIP/2.0/UDP 131.215.131.131
  1356.    Via: SIP/2.0/UDP 128.16.64.19
  1357.    From: mjh@isi.edu
  1358.    To: schooler@cs.caltech.edu
  1359.    Contact-host: IN IP4 131.215.131.131
  1360.    Content-type: application/sdp
  1361.    Content-length: 146
  1362.  
  1363.    v=0
  1364.    o=mm-server 2523535 0 IN IP4 131.215.131.131
  1365.    s=Answering Machine
  1366.    i=Leave an audio message
  1367.    c=IN IP4 128.16.64.19
  1368.    t=0 0
  1369.    m=audio 12345 RTP/AVP 0
  1370.  
  1371.  
  1372.  
  1373.    In this case, the answering server provides a session description
  1374.    that describes an "answering machine".  If the invitation initiator
  1375.    decides to take advantage of this service, it should send an
  1376.    invitation request to the contact host (131.215.131.131) with the
  1377.    session description provided. This request should contain a different
  1378.    session id from the one in the original request.  An example would
  1379.    be:
  1380.  
  1381.  
  1382.    INVITE 128.16.64.19/32492/3 SIP/2.0
  1383.    Via: SIP/2.0/UDP 128.16.64.19
  1384.    From: mjh@isi.edu
  1385.    To: schooler@cs.caltech.edu
  1386.    Content-type: application/sdp
  1387.    Content-length: 146
  1388.  
  1389.    v=0
  1390.    o=mm-server 2523535 0 IN IP4 128.16.5.31
  1391.    s=Answering Machine
  1392.    i=Leave an audio message
  1393.    c=IN IP4 128.16.64.19
  1394.    t=0 0
  1395.    m=audio 12345 RTP/AVP PCMU
  1396.  
  1397.  
  1398.  
  1399.  
  1400.  
  1401. M. Handley, H. Schulzrinne, E. Schooler                      [Page 25]
  1402.  
  1403. Internet Draft                    sip                     March 27, 1997
  1404.  
  1405.  
  1406.    Invitation initiators can choose to treat a "350 Alternative Service"
  1407.    reply as a failure if they wish to do so.
  1408.  
  1409. 10.8.1 Negotiation
  1410.  
  1411.    A "406 Not Acceptable" reply means that the user wishes to
  1412.    communicate, but cannot support the session described adequately. The
  1413.    "406 Not Acceptable" reply contains a list of reasons why the session
  1414.    described cannot be supported. These reasons can be one or more of:
  1415.  
  1416.    406.1 Insufficient Bandwidth: the bandwidth specified in the session
  1417.         description or defined by the media exceeds that known to be
  1418.         available.
  1419.  
  1420.    406.2 Incompatible Protocol: one or more protocols described in the
  1421.         request is not available.
  1422.  
  1423.    406.3 Incompatible Format: one or more media formats described in the
  1424.         request is not available.
  1425.  
  1426.    406.4 Multicast not available: the site where the user is located
  1427.         does not support multicast.
  1428.  
  1429.    406.5 Unicast not available: the site where the user is located does
  1430.         not support unicast communication (usually due to the presence
  1431.         of a firewall).
  1432.  
  1433.    Other reasons are likely to be added later. It is hoped that
  1434.    negotiation will not frequently be needed, and when a new user is
  1435.    being invited to join a pre-existing lightweight session, negotiation
  1436.    may not be possible. If is up to the invitation initiator to decide
  1437.    whether or not to act on a "406 Not Acceptable" reply.
  1438.  
  1439.    A complex example of a "406 Not Acceptable" reply is:
  1440.  
  1441.    SIP/2.0 406 128.16.64.19/32492/5
  1442.    From: mjh@isi.edu
  1443.    To: schooler@cs.caltech.edu
  1444.    Contact-host: 131.215.131.131
  1445.    Reason: 406.1, 406.3, 406.4
  1446.    Content-Type: meta/sdp
  1447.    Content-Length: 50
  1448.  
  1449.    v=0
  1450.    s=Lets talk
  1451.    b=CT:128
  1452.    c=IN IP4 131.215.131.131
  1453.    m=audio 3456 RTP/AVP 7 0 13
  1454.  
  1455.  
  1456.  
  1457. M. Handley, H. Schulzrinne, E. Schooler                      [Page 26]
  1458.  
  1459. Internet Draft                    sip                     March 27, 1997
  1460.  
  1461.  
  1462.    m=video 2232 RTP/AVP 31
  1463.  
  1464.  
  1465.  
  1466.    In this example, the original request specified 256 kb/s total
  1467.    bandwidth, and the reply states that only 128 kb/s is available. The
  1468.    original request specified GSM audio, H.261 video, and WB whiteboard.
  1469.    The audio coding and whiteboard are not available, but the reply
  1470.    states that DVI, PCM or LPC audio could be supported in order of
  1471.    preference. The reply also states that multicast is not available.
  1472.    In such a case, it might be appropriate to set up a transcoding
  1473.    gateway and re-invite the user.
  1474.  
  1475.    Invitation initiators MAY choose to treat "406 Not Acceptable"
  1476.    replies as a failure if they wish to do so.
  1477.  
  1478. 10.9 Compact Form
  1479.  
  1480.    When SIP is carried over UDP with authentication and a complex
  1481.    session description, it may be possible that the size of a request or
  1482.    reply is larger than the MTU (or default 1,000-byte limit if the MTU
  1483.    is not known).  To reduce this problem, a more compact form of SIP is
  1484.    also defined by using alternative names for common header fields.
  1485.    These short forms are NOT abbreviations, they are field names. No
  1486.    other abbreviations are allowed.
  1487.  
  1488.  
  1489.    short field name    long field name      note
  1490.    a                    Confirm             from "acknowledge"
  1491.    c                    Content-Type
  1492.    e                    Content-Encoding
  1493.    f                    From
  1494.    h                    Contact-Host
  1495.    l                    Content-Length
  1496.    m                    Location            from "moved"
  1497.    r                    Reason
  1498.    t                    To
  1499.    v                    Via
  1500.  
  1501.  
  1502.    Thus the header in section ?? could also be written:
  1503.  
  1504.  
  1505.    INVITE 128.16.64.19/65729 SIP/2.0
  1506.    p:IN IP4 UDP 239.128.16.254 1 16
  1507.    p:IN IP4 UDP 131.215.131.131 1
  1508.    p:IN IP4 UDP 128.16.64.19 1
  1509.    f:mjh@isi.edu
  1510.  
  1511.  
  1512.  
  1513. M. Handley, H. Schulzrinne, E. Schooler                      [Page 27]
  1514.  
  1515. Internet Draft                    sip                     March 27, 1997
  1516.  
  1517.  
  1518.    t:schooler@cs.caltech.edu
  1519.    c:application/sdp
  1520.    l:187
  1521.  
  1522.    v=0
  1523.    o=user1 53655765 2353687637 IN IP4 128.3.4.5
  1524.    s=Mbone Audio
  1525.    i=Discussion of Mbone Engineering Issues
  1526.    e=mbone@somewhere.com
  1527.    c=IN IP4 224.2.0.1/127
  1528.    t=0 0
  1529.    m=audio 3456 RTP/AVP 0
  1530.  
  1531.  
  1532.  
  1533.    Mixing short field names and long field names is allowed, but not
  1534.    recommended. Servers MUST accept both short and long field names for
  1535.    requests. Proxies MUST NOT translate a request between short and long
  1536.    forms if authentication fields are present.
  1537.  
  1538. 11 SIP Transport
  1539.  
  1540.    SIP is defined so it can use either UDP or TCP as a transport
  1541.    protocol.
  1542.  
  1543.    UDP has advantages over TCP from a performance point of view, as the
  1544.    SIP application can keep control of the precise timing of
  1545.    retransmissions, and can also make simultaneous call attempts to many
  1546.    potential locations of many users without needing to keep TCP
  1547.    connection state for each connection.
  1548.  
  1549.    TCP has the advantage that clients are simpler to implement because
  1550.    no retransmission timing code needs to be written and also that it is
  1551.    possible to have a single server serving SIP and HTTP with very
  1552.    little extra code.
  1553.  
  1554.    With UDP, all the additional reliability code is in the client. It is
  1555.    recommended that servers SHOULD implement both TCP and UDP
  1556.    functionality as the additional server code required is very small.
  1557.  
  1558.    Clients MAY implement either TCP or UDP transport or both as they see
  1559.    fit.
  1560.  
  1561. 11.1 Reliability using UDP transport
  1562.  
  1563.    The Session Invitation Protocol is straightforward in operation. Only
  1564.    the initiating client needs to keep any state regarding the current
  1565.    connection attempt. SIP assumes no additional reliability from IP.
  1566.  
  1567.  
  1568.  
  1569. M. Handley, H. Schulzrinne, E. Schooler                      [Page 28]
  1570.  
  1571. Internet Draft                    sip                     March 27, 1997
  1572.  
  1573.  
  1574.    Requests or replies may be lost. A SIP client SHOULD simply
  1575.    retransmit a SIP request until it receives a reply, or until it has
  1576.    reached some maximum number of timeouts and retransmissions. If the
  1577.    reply is merely a 1xx Informational progress report, the initiating
  1578.    client SHOULD still continue retransmitting the request, albeit less
  1579.    frequently.
  1580.  
  1581.    When the remote user agent or server sends a final 2xx or 4xx
  1582.    response (not a 1xx report), it cannot be sure the client has
  1583.    received the response, and thus SHOULD cache the results until a
  1584.    connection setup timeout has occurred to avoid having to contact the
  1585.    user again. The server MAY also choose to cache 3xx or 6xx responses
  1586.    if the cost of obtaining the response outweighs the cost of caching
  1587.    it.
  1588.  
  1589.    It is possible that a user can be invited successfully, but that the
  1590.    reply that the user was successfully contacted may not reach the
  1591.    invitation initiator. If the session still exists but the initiator
  1592.    gives up on including the user, the contacted user has sufficient
  1593.    information to be able to join the session. However, if the session
  1594.    no longer exists because the invitation initiator "hung up" before
  1595.    the reply arrived and the session was to be two-way, the conferencing
  1596.    system should be prepared to deal with this circumstance.
  1597.  
  1598.    One solution is for the initiator to acknowledge the invitee's "200
  1599.    OK" reply. Although not required, in the case of a successful
  1600.    invitation the invited user's agent can make a confirmation request
  1601.    in its "200 OK" reply. In this case the initiator's agent sends a
  1602.    single request with a reply  Confirm: true if the request was still
  1603.    valid or a reply  Confirm: false if it was not so that a premature
  1604.    hang-up can be detected without a long timeout. Such a confirmation
  1605.    request may be retransmitted by the invited user's agent if it so
  1606.    desired. Confirmation requests can only be made with "200 OK"
  1607.    replies, and only the invitation initiator's agent may issue the
  1608.    actual confirmation.
  1609.  
  1610.    Only a "200 OK" reply warrants such a confirmation handshake, because
  1611.    it is the only situation where user-relevant state may be
  1612.    instantiated anywhere other than at the initiator's client. In all
  1613.    other cases, it is not necessary that state is maintained. In
  1614.    particular, when a server makes multiple proxy requests, "5xx Server
  1615.    Error" and "6xx Search Response" replies do not immediately get
  1616.    passed back to the invitation initiator, and so no end-to-end
  1617.    acknowledgment of a failed request is possible.
  1618.  
  1619. 11.2 Reliability using TCP transport
  1620.  
  1621.    TCP is a reliable transport protocol, and so we do not need to define
  1622.  
  1623.  
  1624.  
  1625. M. Handley, H. Schulzrinne, E. Schooler                      [Page 29]
  1626.  
  1627. Internet Draft                    sip                     March 27, 1997
  1628.  
  1629.  
  1630.    additional reliability mechanisms. However, we must define rules for
  1631.    connection closedown under normal operation.
  1632.  
  1633.    The normal mode of operation is for the client (or proxy acting as a
  1634.    client) to make a TCP connection to the well-known port of a host
  1635.    housing a SIP server. The client then sends the SIP request to the
  1636.    server over this connection and waits for one or more replies. The
  1637.    client MAY close the connection at any time.
  1638.  
  1639.    The server MAY send one or more 1xx Informational responses before
  1640.    sending a single 2xx, 3xx, 4xx, 5xx or 6xx reply. The server MUST NOT
  1641.    send more than one reply, with the exception of 1xx responses. The
  1642.    server SHOULD NOT close the TCP connection until it has sent its
  1643.    final response, at which point it MAY close the TCP connection if it
  1644.    wishes to. However, normally it is the client's responsibility to
  1645.    close the connection.
  1646.  
  1647.    If the server leaves the connection open, and if the client so
  1648.    desires it may re-use the connection for further SIP requests or for
  1649.    requests from the same family of protocols (such as HTTP or stream
  1650.    control commands).
  1651.  
  1652.    The same application-level confirmation rules apply for TCP as for
  1653.    UDP.
  1654.  
  1655. 12 Searching
  1656.  
  1657.    A basic assumption of SIP is that a location server at the user's
  1658.    home site either knows where the user resides, knows how to locate
  1659.    the user, or at the very least knows another location server that
  1660.    possibly might have a better idea. How these servers get this
  1661.    information is outside the scope of SIP itself, but it is expected
  1662.    that many different user-location services will exist for some time.
  1663.    SIP is designed so that it does not care which location service SIP
  1664.    servers actually employ.
  1665.  
  1666. 12.1 Proxy servers: Relaying and Redirection
  1667.  
  1668.    If a proxy server receives a request for a user whose location it
  1669.    does not know, and for whom it has no better idea where the user
  1670.    might be, then the server should return a "601 Not Currently Here"
  1671.    reply message.
  1672.  
  1673.    If the server does have an idea how to contact the user, it can
  1674.    either forward (relay) the request itself, or can redirect the
  1675.    invitation initiator to another client that is more likely to know by
  1676.    sending a 603, 301 or 302 response as appropriate. It can also
  1677.    gateway the request into some other form if some other invitation
  1678.  
  1679.  
  1680.  
  1681. M. Handley, H. Schulzrinne, E. Schooler                      [Page 30]
  1682.  
  1683. Internet Draft                    sip                     March 27, 1997
  1684.  
  1685.  
  1686.    protocol is in use in a region containing the invited user, though in
  1687.    doing so the server is likely to give up being stateless.
  1688.  
  1689.    Whether to relay the request or to redirect the request is up to the
  1690.    server itself. For example, if the server is on a firewall machine,
  1691.    then it will probably have to relay the request to servers inside the
  1692.    firewall. Additionally, if a local multicast group is to be used for
  1693.    user location, then the server is likely to relay the request.
  1694.    However, if the user is currently away from home, relaying the
  1695.    request makes little sense, and the server is more likely (though not
  1696.    compelled) to send a redirect reply. SIP is policy-free on this
  1697.    issue. In general, local searches are likely to be better performed
  1698.    by relaying whereas wide-area searches are likely to be better
  1699.    performed by redirection.
  1700.  
  1701.    When SIP uses UDP transport, clients and servers can make multiple
  1702.    simultaneous requests to locate a particular user at low cost. This
  1703.    greatly speeds up any search for the user, and in most cases will
  1704.    only result in one successful response. Although several simultaneous
  1705.    paths may reach the same host, successful responses arriving from
  1706.    multiple paths will not confuse the client as they should all contain
  1707.    the same successful host address. However, this does imply that paths
  1708.    with many levels of relaying should be strongly discouraged as if the
  1709.    request is fanned out at each hop and relayed many times, request
  1710.    implosions could result. Thus servers that are not the first hop
  1711.    servers in a chain of servers SHOULD NOT make multiple parallel
  1712.    requests, but should send a redirection response with multiple
  1713.    alternatives. Thus a firewall host can still perform a parallel
  1714.    search but can control the fanout of the search.
  1715.  
  1716. 12.2 Parallel Searches: Initiator Behavior
  1717.  
  1718.    The session initiator may make a parallel search for a user. This can
  1719.    occur when DNS resolution results in multiple addresses, or when
  1720.    contacting a remote server results in a "603 Alternative Address"
  1721.    response containing multiple addresses to try. All such parallel
  1722.    searches for the same SIP request MUST contain the same SIP Id,
  1723.    though the sequence number (given in the  Path field) SHOULD be
  1724.    different for each of the parallel searches.
  1725.  
  1726.    Whilst performing a parallel search, different responses may result
  1727.    from different servers, and it is important for the initiating client
  1728.    to handle these responses correctly. In general, the following rules
  1729.    apply:
  1730.  
  1731.         o If a 2xx response is received, the invitation was successful,
  1732.          the user should be informed and all pending requests should be
  1733.          terminated and/or ignored.
  1734.  
  1735.  
  1736.  
  1737. M. Handley, H. Schulzrinne, E. Schooler                      [Page 31]
  1738.  
  1739. Internet Draft                    sip                     March 27, 1997
  1740.  
  1741.  
  1742.         o If a 4xx response is received the invitation has definitively
  1743.          failed, the user should be informed, and all pending requests
  1744.          should be terminated and/or ignored.
  1745.  
  1746.         o If a 3xx response is received, the search should be terminated
  1747.          and all pending requests should be terminated and/or ignored.
  1748.          However, further action MAY be taken depending on the actual
  1749.          reply without informing the user or alternatively the
  1750.          invitation MAY be regarded as having failed in which case the
  1751.          user MUST be informed.
  1752.  
  1753.         o If a 5xx or 6xx response is received, the particular server
  1754.          responding is removed from the parallel search and the search
  1755.          continues.  If a "603 Alternative Address" response is
  1756.          received, the search may be expanded to include those servers
  1757.          listed in the response that have not already responded. The
  1758.          user SHOULD NOT be informed unless there are no other servers
  1759.          left to try, in which case the user MUST be informed.
  1760.  
  1761.         o If a 1xx response is received, the search continues. The user
  1762.          MAY be informed as deemed appropriate.
  1763.  
  1764. 12.3 Parallel Searches: Proxy Behavior
  1765.  
  1766.    In the same way that an Initiating Client can discover multiple
  1767.    addresses to try, a proxy server can also discover multiple addresses
  1768.    that it may try. For a proxy server to be stateless, it must not make
  1769.    multiple SIP requests because it would then be possible to return a
  1770.    5xx or 6xx response to the Initiating Client and afterwards obtain a
  1771.    definitive answer. To be able to make multiple parallel SIP requests,
  1772.    it must keep state as to the replies it has already received and MUST
  1773.    NOT return any reply other than 1xx informational replies until it
  1774.    has received a definitive reply or has no further addresses to try.
  1775.  
  1776.    Thus faced with DNS resolution giving multiple addresses, a proxy
  1777.    server that wishes to be stateless should only send a SIP request to
  1778.    the first address. Similarly a stateless proxy should not attempt to
  1779.    send SIP request to multiple addresses given in a "603 Alternative
  1780.    Address" response that is returned it it, but should forward such a
  1781.    response back towards the initiator.
  1782.  
  1783.    Proxies that wish to keep state should follow the following rules
  1784.    regarding responses obtained during a parallel search:
  1785.  
  1786.         o If a 2xx response is received, the invitation was successful,
  1787.          the 2xx response should be forwarded back towards the
  1788.          initiator, and all pending requests should be terminated and/or
  1789.          ignored.
  1790.  
  1791.  
  1792.  
  1793. M. Handley, H. Schulzrinne, E. Schooler                      [Page 32]
  1794.  
  1795. Internet Draft                    sip                     March 27, 1997
  1796.  
  1797.  
  1798.         o If a 4xx response is received the invitation has definitively
  1799.          failed, the 4xx response should be forwarded back towards the
  1800.          initiator, and all pending requests should be terminated and/or
  1801.          ignored.
  1802.  
  1803.         o If a 3xx response is received the invitation is regarded by
  1804.          the proxy as having failed, the 3xx response should be
  1805.          forwarded back towards the initiator, the search should be
  1806.          terminated and all pending requests should be terminated and/or
  1807.          ignored.
  1808.  
  1809.         o If a 5xx or 6xx response is received, the particular server
  1810.          responding is removed from the parallel search and the search
  1811.          continues.  If a "603 Alternative Address" response is
  1812.          received, the search may be expanded to include those servers
  1813.          listed in the response that have not already responded. No
  1814.          response other than a periodic "100 Trying" response should be
  1815.          send towards the initiator unless there are no other servers
  1816.          left to try, in which case a response SHOULD be sent as
  1817.          described below.
  1818.  
  1819.         o If a 1xx response is received, the search continues. The 1xx
  1820.          response MAY be forwarded towards the initiator as appropriate.
  1821.  
  1822.    If a proxy had exhausted its search and still not obtained a
  1823.    definitive response (it received only 1xx, 5xx, and 6xx responses)
  1824.    the proxy should cache these responses and return the first response
  1825.    from the following ordered list:
  1826.  
  1827.         1.   503 Service Unavailable;
  1828.  
  1829.         2.   500 Server Internal Error;
  1830.  
  1831.         3.   501 Not Implemented;
  1832.  
  1833.         4.   any other 5xx error not yet defined;
  1834.  
  1835.         5.   600 Search Failure;
  1836.  
  1837.         6.   602 Not Currently Here;
  1838.  
  1839.         7.   601 Not Known Here;
  1840.  
  1841.         8.   any other 6xx error response not yet defined.
  1842.  
  1843.    If a proxy has exhausted its search and the only response it has
  1844.    received has been "603 Alternative Address", then the proxy should
  1845.    send a "600 Search Failure" response if any connection attempt timed
  1846.  
  1847.  
  1848.  
  1849. M. Handley, H. Schulzrinne, E. Schooler                      [Page 33]
  1850.  
  1851. Internet Draft                    sip                     March 27, 1997
  1852.  
  1853.  
  1854.    out or failed, or it should send "602 Not Currently Here" if two or
  1855.    more "603 Alternative Address" responses only provide references to
  1856.    each other.
  1857.  
  1858. 12.4 Change of Transport at a Proxy
  1859.  
  1860.  
  1861.         Editors note: this section is still incomplete. Several
  1862.         options exist for where the responsibility should lie for
  1863.         retransmissions from proxies between TCP and UDP transport.
  1864.         This section generally assumes local retransmission, but
  1865.         end-to-end transmission through a chain of proxies is also
  1866.         possible.
  1867.  
  1868.    It is possible that a proxy server will receiver a request using TCP
  1869.    and relay it onwards using UDP or vice-versa. SIP does not assume
  1870.    end-to-end reliability even when the initiating client is using TCP,
  1871.    but a SIP client sending a request over TCP MAY assume that the
  1872.    request has been received by the server it sent the request to.
  1873.    Retransmission of the request is then not the responsibility of the
  1874.    client. However, a called user agent SHOULD NOT assume that a 2xx
  1875.    success response has been received by the invitation initiator, even
  1876.    if all the path fields in the request indicated TCP transport because
  1877.    it cannot be certain all those TCP connections still exist. If the
  1878.    called user agent requires knowledge that the response did reach the
  1879.    invitation initiator, it MAY add a  Confirm: required field to the
  1880.    reply as it would if the response was sent using UDP.
  1881.  
  1882.    In the following, the term "TCP-UDP proxy" is used to mean a proxy
  1883.    that received a request using TCP and relayed it using UDP. Similarly
  1884.    a "TCP-UDP proxy" receives a reply using UDP and should relay it
  1885.    using TCP.
  1886.  
  1887. 12.4.1 Retransmission from a TCP-UDP Proxy
  1888.  
  1889.    A proxy receiving a request with TCP transport and forwarding that
  1890.    request using UDP becomes responsible for retransmission of the
  1891.    request as required and for timing out the request if no answer is
  1892.    forthcoming.
  1893.  
  1894. 12.4.2 Retransmissions arriving at a UDP-TCP Proxy
  1895.  
  1896.    A proxy receiving a request using UDP transport and forwarding that
  1897.    request using TCP transport may have have SIP request state
  1898.    associated with that TCP connection or SIP response state associated
  1899.    with it.
  1900.  
  1901.    If such a proxy receives a retransmission of the UDP request whilst
  1902.  
  1903.  
  1904.  
  1905. M. Handley, H. Schulzrinne, E. Schooler                      [Page 34]
  1906.  
  1907. Internet Draft                    sip                     March 27, 1997
  1908.  
  1909.  
  1910.    in the state or awaiting a response (i.e, has request state), it
  1911.    SHOULD NOT forward the duplicate request into the TCP connection
  1912.    unless the request has been modified, but instead SHOULD respond with
  1913.    a "100 Trying" response sent back towards the initiator.
  1914.  
  1915.    Note: This behavior is different from a UDP-UDP proxy which MUST
  1916.    forward the retransmitted request and MAY additionally respond with a
  1917.    "100 Trying" response sent back towards the initiator.
  1918.  
  1919.    If such a proxy receives a retransmission of the UDP request in
  1920.    response state (i.e, it has already sent a definitive response) then
  1921.    the proxy MAY retransmit that response if it has cached it.
  1922.    Alternatively if it has not cached the response, it SHOULD resend the
  1923.    request towards the called user agent, either via an existing TCP
  1924.    connection if there is one or via a new TCP connection if there is
  1925.    not, to obtain a retransmission of the response. In the latter case,
  1926.    the proxy MAY additionally respond with a "100 Trying" response sent
  1927.    back towards the initiator.
  1928.  
  1929.    Note: This behavior is the same as a UDP-to-UDP proxy in the same
  1930.    circumstances.
  1931.  
  1932. 12.4.3 Confirmation arriving at a TCP-UDP Proxy
  1933.  
  1934.    One possible event that may occur is that whilst performing a search
  1935.    using UDP, a response may arrive that should be relayed back towards
  1936.    the initiator using TCP, but the TCP connection has been terminated
  1937.    by the initiator. In this case the proxy MUST NOT attempt to relay
  1938.    the response (by opening a TCP connection) and should terminate any
  1939.    outstanding search. In this circumstance only, if the response was a
  1940.    "200 OK" response with a  Confirm: required field, the proxy MAY
  1941.    resend the request to the Contact Host with a  Confirm: false field
  1942.    to speed hang-up discovery at the called user agent.
  1943.  
  1944. 12.4.4 Confirmation sent from a UDP-TCP Proxy
  1945.  
  1946.    Normally a response that arrives at a proxy using TCP that should be
  1947.    sent back towards the initiator using UDP should be sent once, and
  1948.    should only be resent if the request is resent from the UDP proxy
  1949.    closer to the initiator. However, this does not allow for reliable
  1950.    confirmation.
  1951.  
  1952. 13 Using Variants for Terminal Negotiation
  1953.  
  1954.    Redirection allows the called party to indicate several communication
  1955.    alternatives to the caller using the 300 (Multiple Choices) response,
  1956.    all reachable using a single published communication identifier.
  1957.  
  1958.  
  1959.  
  1960.  
  1961. M. Handley, H. Schulzrinne, E. Schooler                      [Page 35]
  1962.  
  1963. Internet Draft                    sip                     March 27, 1997
  1964.  
  1965.  
  1966.    The  Alternates header in the response contains the variant list.
  1967.    The response may contain an entity, typically of content type
  1968.    text/html, providing guidance to the user. The calling user agent is
  1969.    free to ignore this part and solely rely on the  Alternates header.
  1970.  
  1971.  
  1972.      SIP/2.0 300 Multiple Choices
  1973.      Date: Thu, 06 Mar 1997 10:08:55 GMT
  1974.      Alternates:
  1975.         {"hgs@erlang.cs.columbia.edu" 0.9 {mobility fixed} {class business}
  1976.           {service IP, voice-mail} {media all} {duplex full}},
  1977.         {"+12129397042" 0.8 {mobility fixed} {class business}
  1978.           {service POTS} {media audio} {duplex full}},
  1979.         {"+12129397000" 0.7 {mobility fixed} {class business}
  1980.           {service ISDN, attendant} {media audio} {duplex full}
  1981.           {language en, es, iw}},
  1982.         {"+12125551212" 0.6 {mobility mobile} {class personal}
  1983.           {service POTS} {media audio} {duplex full}}
  1984.        }
  1985.      Content-Type: text/html
  1986.      Content-Length: 283
  1987.  
  1988.      <html>
  1989.      You can reach <a href="http://www.cs.columbia.edu/~doe">John Doe</a> at
  1990.  
  1991.      <ul>
  1992.      <li><a href="sip://hgs@erlang.cs.columbia.edu">Internet telephony</a>
  1993.  
  1994.      <li><a href="phone://+1219397042">analog phone</a>
  1995.  
  1996.      <li>...
  1997.  
  1998.      </dl>
  1999.      </html>
  2000.  
  2001.  
  2002.  
  2003.  
  2004. 13.1 Variant Description
  2005.  
  2006.    A variant can be described in a machine-readable way with a variant
  2007.    description [7].
  2008.  
  2009.  
  2010.      variant-description =
  2011.        "{" <"> UCI <"> communication-quality *variant-attribute "}"
  2012.  
  2013.      communications-quality = qvalue
  2014.  
  2015.  
  2016.  
  2017. M. Handley, H. Schulzrinne, E. Schooler                      [Page 36]
  2018.  
  2019. Internet Draft                    sip                     March 27, 1997
  2020.  
  2021.  
  2022.      variant-attribute = "{" "mobility"  ( "fixed" | "mobile" ) "}"
  2023.                        | "{" "class"     ( "personal" | "business" ) "}"
  2024.                        | "{" "language"  1#language-tag "}"
  2025.                        | "{" "service"   1#service-tag "}"
  2026.                        | "{" "media"     1#media-tag "}"
  2027.                        | "{" "features"  feature-list "}"
  2028.                        | "{" "description" quoted-string "}"
  2029.                        | "{" "duplex"    ( "full" | "half" | "receive-only" |
  2030.                                            "send-only" ) "}"
  2031.                        | extension-attribute
  2032.  
  2033.      extension-attribute = "{" extension-name extension-value "}"
  2034.      extension-name      = token
  2035.      extension-value     = *( token | quoted-string | LWS |
  2036.                               extension-specials )
  2037.      extension-specials  = <any element of tspecials except <"> and "}">
  2038.  
  2039.      language-tag        = <see [H3.10]>
  2040.      service-tag         = fax | IP | POTS | pager | voice-mail |
  2041.                            attendant
  2042.      media-tag           = <see SDP: audio | video | ... >
  2043.      feature-list        =
  2044.  
  2045.  
  2046.  
  2047.    Attributes which are unknown should be omitted. New tags for class-
  2048.    tag and  service-tag can be registered with IANA. The media tag uses
  2049.    Internet media types, e.g., audio, video, application/x-wb, etc. This
  2050.    is meant for indicating general communication capability, not the
  2051.    support for specific encodings. It should be sufficient to allow the
  2052.    caller to choose an appropriate communication address.
  2053.  
  2054. 14 Acknowledgments
  2055.  
  2056.    We wish to thank the members of the IETF MMUSIC WG for their comments
  2057.    and suggestions. This work is based, inter alia, on [8,9].
  2058.  
  2059. 15 Authors' Addresses
  2060.  
  2061.    Mark Handley
  2062.    USC Information Sciences Institute
  2063.    c/o MIT Laboratory for Computer Science
  2064.    545 Technology Square
  2065.    Cambridge, MA 02139
  2066.    USA
  2067.    electronic mail: mjh@isi.edu
  2068.  
  2069.    Henning Schulzrinne
  2070.  
  2071.  
  2072.  
  2073. M. Handley, H. Schulzrinne, E. Schooler                      [Page 37]
  2074.  
  2075. Internet Draft                    sip                     March 27, 1997
  2076.  
  2077.  
  2078.    Dept. of Computer Science
  2079.    Columbia University
  2080.    1214 Amsterdam Avenue
  2081.    New York, MY 10027
  2082.    USA electronic mail: schulzrinne@cs.columbia.edu
  2083.  
  2084.    Eve Schooler
  2085.    Computer Science Department 256-80
  2086.    California Institute of Technology
  2087.    Pasadena, CA 91125
  2088.    USA
  2089.    electronic mail: schooler@cs.caltech.edu
  2090.  
  2091. 16 Bibliography
  2092.  
  2093.    [1] M. Handley, "SDP: Session description protocol," Internet Draft,
  2094.    Internet Engineering Task Force, Nov. 1996.  Work in progress.
  2095.  
  2096.    [2] M. Handley, "Sap: Session announcement protocol," Internet Draft,
  2097.    Internet Engineering Task Force, Nov. 1996.  Work in progress.
  2098.  
  2099.    [3] P. Lantz, "Usage of H.323 on the Internet," Internet Draft,
  2100.    Internet Engineering Task Force, Feb. 1997.  Work in progress.
  2101.  
  2102.    [4] S. Bradner, "Key words for use in RFCs to indicate requirement
  2103.    levels," Internet Draft, Internet Engineering Task Force, Jan. 1997.
  2104.    Work in progress.
  2105.  
  2106.    [5] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the
  2107.    location of services (DNS SRV),"  RFC 2052, Internet Engineering Task
  2108.    Force, Oct.  1996.
  2109.  
  2110.    [6] D. Crocker, "Augmented BNF for syntax specifications: ABNF,"
  2111.    Internet Draft, Internet Engineering Task Force, Oct. 1996.  Work in
  2112.    progress.
  2113.  
  2114.    [7] K. Holtman and A. Muntz, "Transparent Content Negotiation in
  2115.    HTTP," Internet Draft, Internet Engineering Task Force, Nov. 1997.
  2116.    Work in progress.
  2117.  
  2118.    [8] E. M. Schooler, "Case study: multimedia conference control in a
  2119.    packet-switched teleconferencing system," Journal of Internetworking:
  2120.    Research and Experience , vol. 4, pp. 99--120, June 1993.  ISI
  2121.    reprint series ISI/RS-93-359.
  2122.  
  2123.    [9] H. Schulzrinne, "Personal mobility for multimedia services in the
  2124.    Internet," in European Workshop on Interactive Distributed Multimedia
  2125.    Systems and Services , (Berlin, Germany), Mar. 1996.
  2126.  
  2127.  
  2128.  
  2129. M. Handley, H. Schulzrinne, E. Schooler                      [Page 38]
  2130.  
  2131.