SIPPING B. Stucker Internet-Draft Nortel Intended status: Informational February 12, 2007 Expires: August 16, 2007 Early Media INDirection (EMIND) in the Session Initiation Protocol (SIP) draft-stucker-sipping-early-media-indirection-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 August 16, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes models that can be used to manage multiple early media streams in the Session Initiation Protocol (SIP). The model seeks to allow calling party endpoints to be able to better control the rendering of early media to the user, and distinguish early media from final media. Although some of early media challenges are likely to never be overcome, (e.g. when interworking with an ISUP PSTN gateway that does Stucker Expires August 16, 2007 [Page 1] Internet-Draft Early Media Indirection in SIP February 2007 not take into account CPG or ACM messages), the potential to improve on what is already there does exist. The recommendations in this document are intended to be an update to RFC-3960 recommendations and to avoid many of the complications outlined in draft-stucker-sipping-early-media-coping. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Early Media Indirection . . . . . . . . . . . . . . . . . . . 5 6. Early Media Indirection Operation . . . . . . . . . . . . . . 6 6.1. The Early-Media Header . . . . . . . . . . . . . . . . . . 6 6.2. User Agent Client Procedures . . . . . . . . . . . . . . . 7 6.2.1. Indicating support for Early Media Indirection (EMIND) . . . . . . . . . . . . . . . . . . . . . . . 7 6.2.2. Accepting indirect early-media streams . . . . . . . . 7 6.2.3. Closing indirect early-media streams . . . . . . . . . 8 6.2.4. Switching from early-media to final-media . . . . . . 8 6.3. Proxy/User Agent Server Procedures . . . . . . . . . . . . 8 6.3.1. Offering indirect early media streams . . . . . . . . 9 6.3.2. Closing indirect early media streams . . . . . . . . . 9 6.3.3. Ordering early media streams . . . . . . . . . . . . . 10 7. Example Call Flow . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informational References . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Stucker Expires August 16, 2007 [Page 2] Internet-Draft Early Media Indirection in SIP February 2007 1. Introduction Establishment of one or more media streams within SIP [RFC3261] using the SDP offer/answer model [RFC3264] typically involves two phases: early media and final media. Early media is media that is generated prior to a particular SIP session being accepted by a called endpoint. Final media differs from early media in that it is generated only after the SIP session has been accepted by a called endpoint. It is important to note, that although [RFC3261] does not require that the originator/UAC actually render ANY early media sent to them (just that they be prepared to receive it). However, in order to prevent media clipping (see section 2 of [RFC3960]), UACs nearly universally do try to render early media streams to the originating user in practice. There are many different reasons that early media may be sent to the calling party. For example: to announce their current account balance, to provide customized ringback, or to present a brief tone identifying the service provider. In each of these cases, an application server may intercept the INVITE and involve a media server into the call. As a result of proxy and/or client interactions (which are explained later in this document) the normal negotiation of SDP between the calling party and the called party's endpoint may be impacted negatively. Another potentially troublesome scenario arises when the INVITE for the call is forked by one or more proxies. This can create a condition where multiple early media streams arrive at the UAC, possibly prior to the SDP offer/answer exchange being completed. This scenario has been previously discussed in [RFC3960], and in particular by the definition of the gateway model given in that document. Despite the previous treatment on the topic, there remains room for improvement. Finally, there is the problem of early media and interworking scenarios. This is typically viewed as a problem with SIP to PSTN interworking, but the reverse (where a PSTN user is trying to contact a SIP user) can also cause problems. When other protocols are interworked with SIP it may become difficult or impossible to know the reason why a particular early media stream is being generated and what the correct course of action is at the UAC. For example, ISUP has no indication in the CPG or ACM messages as to what is likely in a particular media stream is being sent to the originator for presentation to the calling party. This document seeks to improve upon each of these scenarios, where possible, by updating the recommendations from [RFC3960], providing a mechanism to help order early media streams when forking has Stucker Expires August 16, 2007 [Page 3] Internet-Draft Early Media Indirection in SIP February 2007 occurred, and separate early media negotiation triggered by proxies from SDP negotiation with the called party's end device(s). Further information about the various problems currently caused by existing early media processing mechanisms can be found in [I-D.stucker-sipping-early-media-coping]. 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]. 3. Definitions This document uses the following terms: o End-to-end early media - Media generated by the called party's end client device prior to the call being answered at that device. For example, colorful ringback tones streamed to the originator that are generated by the terminating end user's phone. o End-to-middle early media - Media that is generated by an application server that is intended to cease upon arrival of the 200 OK to the INVITE by a device controlled by the called party. For example, account balance information, branding, colorful ringback tones, etc. o Transitional media - End-to-end final media generated by the UAS after the 200 OK, but arrives at the UAC before the 200 OK. In effect the signaling is racing with the media to get to the UAC. For example, the called party has answered the call, and is saying "Hello", but the UAC doesn't yet know that the call has been answered due to the decoupled signaling and media paths having different latentcies. o End-to-end in-band signaling - Signaling that is done end-to-end in the media path instead of through SIP. For example, ICE connectivity checks, or in-band SRTP handshake messages. o Non-SDP early media - Ringback information sent in 180 messages to the UAC per [RFC3261]. 4. Requirements The following requirements are considered to be the starting point in more formally discussing improvements to SIP for early media interactions: Stucker Expires August 16, 2007 [Page 4] Internet-Draft Early Media Indirection in SIP February 2007 R1: A mechanism should exist by which a UAC can signal to a particular UAS that it is now willing to accept early media, without increasing the likelihood of transitional media clipping. R2: A mechanism should exist by which a proxy or UAS can signal to a particular UAC what type of early media (if known) it wishes to present to the UAC. Additionally the proxy or UAS should be able to denote if it requires one-way, or two-way media flows, and the relative importance of the early media. R3: Any mechanism proposed should try, to the greatest extent possible, be simple to implement, and reuse the existing design patterns within [RFC3261], [RFC3264] and [RFC3960]. R4: 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. R5: The mechanism must not require exchange of packets on the media path to identify or coordinate early media streams as this may not interoperate with common network media gating mechanisms. 5. Early Media Indirection In order to satisfy all of the requirements outlined in this document and [I-D.stucker-sipping-early-media-coping], a new mechanism is proposed to manage early media negotiation and rendering: early media indirection. Instead of negotiating both early and final media parameters within the same SIP dialog, proxies and endpoints that wish to generate early-media include a special Early-Media header in any 18x response to the original INVITE if the UAC indicated support for this mechanism. The UAC may then choose the time and conditions under which it will contact the URI specified in the Early-Media header to establish a separate (but related) dialog to handle the "early" media. This separate dialog is called an early-media dialog. The original INVITE dialog is called the final-media dialog. By doing so, several benefits accrue to the UAC and the proxy/UAS: o The UAC has total control over when/if it will initiate the early media dialog. o Because the SDP negotiation is separate from final media the early media may have different directionality from the final-media. For instance, the final-media may be recvonly, but the early media may be sendrecv. o The establishment of a separate early-media dialog reuses the same mechanism on the UAC that generates any other INVITE transaction. No new methods or complex negotiation mechanisms are required. Stucker Expires August 16, 2007 [Page 5] Internet-Draft Early Media Indirection in SIP February 2007 o Forking is no longer an issue for early media. The UAC controls the timing and ordering of any early media dialogs explicitly. In can also know which endpoint is generating what media through subtle manipulation of its SDP parameters. o No negotiation is required in the media path. Everything is handled in the open on the signaling path where proxies may enforce network policies regarding early media. o The mechanism is entirely compatible with existing mechanisms. If no Early-Media header is received by the UAC, it follows [RFC3960] rules for early media rendering. o SRTP negotiation is simplified. The final-media offer may include SRTP whereas early-media dialogs may contain an offer that uses regular RTP to conserve resources. 6. Early Media Indirection Operation 6.1. The Early-Media Header In order to allow proxies and UASs to specify a location that the UAC should contact for early-media, a new header is introduced. This is done instead of adding SDP attributes to ease the ability of a proxy to manage these contacts. For instance, if an Early-Media header is seen coming from an untrusted endpoint, the proxy may strip the header from the message. Likewise, if multiple headers are received on various forked call legs, it is possible that the proxy may store and forward these header values at a later time to facilitate ordering of early media streams to the calling party. The format of the Early-Media header is given as the following (building off of ABNF definitions given in section 25.1 of [RFC3261]): Early-Media = "Early-Media" HCOLON ( contact-param * (COMMA contact-param)) The value of the early media header is one (or more) URIs for the UAC to contact for early-media. In the case that a single URI is specified and the UAC fails to establish a dialog, that early media stream will fail to be rendered. If multiple URIs are specified, the UAC may contact the next URI in the list if it fails to establish an early media stream using a prior entry in the list. Once an early media dialog is established, the remainder of the list (if any) is discarded. Stucker Expires August 16, 2007 [Page 6] Internet-Draft Early Media Indirection in SIP February 2007 6.2. User Agent Client Procedures The following sections describe the procedures that the UAC uses in order to support early media indirection. 6.2.1. Indicating support for Early Media Indirection (EMIND) Upon generation of an initial INVITE request, the UAC MUST include the 'emind' option tag in a Supported header as part of the INVITE request being sent. This lets the UAS know that the UAC supports early media indirection and will process the Early-Media header information sent back in any 18x responses. Failure to include this value in the supported header may cause endpoints wishing to generate early media to not use the procedures defined in this document (i.e. revert to baseline behavior). If the initial INVITE request does not include an SDP offer, then the next SIP request message that contains an SDP offer prior to the 200 OK to the INVITE being received MUST include the 'emind' option tag in a Supported header. 6.2.2. Accepting indirect early-media streams The following section specifies the mechanism that a UAC uses to accept an indirect (EMIND negotiated) early-media stream. If the UAC is currently rendering any non-EMIND negotiated early-media it MUST stop rendering that early-media. If the UAC is currently rendering any EMIND negotiated early-media it MUST stop rendering that early- media and complete the procedures given in section Section 6.2.3. In order to accept indirect early-media, the UAC creates a separate SIP dialog to handle the negotiation of this early media. This dialog, known as an early-media dialog, allows the UAC to receive early media from endpoints other than the called party's device(s) such as a network media server, does not suffer from the problems of forking (since each indirect early-media session creates a separate early media dialog), allows for the UAC to specify a different RTP payload type (to facilitate discrimination of early-media versus final-media), and gives both the UAC and UAS the ability to explicitly start and stop the early media stream without complicating the SDP negotiations for the final media. 1. Create a new "early-media" INVITE request copying information from the original INVITE request. 2. Copy the URI information from the 18x Early-Media header into the request URI of the new "early-media" INVITE. 3. Create a new SDP offer (may be a copy or subset of the offer in the original INVITE). For each codec offered, specify a new dynamic RTP payload type specified for the offered codecs. The payload number MUST be unique such that it does not duplicate a Stucker Expires August 16, 2007 [Page 7] Internet-Draft Early Media Indirection in SIP February 2007 dynamic payload type currently being offered by the UAC. This dynamic RTP payload type is called the early-media payload type. 4. Send the new "early-media" INVITE to the same first-hop as the original INVITE was sent to. 5. Render any media received with the matching the early-media payload type. 6.2.3. Closing indirect early-media streams The following section specifies the mechanism that a UAC uses to close an indirect (EMIND negotiated) early-media stream. These procedures may be executed in parallel to accepting a new indirect early-media stream or any SIP signaling in relation to the original INVITE request sent by the UAC to initiate the dialog. 1. Stop rendering any media matching the early-media payload type used for this indirect early-media stream. 2. Send the UAS generating the early media a BYE request to close the dialog for this early-media stream. 6.2.4. Switching from early-media to final-media The procedure for knowing when early-media packets should be replaced with final-media packets is straight-forward due to the utilization of unique dynamic RTP payload types for the early-media dialog(s). When the UAC detects media being received containing valid RTP payload types that do not match those of a dynamic RTP payload type specified in an early-media dialog, it simply stops rendering the early-media stream(s) and beings rendering the final-media for the original INVITE dialog. This eliminates problems coordinating signaling between early-media generators and a called-party device answering the original INVITE. Upon receiving a final-media RTP payload type, the UAC SHOULD execute the procedures in section Section 6.2.3 in a timely fashion for any early-media dialog(s) it may have created. 6.3. Proxy/User Agent Server Procedures If a proxy or UAS receives an INVITE, and wishes to generate end-to- middle early media towards the UAC, it should first look to see if the UAC has indicated support for early media indirection by the presence of the 'emind' option tag in the Supported header of the INVITE. If it has, then it may use the procedures specified in this section. In order to offer an indirect early media stream, the proxy/UAS creates a secondary dialog. This dialog is called the "early-media Stucker Expires August 16, 2007 [Page 8] Internet-Draft Early Media Indirection in SIP February 2007 dialog". By creating a separate dialog, the negotiation of early- media is separated from the negotiation of final media. Because the early-media is then handled on a separate dialog, there is no reason for it to be "early" anymore. The early-media dialog that is created can be answered or rejected immediately. When either end wishes to discontinue playback of the "early" media stream they simply end the session by sending a BYE request for the early-media dialog. It should be noted that there is no restriction that says that the UAS handling the original INVITE request must also handle the early- media dialog. This allows UASs and proxies to specify media servers which may be available in the network as sources for early-media content. As a result, restrictions placed upon client devices that prevent streaming of media prior to answering the call (i.e. gating of their media) do not interfere with the ability to provide early media services such as colorful ringback. 6.3.1. Offering indirect early media streams If a proxy/UAS wishes to offer an early-media stream, they may do so by including the following in a 18x response to the original INVITE request: 1. A Requires header that includes the tag value 'emind'. 2. Include an Early-Media header that specifies the URI that the originator should contact for early media. This URI may be a SIP URI (possibly a GRUU) that points to the resource that is controlling the early media to be generated. This may be the proxy/UAS itself, or another network element such as a media server. The URI may contain parameters that provide contextual information about what early media is to be played. 6.3.2. Closing indirect early media streams If the proxy/UAS wishes to close an early media stream, they may do so by sending a BYE request on the early-media dialog. Closing early-media streams by a proxy/UAS that are being served by third- party network elements is outside the scope of this specification as it is assumed that there is some form of coordination (such as an H.248 interface to the media server from the proxy server) present that makes this possible. Any early-media dialogs that are controlled by the proxy/UAS MUST be closed after sending a 3xx or higher response code to the original INVITE request. If any early-media dialogs were created that are handled by third-party network elements, it is assumed that the UAC will close these dialogs upon receipt of the 3xx or higher response Stucker Expires August 16, 2007 [Page 9] Internet-Draft Early Media Indirection in SIP February 2007 code from the proxy/UAS. 6.3.3. Ordering early media streams With the current specifications for early media, issues exist when multiple early media streams are sent to the calling party simultaneously. Because the media path may be decoupled from the signaling path, proxies may have little or no control over the ordering of early-media being sent to the calling party. Because devices generating early-media may not be aware of forking of the SIP signaling, they may not know that a conflict exists at the calling party that prevents proper rendering of early media being generated. Correct ordering of early-media is facilitated by early-media indirection due to the requirement that the calling party explicitly create a separate SIP dialog to handle negotiations. Further, because the passing of indirection information is handled in a SIP header instead of in a message body, it is possible for proxies to inspect requests for early media and facilitate proper ordering. 7. Example Call Flow The following call flow is given to show how the early-media indirection procedures operate. In this example User A calls User B. User B has previously instructed their proxy that they wish to have a custom ringtone streamed to the originator. Rather than trying to manage this as an inline operation, the proxy uses early media indirection to handle the media interactions. The call flow for this scenario would be as follows: Stucker Expires August 16, 2007 [Page 10] Internet-Draft Early Media Indirection in SIP February 2007 domain-a.com . domain-b.com . proxy proxy . . . User A's . . . . . . . . . . . . . . . User B's Media device device server | | | | | | INVITE F1 | | | | |------------>| INVITE F2 | | | | |------------>| INVITE F3 | | | | |------------>| | | | | | | | | 180 Ring F4 | | | | 180 Ring F5 |<------------| | | |<------------| | | | | INVITE F6 | | | | |------------>| | INVITE F7 | | | |---------------------------------------->| | | | 200 OK F8 | | | 200 OK F9 |<----------------------------------------| |<------------| | | | | | "Early" Media Session | | |<=====================================================>| | ACK | | | | |------------------------------------------------------>| | | "Final" Media Session | | |<=======================================>| | | | | 200 OK | | | | 200 OK |<------------| | | 200 OK |<------------| | | |<------------| | | | | | BYE | | |------------------------------------------------------>| | | 200 OK | | |<------------------------------------------------------| | | ACK | | | |---------------------------------------->| | Call flow diagram The detailed call flow is as follows: Stucker Expires August 16, 2007 [Page 11] Internet-Draft Early Media Indirection in SIP February 2007 F1: INVITE (User A to Proxy A): INVITE sip:userb@domain-b.com SIP/2.0 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 To: UserB From: UserA ;tag=d7t6d7ftsdf7t6 Call-ID: 843817637684230@998sdasdh09 CSeq: 1 INVITE Supported: emind Contact: Content-Length: ... Content-Type: application/sdp v=0 o=usera 53655765 2353687637 IN IP4 devicea.domain-a.com s=- t=0 0 c=IN IP4 devicea.domain-a.com m=audio 3456 RTP/AVP 0 1 3 99 a=rtpmap:0 PCMU/8000 a=sendrecv User A's proxy forwards the request to User B's proxy. F2: INVITE (Proxy A to Proxy B): INVITE sip:userb@domain-b.com SIP/2.0 Via: SIP/2.0/UDP proxy.domain-a.com:5060;branch=z9hG4bKaf88df7 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 To: UserB From: UserA ;tag=d7t6d7ftsdf7t6 Call-ID: 843817637684230@998sdasdh09 CSeq: 1 INVITE Supported: emind Contact: Content-Length: ... Content-Type: application/sdp v=0 o=usera 53655765 2353687637 IN IP4 devicea.domain-a.com s=- t=0 0 c=IN IP4 devicea.domain-a.com m=audio 3456 RTP/AVP 0 1 3 99 a=rtpmap:0 PCMU/8000 a=sendrecv User B's proxy forwards the request from User A to User B's device. Stucker Expires August 16, 2007 [Page 12] Internet-Draft Early Media Indirection in SIP February 2007 F3: INVITE Proxy B to User B): INVITE sip:userb@deviceb.domain-b.com SIP/2.0 Via: SIP/2.0/UDP proxy.domain-b.com:5060;branch=z9hG4bK87yfgd8g Via: SIP/2.0/UDP proxy.domain-a.com:5060;branch=z9hG4bKaf88df7 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 To: UserB From: UserA ;tag=d7t6d7ftsdf7t6 Call-ID: 843817637684230@998sdasdh09 CSeq: 1 INVITE Supported: emind Contact: Content-Length: ... Content-Type: application/sdp v=0 o=usera 53655765 2353687637 IN IP4 devicea.domain-a.com s=- t=0 0 c=IN IP4 devicea.domain-a.com m=audio 3456 RTP/AVP 0 1 3 99 a=rtpmap:0 PCMU/8000 a=sendrecv Meanwhile, user B's proxy wishes to invoke early media from a media server in domain-b.com to User A's device to provide custom ringback: F4: 180 Ringing (Proxy B to Proxy A): SIP 2.0 180 Ringing Via: SIP/2.0/UDP proxy.domain-a.com:5060;branch=z9hG4bKaf88df7 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 To: UserB ;tag=s12td12tr3t2 From: UserA ;tag=d7t6d7ftsdf7t6 Call-ID: 843817637684230@998sdasdh09 CSeq: 1 INVITE Required: emind Early-Media: Content-Length: 0 User A's proxy validates that User B's proxy is trusted for early media and leaves the Early-Media header alone. The 180 is forwarded to User A's device: Stucker Expires August 16, 2007 [Page 13] Internet-Draft Early Media Indirection in SIP February 2007 F5: 180 Ringing (Proxy A to User A): SIP 2.0 180 Ringing Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 To: UserB ;tag=s12td12tr3t2 From: UserA ;tag=d7t6d7ftsdf7t6 Call-ID: 843817637684230@998sdasdh09 CSeq: 1 INVITE Required: emind Early-Media: Content-Length: 0 User A's device sees that an Early-Media header is present in the 180 response and executes the procedures in section Section 6.2.2 to initiate the requested early-media dialog. It selects the dynamic RTP payload type of 96 for the early-media payload type: F6: INVITE (User A to Proxy A): INVITE sip:service@media-server.domain-b.com:5060 ;service=ringback;user=userb SIP/2.0 Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345aaa To: Service From: UserA Call-ID: 843230@998sdasdh09 CSeq: 1 INVITE Contact: Content-Length: ... Content-Type: application/sdp v=0 o=usera 53655765 2353687637 IN IP4 devicea.domain-a.com s=- t=0 0 c=IN IP4 devicea.domain-a.com m=audio 3456 RTP/AVP 96 a=rtpmap:96 PCMU/8000 a=recvonly User A's proxy forwards the request to the media server in domain- b.com: Stucker Expires August 16, 2007 [Page 14] Internet-Draft Early Media Indirection in SIP February 2007 F7: INVITE (Proxy A to Media Server): INVITE sip:service@media-server.domain-b.com:5060 ;service=ringback;user=userb SIP/2.0 Via: SIP/2.0/UDP proxy.domain-a.com:5060;branch=z9hG4bkdfsd8fysdf Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345aaa To: Service From: UserA ;tag=d87fysdf8sdfy Call-ID: 843230@998sdasdh09 CSeq: 1 INVITE Contact: Content-Length: ... Content-Type: application/sdp v=0 o=usera 53655765 2353687637 IN IP4 devicea.domain-a.com s=- t=0 0 c=IN IP4 devicea.domain-a.com m=audio 3456 RTP/AVP 96 a=rtpmap:96 PCMU/8000 a=recvonly The media server in domain-b accepts the incoming request for media and accepts the offer from User A's device. F8: 200 OK (Media Server to Proxy A): SIP 2.0 200 OK Via: SIP/2.0/UDP proxy.domain-a.com:5060;branch=z9hG4bkdfsd8fysdf Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 To: Service From: UserA ;tag=d87fysdf8sdfy Call-ID: 843230@998sdasdh09 CSeq: 1 INVITE Content-Length: ... Content-Type: application/sdp v=0 o=media 53655765 2353687637 IN IP4 media-server.domain-b.com s=- t=0 0 c=IN IP4 media-server.domain-b.com m=audio 7890 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly User A's proxy forwards the response from User B's media server to Stucker Expires August 16, 2007 [Page 15] Internet-Draft Early Media Indirection in SIP February 2007 User A's device. F9: 200 OK (Proxy A to User A): SIP 2.0 200 OK Via: SIP/2.0/UDP usera.domain-a.com:5060;branch=z9hG4bK12345 To: Service From: UserA ;tag=d87fysdf8sdfy Call-ID: 843230@998sdasdh09 CSeq: 1 INVITE Content-Length: ... Content-Type: application/sdp v=0 o=media 53655765 2353687637 IN IP4 media-server.domain-b.com s=- t=0 0 c=IN IP4 media-server.domain-b.com m=audio 7890 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly Early media is now flowing from User B's media server to User A's device. Some time later, User B answers the phone and begins sending RTP packets to User A's device. These packets arrive ahead of the 200 OK to the INVITE sent to User B's device. User A's device detects packets with an RTP payload type of other than 96 (the selected early media payload type). Accordingly, it sends a BYE to the early-media dialog (not shown). The remaining messaging on the original INVITE dialog follows the normal SIP call setup procedures (not shown). 8. Security Considerations This document is a work in progress. Security considerations will be added as various recommendations become more concrete. 9. IANA Considerations This document defines the option-tag of "emind" which will require IANA registration. 10. References Stucker Expires August 16, 2007 [Page 16] Internet-Draft Early Media Indirection in SIP February 2007 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 10.2. Informational References [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [RFC3261] 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. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3960] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004. [I-D.stucker-sipping-early-media-coping] Stucker, B., "Coping with Early Media in the Session Initiation Protocol (SIP)", draft-stucker-sipping-early-media-coping-03 (work in progress), October 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 August 16, 2007 [Page 17] Internet-Draft Early Media Indirection in SIP February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 August 16, 2007 [Page 18]