Internet Engineering Task Force Adam Roach Internet Draft Ericsson Inc. Category: N/A June 1999 Expires January 2000 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 , 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]