SIPPING B. Stucker Internet-Draft Nortel Intended status: Informational July 23, 2006 Expires: January 24, 2007 Coping with Early Media in the Session Initiation Protocol (SIP) draft-stucker-sipping-early-media-coping-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on January 24, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Stucker Expires January 24, 2007 [Page 1] Internet-Draft Coping w/ Early Media in SIP July 2006 Abstract It is widely known that early media is an area within SIP in which the existing mechanisms within the protocol are not fully capable of handling to make rendering of these media flows a reliable process. Unfortunately, the need for media to be presented to an originator prior to the terminator answering is persistent. As such, a path forward to fixing this limitation is needed. This document seeks to document common ways that SIP networks handle early media, what side- effects those mechanisms have, and what the desired behaviors are. From this, it goes on to try to address as many early media issues as possible using as simple of a generic mechanism as possible. Stucker Expires January 24, 2007 [Page 2] Internet-Draft Coping w/ Early Media in SIP July 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Types of Early Media . . . . . . . . . . . . . . . . . . . . . 6 3.1. Pre-routing early media . . . . . . . . . . . . . . . . . 6 3.2. Pre-presentation early media . . . . . . . . . . . . . . . 6 3.3. Post-presentation early media . . . . . . . . . . . . . . 7 3.4. Non-SDP early media . . . . . . . . . . . . . . . . . . . 7 4. Current common coping mechanisms for early media . . . . . . . 9 4.1. Problems with current coping mechanisms . . . . . . . . . 10 4.1.1. Proxy-side coping mechanisms . . . . . . . . . . . . . 10 4.1.1.1. Proxy SDP stripping . . . . . . . . . . . . . . . 10 4.1.1.2. Proxy SDP weighting . . . . . . . . . . . . . . . 10 4.1.2. Client-side coping mechanisms . . . . . . . . . . . . 10 4.1.2.1. Client detection of forking . . . . . . . . . . . 10 4.1.2.2. Client slow-start INVITE . . . . . . . . . . . . . 11 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Deprecation of forking . . . . . . . . . . . . . . . . . . 12 5.2. Deprecation of early media . . . . . . . . . . . . . . . . 13 5.3. Originating UA's to render early media . . . . . . . . . . 13 5.4. Downstream signaling of acceptance . . . . . . . . . . . . 13 5.5. Upstream signaling of importance . . . . . . . . . . . . . 14 5.6. Universal backward-compatibility . . . . . . . . . . . . . 14 5.7. Recursive forking . . . . . . . . . . . . . . . . . . . . 14 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Early Media Classification and Prioritization . . . . . . 15 6.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15 6.1.1.1. The Early-Media-Class header . . . . . . . . . . . 15 6.1.1.1.1. Early-Media-Class types . . . . . . . . . . . 16 6.1.1.1.2. Early-Media-Q-Value . . . . . . . . . . . . . 16 6.2. Early Media Flow Negotiation . . . . . . . . . . . . . . . 16 6.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 16 6.2.2. SDP parameters . . . . . . . . . . . . . . . . . . . . 17 6.2.3. Usage of emflow with offer/answer . . . . . . . . . . 17 6.2.3.1. Meaning of a=emflow:none . . . . . . . . . . . . . 17 6.2.3.2. Meaning of a=emflow:send . . . . . . . . . . . . . 18 6.2.3.3. Meaning of a=emflow:recv . . . . . . . . . . . . . 18 6.2.3.4. Meaning of a=emflow:sendrecv . . . . . . . . . . . 18 6.2.4. Option tag for emflow . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Stucker Expires January 24, 2007 [Page 3] Internet-Draft Coping w/ Early Media in SIP July 2006 1. Introduction One of the mechanisms within SIP [2] that has caused much consternation (and interesting service scenarios) is forking, especially forking of INVITE requests. This is where a SIP INVITE request sent to a SIP proxy is resolved into two or more destinations which are signaled in parallel. When this occurs, multiple downstream parties will receive similar INVITE requests to initiate a SIP session from a given originating SIP user agent (UA). This creates the possibility of race conditions where the ordering of the provisional and final responses to this request, as observed by the originating SIP UA, may potentially arrive in any order, or not at all. Another mechanism in SIP [2] that looks simple, but causes difficult interactions, was introduced to handle SIP to PSTN interworking. Because the PSTN has a specific set of behaviors which require that only one endpoint in the PSTN network (typically the last PSTN switch reached) may generate media back to the originator of a PSTN call, generation of early media (media produced prior to the intended terminator of a call answering the call) is relatively straight- forward. In SIP, this PSTN interaction with early media was handled by allowing any endpoint that has received an SDP offer as part of setting up a session to be able to immediately generate media back to the to SDP offerer. Further, the SDP offerer was obligated to be prepared to render any media received at the location specified in the SDP offer at any time as long as the session was in a setup or stable state. Each of these mechanisms, taken separately, can create complex signaling flows and difficult service interactions to resolve. Together, however, they compound the effects of one another to create an area of study that has been open within the SIP design community for some time. Several extensions to SIP [2] have been proposed to handle some of the various effects that early media suffers from. However, none have fully attacked a few key areas of interest: o Controlling the order and timing of early media stream rendering at the originating SIP UAC. o Knowing under what general conditions early media flows are potentially being sent to the originating SIP UAC. This document seeks to capture the salient requirements for these areas, and propose a mechanism for handling these early media interactions in a more predictable manner. Stucker Expires January 24, 2007 [Page 4] Internet-Draft Coping w/ Early Media in SIP July 2006 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3]. Stucker Expires January 24, 2007 [Page 5] Internet-Draft Coping w/ Early Media in SIP July 2006 3. Types of Early Media Not all early media is created equal, some types are more problematic than others. There are four generic types of early media within SIP: 1. Pre-routing early media - This is early media that is, conveyed via SDP, and is presented to the originator by a proxy before routing on the URI is started. 2. Pre-presentation early media - This is early media that is presented to the originator, conveyed via SDP, by a proxy after the URI has been routed upon, but before any forwarding of the INVITE request has occurred. 3. Post-presentation early media - This is early media that is presented to the originator, conveyed via SDP, by either a forking proxy or any subsequent hop after the INVITE request has been forwarded from the proxy. 4. Non-SDP early media - This is early media that may be presented to the originator at any time through means other than SDP, such as the Alert-Info header as defined in [2] 3.1. Pre-routing early media Pre-routing early media is typically generated and characterized by a proxy that has an associated media resource. An example of this type of early media would be a brief 'branding' message that is played to the originator thanking them for using the service provider associated with the originator's local outbound proxy. When the message ends, the media resource signals this to the proxy and routing of the request continues per [2] This type of early media typically does not pose the originator's local outbound proxy any issues unless the client is using one of the mechanisms defined in Section 4.1.2 or something similar. This is because the proxy is in complete control over the pace at which the terminator will be routed to relative to the media stream being presented. If the proxy attempting to present pre-routing early media to the originator is a subsequent proxy from the originator's local outbound proxy, then the service may not work due to upstream proxies employing one of the mechanisms described in Section 4.1.1 3.2. Pre-presentation early media Pre-presentation early media is similar to pre-routing early media except that it may take into account the routes that the proxy is about to route the INVITE request to in its decision of what to play. Stucker Expires January 24, 2007 [Page 6] Internet-Draft Coping w/ Early Media in SIP July 2006 This may allow the proxy to employ one of the proxy-side early media coping mechanisms defined in Section 4.1.1. Likewise, the proxy may inject its own SDP answer into the signaling to the originator to kick off services like colorful ringback tone (CRBT) where the originator is hearing a recording (typically music) selected by the terminator while the network attempts to reach the terminating party. Pre-presentation early media also differs from non-SDP early media in that the proxy or proxies are manipulating the SDP offer/answer rather than SIP headers such as Alert-Info (as defined in [2]) to signify what media the originator should be rendering. There are several potential reasons why the Alert-Info header is not used in this case: the service may be interactive, requiring two-way media in order to work (such as digit collection for a credit card number), or may not want to rely on the originator's ability to render the information in the Alert-Info header to the end user (such as a call originating from the PSTN through a SIP gateway). 3.3. Post-presentation early media Post-presentation early media is most typically characterized by the ugly interactions that arise between it and forking. Since this is early media that has come about after the proxy has potentially caused multiple endpoints to be contacted, and therefore the possibility that multiple early media streams may have been triggered, it is commonly considered to be the worst-case scenario with early media. Even worse, because downstream proxies and endpoints may not be aware that the INVITE has forked, they may be generating what is ultimately going to be post-presentation early media while thinking that they are generating pre-routing, pre- presentation, or non-SDP early media erroneously. 3.4. Non-SDP early media Non-SDP early media is typically characterized by the presence of an Alert-Info header [2]. The Alert-Info header specifies a URI that the originator may go to in order to receive a file or stream that contains information (such as a wave recording) about the ringback tone the terminator wishes the originator to hear. It is somewhat simpler in that it is not part of the offer/answer model, and that it is not trying to create a two-way media stream. The problem is that the interaction between this mechanism, inband ringback, client generated ringback, and other forms of early media is not well specified in SIP [2], the offer/answer model [4] or other early media related RFCs such as [5]. At the moment, non-SDP early media is for future study, although it is envisioned that this document would clarify the behavioral Stucker Expires January 24, 2007 [Page 7] Internet-Draft Coping w/ Early Media in SIP July 2006 interactions between of the type of early media and other types of early media. Stucker Expires January 24, 2007 [Page 8] Internet-Draft Coping w/ Early Media in SIP July 2006 4. Current common coping mechanisms for early media A number of mechanisms exist for coping with early media. They all rely, generally, on 'fixing' the early media problem by 'breaking' the behaviors specified in other RFCs (or at least bending the spirit of them to some extent): 1. Proxy SDP stripping - If a proxy detects that it is about to fork an INVITE, it keeps track of this fact in its processing state for the INVITE transaction. Any SDP answers in provisional responses are stripped before being forwarded upstream. The SDP answer may be added into a 200 response upstream from last provisional SDP answer received if SDP is not already present in the message to ensure that the offer/answer exchange is completed. This effectively turns off early media. 2. Proxy SDP weighting - If a proxy detects that it had previously forked the INVITE to which it is now receiving a provisional response it may allow the first provisional response to retain the SDP answer in the message body and strip other SDP answers in provisional responses per the proxy SDP stripping methodology. This mechanism is used to favor SDP that the proxy may have some control over. For instance, if the proxy knows that one forked leg is to a media server streaming CRBT media to the originator, it may allow that SDP answer to flow back, but block all other SDP answers on other legs in the meantime. 3. Client detection of forking - Clients may play audible ringback to the originator until the first SDP answer is received at which time they may switch to playing the media for that SDP answer. Upon detecting that the INVITE forked (reception of two or more distinct SDP answers or [2] 'TO' header tags) the client may irrevocably return to playing audible ringback until the call is answered for the duration of that call's setup period, or until an error condition arises. 4. Client slow-start - Clients may wish to simply not include any SDP in their initial INVITE message in order to accumulate a set of SDP offers from their prospective terminating endpoints. Such INVITEs are known as 'slow-start' INVITEs, because the SDP offer/ answer exchange gets off to a 'slow start'. These may also be used in protocol interworkings (notably H.323 to SIP) with no intent as to managing early media. The client can either use PRACK or UPDATE to respond to offers received in provisional responses at the point in time the originating client wishes to stage early media streams. Stucker Expires January 24, 2007 [Page 9] Internet-Draft Coping w/ Early Media in SIP July 2006 4.1. Problems with current coping mechanisms 4.1.1. Proxy-side coping mechanisms 4.1.1.1. Proxy SDP stripping This is a very common mechanism, perhaps second only to the two client mechansims mentioned above. When a proxy employs this mechanism, it remembers when forking has occurred and removes any SDP in provisional responses as a result. This means that if the originator supports reliable provisional responses (100rel) as defined in [6], that this option tag must be removed by the proxy before forwarding the INVITE to each forked leg. Otherwise it may be forced to potentially handle SDP in negotiation within a PRACK transaction for the originating client with little or no information about the originating client's capabilities. In the case that the originator requires support for PRACK the proxy may have to fail the call setup, handle very complex negotiation signaling in the case that the call forks, or simply not fork the call. Additionally, this mechanism also completely breaks any early media services or announcements, some of which may be critical to proper completion of the call or as to the billing disposition of the call upon answer. For instance, the call may fork to a PSTN gateway that is trying to tell the originator that it is about to bill them $500 to complete the current call. With proxy SDP stripping this announcement would not be heard by the originator. 4.1.1.2. Proxy SDP weighting Proxy weighting of SDP can be useful in situations where the proxy knows what is going on with the call routing for each leg. However, lack of information as to why downstream elements are sending SDP in provisional responses can cause proxies to weight the SDP incorrectly. Further, if multiple proxies are traversed, the SDP that is accepted for delivery to the originating UA may not be the SDP selected at any given proxy. There is no indication to downstream network clients as to what has happened with their SDP as it traverses proxys back upstream towards the originator. Likewise, the $500 warning announcement presented in the previous section may or may not be heard. 4.1.2. Client-side coping mechanisms 4.1.2.1. Client detection of forking This mechanism is where a client may play audible ringback while waiting for an initial provisonal or final response to an INVITE Stucker Expires January 24, 2007 [Page 10] Internet-Draft Coping w/ Early Media in SIP July 2006 message it originated. When the first provisional response with SDP is received, it may switch from playing audible ringback to rendering the media stream defined in the SDP. If a subsequent provisional response is received from a different endpoint (identifiable by a different to-tag in the 'TO' header as defined in [2]) it stops rendering any early media media packets it is receiving and typically returns to audible ringback. Upon receiving a non-3xx final response, the UA switches media appropriately to the response. For 3xx responses, the client continues to play audible ringback if that was what is currently being rendered, or switches (typically) to ringback again if it was rendering media packets. This mechanism is used by client devices for a number of reasons: o What gets presented to the end user is predictable. o Does not rely on the set of proxies handling any given INVITE request to do anything special. o Is easy to implement. The problem with this approach is that it often causes early media to break altogether. This means that if a leg that the call was forked to is awaiting media from the originating client (such as prompting for digit collection, like a credit card number or extension) this may fail depending on what is received at the client by other endpoints in provisional responses. Network services that utilize early media are likely to fail when a client behaves in this manner. What's worse, is that there's no indication as to what the client is doing to the downstream network elements. Clipping may occur if there is a significant delay between the answer to the INVITE being received and the first media packet being received at the originating client. 4.1.2.2. Client slow-start INVITE Slow-start INVITEs circumvent the problem of having to immediately render media packets from an unknown set of terminating endpoints by not giving those endpoints anywhere to send the media to. However, this mechanism has some serious drawbacks, most notably guaranteed clipping (potentially severe if the SDP offer is not received from the other end until a 200 response is received) and the potential for an increased number of messaging round-trips to setup a call. Due to some service designs and protocol interworking slow-start INVITEs will continue to be seen, but due to the clipping problems associated with slow-start INVITEs this coping mechanism is considered to be incomplete. Stucker Expires January 24, 2007 [Page 11] Internet-Draft Coping w/ Early Media in SIP July 2006 5. Requirements The following requirements are considered to be the starting point in more formally discussing improvements to SIP for early media interactions: R1: Deprecation of forking within the SIP protocol [2] is considered to be out-of-scope of the possible solutions (sorry Dean). R2: Deprecation of early media from within the SIP protocol [2] is considered to be out-of-scope of the possible solutions (sorry again, Dean). R3: SIP UAs that are attempting to create a new SIP dialog using the INVITE method should no longer be obligated to blindly render media packets that are sent to them as part of a SIP offer sent in the INVITE. R4: A mechanism should exist by which an originating SIP UA can signal to a downstream SIP endpoint that it is now willing to accept media packets. R5: A mechanism should exist by which a terminating SIP UA can signal to an upstream SIP endpoint what type of early media (if known) it wishes to present to the originating UA, if it requires one-way, or two-way media flows, and the relative importance of the early media. R6: Universal backwards-compatability is a secondary goal. Where possible, backwards-compatability with clients that do not implement recommendations in this draft should be preserved. R7: The mechanism must be able to deal with recursive forking scenarios. This is where an INVITE passes two or more proxies that both choose to fork the request to two or more endpoints at each proxy in parallel. 5.1. Deprecation of forking Deprecation of forking from SIP [2] is considered to be out of scope. This is due to the heavy deployment of forking in existing implementations for key routing services. Changes of this nature are considered by the author (and others) to be of too large a scope relative to the problem at hand and are subsequently excluded from this draft in favor of searching for less radical solutions. Stucker Expires January 24, 2007 [Page 12] Internet-Draft Coping w/ Early Media in SIP July 2006 5.2. Deprecation of early media Deprecation of early media from SIP [2] is considered to be out of scope. Early media is required in order to handle certain PSTN interactions as defined in RFC-3398 [3] and elsewhere. In addition, the desire to provide announcements and other media prior to the terminating party answering the call is considered desirable and must therefore use some form of "pre-answer" media (currently known as early media). 5.3. Originating UA's to render early media Currently, section 5.1 of the offer/answer model [4] states that the offerer in an SDP offer/answer exchange must be prepared to receive media from media streams described in the offer as being 'recvonly' or 'sendrecv'. Further, in section 6.1 of [4] states that the answerer in an SDP offer/answer exchange may immediately send media to media streams that are described in the answer as being 'sendrecv' (note: [4] does not explicitly state as much, but it is assumed that media streams that are 'sendonly' in the answer can also have media immediately sent to them by the answering UA). These statements, taken together, create an obligation upon the originating UA to render any early media sent to them by anyone to whom their SDP was sent to unless the media stream was defined to be 'sendonly' or 'inactive' state when offered. This is useful in resolving the PSTN interactions in [3], especially as noted in the example call flows and ACM message processing in section 7 of that document. This obligation on the part of the originating UA has subsequently been used in the absence of actual PSTN interworking to provide services that mimic the PSTN network (such as providing far- end announcements), or provide other services such as colorful ringback tones (CRBT) in which media is streamed to the originator while the terminator is being located/alerted. An argument can, and has, been made that simply because a service exists in the PSTN world, that it does not mean that it must exist within SIP. However, given the prevalence of services that utilize early media, and the number of RFCs that talk about dealing with various aspects of early media, this particular train appears to have long ago left the station. It is not the intent of this document to pass judgement upon these services, but to find a way to cope with them in a more robust manner than currently is available. 5.4. Downstream signaling of acceptance An INVITE with SDP should serve two simple purposes: establish the path by which all signaling shall follow to/from the originating and set of terminating clients, let the terminating party know what sort Stucker Expires January 24, 2007 [Page 13] Internet-Draft Coping w/ Early Media in SIP July 2006 of communications the originator can and will engage in. Currently, SDP offers also imply tacit acceptance of any and all media that might be generated in the reverse path upstream towards the originator. This should not necessarily always be the case, and a mechanism whereby the originator may assert that it is further ready to receive media packets is needed. 5.5. Upstream signaling of importance A provisional response from a terminating party currently implies that the terminating party is listening to the SIP signaling it is receiving, and (if an SDP answer is present) the type of communications that the terminator wishes to engage in (if any). What is missing is a way for the terminating party to tell upstream entities what sort of demands it has upon the originator for rendering of its early media, and the relative importance associated with the media that it generates towards the originator. This helps the originator decide what is important and what is not when choosing which media stream it should render (if it wishes to, see Section 4.1.2.1). 5.6. Universal backward-compatibility There are scenarios in which there is no way to cope appropriately with early media streams. An example would be a call that forks to an ISUP PSTN gateway as defined in [3] that is ignorant of the content with which it is generating media packets. There is no reliable indication in ISUP as to what the other end might be doing for early media in the CPG or ACM messages. It is possible that a cause code is present in the CPG in some ISUP to legacy platform interworking scenarios, but these are not present generally in ISUP signaling flows, and therefore cannot be relied upon. Mechansims to deal with these types of devices is currently for future study and not explored further here at this time. 5.7. Recursive forking The mechanism should be able to deal with recursive forking scenarios. This would be where two or more independent proxies fork a given INVITE request from an originating client. In this case, the proxies are normally not coordinated in their operations. As a result, the mechanism proposed should be robust enough to allow for both end-to-middle and end-to-end negotiation of early media. Stucker Expires January 24, 2007 [Page 14] Internet-Draft Coping w/ Early Media in SIP July 2006 6. Recommendations The following sections include recommendations that create a framework that is capable of both identifying/prioritizing the type of early media being presented to the originator, and giving the originating client a means by which it can control the order in which early media flows are presented to it. 6.1. Early Media Classification and Prioritization 6.1.1. Overview Regardless of the mechanism that is used to control the presentation of early media, if at any point more than one endpoint is attempting to stream early media to the originator a two problems arise: o Nobody upstream of the device attempting to stream early media to the originator is aware of what exactly it is that the early media generator is generating. Is it advertising? Is it an important message? Who knows. This is important not only for the originating client (see Section 4.1.2.1), but proxies as well as they may be employing a weighting mechanism as described in Section 4.1.1.2. o The device generating the early media may have no idea how many other devices peer to it or downstream from it are also trying to generate early media. Again, this is important if the client is using the client-side detection of forking mechanism defined in Section 4.1.2.1. In order to rectify this situation a new SIP header 'Early-Media- Class' is defined, which includes information such as the category and priority of the SDP being offered. If there is SDP with the Early-Session disposition, as defined in [5], the header applies to the section of SDP that the Early-Session disposition refers to. Upon answer of the INVITE, all processing of media streams and SDP shall revert to [2]RFC-3261 rules. It is presented as a SIP header instead of in the SDP so that it can be read by endpoints that may not have access to the SDP, and so it can be changed without having to touch the message body. 6.1.1.1. The Early-Media-Class header The Early-Media-Class header is inserted by an endpoint generating media in an INVITE response to identify the type and priority of any SDP associated with an early-session disposition, or absent that, and SDP answer received from a given terminating endpoint. It is defined as follows: Stucker Expires January 24, 2007 [Page 15] Internet-Draft Coping w/ Early Media in SIP July 2006 Early-Media-Class = "Early-Media-Class" HCOLON Early-Media-Type ";q=" Early-Media-Q-Value Early-Media-Type = "Advertisement" / "Warning" / "Critical" / "Two-way" / "RFC-3264" / "Unknown" Early-Media-Q-Value = "q" EQUAL qvalue qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) 6.1.1.1.1. Early-Media-Class types The early-media-class type gives the type of early media that is being presented to the originator: 1. Advertisement - A non-critical advertisement. 2. Warning - A non-critical announcement. 3. Critical - A critical announcement, such as: "We're about to bill you for $10k". 4. Two-way - The endpoint presenting early media wishes to establish a two-way early media session before completing the call. 5. RFC-3264 - The default behaivor defined in RFC-3264 is requested. 6. Unknown - The nature of the early media being presented to the originator is unknown (such as from a PSTN gateway receiving a generic announcement.) 6.1.1.1.2. Early-Media-Q-Value This is simply a q-value such as that defined in section 20.10 of [2] that is used for ordering of early media types. Ties should be resolved in favor of the more important type of early media. 6.2. Early Media Flow Negotiation The following sections take the requirements from the earlier section and try to create a mechanism that can satisfy the requirements in Section 5. This mechanism is built along similar lines as the SIP preconditions framework [7]. 6.2.1. Overview A simple mechanism is introduced that tells terminators what the originator expects to have happen with respect to early media. This Stucker Expires January 24, 2007 [Page 16] Internet-Draft Coping w/ Early Media in SIP July 2006 information may also be of use to intermediate nodes that also wish to generate early media. The mechanism differs from the SDP [8] 'a=recvonly', 'a=sendonly', 'a=sendrecv', and 'a=inactive' attributes in that the final media flow mode can be negotiated and ready upon answer without further messaging, and from the preconditions [5] SDP attributes in that QoS can be negotiated separately as well. 6.2.2. SDP parameters The following media-level parameters are defined: early-media-flow-status = "a=emflow:" direction-tag direction-tag = ("none" | "send" | "recv" | "sendrecv") The early-media-flow-status 'emflow' denotes the current state of the early media from the perspective of the originator. It is expected that the directionality indicators such as 'sendrecv', 'sendonly', 'recvonly', and 'inactive' are otherwise unaffected. These values may be changed in subsequent offer/answer exchanges to allow the originator to properly stage multiple early media streams according to the Early-Media-Class header values. For example, an originator may specify 'a=emflow:none' initially to suppress all early media flows, and then send an UPDATE with a new SDP offer to an endpoint the originator received an early media indication from with 'a=emflow:recv' to denote that the originator is now willing to receive early media. Regardless of the value of this parameter, upon answer, both endpoints may immediately begin exchanging media packets upon answer according to [2], [4] and [8].Intermediate proxies should honor this indication, and adjust their behavior accordingly, potentally causing them to divert from their normal early media coping mechanisms. 6.2.3. Usage of emflow with offer/answer 6.2.3.1. Meaning of a=emflow:none If the emflow value of 'none' is set in an the SDP offer, it indicates that the endpoint generating the offer will not accept early media and that anyone accepting this SDP offer MUST NOT send early media. If the emflow value in the SDP offer was 'none', then the emflow value in the SDP answer MUST be set to 'none' as well. If the emflow value of 'none' is set in an SDP answer, it indicates that the endpoint generating the answer will not generate early media. Any early media sent to it per [4] MAY be discarded. The SDP offeror can take this indication to mean that they should not expect Stucker Expires January 24, 2007 [Page 17] Internet-Draft Coping w/ Early Media in SIP July 2006 early media packets from this endpoint, and that any received prior to answer from this source may safely be discarded. 6.2.3.2. Meaning of a=emflow:send If the emflow value of 'send' is set in an the SDP offer, it indicates that the endpoint generating the offer may send early media packets, but will not accept early media. Anyone accepting this SDP offer MUST NOT send early media, but SHOULD process received early media packets if it is appropriate to the device receiving packets to do so. If the emflow value in the SDP offer was 'send', then the emflow value in the SDP answer MUST be set to 'none' or 'recv' depending on whether the application intends to process the early media packets that the offeror may send to it. If the emflow value of 'send' is set in an SDP answer, it indicates that the endpoint generating the answer may generate early media but will not process any sent to it. Any early media sent to it per [4] MAY be discarded. The SDP offeror can take this indication to mean that they should expect early media packets from this endpoint and behave appropriately. 6.2.3.3. Meaning of a=emflow:recv If the emflow value of 'recv' is set in an the SDP offer, it indicates that the endpoint generating the offer may be sent early media packets, but will not generate early media. Anyone accepting this SDP offer MAY send early media, but SHOULD NOT expect to receive early media from the SDP offeror, and that any media packets received prior to answer from this the offeror may safely be discarded. If the emflow value in the SDP offer was 'recv', then the emflow value in the SDP answer MUST be set to 'none' or 'send' depending on whether the application intends to send the early media packets to the offeror or not. If the emflow value of 'recv' is set in an SDP answer, it indicates that the endpoint generating the answer will accept early media but will not generate any.The SDP offeror can take this indication to mean that they should not expect early media packets from this endpoint and may safely discard any received prior to answer. 6.2.3.4. Meaning of a=emflow:sendrecv If the emflow value of 'sendrecv' is set in an the SDP offer, it indicates that the endpoint generating the offer may send and receive early media packets. Anyone accepting this SDP offer MAY send early media, and SHOULD process received early media packets if it is appropriate to the device receiving packets to do so. If the emflow Stucker Expires January 24, 2007 [Page 18] Internet-Draft Coping w/ Early Media in SIP July 2006 value in the SDP offer was 'sendrecv', then the emflow value in the SDP answer MAY be set to any value. The value set in the SDP answer depends on if the endpoint answering the SDP offer intends to send and/or receive early media packets. If the emflow value of 'sendrecv' is set in an SDP answer, it indicates that the endpoint generating the answer may generate and receive early media and behave appropriately. 6.2.4. Option tag for emflow The option tag "emflow" is defined for use in the Require and Supported header fields [2]. An offerer MAY include this tag in a Require header if they wish to ensure that any endpoint reached supports this extension (typically when 'a=emflow:' is not set to 'sendrecv'). The if the party generating an SDP offer or answer supports this extension it MUST include this tag in a Supported header if it is not already in a Require header of any message containing SDP. This allows the other party or parties involved in the signaling flow to know that the other end is processing their emflow values. Stucker Expires January 24, 2007 [Page 19] Internet-Draft Coping w/ Early Media in SIP July 2006 7. Security Considerations TBD. Stucker Expires January 24, 2007 [Page 20] Internet-Draft Coping w/ Early Media in SIP July 2006 8. IANA Considerations TBD. Stucker Expires January 24, 2007 [Page 21] Internet-Draft Coping w/ Early Media in SIP July 2006 9. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping", RFC 3398, December 2002. [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002. [5] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004. [6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [7] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002. [8] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. Stucker Expires January 24, 2007 [Page 22] Internet-Draft Coping w/ Early Media in SIP July 2006 Author's Address Brian Stucker Nortel 2201 Lakeside Richardson, TX 75082 US Phone: +1 972 685 7724 Email: bstucker@nortel.com URI: http://www.nortel.com/ Stucker Expires January 24, 2007 [Page 23] Internet-Draft Coping w/ Early Media in SIP July 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stucker Expires January 24, 2007 [Page 24]