[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 01 02 03 04 05 06 07 08 09 10 11 12 RFC 2543

Internet Engineering Task Force                                   MMUSIC WG
INTERNET-DRAFT                      M. Handley, H. Schulzrinne, E. Schooler
draft-ietf-mmusic-sip-01.txt                           ISI,Columbia,Caltech
                                                               2nd Dec 1996
                                                     Expires: 2nd June 1997


                    SIP: Session Initiation Protocol




Abstract

Many styles of multimedia conferencing are likely  to  co-exist  on  the
Internet,  and  many  of them share the need to invite users to partici-
pate.  The Session  Initiation  Protocol  (SIP)  is  a  simple  protocol
designed  to  enable the invitation of users to participate in such mul-
timedia sessions.  It is not tied to  any  specific  conference  control
scheme,  providing support for either loosely or tightly controlled ses-
sions.  In particular, it aims to enable user mobility by  relaying  and
redirecting invitations to a user's current location.

This document is a product of the Multiparty Multimedia Session  Control
(MMUSIC) working group of the Internet Engineering Task Force.  Comments
are solicited and should be addressed to  the  working  group's  mailing
list at confctrl@isi.edu and/or the authors.


Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are  working  docu-
ments  of the Internet Engineering Task Force (IETF), its areas, and its
working groups.  Note that other  groups  may  also  distribute  working
documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum  of  six  months
and  may  be  updated,  replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference  material
or to cite them other than as ``work in progress.''

To learn the current status of  any  Internet-Draft,  please  check  the
``1id-abstracts.txt''  listing  contained  in the Internet-Drafts Shadow
Directories   on   ftp.is.co.za   (Africa),   nic.nordu.net    (Europe),
munnari.oz.au   (Pacific  Rim),  ds.internic.net  (US  East  Coast),  or
ftp.isi.edu (US West Coast).




Handley/Schulzrinne/Schooler                                    [Page 1]


INTERNET-DRAFT                                              2nd Dec 1996


Distribution of this document is unlimited.


1.  Authors' Note

This document is the result of a merger of the Session Invitation Proto-
col  (draft-ietf-mmusic-sip-00.txt) and the Simple Conference Invitation
Protocol (draft-ietf-mmusic-scip-00.txt), and of an attempt to make  SIP
more  generic  and  to  fit  into  a  more flexible infrastructure which
includes companion protocols including SDP, HTTP and RTSP.


2.  Introduction

There are two basic ways to locate and to participate  in  a  multimedia
session:


+    The session is advertised, users see the advertisement,  then  join
     the session address to participate.

+    Users are invited to participate in a session, which may or may not
     already be advertised.

The  Session  Description  Protocol  (SDP)  together  with  the  Session
Announcement Protocol (SAP), provide a mechanism for the former [1] [2].
This document presents the Session Initiation Protocol (SIP), to perform
the latter.  SIP also can use SDP to specify what is meant by a session.


                    Figure omitted in ASCII version


                                Figure 1


We make the design decision that how a user  discovers  that  a  session
exists  is orthogonal to a session's conference control model.  Figure 1
shows a potential place for SIP in the  lifecycle  of  both  lightweight
sessions  and  in more tightly-coupled conferencing.  Note that the Ses-
sion Initiation Protocol and the Session Announcement  Protocol  may  be
invoked or re-invoked at later stages in a session's lifecycle.

The Session Initiation Protocol is also intended to be  used  to  invite
servers  into  sessions.  Examples might be where a recording server can
be invited to participate in a live multimedia session  to  record  that
session,  or  a  video-on-demand  server  can be invited to play a video
stream into a live multimedia conference.  In such cases we  would  like



Handley/Schulzrinne/Schooler                                    [Page 2]


INTERNET-DRAFT                                              2nd Dec 1996


SIP  to  lead  gracefully into the control protocol to control recording
and playback on such servers.

We also make the design decision that inviting a user to participate  in
a session is independent of quality of service (QoS) guarantees for that
session.  Such QoS guarantees (if they are required) may be dependent on
the  full membership of the session, and this may or may not be known to
the agent performing session invitation.


2.1.  Terminology

This document uses the same words as RFC 1123 for defining the  signifi-
cance of each particular requirement.  These words are:


must:
     This word or the adjective ``required'' means that the item  is  an
     absolute requirement of the specification.


should:
     This word or the adjective ``recommended''  means  that  there  may
     exist  valid  reasons  in  particular  circumstances to ignore this
     item, but the full implications should be understood and  the  case
     carefully weighed before choosing a different course.


may:
     This word or the adjective ``optional'' means  that  this  item  is
     truly  optional.  One implementation may choose to include the item
     because a particular application requires it or because it enhances
     the  product, for example, another implementation may omit the same
     item.

An implementation is not compliant if it fails to satisfy one or more of
the  must  requirements for the protocols it implements.  An implementa-
tion that satisfies all the must and all the should requirements for the
protocols it implements is said to be ``unconditionally compliant''; one
that satisfies all the must requirements  but  not  all  of  the  should
requirements  for the protocols it implements is said to be ``condition-
ally compliant''.


2.2.  Glossary

This specification uses a number of terms to refer to the  roles  played
by  participants  in  SIP  communications.   The  definitions of client,



Handley/Schulzrinne/Schooler                                    [Page 3]


INTERNET-DRAFT                                              2nd Dec 1996


server and proxy are similar to those used by HTTP.


Client:
     An application program that establishes connections for the purpose
     of sending requests.  Clients may or may not interact directly with
     a human user.


Initiator:
     The party initiating a conference invitation.  Note that  the  cal-
     ling  party  does  not  have  to  be the same as the one creating a
     conference.


Invitation:
     A request sent to attempt to contact a user (or service) to request
     that they participate in a session.


Invitee, Invited User:
     The person or service that the calling party is trying to invite to
     a conference.


Location server:
     A program that is contacted by a client and which  returns  one  or
     more  possible locations for the user or service without contacting
     that user or service directly.


Location service:
     A service used by a location server to obtain information  about  a
     user's possible location.


Proxy, Proxy server:
     An intermediary program which acts as both a server  and  a  client
     for  the  purpose  of  making  requests on behalf of other clients.
     Requests are serviced internally or by passing them, with  possible
     translation,  on to other servers.  A proxy must interpret, and, if
     necessary, rewrite a request message before forwarding it.


Server:
     An application program that accepts connections in order to service
     requests  by  sending  back  responses.  A server may be the called
     user agent, a proxy server, or a location server.



Handley/Schulzrinne/Schooler                                    [Page 4]


INTERNET-DRAFT                                              2nd Dec 1996


User Agent, Called User Agent:
     The server application which contacts the invitee to inform them of
     the invitation, and to return a reply.

Any given program may be capable of  acting  both  as  a  client  and  a
server.   A  typical  multimedia  conference  controller  would act as a
client to initiate calls or invite others to conferences and as a server
to accept invitations.


3.  General Requirements

SIP is a Session Initiation Protocol.  It is not  a  conference  control
protocol.  SIP can be used to perform a search for a user or service and
to request that that user or service participate in a session.

Once SIP has been used to initiate a multimedia session  SIP's  task  is
finished.   There  is  no  concept of a SIP session (as opposed to a SIP
search for a user or service).  If whatever conference control mechanism
is used in the session needs to add or remove a media stream, SIP may be
used to perform this task, but again, once the information has been suc-
cessfully conveyed to the participants, SIP is the no longer involved.

SIP must be able to utilise both UDP and TCP as transport protocols.

From a performance point of view, UDP is preferable  as  it  allows  the
application  to more carefully control the timing of messages, it allows
parallel searches without requiring connection state for each  outstand-
ing request, and allows the use of multicast.

From a pragmatic point of view, TCP allows easier passage through exist-
ing  firewalls, and with appropriate protocol design, allows common SIP,
HTTP and RTSP servers.

When TCP is used, SIP can use either one or more than one connection  to
attempt  to  contact  a user or to modify parameters of an existing ses-
sion.  The concept of a session is not implicitly bound to a TCP connec-
tion,  so  the  initial SIP request and a subsequent SIP request may use
different TCP connections or a single persistent connection as appropri-
ate.

SIP is text based.  This allows easy implementation in languages such as
TCL  and  Perl,  allows  easy debugging, and most importantly, makes SIP
flexible and extensible.  As SIP is only used for session initiation, it
is  believed that the additional overhead of using a text-based protocol
is not significant.

Unlike control protocols, there is minimal shared-state in SIP  -  in  a



Handley/Schulzrinne/Schooler                                    [Page 5]


INTERNET-DRAFT                                              2nd Dec 1996


minimal  implementation  the initiator maintains all the state about the
current attempt to locate and contact a user or  service  -  servers  or
proxies  can  be  stateless  (although  they don't have to be).  All the
state needed to get a response back from a server to  the  initiator  is
carried  in  the  SIP  request  itself - this is also necessary for loop
prevention.

Authors Note: Whilst redesigning SIP, we have attempted to  ensure  that
it  can  has  a  clear interaction with the currently evolving Real-Time
Stream Control Protocol.  Whether RTSP will adopt an approach that makes
this meaningful remains to be seen.


4.  Addressing

SIP is a protocol that exchanges messages between peer  user  agents  or
proxies  for  user  agents.   We assume the user agent is an application
that acts on behalf of the user it  represents  (thus  it  is  sometimes
described  as  a  client  of the user) and that is co-resident with that
user.  A proxy for a user agent serves  as  a  forwarding  mechanism  or
bridge  to the actual location of the user agent.  We also refer to such
proxies as conference address servers.

In the computer realm, the equivalent of  a  personal  telephone  number
combines   the   user's   login  id  (mjh)  with  a  machine  host  name
(metro.isi.edu) or address (128.16.64.78).  A  user's  location-specific
address  can  be obtained out-of-band, can be learned via existing media
agents, such as vat (e.g., Mbone Audio channel), can be included in some
mailers'  message headers, or can be recorded during previous invitation
interactions.

However, users also publish several well-known addresses that are  rela-
tively  location-independent,  such as email or web home-page addresses.
Rather than require that users provide their specific  network  locales,
we  can  take advantage of email and web addresses as being (relatively)
memorable, and also leverage off the Domain Name Service (DNS)  to  pro-
vide  a  first  stage  location  mechanism.   Note that an email address
(M.Handley@cs.ucl.ac.uk) is usually different from the combination of  a
specific  machine  name  and login name ( mjh@mercury.lcs.mit.edu).  SIP
should allow both forms of  addressing  to  be  used,  with  the  former
requiring a conference address server to locate the user.

One perceived problem of email addressing is  that  it  is  possible  to
guess  peoples'  addresses and thus the system of unlisted (in the tele-
phone directory) numbers is more of a  problem.   However,  this  really
only  provides  security  through obscurity, and real security is better
provided through authentication and call screening.




Handley/Schulzrinne/Schooler                                    [Page 6]


INTERNET-DRAFT                                              2nd Dec 1996


5.  Call Setup

Call setup is a multi-phase procedure.  In the first phase, the request-
ing  client  tries  to ascertain the address where it should contact the
remote user agent or user agent proxy.  The local client checks  if  the
user address is location-specific.  If so, then that is the address used
for the remote user agent.  If not, the requesting client looks  up  the
domain  part  of the user address in the DNS.  This provides one or more
records giving IP addresses.  If a new service (SRV) resource record [4]
is returned giving a conference address server, then that is the address
to contact next.  If no relevant resource record is returned, but  an  A
record  is  returned, then that is the address to contact next.  If nei-
ther a resource record or an A record is returned, but an MX  record  is
returned, then the mail host is the address to contact next.

Presuming an address for the invitee is found from the DNS,  the  second
and  subsequent  phases basically implement a request-response protocol.
A session description (typically using SDP format) is sent to  the  con-
tact address with an invitation for the user to join the session.

This request may be sent over a  TCP  connection  or  as  a  single  UDP
datagram (the format of both is the same and is described later), and is
sent to a well-known port.

If a user agent or conference server is listening on the relevant  port,
it  can  send  one  of  the  responses  below.  If no server or agent is
listening, an ICMP port-unreachable response  will  be  triggered  which
should  cause  the  TCP  connection  setup  to  fail or cause a UDP send
failure on retransmissions.


5.1.  Locating a User

It is expected that a user is situated  at  one  of  several  frequented
locations.  These locations can be dynamically registered with a confer-
ence address server for a site (for a local area  network  or  organiza-
tion),  and  incoming connections can be routed simultaneously to all of
these locations if so desired.  It is  entirely  up  to  the  conference
address server whether the server issues proxy requests for the request-
ing user, or if the server instructs the client to redirect the request.

In general a reply MUST be sent by the same mechanism that  the  request
was  sent  by.   Hence, if a request was unicast, then the reply MUST be
unicast back to the requester; if the request was multicast,  the  reply
MUST  be  multicast  to the same group to which the request was sent; if
the request was sent by TCP, the reply MUST be sent by TCP.

In all cases where a request is forwarded onwards,  each  host  relaying



Handley/Schulzrinne/Schooler                                    [Page 7]


INTERNET-DRAFT                                              2nd Dec 1996


the  message  SHOULD  add  its own address to the path of the message so
that the replies can take the same  path  back,  thus  ensuring  correct
operation  through  compliant  firewalls and loop-free requests.  On the
reply path, these routing headers MUST be removed as the reply  retraces
the path, so that routing internal to sites is hidden.  When a multicast
request is made, first the host making the request, then  the  multicast
address itself are added to the path.



6.  Message Formats

All messages are text-based.   When  sent  over  TCP  or  UDP,  multiple
requests can be carried in a single TCP connection or UDP datagram.  UDP
Datagrams should not normally exceed the path  MTU  in  size  if  it  is
known, or 1 KByte if the MTU is unknown.


6.1.  Session Invitations

An example of a session invitation is shown below.  It is divided into a
request and a number of header fields.  The request is of the form:

<method> <request-id> SIP/2.0

The method may be either INVITE or CAPABILITY.  The request  ID  may  be
any  URL encoded string that can be guaranteed to be globally unique for
the duration of the request.  Using the initiator's IP-address,  process
id, and instance (if more than one request is being made simultaneously)
satisfies this requirement.


6.1.1.  Methods

The following methods are defined:

INVITEThe user or service is being invited to participate  in  the  ses-
     sion.   The session description given must be completely acceptable
     for a ``200 OK'' response to be given.  This method  MUST  be  sup-
     ported by a SIP server.

CAPABILITY
     The user or service is being queried as  to  its  capabilities.   A
     server  that believes it can contact the user (such as a user agent
     where the user is logged in  and  has  been  recently  active)  MAY
     respond  to  this  request  with a capability set.  Support of this
     method is OPTIONAL.




Handley/Schulzrinne/Schooler                                    [Page 8]


INTERNET-DRAFT                                              2nd Dec 1996


Methods that are not supported by a proxy server SHOULD  be  treated  by
that  proxy  as  if  they  were  an  INVITE  method, and relayed through
unchanged or cause a redirection as appropriate.

Methods that are not supported by a user agent should cause a ``501  Not
Implemented'' response to be returned.


6.1.2.  Header Fields

SIP header fields are similar to MIME header fields in both  syntax  and
semantics.   In  general  the  ordering  of  the header fields is not of
importance (with the exception of Path fields, see  below)  but  proxies
MUST  NOT reorder or otherwise modify header fields other than by adding
a new Path field. This allows an authentication field to be added  after
the  Path  fields  that will not be invalidated by proxies.  Field names
are not case-sensitive, although their values may be.

Content-Length, Content-Type, To, From, Path header fields  are  compul-
sory.   Other  fields  may  be added as required.  Header fields MUST be
separated by a single linefeed character.  The header MUST be  separated
from the payload by an emply line (two linefeed characters).

A compact form of these codes is also defined in  section  6.3  for  use
over UDP when the request has to fit into a single packet and size is an
issue.


+    The ``Path:'' field indicates the path taken by the request so far.
     This  prevents  request  looping  and ensures replies take the same
     path as the requests, which assists in firewall traversal and other
     unusual  routing  situations.   Initiators  MUST add their own Path
     field to each request.  This Path field MUST be the first field  in
     the  request.   Subsequent  proxies SHOULD each add their own addi-
     tional Path field which MUST be  added  before  any  existing  Path
     fields.   When  a reply passes through a proxy on the reverse path,
     that proxies Path field MUST be removed from the reply.

     The format for a Path field is:

     Path:<net-type> <address-type> <protocol> <address> <sequence> [<ttl>]

     Net type is typically IN (Internet) and address-type  is  typically
     IP4  or IP6 for IP version 4 and IP version 6 respectively.  Proto-
     col may be UDP or TCP.  Sequence is a request sequence number which
     typically  starts  at 1 and is incremented each time the request is
     re-sent by this host.  TTL is included if the address is  a  multi-
     cast address.



Handley/Schulzrinne/Schooler                                    [Page 9]


INTERNET-DRAFT                                              2nd Dec 1996


+    Authentication fields provide a digital signature of the  remaining
     fields  for authentication purposes.  They are not yet defined, but
     when they are defined they MUST be added to the  header  after  the
     Path fields and before the rest of the fields.


+    The request header MUST contain both a ``From:'' field , indicating
     the  invitation  initiator,  and  a  ``To:'' field , specifying the
     invited user.  Both of these  fields  MUST  be  machine-usable,  as
     defined my mailbox in RFC 822 (as updated by RFC 1123). Only a sin-
     gle initiator and a single invited user are allowed to be specified
     in a single SIP request.


+    The session description payload gives details of  the  session  the
     user  is  being  invited to join.  It's format MUST be given by the
     ``Content-type:'' header field, and the  payload  length  in  bytes
     MUST  be given by the ``Content-length'' header field.  If the pay-
     load has undergone any encoding (such  as  compression)  then  this
     MUST be indicated by the ``Content-encoding:'' header field, other-
     wise `` Content-encoding:'' MUST be omitted.

The example below is a request message en route from initiator to  invi-
tee:

INVITE 128.16.64.19/65729 SIP/2.0
Path:IN IP4 UDP 239.128.16.254 1 16
Path:IN IP4 UDP 131.215.131.131 1
Path:IN IP4 UDP 128.16.64.19 1
From:mjh@isi.edu
To:schooler@cs.caltech.edu
Content-type:meta/sdp
Content-Length:187

v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0


The first line above states that this is a SIP version 2.0 request.

The path fields (Path:...) give the hosts along the path from invitation
initiator  (the  first element of the list) towards the invitee.  In the



Handley/Schulzrinne/Schooler                                   [Page 10]


INTERNET-DRAFT                                              2nd Dec 1996


example above, the message was last multicast  to  the  administratively
scoped   group   239.128.16.254   with   a  ttl  of  16  from  the  host
131.215.131.131.

The request header above  states  that  the  request  was  initiated  by
mjh@isi.edu  (specifically it was initiated from 128.16.64.19, as can be
seen  from  the  path   field)   and   the   user   being   invited   is
schooler@cs.caltech.edu.

In this case, the session  description  (as  stated  in  the  ``Content-
type:''  field)  is  a Session Description Protocol (SDP) description as
defined in the companion draft [1].

The header is terminated by an empty line (two linefeed characters)  and
is followed by the session description payload.

If required, the session description can be encrypted using  public  key
cryptography,  and then can also carry private session keys for the ses-
sion.  If this is the case, four random bytes are added to the beginning
of  the  session  description  before  encryption  and are removed after
decryption but before parsing.


6.2.  Responses


6.2.1.  Response Codes

The response codes are consistent with, and  extend,  HTTP/1.1  response
codes.   Not all HTTP/1.1 response codes are appropriate, and only those
that are appropriate are given here.   Response  codes  not  defined  by
HTTP/1.1  are  marked  with  an  asterisk, and have codes x50 upwards to
avoid clashes with future HTTP response codes, or 6xx which are not used
by  HTTP.  The default behaviour for unknown response codes is given for
each category of codes.


Informational 1xx

Informational responses indicate that the server or proxy  contacted  is
performing  some  further  action  and  does  not  yet have a definitive
response.  The client SHOULD  wait  for  a  further  response  from  the
server,  and  the  server  SHOULD  send  such a response without further
prompting.  If UDP transport is being used, the client  SHOULD  periodi-
cally re-send the request in case the final response is lost.  Typically
a server should send a ``1xx'' response if it expects to take more  than
one second to obtain a final reply.




Handley/Schulzrinne/Schooler                                   [Page 11]


INTERNET-DRAFT                                              2nd Dec 1996


100 Trying
     Some further action is being taken (e.g., the request is being for-
     warded) but the user has not yet been located.

150* Ringing
     The user agent or conference server has located a possible location
     where the user has been recently and is trying to alert them.


Successful 2xx

The request was successful and MUST terminate a search.


200 OKThe request was successful in contacting the user,  and  the  user
     has agreed to participate.


Redirection 3xx

3xx responses give information about the user's new location,  or  about
alternative  services that may be able to satisfy the call.  They SHOULD
terminate an existing search, and MAY cause the initiator to begin a new
search if appropriate.


301 Moved Permanently
     The requesting client should retry on the new address given by  the
     Location:  field  because  the  user  has permanently moved and the
     address this reponse is in reply to is no longer a current  address
     for  the user.  A 301 response MUST NOT suggest any of the hosts in
     the request's Path as the user's new location.


302 Moved Temporarily
     The requesting client should retry on the new address(es) given  by
     the  Location:  field.  A  302 response MUST NOT suggest any of the
     hosts in the request's Path as the user's new location.


350* Alternative Service
     The call was not successful, but alternative services are possible.
     The alternative services are described in the body of the reply.


Request Failure 4xx

4xx responses are definite failure responses  that  MUST  terminate  the



Handley/Schulzrinne/Schooler                                   [Page 12]


INTERNET-DRAFT                                              2nd Dec 1996


existing  search  for  a  user  or  service.  They SHOULD NOT be retried
immediately without modification.


400 Bad Request
     The request could not be understood due to malformed syntax.


401 Unauthorized
     The request requires user authentication.


402 Payment Required
     Reserved for future use.


403 Forbidden
     The server understood the request, but is refusing to  fulfill  it.
     Authorisation  will  not  help,  and  the  request  should  not  be
     repeated.


404 Not Found
     The server has definitive information that the user does not  exist
     at the domain specified.


406 Not Acceptable
     The user's agent was contacted successfully but some aspects of the
     session  profile  (the  requested  media,  bandwidth, or addressing
     style) were not acceptable.


450* Decline
     The user's machine was successfully contacted but the  user  expli-
     citly does not wish to participate.


451* Busy
     The user's machine was successfully contacted but the user is busy,
     or  the  user does not wish to participate (the ambiguity is inten-
     tional).


Server Failure 5xx

5xx responses are failure responses  given  when  a  server  itself  has
erred.   They  are  not  definitive failures, and SHOULD NOT terminate a



Handley/Schulzrinne/Schooler                                   [Page 13]


INTERNET-DRAFT                                              2nd Dec 1996


search if other possible locations remain untried.


500 Server Internal Error
     The server encountered an unexpected condition  that  prevented  it
     from fulfilling the request.

501 Not implemented
     The server does not support the functionality required  to  fulfill
     the request.  This is the appropriate response when the server does
     not recognise the request method and is not capable  of  supporting
     it for any user.

503 Service Unavailable
     The server is currently unable to handle the request due to a  tem-
     porary  overloading  or maintenance of the server.  The implication
     is that this is a temporary  condition  which  will  be  alleviated
     after some delay.


Search Responses 6xx

6xx responses are failure responses given whilst trying  to  locate  the
specified user or service.  They are not definitive failures, and SHOULD
NOT terminate the search if other possible locations remain untried.


600* Search Failure
     The user agent or proxy server understood the user's  address,  but
     the  request was unsuccessful in contacting the user. A proxy might
     return this error towards the initiator if an attempt to contact  a
     server failed for an unknown reason.


601* Not known here
     The call was unsuccessful because the user or service was not known
     at  the  address  called.   This  is not a definitive failure - the
     address may be valid at another server.


602* Not currently here
     The call was unsuccessful because although the the user or  service
     was  known  at  the  address  called,  the  user  or service is not
     currently located at  this  address.   This  is  not  a  definitive
     failure - the user may be contactable at another server.


603* Alternative Address



Handley/Schulzrinne/Schooler                                   [Page 14]


INTERNET-DRAFT                                              2nd Dec 1996


     The call was unsuccessful because the user or service is not avail-
     able  at  this location, but one or more alternative non-definitive
     locations are suggested to try in addition to any that may  already
     be  being  tried.  A 603 response MUST NOT suggest any of the hosts
     in the request's Path as an alternative location.


6.2.2.  Normal Replies

An example reply is given below.  The first line of the reply states the
SIP  version  number,  that  it  is  a ``200 OK'' reply, which means the
request was successful.  The path fields are taken from the request, and
entries are removed hop by hop as the reply retraces the request's path.
A new authentication field is added  by  the  invited  user's  agent  if
required.  The  session  ID is taken directly from the original request,
along with the request header.  The original sense of ``From:'' field is
preserved (i.e it's the session originator).

In addition, a ``Contact-host:'' field is added giving  details  of  the
host  the  user was located on, or alternatively the relevant proxy con-
tact point which should be reachable  from  the  invitation  initiator's
host.


SIP/2.0 200 128.16.64.19/65729
Path:IN IP4 UDP 239.128.16.254 1 16
Path:IN IP4 UDP 131.215.131.131 1
Path:IN IP4 UDP 128.16.64.19 1
From:mjh@isi.edu
To:schooler@cs.caltech.edu
Contact-host:IN IP4 131.215.131.147
Content-length:0


This same format is used for replies  for  other  categories  of  reply,
except that some of then may require payloads to be carried.

If the invited user's agent requires confirmation of receipt of a  ``200
OK''  reply,  it  may  optionally  add an additional ``Confirm:required'
field to the body of the message specifying that an acknowledgementy  is
required.  This is only permitted with category 2xx replies.  An example
is:









Handley/Schulzrinne/Schooler                                   [Page 15]


INTERNET-DRAFT                                              2nd Dec 1996



SIP/2.0 200 128.16.64.19/65729
Path:IN IP4 UDP 239.128.16.254 1 16
Path:IN IP4 UDP 131.215.131.131 1
Path:IN IP4 UDP 128.16.64.19 1
From:mjh@isi.edu
To:schooler@cs.caltech.edu
Contact-host:IN IP4 131.215.131.147
Confirm:required
Content-length:0


In response to such a request, the invitation  initiators  agent  should
retransmit  its  request with an additional ``Confirm:'' field, with the
value ``true'' or ``false'' stating whether the session still exists  or
no longer exists respectively (see section 7.1 for details).  An example
of an confirmation request is:


INVITE 128.16.64.19/65729 SIP/2.0
Path:IN IP4 UDP 239.128.16.254 1 16
Path:IN IP4 UDP 131.215.131.131 1
Path:IN IP4 UDP 128.16.64.19 1
From:mjh@isi.edu
To:schooler@cs.caltech.edu
Confirm:true
Content-type:meta/sdp
Content-Length:187

v=0
o=user1 2353655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0


Such confirmations are still useful when TCP transport is used  as  they
provide  application level confirmation rather than transport level con-
firmation.  If they are not used, it  is  possible  that  a  ``200  OK''
response may be received after the application making the call has timed
out the call and exited.







Handley/Schulzrinne/Schooler                                   [Page 16]


INTERNET-DRAFT                                              2nd Dec 1996


6.2.3.  Redirects

``603 alternative address'' replies and 301 and 302 moved replies should
specify another location using the Location: field.

An example of a ``603 alternative address'' reply is:

SIP/2.0 603 128.16.64.19/65729
Path:IN IP4 UDP 131.215.131.131 1
Path:IN IP4 UDP 128.16.64.19 1
From:mjh@isi.edu
To:schooler@cs.caltech.edu
Location:IP IP4 239.128.16.254 16
Content-length:0

In this example, the proxy (131.215.131.131) is being advised to contact
the  multicast  group 239.128.16.254 with a ttl of 16.  In normal situa-
tions a server would not suggest a redirect to a local  multicast  group
unless  (as  in the above situation) it knows that the previous proxy or
client is within the scope of the local group.

For unicast 603 redirects, a proxy  MAY  query  the  suggested  location
itself  or send MAY the redirect on back towards the client.  For multi-
cast 603 redirects, a proxy SHOULD query the  multicast  address  itself
rather  than  sending  the redirect back towards the client as multicast
may be scoped and this allows  a  proxy  within  the  appropriate  scope
regions to make the query.

For 301 or 302 redirects, a proxy  SHOULD  send  the  redirect  on  back
towards  the client and terminate any other searchs it is performing for
the same request.  Multicast 301 or 302 redirects MUST NOT be generated.


Alternative Services

An example of an ``350 Alternative Service'' reply is:















Handley/Schulzrinne/Schooler                                   [Page 17]


INTERNET-DRAFT                                              2nd Dec 1996



SIP/2.0 350 128.16.64.19/32492/2
Path:IN IP4 UDP 131.215.131.131 1
Path:IN IP4 UDP 128.16.64.19 1
From:mjh@isi.edu
To:schooler@cs.caltech.edu
Contact-host:IN IP4 131.215.131.131
Content-type:meta/sdp
Content-length: 146

v=0
o=mm-server 2523535 0 IN IP4 131.215.131.131
s=Answering Machine
i=Leave an audio message
c=IN IP4 128.16.64.19
t=0 0
m=audio 12345 RTP/AVP 0

In this case, the answering server provides a session  description  that
describes  an ``answering machine''. If the invitation initiator decides
to take advantage of this service, it should send an invitation  request
to  the contact host (131.215.131.131) with the session description pro-
vided.  This request should contain a different session id from the  one
in the original request. An example would be:

INVITE 128.16.64.19/32492/3 SIP/2.0
Path:IN IP4 UDP 128.16.64.19 1
From:mjh@isi.edu
To:schooler@cs.caltech.edu
Content-type:meta/sdp
Content-length: 146

v=0
o=mm-server 2523535 0 IN IP4 128.16.5.31
s=Answering Machine
i=Leave an audio message
c=IN IP4 128.16.64.19
t=0 0
m=audio 12345 RTP PCMU


Invitation initiators can choose to treat a ``350 Alternative  Service''
reply as a failure if they wish to do so.


6.2.4.  Negotiation

A  ``406  Not  Acceptable''  reply  means  that  the  user   wishes   to



Handley/Schulzrinne/Schooler                                   [Page 18]


INTERNET-DRAFT                                              2nd Dec 1996


communicate,  but  cannot support the session described adequately.  The
``406 Not Acceptable'' reply contains a list of reasons why the  session
described cannot be supported.  These reasons can be one or more of:


406.1 Insufficient Bandwidth - the bandwidth specified  in  the  session
      description  or  defined  by  the  media  exceeds that known to be
      available.

406.2 Incompatible Protocol - one or more  protocols  described  in  the
      request is not available.

406.3 Incompatible Format - one or more media formats described  in  the
      request is not available.

406.4 Multicast not available - the site where the user is located  does
      not support multicast.

406.5 Unicast not available - the site where the user  is  located  does
      not  support unicast communication (usually due to the presence of
      a firewall).

Other reasons are likely to be added later.  It is hoped  that  negotia-
tion will not frequently be needed, and when a new user is being invited
to join a pre-existing lightweight session, negotiation may not be  pos-
sible.  If is up to the invitation initiator to decide whether or not to
act on a ``406 Not Acceptable'' reply.

A complex example of a ``406 Not Acceptable'' reply is:

SIP/2.0 406 128.16.64.19/32492/5
Path:IN IP4 UDP 131.215.131.131 1
Path:IN IP4 UDP 128.16.64.19 1
From:mjh@isi.edu
To:schooler@cs.caltech.edu
Contact-host:IN IP4 131.215.131.131
Reason:406.1
Reason:406.3
Reason:406.4
Content-type: meta/sdp
Content-length:

v=0
s=Lets talk
b=CT:128
c=IN IP4 131.215.131.131
m=audio 3456 RTP/AVP 7 0 13
m=video 2232 RTP/AVP 31



Handley/Schulzrinne/Schooler                                   [Page 19]


INTERNET-DRAFT                                              2nd Dec 1996


In this example, the original request specified 256Kbps total bandwidth,
and  the  reply  states  that  only  128Kbps is available.  The original
request specified GSM audio, H.261 video, and WB whiteboard.  The  audio
coding  and whiteboard are not available, but the reply states that DVI,
PCM or LPC audio could be supported in order of preference.   The  reply
also  states  that multicast is not available.  In such a case, it might
be appropriate to set up a transcoding gateway and re-invite the user.

Invitation initiators MAY choose to treat ``406 Not Acceptable'' replies
as a failure if they wish to do so.


6.3.  Compact Form

When SIP is carried over UDP with authentication and a  complex  session
description,  it  may be possible that the size of a request or reply is
larger than the MTU (or default 1Kbyte limit if the MTU is  not  known).
To  reduce  this  problem, a more compact form of SIP is also defined by
using alternative names for common header fields.  These short forms are
NOT  abbrieviations - they are field names.  No other abbrieviations are
allowed.


    p:same as Path:

    f:same as From:

    t:same as To:

    c:same as Content-type:

    l:same as Content-length:

    e:same as Content-encoding:

    a:same as Confirm: (derived from acknowledge)

    h:same as Contact-host:

    m:same as Location: (derived from moved)

    r:same as Reason:


Thus the header in section ?? could also be written:






Handley/Schulzrinne/Schooler                                   [Page 20]


INTERNET-DRAFT                                              2nd Dec 1996



INVITE 128.16.64.19/65729 SIP/2.0
p:IN IP4 UDP 239.128.16.254 1 16
p:IN IP4 UDP 131.215.131.131 1
p:IN IP4 UDP 128.16.64.19 1
f:mjh@isi.edu
t:schooler@cs.caltech.edu
c:meta/sdp
l:187

v=0
o=user1 53655765 2353687637 IN IP4 128.3.4.5
s=Mbone Audio
i=Discussion of Mbone Engineering Issues
e=mbone@somewhere.com
c=IN IP4 224.2.0.1/127
t=0 0
m=audio 3456 RTP/AVP 0


Mixing short fieldnames and long fieldnames is allowed, but  not  recom-
mended.   Servers  MUST  accept  both  short  and  long  fieldnames  for
requests.  Proxies MUST NOT translate a request between short  and  long
forms if authentication fields are present.


7.  SIP Transport

SIP is defined so it can use either UDP or TCP as a transport protocol.

UDP has advantages over TCP from a performance point of view, as the SIP
application  can  keep control of the precise timing of retransmissions,
and can also make simultaneous call attempts to many potential locations
of many users without needing to keep TCP connection state for each con-
nection.

TCP has the advantage that clients are simpler to implement  because  no
retransmission  timing code needs to be written and also that it is pos-
sible to have a single server serving SIP  and  HTTP  with  very  little
extra code.

With UDP, all the additional reliability code is in the client.   It  is
recommended that servers SHOULD implement both TCP and UDP functionality
as the additional server code required is very small.

Clients MAY implement either TCP or UDP transport or both  as  they  see
fit.




Handley/Schulzrinne/Schooler                                   [Page 21]


INTERNET-DRAFT                                              2nd Dec 1996


7.1.  Reliability using UDP transport

The Session Invitation Protocol is straightforward in  operation.   Only
the initiating client needs to keep any state regarding the current con-
nection  attempt.   SIP  assumes  no  additional  reliability  from  IP.
Requests  or replies may be lost.  A SIP client SHOULD simply retransmit
a SIP request until it receives a reply, or until it  has  reached  some
maximum  number of timeouts and retransmissions.  If the reply is merely
a 1xx Informational progress report, the initiating client SHOULD  still
continue retransmitting the request, albeit less frequently.

When the remote user agent or server sends a final 2xx or  4xx  response
(not  a  1xx  report),  it  cannot  be  sure the client has received the
response, and thus SHOULD cache the results  until  a  connection  setup
timeout  has  occurred  to  avoid having to contact the user again.  The
server MAY also choose to cache 3xx or 6xx  responses  if  the  cost  of
obtaining the response outweighs the cost of caching it.

It is possible that a user can be invited  successfully,  but  that  the
reply  that the user was succeffully contacted may not reach the invita-
tion initiator.  If the session still exists but the initiator gives  up
on  including the user, the contacted user has sufficient information to
be able to join the session.  However, if the session no  longer  exists
because  the  invitation  initiator ``hung up'' before the reply arrived
and the session was to be two-way, the  conferencing  system  should  be
prepared to deal with this circumstance.

One solution is for the initiator to  acknowledge  the  invitee's  ``200
OK''  reply.  Although not required, in the case of a successful invita-
tion the invited user's agent can make a  confirmation  request  in  its
``200  OK''  reply.   In  this case the initiator's agent sends a single
request with a reply ``Confirm:true'' if the request was still valid  or
a  reply ``Confirm:false'' if it was not so that a premature hang-up can
be detected without a long timeout.  Such a confirmation request may  be
retransmitted  by  the invited user's agent if it so desired.  Confirma-
tion requests can only be made with ``200 OK''  replies,  and  only  the
invitation initiator's agent may issue the actual confirmation.

Only a ``200 OK'' reply warrants such a confirmation handshake,  because
it  is  the only situation where user-relevant state may be instantiated
anywhere other than at the initiator's client.  In all other  cases,  it
is not necessary that state is maintained.  In particular, when a server
makes multiple proxy requests, ``5xx Server  Error''  and  ``6xx  Search
Response''  replies do not immediately get passed back to the invitation
initiator, and so no end-to-end acknowledgment of a  failed  request  is
possible.





Handley/Schulzrinne/Schooler                                   [Page 22]


INTERNET-DRAFT                                              2nd Dec 1996


7.2.  Reliability using TCP transport

TCP is a reliable transport protocol, and so we do not  need  to  define
additional  reliability  mechanisms.   However  we must define rules for
connection closedown under normal operation.

The normal mode of operation is for the client (or  proxy  acting  as  a
client)  to make a TCP connection to the well-known port of a host hous-
ing a SIP server.  The client then sends the SIP request to  the  server
over  this connection and waits for one or more replies.  The client MAY
close the connection at any time.

The server MAY send one or more 1xx Informational responses before send-
ing  a single 2xx, 3xx, 4xx, 5xx or 6xx reply.  The server MUST NOT send
more than one reply, with the exception of 1xx  responses.   The  server
SHOULD  NOT  close  the  TCP  connection  until  it  has  sent its final
response, at which point it MAY close the TCP connection  if  it  wishes
to.   However,  normally  it is the client's responsibility to close the
connection.

If the server leaves the connection open, and if the client  so  desires
it  may  re-use  the connection for further SIP requests or for requests
from the same family of protocols (such as HTTP or stream  control  com-
mands).

The same application-level confirmation rules apply for TCP as for UDP.



8.  Searching

A basic assumption of SIP is that a location server at the  user's  home
site  either knows where the user resides, knows how to locate the user,
or at the very least knows another location server that  possibly  might
have  a  better idea.  How these servers get this information is outside
the scope of SIP itself, but it is expected that  many  different  user-
location  services will exist for some time.  SIP is designed so that it
does not care which location service SIP servers actually employ.


8.1.  Proxy servers: Relaying and Redirection

If a proxy server receives a request for a user whose location  it  does
not  know,  and  for whom it has no better idea where the user might be,
then the server should return a ``601 Not Currently  Here''  reply  mes-
sage.

If the server does have an idea how to contact the user, it  can  either



Handley/Schulzrinne/Schooler                                   [Page 23]


INTERNET-DRAFT                                              2nd Dec 1996


forward  (relay) the request itself, or can redirect the invitation ini-
tiator to another client that is more likely to know by sending  a  603,
301  or  302  response  as appropriate.  It can also gateway the request
into some other form if some other invitation protocol is in  use  in  a
region  containing  the  invited  user, though in doing so the server is
likely to give up being stateless.

Whether to relay the request or to redirect the request  is  up  to  the
server  itself.   For  example,  if the server is on a firewall machine,
then it will probably have to relay the request to  servers  inside  the
firewall.   Additionally,  if  a local multicast group is to be used for
user location, then the server is likely to relay the request.  However,
if the user is currently away from home, relaying the request makes lit-
tle sense, and the server is more likely (though not compelled) to  send
a  redirect  reply.  SIP is policy-free on this issue. In general, local
searches are likely to be better performed by relaying whereas wide-area
searches are likely to be better performed by redirection.

When SIP uses UDP transport,  clients  and  servers  can  make  multiple
simultaneous  requests  to  locate  a particular user at low cost.  This
greatly speeds up any search for the user, and in most cases  will  only
result  in one successful response.  Although several simultaneous paths
may reach the same host, successful  responses  arriving  from  multiple
paths  will  not  confuse the client as they should all contain the same
successful host address.  However, this does imply that paths with  many
levels  of  relaying should be strongly discouraged as if the request is
fanned out at each hop and relayed many times, request implosions  could
result.  Thus  servers  that are not the first hop servers in a chain of
servers SHOULD NOT make multiple parallel requests, but  should  send  a
redirection  response  with multiple alternatives.  Thus a firewall host
can still perform a parallel search but can control the  fanout  of  the
search.


8.2.  Parallel Searches: Initiator Behaviour

The session inititor may make a parallel search for a  user.   This  can
occur  when  DNS  resolution results in multiple addresses, or when con-
tacting a  remote  server  results  in  a  ``603  Alternative  Address''
response  containing  multiple  addresses  to  try.   All  such parallel
searches for the same SIP request MUST contain the same SIP  Id,  though
the  sequence  number (given in the ``Path:'' field) SHOULD be different
for each of the parallel searches.

Whilst performing a parallel search, different responses may result from
different servers, and it is important for the initiating client to han-
dle these responses correctly.  In general, the following rules apply:




Handley/Schulzrinne/Schooler                                   [Page 24]


INTERNET-DRAFT                                              2nd Dec 1996


+    If a 2xx response is received, the invitation was  successful,  the
     user  should  be  informed  and all pending requests should be ter-
     minated and/or ignored.

+    If a 4xx response  is  received  the  invitation  has  definitively
     failed,  the  user  should  be  informed,  and all pending requests
     should be terminated and/or ignored.

+    If a 3xx response is received, the search should be terminated  and
     all pending requests should be terminated and/or ignored.  However,
     further action MAY be taken depending on the actual  reply  without
     informing  the user or alternatively the invitation MAY be regarded
     as having failed in which case the user MUST be informed.

+    If a 5xx  or  6xx  response  is  received,  the  particular  server
     responding  is removed from the parallel search and the search con-
     tinues.  If a ``603 Alternative Address'' response is received, the
     search  may  be  expanded  to  include  those servers listed in the
     response that have not already responded.  The user SHOULD  NOT  be
     informed  unless  there  are no other servers left to try, in which
     case the user MUST be informed.

+    If a 1xx response is received, the search continues.  The user  MAY
     be informed as deemed appropriate.


8.3.  Parallel Searches: Proxy Behaviour

In the  same  way  that  an  Initiating  Client  can  discover  multiple
addresses  to  try,  a proxy server can also discover multiple addresses
that it may try.  For a proxy server to be stateless, it must  not  make
multiple  SIP requests because it would then be possible to return a 5xx
or 6xx response to the Initiating Client and afterwards obtain a defini-
tive answer.  To be able to make multiple parallel SIP requests, it must
keep state as to the replies it has already received and MUST NOT return
any  reply  other than 1xx informational replies until it has received a
definitive reply or has no further addresses to try.

Thus faced with DNS resolution giving multiple addresses, a proxy server
that  wishes to be stateless should only send a SIP request to the first
address.  Similarly a stateless proxy should not  attempt  to  send  SIP
request  to  multiple  addresses  given in a ``603 Alternative Address''
response that is returned it it, but should forward such a response back
towards the initiator.

Proxies that wish to  keep  state  should  follow  the  following  rules
regarding responses obtained during a parallel search:




Handley/Schulzrinne/Schooler                                   [Page 25]


INTERNET-DRAFT                                              2nd Dec 1996


+    If a 2xx response is received, the invitation was  successful,  the
     2xx  response  should  be forwarded back towards the initiator, and
     all pending requests should be terminated and/or ignored.

+    If a 4xx response  is  received  the  invitation  has  definitively
     failed,  the 4xx response should be forwarded back towards the ini-
     tiator, and  all  pending  requests  should  be  terminated  and/or
     ignored.

+    If a 3xx response is received the invitation  is  regarded  by  the
     proxy  as  having failed, the 3xx response should be forwarded back
     towards the initiator, the search  should  be  terminated  and  all
     pending requests should be terminated and/or ignored.

+    If a 5xx  or  6xx  response  is  received,  the  particular  server
     responding  is removed from the parallel search and the search con-
     tinues.  If a ``603 Alternative Address'' response is received, the
     search  may  be  expanded  to  include  those servers listed in the
     response that have not already responded.  No response other than a
     periodic  ``100 Trying'' resonse should be send towards the initia-
     tor unless there are no other servers left to try, in which case  a
     response SHOULD be sent as described below.

+    If a 1xx response is  received,  the  search  continues.   The  1xx
     response MAY be forwarded towards the initiator as appropriate.

If a proxy had exhausted its search and still not obtained a  definitive
response (it received only 1xx, 5xx, and 6xx responses) the proxy should
cache these responses and return the first response from  the  following
ordered list:


    1.- 503 Service Unavailable

    2.- 500 Server Internal Error

    3.- 501 Not Implemented

    4.- any other 5xx error not yet defined

    5.- 600 Search Failure

    6.- 602 Not Currently Here

    7.- 601 Not Known Here

    8.- any other 6xx error response not yet defined




Handley/Schulzrinne/Schooler                                   [Page 26]


INTERNET-DRAFT                                              2nd Dec 1996


If a proxy has exhausted  its  search  and  the  only  response  it  has
received  has  been  ``603  Alternative Address'', then the proxy should
send a ``600 Search Failure'' response if any connection  attempt  timed
out  or  failed,  or it should send ``602 Not Currently Here'' if two or
more ``603 Alternative Address'' responses only  provide  references  to
each other.


8.4.  Change of Transport at a Proxy

Editors note: this section is still incomplete.  Several  options  exist
for  where the responsibilty should lie for retransmissions from proxies
between TCP and UDP transport.  This  section  generally  assumes  local
retransmission,  but  end-to-end transmission through a chain of proxies
is also possible

It is possible that a proxy server will receiver a request using TCP and
relay  it  onwards using UDP or vice-versa.  SIP does not assume end-to-
end reliability even when the initiating client is using TCP, but a  SIP
client  sending  a request over TCP MAY assume that the request has been
received by the server it sent the request to.   Retransmission  of  the
request is then not the responsibility of the client.  However, a called
user agent SHOULD NOT assume  that  a  2xx  success  response  has  been
received by the invitation initiator, even if all the path fields in the
request indicated TCP transport because it cannot be certain  all  those
TCP  connections  still  exist.   If  the  called  user  agent  requires
knowledge that the response did reach the invitation initiator,  it  MAY
add  a  ``Confirm:required''  field  to  the  reply  as  it would if the
response was sent using UDP.

In the following, the term ``TCP->UDP proxy'' is used to  mean  a  proxy
that received a request using TCP and relayed it using UDP.  Similarly a
``TCP->UDP proxy'' receives a reply using UDP and should relay it  using
TCP.



8.4.1.  Retransmission from a TCP->UDP Proxy

A proxy receiving a request  with  TCP  transport  and  forwarding  that
request using UDP becomes responsible for restransmission of the request
as required and for timing out the request if no answer is forthcoming.


8.4.2.  Retransmissions arriving at a UDP->TCP Proxy

A proxy receiving a request using  UDP  transport  and  forwarding  that
request  using  TCP transport may have have SIP request state associated



Handley/Schulzrinne/Schooler                                   [Page 27]


INTERNET-DRAFT                                              2nd Dec 1996


with that TCP connection or SIP response state accociated with it.

If such a proxy receives a retransmission of the UDP request  whilst  in
the  state  or  awaiting a response (i.e, has  request state), it SHOULD
NOT forward the duplicate request into the  TCP  connection  unless  the
request  has been modified, but instead SHOULD respond with a ``100 Try-
ing'' response sent back towards the initiator.

Note: this behaviour is different from a UDP->UDP proxy which MUST  for-
ward the retransmitted request and MAY additionally respond with a ``100
Trying'' response sent back towards the initiator.

If such a proxy receives a retransmission of the UDP request in response
state  (i.e,  it  has already sent a definitive response) then the proxy
MAY retransmit that response if it has cached it.  Alternatively  if  it
has  not  cached  the  response,  it MAY re-send the request towards the
called user agent, either via an existing TCP connection if there is one
or  via a new TCP connection if there is not, to obtain a retransmission
of the response.  In the latter case, the proxy MAY additionally respond
with a ``100 Trying'' response sent back towards the initiator.

Note: this behaviour is the same as a UDP->UDP proxy in  the  same  cir-
cumstances.


8.4.3.  Confirmation arriving at a TCP->UDP Proxy

One possible event that may occur is that  whilst  performing  a  search
using UDP, a response may arrive that should be relayed back towards the
initiator using TCP, but the TCP connection has been terminated  by  the
initiator.   In  this  case  the  proxy  MUST  NOT  attempt to relay the
response (by opening a TCP connection) and  should  terminate  any  out-
standing search.  In this circumstance only, if the response was a ``200
OK'' response with a ``Confirm:required'' field, the proxy  MAY  re-send
the  request to the Contact Host with a ``Confirm:false'' field to speed
hang-up discovery at the called user agent.


8.4.4.  Confirmation sent from a UDP->TCP Proxy

Normally a response that arrives at a proxy using  TCP  that  should  be
sent  back  towards  the  initiator  using  UDP should be sent once, and
should only be re-sent if the request is  re-sent  from  the  UDP  proxy
closer to the initiator.  However, this does not allow for reliable con-
firmation.






Handley/Schulzrinne/Schooler                                   [Page 28]


INTERNET-DRAFT                                              2nd Dec 1996


9.  Security Considerations

TBD


Acknowledgments

We wish to thank the members of the IETF MMUSIC WG  for  their  comments
and suggestions.


Authors' Addresses

Mark Handley
USC Information Sciences Institute
c/o MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, USA
electronic mail: mjh@isi.edu

Henning Schulzrinne
Dept of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, MY 10027, USA
electronic mail: schulzrinne@cs.columbia.edu

Eve Schooler
Computer Science Department 256-80
California Institute of Technology
Pasadena, CA 91125. USA.
electronic mail: schooler@cs.caltech.edu



References

[1]  M. Handley,  V.  Jacobson  ``SDP:  Session  Description  Protocol''
     Internet Draft  draft-ietf-mmusic-sdp-03.txt, Work in Progress, Nov
     1996.

[2]  M. Handley, ``SAP: Session Announcement Protocol''  Internet  Draft
     draft-ietf-mmusic-sap-01.txt, Work in Progress, Nov 1996.

[3]  Schooler, E.M., ``Case Study: Multimedia Conference  Control  in  a
     Packet-switched  Teleconferencing System'' Journal of Internetwork-
     ing: Research and Experience, Vol.4, No.2,  pp.99-120,  June  1993;
     also  available as an ISI technical report ISI/RS-93-359, Aug 1993.



Handley/Schulzrinne/Schooler                                   [Page 29]


INTERNET-DRAFT                                              2nd Dec 1996


     ftp://ftp.isi.edu/pub/hpcc-papers/mmc/joi.ps

[4]  A. Gulbrandsen, P. Vixie, ``A DNS RR for specifying the location of
     services''  Internet  Draft  draft-gulbrandsen-dns-rr-srvcs-02.txt,
     Work in Progress, Jan 1996.














































Handley/Schulzrinne/Schooler                                   [Page 30]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/