draft-donovan-mmusic-183


HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:37:46 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 22 Jun 1999 17:09:34 GMT
ETag: "2e6ef7-70ea-376fc34e"
Accept-Ranges: bytes
Content-Length: 28906
Connection: close
Content-Type: text/plain

Internet Engineering Task Force                           Steve Donovan
Internet Draft                                              John Hearty
draft-donovan-mmusic-183-00.txt                             Matt Cannon
                                                           MCI Worldcom
                                                    Henning Schulzrinne
                                                    Columbia University
June, 1999                                           Jonathan Rosenberg
Expires: December, 1999                               Bell Laboratories


                    SIP 183 Session Progress Message

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 describes a proposed extension of the Session Initia-
   tion Protocol.  This extension would add the 183 Session Progress
   response message.

   The introduction of the 183 informational response message would
   allow a called user agent to indicate to the calling user agent
   whether or not the calling user agent should apply local alerting for
   the session.  The existing 180 Ringing message would indicate that
   the calling user agent has the option of providing local alerting
   (and generally should).  The 183 Session Progress message would indi-
   cate that the calling user agent should not provide local alerting
   and should establish a media session to be used by the called user
   agent to indicate the status of the session setup request as part of
   the indicated media stream.






Donovan, et al.      draft-donovan-mmusic-183-00.txt              Page 1

Internet Draft      SIP 183 Session Progress Message           June 1999

1 Introduction

   There are instances, most notably dealing with SIP to PSTN interwork-
   ing, that necessitate that the SIP called User Agent (UA) be able to
   suppress local alerting by the SIP calling UA and to set up a prelim-
   inary media session from the called UA to the calling UA.  This would
   allow the called UA to play back media prior to the full SIP session
   being set up.  This media would be used to report on the status of
   the session setup request.  It could also be used to play music while
   the session setup is attempted.  This would be useful for find-me
   like services that involve attempting multiple locations for a single
   setup request.

   The only method in the current SIP specification that allows the
   called UA to playback media would be to set up a full SIP session. In
   PSTN interworking situations (and likely in end-to-end SIP sessions)
   this will cause a billing relationship to be established between net-
   works for the session.  This causes a problem when the reason for
   setting up the media session is to indicate a failure in the session
   setup.

   This document proposes an extension to the Session Initiation Proto-
   col (SIP) that introduces this capability.

2 PSTN Interworking Issues

   In the PSTN today there are times when a media (voice) path is set up
   from the called party to the calling party in order to play a treat-
   ment (a special tone or announcement).  The treatment can range from
   alerting (ring back) to busy tones to announcements explaining why
   the call could not be set up.  The participants in this call are not
   charged for the remote treatment portion of the call.

   This one way voice path is generally set up as part of the processing
   of the SS#7 ISUP ACM message.



















Donovan, et al.      draft-donovan-mmusic-183-00.txt              Page 2

Internet Draft      SIP 183 Session Progress Message           June 1999

   The following call flow illustrates call setup using SS7 ISUP in a
   PSTN network.

           Originating              Terminating
           Network                  Network
              IAM---------------------->

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

              <=========================
                  One way voice path

            * <----------------------ANM

              <========================>
                  Two way voice path

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

              <----------------------RLC


*  If the originating network is a Local Exchange Carrier and the termi-
   nating network is an Interexchange Carrier then the LEC will start
   charging for the call at this point in the call.

   The following call flow illustrates the setup of a call that does not
   result in a completed call but does involve a media path being set
   up.  In this case, the terminating network may be playing a busy sig-
   nal or playing an announcement.  The following are examples of
   announcements that might be played in this scenario:

   - The number you have dialed is no longer valid.

   - The wireless subscriber you are calling is not currently reachable.

           Originating              Terminating
           Network                  Network
              IAM---------------------->

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

              <=========================
                  One way voice path

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

              <----------------------RLC






Donovan, et al.      draft-donovan-mmusic-183-00.txt              Page 3

Internet Draft      SIP 183 Session Progress Message           June 1999

2.1 PSTN to SIP Network Interworking Requirements

   The following are a subset of the requirements for interworking
   between a PSTN network and a SIP network.

   When the SIP network is in the middle of two PSTN networks, it must
   support the following:

   - The ingress gateway into the SIP network shall have the ability to
   determine, based on SIP signaling messages, when to send an ISUP ACM
   message and when to send an ISUP ANM message.

   - The SIP network shall have the ability to support fast setup. This
   occurs when the terminating network does not send an ACM prior to
   sending an ANM.

   - The SIP network shall support the ability to cut through a voice
   path from the terminating PSTN network to the originating PSTN net-
   work without the interim SIP network incurring charges from the orig-
   inating network.

   The SIP network shall support the ability to place calls to a PSTN
   network without the egress gateway knowing what type of device the
   call was originated from.  Thus, the egress gateway shall not need to
   behave differently when the call originates from a PSTN network then
   when the call originates from a native IP SIP device.

   The following is an illustration of the two scenarios that must be
   supported:


       +-------------+             +---------+              +-------------+
       | Originating |   +-----+   | SIP     |   +-----+    | Terminating |
       | PSTN        |-->| IGW |-->| Network |-->| EGW |--->| PSTN        |
       | Network     |   +-----+   |         |   +-----+    | Network     |
       +-------------+             +---------+              +-------------+

        IGW = Ingress Gateway
        EGW = Egress Gateway

                                   +---------+              +-------------+
                                   | SIP     |   +-----+    | Terminating |
                                   | IP      |-->| EGW |--->| PSTN        |
                                   | Device  |   +-----+    | Network     |
                                   +---------+              +-------------+


3.0 Options With Existing SIP Specification

   The following sections show the results of investigating various
   options for addressing the above requirements using existing SIP pro-
   tocol capabilities.  In each case, it is shown why the option either
   cannot address the requirements or has short comings that can be

Donovan, et al.      draft-donovan-mmusic-183-00.txt              Page 4

Internet Draft      SIP 183 Session Progress Message           June 1999

   better addressed using the 183 Session Progress message.

3.1 100 Trying Mapped to ACM

   The first option investigated involved mapping the 100 Trying message
   to the ACM message.

   The following call flow illustrates this option.

           Originating  Ingress      Egress     Terminating
           Network      SIP GW       SIP GW      Network
               ------------>------------>----------->
               IAM          INVITE       IAM

               <-----------<------------<------------
               ACM          100 Trying   ACM

               <===========             <============
               One way voice            One way voice


   The call flow breaks at this point for two reasons.  First, at this
   point in the call flow a one way voice path is needed so that the
   terminating network can provide session setup status as part of the
   voice path.  The 100 Trying does not cause a voice path cut-through
   between the ingress and egress gateways.  This potentially could be
   addressed by allowing the 100 Trying to carry SDP information to be
   used for carrying the preliminary session media.  This option is
   explored in the context of the 180 Ringing message in section 3.3.

   The use of the 100 Trying also fails because a SIP Proxy Server sit-
   ting in the signaling path between the ingress gateway and the egress
   gateway might have generated the 100 Trying message, causing the ACM
   message to be sent prior to the egress gateway receiving an ACM from
   the terminating network.

3.2 180 Ringing Mapped to ACM

   The second option investigated was to use a 180 Ringing message to
   trigger the ACM message at the ingress gateway.

   This option is illustrated in the following call flow:












Donovan, et al.      draft-donovan-mmusic-183-00.txt              Page 5

Internet Draft      SIP 183 Session Progress Message           June 1999

           Originating  Ingress      Egress     Terminating
           Network      SIP GW       SIP GW      Network
               ------------>------------>----------->
               IAM          INVITE       IAM

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

               <===========             <============
               One way voice            One way voice


   This option breaks at this point because a media voice path cannot be
   cut through at this point for the terminating PSTN network to report
   on the session progress.  This is due to the fact that the egress
   gateway has not yet communicated its RTP information to the ingress
   gateway.  The next two options attempt to address this issue.

3.3 180 With SDP Mapped to ACM

   The next option investigated involves using the presence of SDP in
   the 180 Ringing message to indicate that session progress will be
   communicated by the called user agent using the media stream.  In
   this case, absence of the SDP message body would indicate that local
   alerting should take place.

   The following call flow illustrates this option:



























Donovan, et al.      draft-donovan-mmusic-183-00.txt              Page 6

Internet Draft      SIP 183 Session Progress Message           June 1999

           Originating  Ingress      Egress     Terminating
           Network      SIP GW       SIP GW      Network
               ------------>------------>----------->
               IAM          INVITE       IAM

               <-----------<------------<------------
               ACM          180 Ringing  ACM
                            One way SDP

                           <============
                         One way voice path

               <-----------<------------<------------
               ANM          200 OK       ANM
                            Two way SDP

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

               <====================================>
                         Two Way Voice Path

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

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


   Although this option looks promising on first review, it does not
   give the called user agent the ability to include SDP in the message
   and rely on the calling user agent (the ingress gateway in this sce-
   nario) to provide local alerting.  As illustrated in [2] there are
   other reasons that SDP might be included in a 180 Ringing message.
   Thus the user requiring a coupling of SIP and QOS signaling, which
   requires inclusion of SDP in the 18x message, could not also request
   local alerting.

3.4 200 OK Mapped to ACM

   The final option investigated involves setting up a full media ses-
   sion in the SIP network prior to receiving the ANM from the terminat-
   ing PSTN network.  This involves mapping the 200 OK to the ACM mes-
   sage at the ingress gateway and having the egress gateway send a re-
   INVITE upon receipt of the ANM.  The ingress gateway would use the
   re-INVITE to trigger the ANM message.

   This option is illustrated in the following call flow:






Donovan, et al.      draft-donovan-mmusic-183-00.txt              Page 7

Internet Draft      SIP 183 Session Progress Message           June 1999

           Originating  Ingress      Egress     Terminating
           Network      SIP GW       SIP GW      Network
               ------------>------------>----------->
               IAM          INVITE       IAM

               <-----------<------------<------------
               ACM          200 OK       ACM
                            One way SDP

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

                            <============
                          One way voice path

               <-----------<------------<------------
               ANM          INVITE       ANM

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

                           <------------
                            ACK

               <====================================>
                         Two Way Voice Path

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

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






















Donovan, et al.      draft-donovan-mmusic-183-00.txt              Page 8

Internet Draft      SIP 183 Session Progress Message           June 1999

Although this will work in the above scenario, it introduces additional
messaging overhead.  In addition, as illustrated in the following fast
answer call flow, it is at best awkward and may result in clipping off
of the beginning of the voice call.

        Originating  Ingress      Egress     Terminating
        Network      SIP GW       SIP GW      Network
            ------------>------------>----------->
            IAM          INVITE       IAM

            <-----------<------------<------------
            ACM          200 OK       ANM
                         One way SDP

            <-----------<------------
            ANM          INVITE
                         Two way SDP

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

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

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

            <====================================>
                      Two Way Voice Path

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

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



















Donovan, et al.      draft-donovan-mmusic-183-00.txt              Page 9

Internet Draft      SIP 183 Session Progress Message           June 1999

4 Proposed 183 Session Progress

   The following session signaling flows show the proposed solution
   using the 183 Session Progress Message to map to the ISUP ACM message
   and how the 183 Session Progress message is used for when the call
   originates from a SIP IP Device.

4.1 PSTN to SIP to PSTN Session Using 183 Session Progress

   The following session signaling flow shows the use of the 183 Session
   Progress message for a session setup in a SIP based network when the
   session will be between two PSTN networks.

           Originating  Ingress      Egress     Terminating
           Network      SIP GW       SIP GW      Network
               ------------>------------>----------->
               IAM          INVITE       IAM

               <-----------<------------<------------
               ACM          183 Session  ACM
                                Progress
                            One way SDP

                           <============
                         One way voice path

               <-----------<------------<------------
               ANM          200 OK       ANM
                            Two way SDP

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

               <====================================>
                         Two Way Voice Path

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

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













Donovan, et al.      draft-donovan-mmusic-183-00.txt             Page 10

Internet Draft      SIP 183 Session Progress Message           June 1999

4.2 PSTN Fast Answer

   The following session signaling flow shows the method for handling of
   the fast answer scenario.  Note that in this case the 183 Session
   Progress message is not used, as the ANM is mapped directly to a 200
   OK.  This meets the requirement that the SIP gateways must be able to
   differentiate between ACM and ANM messages.

           Originating  Ingress      Egress     Terminating
           Network      SIP GW       SIP GW      Network
               ------------>------------>----------->
               IAM          INVITE       IAM

               <-----------<------------<------------
               ANM          200 OK       ANM
                            Two way SDP

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

               <====================================>
                         Two Way Voice Path

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

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


























Donovan, et al.      draft-donovan-mmusic-183-00.txt             Page 11

Internet Draft      SIP 183 Session Progress Message           June 1999

4.3 SIP to PSTN Session Using 183 Session Progress

   The following session signaling flow shows the use of the 183 Session
   Progress message for a session setup in a SIP based network when the
   session originates in the SIP network and terminates to a PSTN net-
   work.

           Calling       Egress    Terminating
              UA         SIP GW      Network
               ------------>------------>
               INVITE       IAM

               <-----------
               100 Trying

               <-----------<------------
               183 Session  ACM
                   Progress
               One way SDP

               <========================
                   One way voice path

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

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

               <========================
                   Two Way Voice Path

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

               ------------>------------>

               200 OK       RLC


5 Proposed Extensions to the SIP Specification

   The remainder of the document describes the proposed extensions to
   the SIP specification.  The section number indicates the section of
   the SIP specification that requires modification.  Thus section 5.M.N
   would include proposed modifications to section M.N of the SIP speci-
   fication.

   Absence of a section indicates that no modifications are proposed for
   that section.

5.7 Status Code Definitions


Donovan, et al.      draft-donovan-mmusic-183-00.txt             Page 12

Internet Draft      SIP 183 Session Progress Message           June 1999

5.7.1 Informational 1xx

5.7.1.2 180 Ringing

   The following text is proposed to be added to the description of the
   180 Ringing message:

   The calling UA should initiate local alerting (for instance, the
   playing of a ringing tone or other alerting mechanism) so as to indi-
   cate the progress of the session setup.

5.7.1.5 183 Session Progress

   The called UA has the need to communicate the status of the session
   setup attempt as part of a media stream.  The calling UA shall estab-
   lish a media session according to the contents of the session
   description contained in the 183 message.  The calling UA should not
   apply local alerting that would interfere with the media session
   information supplied by the called UA.

   The 183 message SHOULD include enough session description information
   to allow for a media session between the called UA and the calling
   UA.

   Although not strictly required for a one way voice path to be setup
   between the egress gateway and the ingress gateway, the SDP in the
   183 has the following benefits:

   1. The list of audio (or video) codecs is reduced, so the calling
   gateway need only expect a smaller set.

   2. The 183 can contain security preconditions in the SDP (if they
   were in the SDP in the INVITE), so that the calling gateway can per-
   form appropriate authentication/encryption for each media stream from
   each egress gateway.

   3. If any kind of pre-call announcement requires two-way media (per-
   haps some kind of speech recognition for credit card numbers, or even
   DTMF too), the SDP in the 183 is needed.

5.8 SIP Message Body

5.8.1 Body Inclusion

   The following is proposed rewording of paragraph 2 in Section 8.1 of
   the SIP specification:

   For response messages, the request method and the response status
   code determine the type and interpretation of any message body.  All
   responses MAY include a body.  Message bodies for 1xx responses con-
   tain advisory information about the progress of the request.  In
   addition, message bodies for 1xx responses can contain session
   descriptions.  2xx responses ...

Donovan, et al.      draft-donovan-mmusic-183-00.txt             Page 13

Internet Draft      SIP 183 Session Progress Message           June 1999

5.10 Behavior of SIP Clients and Servers

5.10.1.2 Responses

   The following is proposed text for inclusion in section 10.1.2 of the
   SIP specification:

   183 responses SHALL always be forwarded.

5.11 Behavior of SIP User Agents

5.11.6. Callee Needs Early Media

   When the called UA receives and INVITE message that results in the
   need to report on the status of the media setup through a media
   stream, the called UA has the option to send a 183 message with a
   session description to the calling UA.

5.11.7 Caller Receives 183 Response

   When the calling UA receives a 183 response that contains a session
   description it SHALL setup the associated media session and present
   any media received from the called UA to the user.

5.13 Security Considerations

   The security considerations for the 183 Session Progress message are
   the same as for SIP in general.

5.16 Examples

5.16.9 PSTN to PSTN Session Setup (SIP in the middle)

   The following call flow illustrates the case where a call is origi-
   nating from a PSTN network, transiting a SIP network and being deliv-
   ered to a second PSTN network.  In this case, the 183 message is used
   to trigger the ACM message and results in a one way media session
   being setup through the SIP network.
















Donovan, et al.      draft-donovan-mmusic-183-00.txt             Page 14

Internet Draft      SIP 183 Session Progress Message           June 1999

           Originating  Ingress      Egress     Terminating
           Network      SIP GW       SIP GW      Network
               ------------>------------>----------->
               IAM          INVITE       IAM

                           <------------
                            100 Trying

               <-----------<------------<------------

               ACM          183 Session  ACM
                                Progress
                            One way SDP

               <=====================================
                         One way voice path

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

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

               <====================================>
                         Two Way Voice Path

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

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























Donovan, et al.      draft-donovan-mmusic-183-00.txt             Page 15

Internet Draft      SIP 183 Session Progress Message           June 1999

5.16.10 SIP User Agent Session Setup to a PSTN Destination

        Calling       Egress    Terminating
           UA         SIP GW      Network
            ------------>------------>
            INVITE       IAM

            <-----------
            100 Trying

            <-----------<------------
            183 Session  ACM
                Progress
            One way SDP

            <========================
                One way voice path

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

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

            <========================
                Two Way Voice Path

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

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



5.A Minimal Implementation

5.A.1 Client

   The following is a suggested addition to Appendix A.1 of the SIP
   specification:

   PSTN Interworking: If a client wishes to interwork properly with PSTN
   works then it MUST support the 183 Session Progress message.

6 References

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

[2] J. Rosenberg, H. Schulzrinne, S. Donovan, "Establishing QoS and
   Security Preconditions for SDP Sessions", draft-rosenberg-mmusic-
   sipqos-00.txt, To be published, Work in Progress.

Donovan, et al.      draft-donovan-mmusic-183-00.txt             Page 16

Internet Draft      SIP 183 Session Progress Message           June 1999

[3] J. Rosenberg, H. Schulzrinne, "Reliability of Provisional Responses
   in SIP", draft-ietf-mmusic-sip-100rel-01.txt, May 21, 1999, Work in
   Progress.

[4] H. Schulzrinne, "RTP Profile for Audio and Video Conferences with
   Minimal Control ", RFC 1890, January, 1996.

6 Authors' Addresses

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

   John Hearty
   MCI Worldcom
   9514/107
   2400 North Glenville Drive
   Richardson, TX 75082
   Email: john.h.hearty@mci.com

   Mathew Cannon
   MCI Worldcom
   9514/107
   2400 North Glenville Drive
   Richardson, TX 75082
   Email: matt.cannon@wcom.com

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

   Jonathan Rosenberg
   Lucent Technologies, Bell Laboratories
   Rm. 4C-526
   101 Crawfords Corner Road
   Holmdel, NJ 07733
   USA
   Email:  jdrosen@bell-labs.com









Donovan, et al.      draft-donovan-mmusic-183-00.txt             Page 17