SIPPING Working Group Jayshree Bharatia Internet Draft Sanjoy Sen Category: Standards Track Ray Yuhanna Expires on May 2002 Scott Orton Mark Watson NORTEL NETWORKS November 2001 Redirection Service Capability in SIP Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 Abstract SIP is selected as a session control protocol for many VOIP applications. Hence it should provide capabilities for supporting such redirection-based services as automatic call distribution for call centers, third-party voicemail, follow-me service etc. The concept of Call Redirection is implicit in the capabilities already defined for SIP Proxies and Clients. However, in order to allow redirection to be used as a component of other services (in particular voicemail), and in order to facilitate inter-working with existing services, these capabilities needs to operate in a consistent and well-defined way, and also need to support transfer of certain additional pieces of information, such as redirecting and redirected-to addresses, redirecting reason, redirection counter etc. This draft discusses this required set of information, evaluates existing work and proposes solution to this effect. Table of Contents SIP Voicemail Solutions November 2001 Status of this Memo................................................1 Abstract...........................................................1 1 Conventions used in this document ..............................2 2 Introduction: Redirection Services .............................2 3 Redirection Information ........................................3 4 Existing Mechanisms in SIP .....................................6 5 Other Solution Options .........................................7 6 Examples of using the Redirection Information ..................9 7 Security Considerations .......................................18 8 IANA Considerations ...........................................19 9 References ....................................................19 10 Acknowledgments .............................................19 11 Author's Address ............................................19 12 Full Copyright Statement ....................................19 1 Conventions used in this document 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 RFC-2119. 2 Introduction: Redirection Services Call redirection is a standard feature currently provided by the traditional PBX and CO switches in Enterprise/PSTN and ISDN networks. Typical applications for call redirection are in automatic call distribution (ACD) for call centers, third-party voicemail, follow-me service etc. Since SIP is being selected as a session control protocol for many VOIP applications, it becomes a natural choice for supporting such services and beyond. The concept of Call Redirection is implicit in the capabilities already defined for SIP Proxies and Clients. However, in order to allow redirection to be used as a component of other services (in particular voicemail), and in order to facilitate inter-working with existing redirection services, these capabilities needs to operate in a consistent and well-defined way, and also need to support transfer of certain additional pieces of information. The intention is not to duplicate ISDN Diversion services in SIP networks - the move to SIP based session control allows us the opportunity to redesign certain aspects of these legacy services and in particular allows us to move from a model in which services themselves are monolithically standardized, to one where the subject of standardization is 'service capabilities' which can be built into services by service providers or end-users. Nonetheless, attention must be paid to inter-working with legacy services. Usually this can be limited to capabilities for the Internet Draft Expires May 2002 [Page 2] SIP Voicemail Solutions November 2001 transfer of information associated, without impact on the functional behavior of the SIP elements. In order to understand what information may need to be carried between SIP entities and possible PSTN entities involved in the call, we examine first the services currently offered in the PSTN/ISDN. [Q.952] describes a list of redirection services for PSTN. SIP should contain capabilities, which allow services to be built at least as advanced as these, and hopefully considerably better. Examples, 1. Pre-configured call forwarding service to a certain destination address when the user is busy or not-available or does not reply 2. Per-call call forwarding service triggered by the called party themselves (call deflection) 3. A service, which notifies the calling party with redirected- to information, when a redirection occurs. Certain privacy restrictions need to be met while presenting the redirection information. 4. A service, which notifies the redirecting party with redirected-to information, when a redirection occurs. Certain privacy restrictions need to be met while presenting the redirection information. 5. The presentation of the address of the redirecting user to the user that the call is redirected to. 6. It should be possible to restrict the maximum number of times a call is forwarded (e.g., to avoid a loop). The above services should operate in a consistent manner for calls originating (terminating) in an IP network and terminating (originating) in the PSTN. 3 Redirection Information This section presents a non-exhaustive list of information elements that are required to be carried between call-control entities in support of services such as those listed above. For each such information element, we have provided a definition (i.e., WHAT is this information?), assessed its applicability (i.e., WHY is it useful?) and WHERE would it appear in current SIP messages. Voicemail is used as an example but the capabilities discussed here could be relevant to any service residing on a service platform to which a call is redirected. Internet Draft Expires May 2002 [Page 3] SIP Voicemail Solutions November 2001 In this context, there are two approaches to carry this information required by the service platform to perform the service: A) Service-specific: if the information is required to be understood only by the domain addressed in the Request-URI, then the information can be encoded on the left-hand-side of the Request-URI [RFC3087]. For example, the Request-URI for depositing a voicemail could be of the following form, indicating that the call should be directed to voicemail box 025643, and that the greeting should be the `busy' greeting: Vm025643_busy@myVoicemail.myProvider.com Approach (A) has the advantage of not requiring any specific client capabilities, but the disadvantage of potential obscurity in the provisioning of the service and the absence of a mechanism to authenticate the information. This also does not satisfy any privacy requirements as the subscriber information can be derived from the Request-URI. B) Generic: if the information may be required to be understood by other entities, then a standardized mechanism is required to carry it. In this case it would be more appropriate to use existing SIP headers. Approach (B) has the disadvantage that clients must support the `generic' information headers before they can access the service, but the advantage is that other entities (e.g., proxies, gateways) can see the information and thereby enhance the service (for instance by authenticating the information). The information we consider is as follows: 1) Calling party address, e.g., SIP URL, E.164 WHAT: The party who placed the call WHY: A voicemail system, for example, can provide special service based on recognition of certain address-domain or DN (e.g., play a different-than-normal greeting or allow out- calling from the voicemail system). WHERE: This information is carried in the From header and/or Remote-Party-ID, where privacy restrictions apply. In many cases a user may have multiple addresses a subset of which is understood by the redirection service (e.g., for certain legacy voicemail systems, this parameter can be a DN or a local number required by that system). Consider a scenario Internet Draft Expires May 2002 [Page 4] SIP Voicemail Solutions November 2001 where A calls B in SIP domain and the call is forwarded to B's voicemail in PSTN domain. Then, A's SIP URI in the From header is not adequate to represent A to the PSTN voicemail system. 2) Original called party address, e.g., SIP URL, E.164 WHAT: The original address called by the caller WHY: For our voicemail example, this would allow the system to locate the called party's mailbox WHERE: This is typically carried in the To header. As stated earlier, in many cases a user may have multiple addresses a subset of which is understood by the redirection service. 3) Redirected-to address, e.g., SIP URL, E.164 WHAT: The address towards which the call has been forwarded or must be forwarded WHY: Needed for routing the forwarded leg of the call and for notifying the calling party of the new destination of the call. Can also be used to provide special service contexts, e.g., different addresses for voice-mail and fax deposit/retrieval services in a unified messaging system. WHERE: For an INVITE forwarded onwards from the redirecting party, this information is just the Request-URI. 4) Redirecting address, e.g., SIP URL, E.164 WHAT: The address from which the call is redirected. For the first redirection, this is the same as the original called party address. WHY: In case the redirected-to party would need to know the redirecting party address, during multiple call forwarding. WHERE: If there is a single redirection, then this information is equal to the originally called party and so is carried in the To header. For multiple redirections, this information is not carried in any of current SIP headers, but could be encoded into the SIP URI if following approach (A). 5) Redirecting reason(s) WHAT: The reason for (each) redirection WHY: This information might be useful for presentation to the redirected-to party. A voicemail service can also use this information to play out the corresponding announcement. WHERE: No current SIP header carries this information, but could be encoded into the SIP URI if following approach (A). 6) Redirection counter Internet Draft Expires May 2002 [Page 5] SIP Voicemail Solutions November 2001 WHAT: A counter, which is incremented each time a redirection occurs during session set-up. WHY: Useful for eliminating possible loops or wastage of network resources, when a forwarding chain gets too long. Also, for an IP<->PSTN call, a separate counter is required to consolidate the number of call forwards in both the segments (IP and PSTN). This is required for a network provider operating both the segments. WHERE: Typically SIP uses the Max-Forwards header to limit the number of entities that a message can pass. However, this applies to every time a request passes a SIP entity and is not limited to redirection as discussed here. PRIVACY Requirement: There may be privacy restrictions in presenting the address information (e.g., called, calling, redirected-to, redirecting) of the party's involved in the call. At any point, the SIP UA or the Proxy should be able to hide the address information before sending a message containing the above information to an un- trusted party. The framework described in [Priv] can be used as discussed later in this draft. The above parameters need to be sent in the direction of the redirected-to party or service (downstream direction). For a simple voicemail service example, the mandatory parameters are calling party address, original called party address or redirecting address, the redirected-to address and the redirecting reason(s). In the upstream direction, parameters that may be used for redirection notification to the calling party are redirected-to address and the redirecting reason. All trusted SIP entities involved in redirection should be able to create and modify redirection information. 4 Existing Mechanisms in SIP The existing SIP protocol does not provide explicit mechanisms for carrying some of the information required for supporting redirection-based services. In particular, it does not provide a vehicle to carry some of the redirection information such as redirecting reasons, redirection counter and the redirecting address towards the redirected-to party. There is also no explicit way to carry some or all of this information to the calling party. [Div] provides a partial solution to the problem. It defines a new SIP header, Diversion, which conveys some, not all, of the redirection information. The Diversion header is added when a SIP Internet Draft Expires May 2002 [Page 6] SIP Voicemail Solutions November 2001 Proxy or an UA changes the destination of the call from that derived by normal routing. The main advantages of the Diversion header are that it creates a placeholder for all information that a re- directing service endpoint might need and is extensible. However, under the existing behavior, the calling party is not notified of the diversion information and the privacy issues are not dealt with. [Div] is also not a Working Group draft. [RFC3087] provides examples of using the Request-URI to carry the redirection address that would map to a specific mailbox service. Not only does this generate URI's that are cumbersome and difficult to parse, this also assumes that the UAC or Proxy have knowledge of the service context. It also has other shortcomings, stemming from the fact that information so encoded is only visible to the addressed domain. Devices between the client (or its proxy) and the service platform may need to see this information for two reasons: 1) Proxies may be required to authenticate this information 2) Gateways may be required to map this information into other systems So, without explicit mechanisms for carrying this information, it can only ever be authenticated by the entity inserting it (which may be the client) and can never be mapped into other systems. This latter point means that PSTN Voicemail servers could not be used to offer service to SIP endpoints and SIP voicemail servers could not be used to offer service to PSTN endpoints. In support of these scenarios we now consider options for explicit support of redirection information in SIP. 5 Other Solution Options 1) REMOTE-PARTY-ID Header: The primary use of this extension [Priv] is for communication of the identity of the parties with support of generic privacy requirements. The Remote-Party-ID (RPI) header can be easily extended to include all the information described in Section 3. Every time a redirection occurs, an RPI header is added, if required, with the of the redirecting party. A series of RPI headers are thus built up as multiple redirections occur, charting the history of the call. Similarly, RPI could be used to communicate the redirected-to address to the calling party in the 181 response. Internet Draft Expires May 2002 [Page 7] SIP Voicemail Solutions November 2001 Two new "rpi-pty-type" are defined: "redirecting" and "redirected- to". The other parameters, which in this case, characterize the identity of the redirecting and redirected-to party, such as redirecting reason, the order in the redirection list (redirection counter) etc., can be added as extensions. The extended syntax is as follows: Remote-Party-ID = "Remote-Party-ID" ":" [display-name]" <"addr- spec">" *(";" rpi-token) rpi-token = rpi-screen | rpi-pty-type | rpi-id-type | rpi- privacy | rpi-redirect | other-rpi-token | rpi-screen = "screen" "=" ("no" | "yes" ) rpi-pty-type = "party" "=" ( "calling" | "called" | "redirecting" | "redirected-to" | token ) rpi-id-type = "id-type" "=" ( "subscriber" | "user" |"alias" | "return" | "term" | token ) rpi-privacy = "privacy" "=" 1#(("full" | "name" | "uri" | "off" | token ) [ "-" ( "network" | token ) ] ) other-rpi-token = token ["-"] ["=" (token | quoted-string)] rpi-redirect = "redirect" "=" rpi-rd-count ["," rpi-rd-reason] rpi-id-count = 1*DIGIT rpi-rd-reason = "busy" | "noAnswer" | "unconditional" | token | quoted-string One important advantage of using RPI header for redirection is that it allows us to deal with the privacy issues. Since privacy is one of the more important requirements for any redirection-based service, we can effectively reuse an existing framework instead of re-inventing one for a new header. [Priv] is already a SIPPING Working Group draft and hence, has certain lead-time advantage. 2) STATE header: In [Dcs] usage, the UAC or UAS are not required to create or modify a State header. If used for redirection, the UAC/UAS should be able to create or modify a State header. In [Dcs] usage, a Proxy is not allowed to modify or delete State header information, unless the hostname parameter matches that of the Proxy's. If used to carry redirection information, any participating Proxy should be able to modify certain information (e.g., redirecting address, counter). The only way that [Dcs] deals with privacy issues is by mandating use of encryption. Apart from these differences, the State header is extensible and also flexible for exchanging redirection information between SIP entities. This is also a current WG draft. Internet Draft Expires May 2002 [Page 8] SIP Voicemail Solutions November 2001 3) COOKIE header: The Cookie header can also be used in a way similar to that of the State header (see above). When used in "participatory" mode, SIP entities are allowed to modify Cookie headers [Willis]. However, a Cookie is normally used when there is a need for storage and usage of persistent state information across sessions - this is not applicable to redirection. The other disadvantages are - the idea is still in its infancy, and this is currently not a WG draft. 6 Examples of using the Redirection Information In this section, we provide two examples of how the redirection information would be used in a voicemail system. The redirection information is carried in the Remote-Party-ID headers. Other redirection scenarios will be considered in future versions of the draft. Example 1: Call forward on busy The call flow depicts the following scenario - user A calls user B, but is forwarded by the Proxy to UserB's Voicemail Server (VMS) on busy. The Proxy determines the voicemail box address of UserB and inserts a RPI header in the INVITE. The Proxy sends the redirection information to A in an RPI header in 181 response. User A Proxy User B VMS | | | | | INVITE F1 | | | |---------------->| INVITE F2 | | | |----------------->| | | (100 Trying) F3 | | | |<----------------| 486 Busy F4 | | | |<-----------------| | | | | | | | INVITE F5 | |(181 Call Fwd) F6|---------------------------------->| |<----------------| | | | | 200 OK F7| | | 200 OK F8 |<----------------------------------| |<----------------| | | | | ACK F9 | | |---------------------------------------------------->| | | | | | RTP Established between A and voice-mail box for B | |<-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m->| Internet Draft Expires May 2002 [Page 9] SIP Voicemail Solutions November 2001 | | | | Flow Id Comments INVITE F1 INVITE sip:UserB@nortelnetworks.com SIP/2.0 A->Proxy Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /*Client for A prepares to receive data on port 49170 from the network. */ INVITE F2 INVITE sip:UserB1@ims.nortelnetworks.com SIP/2.0 Proxy->B1 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: BigGuy To: LittleGuy Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Internet Draft Expires May 2002 [Page 10] SIP Voicemail Solutions November 2001 (100 Trying SIP/2.0 100 Trying F3 Via: SIP/2.0/UDP here.com:5060 Proxy->A) From: BigGuy To: LittleGuy Call-Id: 12345600@here.com CSeq: 1 INVITE Content-Length: 0 486 Busy SIP/2.0 486 Busy F4 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1 B1->Proxy Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy ;tag=3 Call-Id: 12345600@here.com CSeq: 1 INVITE Content-Length: 0 INVITE F5 INVITE sip:VM@nortelnetworks.com SIP/2.0 Proxy->VM Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=2 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: BigGuy To: LittleGuy Call-Id: 12345600@here.com Remote-Party-ID: LittleGuy <9726852222>; screen=yes; party=redirecting; id-type=alias; redirect=1,busy CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 181 F6 SIP/2.0 181 Call is forwarding (Proxy->A) Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-Id: 12345600@here.com Internet Draft Expires May 2002 [Page 11] SIP Voicemail Solutions November 2001 Remote-Party-ID: TheVoiceMail; screen=yes; party=redirected-to; id-type=subscriber; redirect=1,busy CSeq: 1 INVITE Content-Length: 0 200 OK F7 SIP/2.0 200 OK VM->Proxy Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=2 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: BigGuy To: LittleGuy ;tag=3 Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: TheVoiceMail Content-Type: application/sdp Content-Length: v=0 o=UserB 2890844527 2890844527 IN IP4 vm.nortelnetworks.com s=Session SDP c=IN IP4 110.111.112.114 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 200 OK F8 SIP/2.0 200 OK Proxy->A Via: SIP/2.0/UDP nortelnetworks.com:5060; branch=2 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: BigGuy To: LittleGuy ;tag=3 Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: TheVoiceMail Content-Type: application/sdp Content-Length: v=0 o=UserB 2890844527 2890844527 IN IP4 vm.nortelnetworks.com s=Session SDP c=IN IP4 110.111.112.114 Internet Draft Expires May 2002 [Page 12] SIP Voicemail Solutions November 2001 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ACK F9 ACK sip:VM@nortelnetworks.com SIP/2.0 A->VM Via: SIP/2.0/UDP here.com:5060 Route: From: BigGuy To: LittleGuy ;tag=3 Call-Id: 12345600@here.com CSeq: 1 ACK Content-Length: 0 /* RTP streams are established between A and VMS. The VMS starts announcement for UserB */ Example 2: Multiple Call Forwarding In this example, UA A calls UA B through a Proxy. Proxy determines that B is busy and forwards the call to C, who is temporarily unavailable. The Proxy now forwards the call to B's VMS. A Proxy B C VMS | | | | | |--INVITE F1-->| | | | | | | | | | |--INVITE F2 ->| | | |<--100 F3 ----| | | | | |<-486 F4------| | | | | | | | |<---181 F5 ---| | | | | |--------INVITE F6---------->| | | | | | | | |<--------180 F7-------------| | |<---180 F8 ---| | | | | | | | | | . . . |--------INVITE------------->| | | | timeout | | |<---181 F9 ---| | | | | | | | | | |-------INVITE F10--------------------->| | | | | | Internet Draft Expires May 2002 [Page 13] SIP Voicemail Solutions November 2001 | |<-200 F11------------------------------| | | | | | |<-200-F12-----| | | | | | | | | |--ACK F13-------------------------------------------->| | | | | | | | | | | Flow Id Comments INVITE F1 INVITE sip:UserB@nortelnetworks.com SIP/2.0 A->Proxy Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /*Client for A prepares to receive data on port 49170 from the network. */ INVITE F2 INVITE sip:UserB1@ims.nortelnetworks.com SIP/2.0 Proxy->B1 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: BigGuy To: LittleGuy Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.here.com s=Session SDP Internet Draft Expires May 2002 [Page 14] SIP Voicemail Solutions November 2001 c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 (100 Trying SIP/2.0 100 Trying F3 Via: SIP/2.0/UDP here.com:5060 Proxy->A) From: BigGuy To: LittleGuy Call-Id: 12345600@here.com CSeq: 1 INVITE Content-Length: 0 486 Busy SIP/2.0 486 Busy F4 Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=1 B1->Proxy Via: SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy ;tag=3 Call-Id: 12345600@here.com CSeq: 1 INVITE Content-Length: 0 SIP/2.0 181 Call is forwarding 181 F5 Via: SIP/2.0/UDP here.com:5060 (Proxy->A) From: BigGuy To: LittleGuy Call-Id: 12345600@here.com Remote-Party-ID: PartyC <9726853333>; screen=yes; party=redirected-to; id-type=alias; redirect=1,busy CSeq: 1 INVITE Content-Length: 0 INVITE F6 INVITE sip:UserC1@nortelnetworks.com SIP/2.0 Proxy->C Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=2 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: BigGuy To: LittleGuy Call-Id: 12345600@here.com Remote-Party-ID: LittleGuy <9726852222 >; screen=yes; party=redirecting; id-type=alias; redirect=1,busy CSeq: 1 INVITE Contact: BigGuy Internet Draft Expires May 2002 [Page 15] SIP Voicemail Solutions November 2001 Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 180 Ring F7 SIP/2.0 180 Ringing C->Proxy Via: SIP/2.0/UDP there.com:5060 From: BigGuy To: LittleGuy ;tag=5 Call-ID: 12345600@here.com CSeq: 1 INVITE Content-Length: 0 F8 180 SIP/2.0 180 Ringing (Proxy->A) SIP/2.0/UDP here.com:5060 From: BigGuy To: LittleGuy Call-Id: 12345600@here.com CSeq: 1 INVITE Content-Length: 0 /* User C is not available. INVITE is sent multiple times until it times out. */ 181 F9 Via: SIP/2.0/UDP here.com:5060 (Proxy->A) From: BigGuy To: LittleGuy Call-Id: 12345600@here.com Remote-Party-ID: TheVoiceMail; screen=yes; party=redirected-to; id-type=subscriber; redirect=2,noAnswer CSeq: 1 INVITE Content-Length: 0 INVITE F10 INVITE sip:VM@nortelnetworks.com SIP/2.0 Proxy->VM Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: BigGuy To: LittleGuy Internet Draft Expires May 2002 [Page 16] SIP Voicemail Solutions November 2001 Call-Id: 12345600@here.com Remote-Party-ID: LittleGuy <9726852222>; screen=yes; party=redirecting; id-type=alias; redirect=1,busy Remote-Party-ID: PartyC <9726853333>; screen=yes; party=redirecting; id-type=alias; redirect=2,noAnswer CSeq: 1 INVITE Contact: BigGuy Content-Type: application/sdp Content-Length: v=0 o=UserA 2890844526 2890844526 IN IP4 client.here.com s=Session SDP c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 /* The proxy forwards the INVITE to VMS after adding two RPI headers */ 200 OK F11 SIP/2.0 200 OK VM->Proxy Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: BigGuy To: LittleGuy ;tag=3 Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: TheVoiceMail Content-Type: application/sdp Content-Length: v=0 o=UserB 2890844527 2890844527 IN IP4 vm.nortelnetworks.com s=Session SDP c=IN IP4 110.111.112.114 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 200 OK F12 SIP/2.0 200 OK Proxy->A Via: SIP/2.0/UDP ims.nortelnetworks.com:5060;branch=3 Internet Draft Expires May 2002 [Page 17] SIP Voicemail Solutions November 2001 Via: SIP/2.0/UDP here.com:5060 Record-Route: From: BigGuy To: LittleGuy ;tag=3 Call-Id: 12345600@here.com CSeq: 1 INVITE Contact: TheVoiceMail Content-Type: application/sdp Content-Length: v=0 o=UserB 2890844527 2890844527 IN IP4 vm.nortelnetworks.com s=Session SDP c=IN IP4 110.111.112.114 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 ACK F13 ACK sip:VM@nortelnetworks.com SIP/2.0 A->VM Via: SIP/2.0/UDP here.com:5060 Route: From: BigGuy To: LittleGuy ;tag=3 Call-Id: 12345600@here.com CSeq: 1 ACK Content-Length: 0 /* RTP streams are established between A and VMS. VMS starts announcement for UserB */ 7 Security Considerations In the proposed usage of RPI header, the security considerations discussed in [Priv] applies. If the RPI header is received by an un- trusted entity, the header may be discarded. For proper usage of the RPI header in this context, it is required that there is a trust relationship between the redirecting and redirected-to parties. Integrity protection of messages carrying the RPI header towards the service endpoint is of utmost importance, as a possible man-in-the- middle attack can easily modify header information and subvert the service. Internet Draft Expires May 2002 [Page 18] SIP Voicemail Solutions November 2001 8 IANA Considerations The new tokens defined as extensions to the RPI header fields need to be registered with IANA. 9 References [RFC3087] "Control of Service Context using SIP Request-URI" [Div] "Diversion Indication in SIP", draft-levy-sip-diversion- 02.txt [Priv] "SIP Extensions for Caller Identity and Privacy", draft- ietf-sip-privacy-02.txt [Willis] "SIP Cookies", draft-willis-sip-cookies-00.txt [Dcs] "SIP Extensions for supporting distributed call state", draft-ietf-sip-state-02.txt [Q.952] "Stage 3 Service Description for Call Offering Supplementary Services using DSS 1 - Diversion Supplementary Services" 10 Acknowledgments The authors would like to thank Francois Audet, Mary Barnes, Anthony Brown, Chris Hogg (Nortel) and Ari Immonen (Tecnomen) for their useful comments and suggestions related to this draft. 11 Author's Address Sanjoy Sen Nortel Networks sanjoy@nortelnetworks.com Jayshree Bharatia Nortel Networks bharatia@nortelnetworks.com Ray Yuhanna Nortel Networks yuhanna@nortelnetworks.com Scott Orton Nortel Networks orton@nortelnetworks.com Mark Watson Nortel Networks mwatson@nortelnetworks.com 12 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. Internet Draft Expires May 2002 [Page 19] SIP Voicemail Solutions November 2001 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Internet Draft Expires May 2002 [Page 20]