One document matched: draft-roach-mmusic-sip-provisional-media-00.txt

                  Provisional SIP Responses with Media

Status of this Memo

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

     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 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/1id-abstracts.txt

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

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Northern Europe), ftp.nis.garr.it (Southern Europe),
     munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
     ftp.isi.edu (US West Coast).

Abstract

     This document describes an extension of the SIP protocol which
     allows transit of SDP in provisional INVITE responses, so that
     media may be transferred before a final connection is
     established.

1. Introduction

     When SIP ( ref [1] ) is used for inter-operation with standard
     telephony networks, several situations arise when it is useful to
     allow temporary media sessions to be established before an INVITE
     request has finished. While these have certain useful
     applications in interaction with "standard" SIP clients (e.g. PC
     software applications), they provide the greatest benefit when
     used between gateways to a standard telephony network.

     The usefulness of being able to send media before a final
     connection is established can be demonstrated for the existing
     100 class INVITE responses:

     100 Trying -- Some localities provide a call progressing tone

Roach                                                           [Page 1]

Internet Draft    Provisional SIP Responses with Media         June 1999

         between dialing and ringing (known as a "comfort tone") under
         certain circumstances.

     180 Ringing -- Public network telephony users are accustomed to
         hearing a remotely generated ringtone when placing a call.
         For example, when dialing a British destination from the
         U.S., users expect to hear a British ringtone, not a U.S.
         one. Additionally, this allows users to hear a "caller
         waiting tone" when applicable (see ref [4] ).

     181 Call is being Forwarded -- PBX systems will often provide a
         voice announcement or tone indicating that a call is being
         forwarded from the dialed number.

     182 Call is Queued -- PBX systems will typically produce an
         announcement, hold music, or a tone to indicate to users that
         they are queued.

     The simplest method by which this type of media transit can be
     accomplished is by including session description information for
     the temporary media streams in these provisional responses.

     Temporary media streams which do not fit into the above
     categories can be sent in a "183" provisional response; see
     section 3, "New Provisional 183 Status Code" .

2. Format and Usage

     The format of provisional responses with media sessions is
     identical to that of 200-class responses to INVITE requests,
     except as noted in section 4, "Reliability" ; the body will
     contain a session description (usually SDP; see ref [2] ).

2.1. Temporary Media Establishment

     Under most circumstances, provisional responses used to initiate
     temporary media will contain SDP which is a subset of the media
     description presented in the INVITE message (as in normal 200
     responses).

     If the original INVITE message contains no media description, the
     server will generate SDP representing the capabilities it
     requires for media transmission and include it in the provisional
     response. The client will include a final SDP in its
     acknowledgement of receipt (see section 4, "Reliability" ).

     In both cases, the media streams will be established after the
     message confirming receipt of the provisional response has been
     sent (from the client's perspective) or received (from the
     server's perspective).

Roach                                                           [Page 2]

Internet Draft    Provisional SIP Responses with Media         June 1999

     The designation of media capabilities in a provisional response
     has no implications on the capabilities of any subsequent
     temporary connections or the final connection. Each media stream
     is negotiated relative to the session description in the original
     INVITE request (or lack thereof).

2.2. Change of Temporary Media

     After a temporary media stream has been established, its
     parameters can be changed by sending further provisional
     responses which also contain session descriptions. Upon receipt
     of such a response, the client MUST immediately cease
     transmission of media relating to the old temporary stream. As
     before, the new temporary media stream is established after
     acknowledgement of the provisional response.

     Provisional responses which contain no session description SHOULD
     NOT have an effect on any currently established temporary media
     stream.

2.3. Discontinuation of Temporary Media

     Sending of temporary media MUST be discontinued upon the sending
     (from the server's perspective) or the receipt (from the client's
     perspective) of any INVITE final response.

     A temporary media stream can also be discontinued by sending a
     provisional response which contains a session description with
     all media stream port numbers set to zero.

3. New Provisional 183 Status Code

     To allow for transmission of temporary media which does not
     correspond to the four provisional status codes defined in the
     SIP RFC ( ref [1] ), this protocol extension defines one
     additional response code of "183."

     183 can be used for any arbitrary in-band communication of call
     status. It SHOULD NOT, however, be used to convey ringing,
     forwarding, or call queueing situations.

     No suggested text is provided for the 183 status code; instead,
     implementors SHOULD include a text representation of the
     information conveyed by the media stream. In the case of a
     recorded announcement, this text SHOULD be the text of the
     announcement. For a tone, this text SHOULD be either the name of
     the tone as defined in E.182 ( ref [4] ) (e.g. "Payphone
     Recognition Tone") or a description of the condition the tone is
     attempting to report (e.g. "The Called Party is a Payphone").

Roach                                                           [Page 3]

Internet Draft    Provisional SIP Responses with Media         June 1999

4. Reliability

     Clients which understand this extension MUST also understand the
     extension described in "Reliability of Provisional Responses in
     SIP" ( ref [3] ) and will indicate that they require reliable
     transmission of provisional responses in Require: and
     Proxy-Require: headers.

     If a server requires the ability to deliver provisional media,
     but the client INVITE does not contain an appropriate Requires:
     header, the server will respond with a "403 Forbidden" response
     which contains a "Warning:" header. The value of the warning code
     will be reserved from the IANA at a later date. The warning
     header will indicate that reliable responses are required for
     communication with the server. Clients understanding the warning
     code SHOULD then automatically re-issue the INVITE request with
     appropriate headers.

5. Media Negotiation Failure for Temporary Media

     If no acceptable media type is available in the client's INVITE
     request session description, the server MAY return a "406 Not
     Acceptable" message; the alternative is to forgo the transmission
     of provisional media. While it is perhaps a more appropriate
     error code, "606 Not Acceptable" is not suggested, owing to its
     properties of terminating any ongoing searches.

     If the client finds the session description proposed by the
     server in a provisional response unacceptable, its
     acknowledgement SHOULD contain a session description with all
     media stream port numbers set to zero. A server which receives
     such a message MAY respond with a "406 Not Acceptable" message;
     the alternative is to forgo the transmission of provisional
     media.

6. Examples

     Only the relevant headers have been included in the following
     examples. Notably, the mandatory parameters Call-ID and CSeq are
     not shown.

6.1. Remote Ringtone, Followed by "Queued" Announcement

     Client to server:

          INVITE sip:+12145551212@bell.com SIP/2.0
          RAck: 0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com

Roach                                                           [Page 4]

Internet Draft    Provisional SIP Responses with Media         June 1999

          Require: org.ietf.sip.reliable-100
          Proxy-Require: org.ietf.sip.reliable-100
          Content-Type: application/sdp

          v=0
          o=- 929142225 929142225 IN IP4 vgw.domain.com
          c=IN IP4 vgw.domain.com
          M=audio 49152 RTP/AVP 0 1
          a=rtpmap:0 PCMU/8000
          a=rtpmap:1 1016/8000

     Server to client:

          SIP/2.0 180 Ringing
          RSeq: 1
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Content-Type: application/sdp

          v=0
          o=- 929142942 929142942 IN IP4 media.bell.com
          c=IN IP4 media.bell.com
          M=audio 49180 RTP/AVP 0
          a=rtpmap:0 PCMU/8000

     Client to server:

          INVITE sip:+12145551212@bell.com SIP/2.0
          RAck: 1
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Require: org.ietf.sip.reliable-100
          Proxy-Require: org.ietf.sip.reliable-100

     [Remote ringing tone is played]

     Server to client:

          SIP/2.0 182 Call is queued; est. wait is 5 minutes
          RSeq: 2
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Content-Type: application/sdp

          v=0
          o=- 929143057 929143057 IN IP4 media.bell.com
          c=IN IP4 media.bell.com

Roach                                                           [Page 5]

Internet Draft    Provisional SIP Responses with Media         June 1999

          M=audio 49180 RTP/AVP 1
          a=rtpmap:1 1016/8000

     [Ring tone is discontinued]

     Client to server:

          INVITE sip:+12145551212@bell.com SIP/2.0
          RAck: 2
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Require: org.ietf.sip.reliable-100
          Proxy-Require: org.ietf.sip.reliable-100

     ["Your call is queued" announcement is played, followed by hold
     music]

     Server to client:

          SIP/2.0 200 OK
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Content-Type: application/sdp

          v=0
          o=- 929143373 929143373 IN IP4 vgw.bell.com
          c=IN IP4 mg.bell.com
          M=audio 49199 RTP/AVP 1
          a=rtpmap:1 1016/8000

     [Hold music is discontinued]

     Client to server:

          ACK sip:+12145551212@bell.com SIP/2.0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com

     [Final media stream is established]

6.2. Remote Announcement: "Call is being forwarded," local ring tone.

     Client to server:

Roach                                                           [Page 6]

Internet Draft    Provisional SIP Responses with Media         June 1999

          INVITE sip:+12145551212@bell.com SIP/2.0
          RAck: 0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Require: org.ietf.sip.reliable-100
          Proxy-Require: org.ietf.sip.reliable-100
          Content-Type: application/sdp

          v=0
          o=- 929142225 929142225 IN IP4 vgw.domain.com
          c=IN IP4 vgw.domain.com
          M=audio 49152 RTP/AVP 0 1
          a=rtpmap:0 PCMU/8000
          a=rtpmap:1 1016/8000

     Server to client:

          SIP/2.0 180 Call is being forwarded
          RSeq: 1
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Content-Type: application/sdp

          v=0
          o=- 929142942 929142942 IN IP4 media.bell.com
          c=IN IP4 media.bell.com
          M=audio 49180 RTP/AVP 0
          a=rtpmap:0 PCMU/8000

     Client to server:

          INVITE sip:+12145551212@bell.com SIP/2.0
          RAck: 1
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Require: org.ietf.sip.reliable-100
          Proxy-Require: org.ietf.sip.reliable-100

     [Announcement plays: "Your call is being forwarded to a phone
     outside the company's premises. Please wait."]

     Server to client:

          SIP/2.0 180 Ringing
          RSeq: 2
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com

Roach                                                           [Page 7]

Internet Draft    Provisional SIP Responses with Media         June 1999

          Content-Type: application/sdp

          v=0
          o=- 929143373 929143373 IN IP4 media.bell.com
          c=IN IP4 media.bell.com
          M=audio 0 RTP/AVP 0

     [Media stream is discontinued. Local ring-tone is generated by
     the client towards the PSTN user.]

     Client to server:

          INVITE sip:+12145551212@bell.com SIP/2.0
          RAck: 2
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Require: org.ietf.sip.reliable-100
          Proxy-Require: org.ietf.sip.reliable-100

     Server to client:

          SIP/2.0 200 OK
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Content-Type: application/sdp

          v=0
          o=- 929143373 929143373 IN IP4 vgw.bell.com
          c=IN IP4 mg.bell.com
          M=audio 49199 RTP/AVP 1
          a=rtpmap:1 1016/8000

     Client to server:

          ACK sip:+12145551212@bell.com SIP/2.0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com

     [Final media stream is established]

6.3. Reliable Provisional Responses not specified, but supported

     Client to server:

Roach                                                           [Page 8]

Internet Draft    Provisional SIP Responses with Media         June 1999

          INVITE sip:+12145551212@bell.com SIP/2.0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Content-Type: application/sdp

          v=0
          o=- 929142225 929142225 IN IP4 vgw.domain.com
          c=IN IP4 vgw.domain.com
          M=audio 49152 RTP/AVP 0 1
          a=rtpmap:0 PCMU/8000
          a=rtpmap:1 1016/8000

     Server to client (the 395 warning code is only an example; an
     actual number will be reserved from the IANA as this draft
     progresses):

          SIP/2.0 403 Forbidden
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Warning: 395 bell.com "Incompatible Client"

     Client to server:

          ACK sip:+12145551212@bell.com SIP/2.0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com

     Client to server (no user interaction required):

          INVITE sip:+12145551212@bell.com SIP/2.0
          RAck: 0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Require: org.ietf.sip.reliable-100
          Proxy-Require: org.ietf.sip.reliable-100
          Content-Type: application/sdp

          v=0
          o=- 929142225 929142225 IN IP4 vgw.domain.com
          c=IN IP4 vgw.domain.com
          M=audio 49152 RTP/AVP 0 1
          a=rtpmap:0 PCMU/8000
          a=rtpmap:1 1016/8000

     Call continues normally from here.

Roach                                                           [Page 9]

Internet Draft    Provisional SIP Responses with Media         June 1999

6.4. Server Side Media Failure

     Client to server:

          INVITE sip:+12145551212@bell.com SIP/2.0
          RAck: 0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Require: org.ietf.sip.reliable-100
          Proxy-Require: org.ietf.sip.reliable-100
          Content-Type: application/sdp

          v=0
          o=- 929142225 929142225 IN IP4 vgw.domain.com
          c=IN IP4 vgw.domain.com
          M=audio 49152 RTP/AVP 0 1
          a=rtpmap:0 PCMU/8000
          a=rtpmap:1 1016/8000

     Server to client:

          SIP/2.0 406 No codecs match
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com

     Client to server:

          ACK sip:+12145551212@bell.com SIP/2.0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com

6.5. Client Side Media Failure

     Client to server:

          INVITE sip:+12145551212@bell.com SIP/2.0
          RAck: 0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Require: org.ietf.sip.reliable-100
          Proxy-Require: org.ietf.sip.reliable-100

Roach                                                          [Page 10]

Internet Draft    Provisional SIP Responses with Media         June 1999

     Server to client:

          SIP/2.0 180 Ringing
          RSeq: 1
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Content-Type: application/sdp

          v=0
          o=- 929142942 929142942 IN IP4 media.bell.com
          c=IN IP4 media.bell.com
          M=audio 49180 RTP/AVP 0
          a=rtpmap:0 PCMU/8000

     Client to server:

          INVITE sip:+12145551212@bell.com SIP/2.0
          RAck: 1
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com
          Require: org.ietf.sip.reliable-100
          Proxy-Require: org.ietf.sip.reliable-100
          Content-Type: application/sdp

          v=0
          o=- 929144697 929144697 IN IP4 vgw.domain.com
          c=IN IP4 vgw.domain.com
          M=audio 0 RTP/AVP 0

     Server to client:

          SIP/2.0 406 No codecs match
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com

     Client to server:

          ACK sip:+12145551212@bell.com SIP/2.0
          To: sip:+12145551212@bell.com
          From: sip:+15125559876@domain.com

7. Security Considerations

     When this extension is used by PSTN gateways, care must be taken

Roach                                                          [Page 11]

Internet Draft    Provisional SIP Responses with Media         June 1999

     that provisional responses with media descriptions are accepted
     only from trusted nodes in the network. Most gateway
     implementations will operate such that only final connections
     will trigger billing (since billing for ringtone or announcements
     doesn't generally make sense). If provisional media is accepted
     from arbitrary nodes, a limited level of free service may be
     stolen by clients which have been programmed to return
     provisional responses with media description instead of final
     responses.

8. References

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

     [2] M. Handley/V. Jacobson, "SDP: Session Description Protocol",
         RFC 2327, IETF; April 1998.

     [3] J. Rosenberg/H. Schulzrinne, "Reliability of Provisional
         Responses in SIP", Internet Draft
         <draft-ietf-mmusic-sip-100rel-01.txt>, IETF; May 1999. Work
         in progress.

     [4] "Application of Tones and Recorded Announcements in Telephone
         Services", ITU-T Recommendation E.182; 1993

9. Acknowledgements

     I must express my gratitude to John Hearty, Sean Olson, and Eric
     Havens for their feedback on this document.

10. Author's Address

     Adam Roach
     Ericsson Inc.
     Mailstop L-04
     851 International Pkwy.
     Richardson, TX 75081
     USA
     Phone: +1 972-583-7594
     Fax: +1 972-669-0154
     E-Mail: adam.roach@ericsson.com

Roach                                                          [Page 12]