Internet Engineering Task Force                        Steven R. Draft                                            Steve Donovan
draft-ietf-mmusic-sip-info-method-01.txt                    Matt Cannon
June 1999                                                  MCI Worldcom
February 8, 1999                                  Expires August 8, 1999

                          The SIP INFO Method

Status of this document Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. 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 material mate-
   rial or to cite them other than as "work in progress."

To view the entire

   The list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories on (Africa), (Northern Europe), (Southern Europe), (Pacific Rim), (US East Coast), or (US West Coast). can be accessed at


   This document proposes an extension to the Session Initiation Protocol. 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.  Examples  One
   example of such session control information are ISUP/ISDN signaling messages is ISUP and DTMF digits ISDN signal-
   ing messages used to control telephony calls services.

Internet draft

   Another example might include reporting of signal strength in a wire-
   less mobility application.

1 Introduction

   The SIP INFO Method            February 8, 1999

1.0 Introduction

There are situations where protocol handles the transport of session related control information needs to
be sent
   during the setup and tear down stages of a SIP controlled session.  This

   While SIP re-INVITEs can be used during a session to change the char-
   acteristics of the session (generally to change the properties of
   media flows related to the session), there is no general purpose
   mechanism to carry session control information during the session.

   Although it is separate from true that users and/or user agents involved in the media
   session can communicate directly during the session, this does not
   ensure that SIP proxy servers that are involved in the setup and tear
   down of the session will also be involved in the exchange of mid-
   session control information.

   One good example of mid-session control information that will need to
   be carried between SIP user agents is being exchanged as part PSTN mid-call signaling mes-
   sages.  These messages exist for both SS7 based ISUP signaling and
   ISDN DSS1 based signaling.

   Another hypothetical use of mid-session control is the session.

Two examples use of SIP to
   support wireless mobility applications.  In this are motivated by telephony related services:

1 - Mid Call Telephony Signaling Messages
2 - DTMF Digit/Dial Plus Control of Telephony Services 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 there will be non telephony inspired
   uses of a mechanism for relaying mid session information between
participants par-
   ticipants of the session and to Proxy Servers interested in the
session. ses-

   This document proposes the addition of the INFO Request method to the
   SIP specification.

1.1 specification to be used for carrying of mid session information
   along the session signaling path.

2 Mid Call Telephony Signaling Messages

The first

   One use for the INFO method is the need to carry mid call signaling
   information resulting from the interworking between an ISUP or ISDN
   network/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 mid-call PSTN signaling that is originated by from the calling party originating PSTN network,
   through the SIP network to the called party.

1.2 DTMF Digit/Dial Plus Control of Telephony Services destination PSTN network.

2.1 ISUP Messages

   The second type of telephony session control information that needs to
be carried during a session following is DTMF or dial plus (refered to from here
on as DTMF) generated information.  There are various telephony services
implemented today which require the use of DTMF digits.  Due to the
design of these features, the DTMF information needs to be carried both
as part of the media stream (in the RTP flow) and as part a partial list of the
signaling or control path.  This is due to the fact that there mid-call ISUP messages:

         Full Message Name         Abbreviated  ISUP Type
         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
implicit separation of the media and control path in the SIP protocol.
Thus, SIP Proxy Servers that implement services that require DTMF
control and that are not in example call flow showing the media path require a mechanism to be
notified use of the DTMF digits.

Internet draft           The INFO message
   for carrying PSTN mid-call signaling messages.

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

             ANM          200 OK       200 OK       ANM

                          ACK SPS1     ACK SPS3

             USR          INFO Method            February 8, 1999

2.0         INFO         USR
                          ISUP MIME    ISUP MIME
                          USR          USR

             USR          INFO         INFO         USR
                          ISUP MIME    ISUP MIME
                          USR          USR

             REL          BYE          BYE          REL

             RLC          200 OK       200 OK       RLC

3 INFO Method

   The INFO method is used for communicating mid-session control
information infor-
   mation 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 agent 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.

   If the control information is telephony signaling information than then
   the signaling message would shall be carried as part of an ISUP attachment
   to the INFO message as described in draft-ietf-sigtran-mime-isup-00.txt.

The method for carrying the DTMF information in the INFO message has
not yet been defined and is outside the scope of this document. draft-ietf-sigtran-mime-

2.1 Header Field Support for INFO Method

   The following table is an extension of tables 4 and 5 in the SIP
   specification.  Refer to Section 6 of the SIP Specification 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

Internet draft           The SIP INFO Method            February 8, 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

2.2 Responses to the INFO Request Method

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

Request Failure

   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.

2.3 Message Body Inclusion

   The INFO request may contain a message body.

2.4 Behavior of SIP User Agents

   The protocol rules applied by the SIP User Agent shall be similar to
   those applied used for the BYE request.  However, the INFO message shall
shall not
   change the state of the session.

2.5 Behavior of SIP Proxy and Redirect Servers

2.5.1 Proxy Server

   The protocol rules applied by the SIP Proxy Server shall be similar
   to those applied used for the BYE request.  However, the INFO message
shall not change the state of the session.

Internet draft           The SIP INFO Method            February 8, 1999

2.5.2 Forking Proxy Server

   The protocol rules applied by the SIP Forking Proxy Server shall be
   similar to those applied used for the BYE request.  However, the INFO
   message shall shall not change the state of the session.

2.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.

2.6 Security Considerations

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

3.0 References

[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   Session Initiation Protocol", Internet Draft, Internet
    Engineering Task Force, January 15, RFC 2543, March 1999.  Work in progress.

[2] C. Huitema, "The multipart/sip-id media type", Internet Draft,
   Internet Engineering Task Force, February 5, 1999.  Work in Progress

4.0 Author's Address

   Steve Donovan
   MCI Worldcom
   901 International Parkway
   Richardson, Texas 75081

   Matthew Cannon
   MCI Worldcom
   2400 North Glenville Drive
   Richardson, Texas 75082