Internet Draft                                            Steve Donovan
draft-ietf-sip-info-method-00.txt                          MCI Worldcom
October 1999


                          The SIP INFO Method

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents 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 mate-
   rial or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document proposes an extension to the Session Initiation Proto-
   col.  This extension adds the INFO method to the SIP protocol.  The
   intent of the INFO method is to allow for the carrying of session
   related control information that is generated during a session.  One
   example of such session control information is ISUP and ISDN signal-
   ing messages used to control telephony calls services.

   Other example uses of the INFO method include the carrying of encoded
   DTMF digits and the reporting of signal strength in a wireless mobil-
   ity application.














Donovan             draft-ietf-sip-info-method-00.txt             Page 1

Internet Draft             The SIP INFO Method              October 1999

1 Introduction

   The SIP protocol defined in [1] defines session control messages used
   during the setup and tear down stages of a SIP controlled session.

   In addition, the SIP re-INVITE can be used during a session to change
   the characteristics of the session.  This is generally to change the
   properties of media flows related to the session or to update the
   session timer as defined in [2].

   However, there is no general-purpose mechanism to carry session con-
   trol information along the SIP signaling path during the session.

   It is necessary for the mid-session signaling information traverse
   the post session setup SIP signaling path.  This is the path taken by
   SIP re-INVITEs, BYEs and other SIP requests sent that are tied to an
   individual session. This will allow SIP proxy servers to receive the
   mid-session signaling information.

   1.1 Example Uses

   One example of mid-session control information that will need to be
   carried between SIP user agents is PSTN mid-call signaling messages.
   These messages exist for both SS7 based ISUP signaling and ISDN DSS1
   based signaling.  This example is explained in more detail in a fol-
   lowing section of this document.

   A second type of session control information that needs to be carried
   during a session is DTMF or dial plus (referred to from here on as
   DTMF) digits.  There are various telephony services implemented today
   that require the use of DTMF digits.  Due to the design of these fea-
   tures, the DTMF information needs to be carried both as part of the
   media stream (in the RTP flow) and as part of the signaling or con-
   trol path.  This is due to the fact that there is an implicit separa-
   tion of the media and control path in the SIP protocol.  Thus, SIP
   Proxy Servers that implement services that require DTMF based control
   and that are not in the media path require a mechanism to be notified
   of when DTMF digits are entered by one of the user agents.

   Another hypothetical use of mid-session control is the use of SIP to
   support wireless mobility applications.  In this scenario it can be
   envisioned that mid-session messages would be sent to a control
   entity to report on the signal strength for a wireless handset from
   various base stations.  The control entity would then use this infor-
   mation to control handoffs between the base stations.

   It can also be envisioned that the INFO method could be used for a
   UAS (either the called user agent of an intermediary server) to
   update the calling user on account status.  For instance, the called
   user agent could communicate through the INFO method the message that
   the user's credit is about to expire.  This could be via a text mes-
   sage body attached to the INFO message.  The use of the SIP INFO

Donovan             draft-ietf-sip-info-method-00.txt             Page 2

Internet Draft             The SIP INFO Method              October 1999

   method for this type of communication would allow the calling user
   agents IP address information to remain hidden from the UAS (assuming
   that an intermediary element is performing an address translation
   function for the calling user agent).

   If the contents of the message body are private then end-to-end
   encryption of the message body can be used to prevent intermediary
   proxy servers from seeing the content.

   It can also be envisioned that there will be other telephony and non-
   telephony uses of the INFO method.

   This document proposes the addition of the INFO Request method to the
   SIP specification to be used for carrying of mid-session information
   along the session signaling path.

2 Mid Call Telephony Signaling Messages

   One use for the INFO method is to carry mid call signaling informa-
   tion resulting from the interworking between an ISUP or ISDN net-
   work/device and a SIP controlled network.

   One specific example of this interworking is when the SIP controlled
   network is used for transport between two PSTN locations.  For this
   type of call, there will be a PSTN leg from the calling party to the
   SIP network, a SIP leg through the SIP network and a PSTN leg from
   the SIP network to the called party.  There needs to be a method to
   carry mid-call PSTN signaling from the originating PSTN network,
   through the SIP network, to the destination PSTN network.

2.1 ISUP Messages

   The following is a partial list of the mid-call ISUP messages:




















Donovan             draft-ietf-sip-info-method-00.txt             Page 3

Internet Draft             The SIP INFO Method              October 1999

         Full Message Name         Abbreviated  ISUP Type
                                      Name
         ------------------------------------------------
         Facility Accepted            FAA       ANSI/ITU
         Facility Reject              FRJ       ANSI/ITU
         Facility Request             FAR       ANSI/ITU
         Forward Transfer             FOT       ANSI/ITU
         Identification Request       IDR       ITU
         Identification Response      IDF       ITU
         Facility Deactivated         FAD       ANSI
         Facility Information         FAI       ANSI
         Facility                     FAC       ANSI/ITU
         Information                  INF       ANSI/ITU
         Information Request          INR       ANSI/ITU
         Pass Along Message           PAM       ANSI/ITU
         Suspend                      SUS       ANSI/ITU
         Resume                       RES       ANSI/ITU
         User-to-User Information     USR       ANSI/ITU


2.2 Example PSTN Call Flow

   The following is an example call flow showing PSTN mid-call signaling
   messages.

        Orig PSTN    Dest PSTN
             ------------>
             IAM

             <-----------
             ACM

             <-----------
             ANM

             ------------>
             USR

             <-----------
             USR

             ------------>
             REL

             <-----------
             REL

   3 Implementation Alternatives

   This section outlines alternatives that have been proposed for the
   carrying of mid-session signaling information.  This includes using a
   re-INVITE, using the SIGTRAN defined protocol and using the INFO

Donovan             draft-ietf-sip-info-method-00.txt             Page 4

Internet Draft             The SIP INFO Method              October 1999

   method.

3.1 Re-INVITE

   One method for addressing the requirement to carry mid-session sig-
   naling information is to carry this information in an INVITE message
   that contains the same call identification information.  This is
   referred to as a re-INVITE.  This method is currently used to commu-
   nicate changes to an existing SIP session, for instance to change the
   codec used for a voice media stream or the updating of the session
   timer.

   While this would work for mid-session signaling, it has the problem
   that it further overloads the INVITE method.  In addition, the cur-
   rent re-INVITE is used to communication a desired change in the ses-
   sion.  Mid-session signaling information will generally not be used
   to make changes to the SIP session, especially if the information
   carried is ISUP or other PSTN signaling messages.

3.2 Sigtran

   There is work currently under way in the SIGTRAN working group to
   define a protocol for the reliable transport of PSTN signaling mes-
   sages.  This would include carrying of the ISUP protocol over an IP
   network.

   One proposal would be to establish a SIGTRAN relationship for the
   transport of mid-session signaling information.  It could be envi-
   sioned that the SIGTRAN session setup could be achieved by adding a
   SIGTRAN session description message body to the SIP INVITE and 200 OK
   messages.

   The primary drawback of this approach is that the SIGTRAN session
   would be between user agents (i.e.; between the ingress PSTN gateway
   and the egress PSTN gateway). As a result, proxy servers involved in
   setting up the session would not be able to receive any user agent to
   user agent SIGTRAN mid-session signaling information.

   A second objection to this approach is that it assumes that all of
   the mid-session information to be carried is telephony signaling
   information.  This is a limiting assumption as there are non-tele-
   phony uses of mid-session signaling.

   A further drawback to this approach is the complexity that it would
   put on user agents. User agents would need to setup and manage two
   signaling relationships for every session.  In addition, if the user
   agent were a PSTN gateway, then it would need to build PSTN signaling
   messages based on both SIP and SIGTRAN messages received.

3.3 INFO



Donovan             draft-ietf-sip-info-method-00.txt             Page 5

Internet Draft             The SIP INFO Method              October 1999

   The mechanism proposed in this draft is to add a new method to the
   SIP protocol.  This method, called the INFO method, would be used to
   carry any mid-session signaling information along the SIP signaling
   path, between the calling and called user agents.

3.3.1 Example PSTN Call Flow with the INFO message.

   The following is an example call flow showing the use of INFO message
   for carrying PSTN mid-call signaling messages.

        Orig PSTN    Ingress GW   SIP Server   Egress GW    Dest PSTN
                        GW1          SPS          GW2
             ------------>------------>------------>------------>
             IAM          Invite       Invite       IAM

             <-----------<------------<------------<------------
             ACM          180 Ringing  180 Ringing  ACM

             <-----------<------------<------------<------------
             ANM          200 OK       200 OK       ANM

                          ------------>------------>
                          ACK          ACK

             <-----------<------------<------------<------------
             USR          INFO         INFO         USR
                          ISUP MIME    ISUP MIME
                          USR          USR

                          ------------>------------>
                          200 OK       200 OK

             ------------>------------>------------>------------>
             USR          INFO         INFO         USR
                          ISUP MIME    ISUP MIME
                          USR          USR

                         <------------<------------
                          200 OK       200 OK

             <-----------<------------<------------<------------
             REL          BYE          BYE          REL

                                                    ------------>
                                                    RLC

                          ------------>------------>
                          200 OK       200 OK

             ------------>
             RLC


Donovan             draft-ietf-sip-info-method-00.txt             Page 6

Internet Draft             The SIP INFO Method              October 1999

4 INFO Method

   The INFO method is used for communicating mid-session signaling
   information along the signaling path for the session.  The signaling
   path for the INFO method is the signaling path established as a
   result of the session setup.  This can be either direct signaling
   between the calling and called user agents or a signaling path
   involving SIP proxy servers that were involved in the session setup
   and added themselves to the Record-Route header on the initial INVITE
   message.

   The mid-session control information can be communicated in either an
   INFO message header or as part of an attachment.  The definition of
   the attachments used to carry the mid-session information is outside
   the scope of this document.

4.1 Header Field Support for INFO Method

   The following table is an extension of tables 4 and 5 in the [1].
   Refer to Section 6 of [1] for a description of the content of the
   table.

        Header                    Where    INFO
        ------                    -----    ----
        Accept                      R       -
        Accept-Encoding             R       -
        Accept-Language             R       o
        Allow                      200      -
        Allow                      405      o
        Authorization               R       o
        Call-ID                    gc       m
        Contact                     R       -
        Contact                    1xx      -
        Contact                    2xx      -
        Contact                    3xx      -
        Contact                    485      -
        Content-Encoding            e       o
        Content-Length              e       o
        Content-Type                e       *
        CSeq                       gc       m
        Date                        g       o
        Encryption                  g       o
        Expires                     g       -
        From                       gc       m
        Hide                        R       o
        Max-Forwards                R       o
        Organization                g       o






Donovan             draft-ietf-sip-info-method-00.txt             Page 7

Internet Draft             The SIP INFO Method              October 1999

        Header                    Where    INFO
        ------                    -----    ----
        Priority                    R       o
        Proxy-Authenticate         407      o
        Proxy-Authorization         R       o
        Proxy-Require               R       o
        Require                     R       o
        Retry-After                 R       -
        Retry-After            404,480,486  o
        Retry-After                503      o
        Retry-After              600,603    o
        Response-Key                R       o
        Record-Route                R       o
        Record-Route               2xx      o
        Route                       R       o
        Server                      r       o
        Subject                     R       -
        Timestamp                   g       o
        To                        gc(1)     m
        Unsupported                420      o
        User-Agent                  g       o
        Via                       gc(2)     m
        Warning                     r       o
        WWW-Authenticate           401      o


4.2 Responses to the INFO Request Method

   A 200 OK response shall be sent if the INFO request was successfully
   received.

   A 481 Call Leg/Transaction Does Not Exist shall be sent if the INFO
   request does not match any existing call leg.

   Other request failure (4xx), Server Failure (5xx) and Global Failure
   (6xx) responses can also be sent for the INFO Request.

4.3 Message Body Inclusion

   The INFO request may contain a message body.

4.4 Behavior of SIP User Agents

   Unless stated otherwise, the protocol rules defined in [1] for the
   BYE request shall apply to the INFO request.

   However, the INFO message shall not change the state of the session.

4.5 Behavior of SIP Proxy and Redirect Servers

4.5.1 Proxy Server


Donovan             draft-ietf-sip-info-method-00.txt             Page 8

Internet Draft             The SIP INFO Method              October 1999

   Unless stated otherwise, the protocol rules defined in [1] for the
   BYE request shall apply to the INFO request.

   However, the INFO message shall not change the state of the session.

4.5.2 Forking Proxy Server

   Unless stated otherwise, the protocol rules defined in [1] for the
   BYE request shall apply to the INFO request.

   However, the INFO message shall not change the state of the session.

4.5.3 Redirection Server

   A redirection server should not receive the INFO method, as it is a
   part of the signaling path only at the initiation of the session.  As
   such, a redirection server should send a 403 Forbidden response to an
   INFO message.

4.6 Security Considerations

   There are no security issues specific to the INFO method.  The secu-
   rity requirements specified in the SIP specification apply to the
   INFO method.

5.0 INFO Message Bodies

   The purpose of the INFO message is to carry mid-session information
   between SIP user agents.  This information will generally be carried
   in message bodies, although it can be carried in headers in the INFO
   message.

   The definition of the message bodies or any new headers created for
   the INFO method is outside the scope of this document.  It is
   expected that separate documents will be created to address defini-
   tion of these entities.

   In addition, the INFO method does not add to the mechanisms of the
   SIP protocol for ensuring in-order delivery of mid-session signaling
   information.  While the CSeq header will be incremented upon the
   transmission of new INFO messages, this should not be used to deter-
   mine the sequence of INFO information.  This is due to the fact that
   there could be gaps in the INFO message CSeq count caused by a user
   agent sending re-INVITES or other SIP messages.  5.0 References

[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   Session Initiation Protocol", RFC 2543, March 1999.

[2] S. Donovan, "SIP Session Timer", Internet Draft, Internet Engineer-
   ing Task Force, October, 1999.  Work in Progress.



Donovan             draft-ietf-sip-info-method-00.txt             Page 9

Internet Draft             The SIP INFO Method              October 1999

6.0 Author's Address

   Steve Donovan
   MCI Worldcom
   1493/678
   901 International Parkway
   Richardson, Texas 75081
   Email: steven.r.donovan@wcom.com













































Donovan             draft-ietf-sip-info-method-00.txt            Page 10