diff options
Diffstat (limited to 'doc/rfc/rfc3087.txt')
| -rw-r--r-- | doc/rfc/rfc3087.txt | 2187 |
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc3087.txt b/doc/rfc/rfc3087.txt new file mode 100644 index 0000000..69e79c3 --- /dev/null +++ b/doc/rfc/rfc3087.txt @@ -0,0 +1,2187 @@ + + + + + + +Network Working Group B. Campbell +Request for Comments: 3087 R. Sparks +Category: Informational dynamicsoft + April 2001 + + + Control of Service Context using SIP Request-URI + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This memo provides information for the Internet community. It + describes a useful way to conceptualize the use of the standard SIP + (Session Initiation Protocol) Request-URI (Uniform Resource + Identifier) that the authors and many members of the SIP community + think is suitable as a convention. It does not define any new + protocol with respect to RFC 2543. + + In a conventional telephony environment, extended service + applications often use call state information, such as calling party, + called party, reason for forward, etc, to infer application context. + In a SIP/2.0 call, much of this information may be either non- + existent or unreliable. This document proposes a mechanism to + communicate context information to an application. Under this + proposal, a client or proxy can communicate context through the use + of a distinctive Request-URI. This document continues with examples + of how this mechanism could be used in a voice mail application. + + + + + + + + + + + + + + + +Campbell & Sparks Informational [Page 1] + +RFC 3087 SIP Service Control April 2001 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Example Application . . . . . . . . . . . . . . . . . . . 3 + 2.1 Using URIs to Control Voice Mail Service Behavior . . . . 3 + 3. Voice Mail Scenario Descriptions . . . . . . . . . . . . . 5 + 3.1 Deposits . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1.1 Direct Request to Deposit to a particular mailbox . . . . 5 + 3.1.1.1 SIP source . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1.1.2 Arbitrary PSTN source . . . . . . . . . . . . . . . . . . 5 + 3.1.1.3 Recognized PSTN source . . . . . . . . . . . . . . . . . . 6 + 3.1.2 Direct Request to Deposit, mailbox to be determined . . . 6 + 3.1.2.1 SIP source . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1.2.2 PSTN source . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1.2.3 Indirect Request to Deposit, due to find-me proxy decision 6 + 3.2 Retrievals . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2.1 Request to Retrieve from a particular mailbox . . . . . . 7 + 3.2.1.1 Trusted SIP source . . . . . . . . . . . . . . . . . . . . 7 + 3.2.1.2 Authenticated SIP source . . . . . . . . . . . . . . . . . 7 + 3.2.1.3 Unauthenticated SIP source . . . . . . . . . . . . . . . . 7 + 3.2.1.4 PSTN source . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2.2 Request to Retrieve, mailbox to be determined . . . . . . 7 + 3.2.2.1 SIP source . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2.2.2 Arbitrary PSTN source . . . . . . . . . . . . . . . . . . 8 + 3.2.2.3 Recognized PSTN source . . . . . . . . . . . . . . . . . . 8 + 4. Voice Mail Call Flow Examples . . . . . . . . . . . . . . 8 + 4.1 Generic Scenario . . . . . . . . . . . . . . . . . . . . . 8 + 4.1.1 Direct call to the voice mail system . . . . . . . . . . . 8 + 4.2 Message Deposit Scenarios . . . . . . . . . . . . . . . . 13 + 4.2.1 Call to known subscriber forwarded on no answer . . . . . 13 + 4.2.2 Call to known subscriber forwarded on busy . . . . . . . . 19 + 4.2.3 Direct call to a subscriber's mailbox . . . . . . . . . . 24 + 4.3 Message Retrieval Scenarios . . . . . . . . . . . . . . . 29 + 4.3.1 Call to retrieve messages believed to be from a known + subscriber . . . . . . . . . . . . . . . . . . . . . . . . 29 + 4.3.2 Call to retrieve messages from an authenticated subscriber 33 + 5. Security Considerations . . . . . . . . . . . . . . . . . 38 + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 38 + References . . . . . . . . . . . . . . . . . . . . . . . . 38 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . 38 + Full Copyright Statement . . . . . . . . . . . . . . . . . 39 + + + + + + + + + + +Campbell & Sparks Informational [Page 2] + +RFC 3087 SIP Service Control April 2001 + + +1. Introduction + + A communication service should make use of the information it has at + hand when being accessed. For example, in most current voice mail + implementations, a subscriber retrieving messages from his own desk + does not have to reenter his voice mailbox number - the service + assumes that the store being accessed is the one associated with the + endpoint being used to access the service. Some services allow the + user to validate this assumption using IVR techniques before + prompting for a PIN. + + This concept of context-awareness can be captured in a voice mail + service implementing SIP as defined in RFC 2543[1], without + modification, through the standard use of that protocol's Request- + URI. Furthermore, the concept is applicable to any SIP-based service + where initial application state should be determined from context. + + This concept is a usage convention of standard SIP as defined in RFC + 2543[1] and does not modify or extend that protocol in any way. + +2. Example Application + + In this document, we use the example of voice mail to illustrate the + technique. One motivation for applying this technique to this + problem is allowing a proxy or location server to control the initial + state of a voice service. For example, a voice client might register + a contact list ending with the URL that would accept voice messages + for the client. + +2.1 Using URIs to Control Voice Mail Service Behavior + + Many conventional voice mail systems use call state information, such + as the calling party, called party, reason for forward, etc, to + decide the initial application state. For example, it might play one + outgoing message if the call reached voice mail because the called + party did not answer and another if the line was busy. It decides + whom the message is for based on the called party information. If + the call originated from a subscriber's phone number, it might + authenticate the caller and then go directly to the message retrieval + and account maintenance menu. + + When a new subscriber is added to a system, a set of identities could + be generated, each given a unique sip URI. The following tables show + some of the identities that might be generated (it is not + exhaustive). The example schemes show that the URIs could, but don't + necessarily have to, have mnemonic value. + + + + + +Campbell & Sparks Informational [Page 3] + +RFC 3087 SIP Service Control April 2001 + + + In practical applications, it is important that an application does + not apply semantic rules to the various URIs. Instead, it should + allow any arbitrary string to be provisioned, and map the string to + the desired behavior. The owner of the system may choose to + provision mnemonic strings, but the application should not require + it. In any large installation, the system owner is likely to have + pre-existing rules for mnemonic URIs, and any attempt by an + application to define its own rules may create a conflict. For our + example, this means a voice mail system should allow an arbitrary mix + of URLs from these schemes, or any other scheme that renders valid + SIP URIs to be provisioned, rather than enforce one particular + scheme. + + URI Identity Example Scheme 1 + Example Scheme 2 + Example Scheme 3 + + Deposit with sip:sub-rjs-deposit@vm.wcom.com + standard greeting sip:677283@vm.wcom.com + sip:rjs@vm.wcom.com;mode=deposit + + + Deposit with on sip:sub-rjs-deposit-busy.vm.wcom.com + phone greeting sip:677372@vm.wcom.com + sip:rjs@vm.wcom.com;mode=3991243 + + Deposit with sip:sub-rjs-deposit-sg@vm.wcom.com + special greeting sip:677384@vm.wcom.com + sip:rjs@vm.wcom.com;mode=sg + + Retrieve - SIP sip:sub-rjs-retrieve@vm.wcom.com + authentication sip:677405@vm.wcom.com + sip:rjs@vm.wcom.com;mode=retrieve + + Retrieve - prompt sip:sub-rjs-retrieve-inpin.vm.wcom.com + for PIN in-band sip:677415@vm.wcom.com + sip:rjs@vm.wcom.com;mode=inpin + + When a service is first set up, identities such as the following + could be created. + + URI Identity Example Scheme 1 + Example Scheme 2 + Example Scheme 3 + + Deposit - sip:deposit@vm.wcom.com + identify target sip:670001@vm.wcom.com + mailbox by To: sip:deposit@vm.wcom.com + + + +Campbell & Sparks Informational [Page 4] + +RFC 3087 SIP Service Control April 2001 + + + Retrieve - sip:retrieve@vm.wcom.com + identify target sip:670002@vm.wcom.com + mailbox by SIP sip:retrieve@vm.wcom.com + authentication + + Deposit - prompt sip:deposit-in@vm.wcom.com + for target sip:670003@vm.wcom.com + mailbox in-band sip:deposit@vm.wcom.com;mode=inband + + Retrieve - prompt sip:retrieve-in@vm.wcom.com + for target sip:670004@vm.wcom.com + mailbox and PIN sip:retrieve@vm.wcom.com;mode=inband + in-band + + In addition to providing this set of URIs to the subscriber (to use + as he sees fit), an integrated service provider could add these to + the set of contacts in a find-me proxy. The proxy could then route + calls to the appropriate URI based on the origin of the request, the + subscriber's preferences and current state. + +3. Voice Mail Scenario Descriptions + + In each of these scenarios, the PSTN gateway is configured to + communicate only with a particular proxy-registrar. + +3.1 Deposits + +3.1.1 Direct Request to Deposit to a particular mailbox + +3.1.1.1 SIP source + + A SIP client that knew the URI for a particular deposit mailbox + (sip:sub-rjs-deposit@vm.wcom.com) could place a direct invitation to + the voicemail service, or through a protecting proxy. The proxy + could restrict access to deposit identities with special greetings by + authenticating the requester. + +3.1.1.2 Arbitrary PSTN source + + The gateway's proxy would map a call from an unrecognized PSTN number + to a number associated with a subscriber's mailbox into an invite to + the deposit with standard greeting URI (sip:sub-rjs- + deposit@vm.wcom.com). + + + + + + + + +Campbell & Sparks Informational [Page 5] + +RFC 3087 SIP Service Control April 2001 + + +3.1.1.3 Recognized PSTN source + + The gateway's proxy would map a call from a recognized (exact or + pattern match) PSTN number to a number associated with a subscriber's + mailbox into an invite to the appropriate special greeting URI + (sip:sub-rjs-deposit-sg@vm.wcom.com). The gateway's ability to + identify the calling party (using calling party number) is trusted, + so no further authentication of the requester is performed. + +3.1.2 Direct Request to Deposit, mailbox to be determined + +3.1.2.1 SIP source + + A voice mail service or its protecting proxy could expose a generic + deposit URL for use when a caller wished to go directly to voice + mail. The service would likely play an IVR dialog to determine what + message store to deposit a message into. + + An application designer may be tempted to attempt to match the To: + and From: headers on a call to infer information. However, this + approach could cause complications when multiple proxy forwards occur + in a call. For example, A calls B, who has all calls forwarded to C. + C forwards the call to her voice mail service. If the voice mail + service matches the To: header to determine the message store, it + will get the information for B instead of C. But there is no reason + to assume that C's voice mail service has any knowledge of B. + +3.1.2.2 PSTN source + + The gateway's proxy would map a call from an unrecognized PSTN number + to the top level voice mail service access number to an invite to the + Deposit - prompt for target mailbox in-band URI (sip:deposit- + in@vm.wcom.com for example). Getting the call to the target mailbox + would proceed as in the SIP source case. + +3.1.2.3 Indirect Request to Deposit, due to find-me proxy decision + + A find-me proxy could map an invitation to a subscriber + (sip:rjs@wcom.com) to the appropriate voice mail service URI + depending on the subscriber's current state. The normal deposit URI + could be chosen if the subscriber's contact list has been otherwise + exhausted with no answer. The busy-announcement URI would be chosen + when a busy everywhere response is received from one of the contacts. + A DND announcement URI could be selected if the subscriber had + activated DND. Calls to sip:receptionist@wcom.com could be configured + to roll to sip:deposit@wcom.com + + + + + +Campbell & Sparks Informational [Page 6] + +RFC 3087 SIP Service Control April 2001 + + +3.2 Retrievals + +3.2.1 Request to Retrieve from a particular mailbox + +3.2.1.1 Trusted SIP source + + A request to retrieve the contents of a particular mailbox (sip:sub- + rjs-retrieve@vm.wcom.com) coming from a trusted source could be + honored without further authentication checks. A trusted source is + one with which the voice mail service has secure communications, and + to which it is willing to delegate authentication. This could be the + service's protecting proxy for example. + +3.2.1.2 Authenticated SIP source + + A service, or its protecting proxy, could choose to honor a retrieve + request for a particular mailbox (sip:sub-rjs-retrieve@vm.wcom.com) + based on SIP authentication. If SIP level authentication failed, the + service or proxy could be configured to send the call to the in-band + pin prompting URI (sip:sub-rjs-retrieve-inpin@vm.wcom.com). + +3.2.1.3 Unauthenticated SIP source + + A service, or its protecting proxy, receiving a retrieve request for + a particular mailbox (sip:sub-rjs-retrieve@vm.wcom.com) with no other + method of authenticating the requestor could send the request to the + in-band pin prompting URI (sip:sub-rjs-retrieve-inpin@vm.wcom.com). + +3.2.1.4 PSTN source + + This scenario assumes that the service provider's network has been + configured such that a PSTN number could be dialed explicitly for + retrieving messages from a particular mailbox. Such services + currently exist, but are not common. In such a network, the + gateway's proxy would map the call to the in-band pin prompting URI + (sip:sub-rjs-retrieve-inpin@vm.wcom.com). + +3.2.2 Request to Retrieve, mailbox to be determined + +3.2.2.1 SIP source + + As in the Request to Deposit scenario, when a service receives a + request for the top level retrieve URI it would most likely need to + use in-band IVR techniques to determine the target mailbox and + authenticate the caller. + + + + + + +Campbell & Sparks Informational [Page 7] + +RFC 3087 SIP Service Control April 2001 + + +3.2.2.2 Arbitrary PSTN source + + This scenario assumes there is a single PSTN number that subscribers + dial to access the voice mail service to retrieve messages. This is + the most common access method provided by current voice mail + services. + + The gateway's proxy would map a call to the top level PSTN number to + the top level retrieve in-band prompting URI (sip:retrieve- + in@vm.wcom.com). Once the system identifies the target mailbox, the + call would be transferred to the appropriate in-band pin prompting + URI (sip:sub-rjs-retrieve-inpin@vm.wcom.com). + +3.2.2.3 Recognized PSTN source + + This scenario also assumes there is a single PSTN number that + subscribers dial to access the voice mail service to retrieve + messages. + + The gateway's proxy would recognize the calling party number as a + subscriber, and map the call to the subscriber's in-band prompting + URI (sip:sub-rjs-retrieve-inpin@vm.wcom.com) + +4. Voice Mail Call Flow Examples + + The following section describes some example call flows for a + hypothetical voice mail service, with the host name of vm.wcom.com. + All the call flows assume that a proxy protects the voice mail + service and that a trust relationship exists between the voice mail + service and the proxy. + +4.1 Generic Scenario + +4.1.1 Direct call to the voice mail system + + User A calls the voice mail system directly. The voice mail system + invokes the top-level menu, which might prompt the caller for an + extension or the first few letters of a name. + + + + + + + + + + + + + +Campbell & Sparks Informational [Page 8] + +RFC 3087 SIP Service Control April 2001 + + + User A Proxy VM Service + | | | + | INVITE F1 | | + |------------------>| | + | | INVITE F2 | + | (100 Trying) F3 |---------------------->| + |<------------------| | + | | 180 Ringing F4 | + | 180 Ringing F5 |<----------------------| + |<------------------| | + | | 200 OK F6 | + | 200 OK F6 |<----------------------| + |<------------------| | + | | | + | ACK F8 | | + |------------------>| ACK F9 | + | |---------------------->| + | | | + | RTP Established- Play top level menu | + |<-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m->| + | | | + | BYE F10 | | + |------------------>| BYE F11 | + | |---------------------->| + | | | + | | 200 OK F12 | + | |<----------------------| + | 200 OK F13 | | + |<------------------| | + | | | + + + Flow Id Comments + + INVITE F1 INVITE sip:VoiceMail@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Proxy-Authorization:Digest username="UserA", + realm="MCI WorldCom SIP", + nonce="ea9c8e88df84f1cc4e341ae6cbe5a359", opaque="", + uri="sip:VoiceMail@wcom.com", response=<appropriately + calculated hash goes here> + Content-Type: application/sdp + Content-Length: <appropriate value> + + + +Campbell & Sparks Informational [Page 9] + +RFC 3087 SIP Service Control April 2001 + + + 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:top@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060; branch=1 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:VoiceMail@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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 + + (100 Trying SIP/2.0 100 Trying + F3 Via: SIP/2.0/UDP here.com:5060 + Proxy->A) From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + 180 Ringing SIP/2.0 180 Ringing + F4 Via: SIP/2.0/UDP wcom.com:5060; branch=1 + VM->Proxy Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + + + +Campbell & Sparks Informational [Page 10] + +RFC 3087 SIP Service Control April 2001 + + + 180 Ringing SIP/2.0 180 Ringing + F5 Via: SIP/2.0/UDP here.com:5060 + Proxy->A From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + 200 OK F6 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060; branch=1 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:VoiceMail@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: VoiceMailSystem <sip:top@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.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 F7 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:VoiceMail@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact VoiceMailSystem <sip:top@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.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 + + + + +Campbell & Sparks Informational [Page 11] + +RFC 3087 SIP Service Control April 2001 + + + ACK F8 ACK sip:VoiceMail@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route:<sip:top@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + ACK F9 ACK sip:top@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>; tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + /* RTP streams are established between A and VM. VM + system starts IVR dialog for top level menu */ + + /* User A Hangs Up with VM system. Alternatively, the + VM system could initiate the BYE*/ + + BYE F10 BYE sip:VoiceMail@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route:<sip: top@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + BYE F11 BYE sip: top@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F12 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + + + +Campbell & Sparks Informational [Page 12] + +RFC 3087 SIP Service Control April 2001 + + + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F13 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + +4.2 Message Deposit Scenarios + +4.2.1 Call to known subscriber forwarded on no answer + + User A attempts to call UserB, who does not answer. The call is + forwarded to UserB's mailbox, and the voice mail system plays UserB's + outgoing message for a ring-no-answer. The flow assumes that the URL + of "sip:UserB-dep-fna@vm.wcom.com maps" to the desired behavior for + depositing a message on a forward-no-answer. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Campbell & Sparks Informational [Page 13] + +RFC 3087 SIP Service Control April 2001 + + + User A Proxy User B VM System + | | | | + | INVITE F1 | | | + |---------------->| INVITE F2 | | + | |----------------->| | + | (100 Trying) F3 | | | + |<----------------| 180 Ringing F4 | | + | |<-----------------| | + | 180 Ringing F5 | | | + |<----------------| (Request Timeout)| | + | | | | + | | Cancel F6 | | + | |----------------->| | + | | | | + | | 200 OK F7 | | + | |<-----------------| | + | | | | + | | INVITE F8 | + | |---------------------------------->| + | | | | + | | 200 OK F9| | + | 200 OK F10 |<----------------------------------| + |<----------------| | | + | | | | + | ACK F11 | | | + |---------------->| ACK F12 | | + | |---------------------------------->| + | | | | + | RTP Established Both Ways-Deposit Msg 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->| + | | | | + | BYE F13 | | | + |---------------->| BYE F14 | | + | |---------------------------------->| + | | | | + | | OK F15 | | + | OK F16 |<----------------------------------| + |<----------------| | | + | | | | + + + Flow Id Comments + + INVITE F1 INVITE sip:UserB@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com> + Call-Id: 12345600@here.com + + + +Campbell & Sparks Informational [Page 14] + +RFC 3087 SIP Service Control April 2001 + + + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Proxy-Authorization:Digest username="UserA", + realm="MCI WorldCom SIP", + nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", + uri="sip:UserB@wcom.com", response=<appropriately + calculated hash goes here> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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@somewhere.wcom.com SIP/2.0 + Proxy->B1 Via: SIP/2.0/UDP wcom.com:5060; branch=1 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:UserB@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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 + + (100 Trying SIP/2.0 100 Trying + F3 Via: SIP/2.0/UDP here.com:5060 + Proxy->A) From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + + +Campbell & Sparks Informational [Page 15] + +RFC 3087 SIP Service Control April 2001 + + + 180 Ringing SIP/2.0 180 Ringing + F4 Via: SIP/2.0/UDP wcom.com:5060; branch=1 + B1->Proxy Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + 180 Ringing SIP/2.0 180 Ringing + F5 Via: SIP/2.0/UDP here.com:5060 + Proxy->A From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + /* B1 rings for 9 seconds, this duration is a + configurable parameter in the Proxy Server. Proxy + sends Cancel and proceeds down the list of routes, + eventually hitting the voice mail URI for forward no + answer */ + + CANCEL F6 CANCEL sip:UserB1@wcom.com SIP/2.0 + Proxy->B1 Via: SIP/2.0/UDP wcom.com:5060; branch=1 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 CANCEL + Content-Length: 0 + + 200 OK F7 SIP/2.0 200 OK + B1->Proxy Via: SIP/2.0/UDP wcom.com:5060; branch=1 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 CANCEL + Content-Length: 0 + + + INVITE F8 INVITE sip:UserB-dep-fna@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060;branch=2 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:UserB@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + + + +Campbell & Sparks Informational [Page 16] + +RFC 3087 SIP Service Control April 2001 + + + Contact: TheBigGuy <sip:UserA@here.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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 + + 200 OK F9 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060; branch=2 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:UserB@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=123456 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheLittleGuyVoiceMail <sip:UserB-dep- + fna@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.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 F10 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:UserB@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=123456 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheLittleGuyVoiceMail <sip:UserB-dep- + fna@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.com + + + +Campbell & Sparks Informational [Page 17] + +RFC 3087 SIP Service Control April 2001 + + + 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 F11 ACK sip:UserB@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route:<sip: UserB-dep-fna@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=123456 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + ACK F12 ACK sip:UserB-dep-fna@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=123456 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + /* RTP streams are established between A and B2. VM + system starts IVR dialog for message-deposit on no- + answer for UserB */ + + /* User A Hangs Up with VM system. Alternatively, the + VM system could initiate the BYE*/ + + BYE F13 BYE sip:UserB@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route:<sip: UserB-dep-fna@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=123456 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + BYE F14 BYE sip: UserB-dep-fna@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=123456 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + + +Campbell & Sparks Informational [Page 18] + +RFC 3087 SIP Service Control April 2001 + + + 200 OK F15 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=123456 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F16 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=123456 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + +4.2.2 Call to known subscriber forwarded on busy + + User A attempts to call UserB, who is busy. The call is forwarded to + UserB's mailbox, and the voice mail system plays UserB's outgoing + message for a busy. This flow assumes that "sip:UserB-dep- + fb@vm.wcom.com" maps to UserB's mailbox and the behavior of "deposit + message on busy." + + + + + + + + + + + + + + + + + + + + + + + + + + + +Campbell & Sparks Informational [Page 19] + +RFC 3087 SIP Service Control April 2001 + + + User A Proxy User B VM System + | | | | + | INVITE F1 | | | + |---------------->| INVITE F2 | | + | |----------------->| | + | (100 Trying) F3 | | | + |<----------------| 486 Busy Here F4 | | + | |<-----------------| | + | | | | + | | ACK F5 | | + | |----------------->| | + | | | | + | | INVITE F6 | + | |---------------------------------->| + | | | | + | | 200 OK F7| | + | 200 OK F8 |<----------------------------------| + |<----------------| | | + | | | | + | ACK F9 | | | + |---------------->| ACK F10 | | + | |---------------------------------->| + | | | | + | RTP Established Both Ways-Deposit Msg 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->| + | | | | + | BYE F11 | | | + |---------------->| BYE F12 | | + | |---------------------------------->| + | | | | + | | OK F13 | | + | OK F14 |<----------------------------------| + |<----------------| | | + | | | | + + Flow Id Comments + + INVITE F1 INVITE sip:UserB@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Proxy-Authorization:Digest username="UserA", + realm="MCI WorldCom SIP", + nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", + uri="sip:UserB@wcom.com", response=<appropriately + + + +Campbell & Sparks Informational [Page 20] + +RFC 3087 SIP Service Control April 2001 + + + calculated hash goes here> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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@somewhere.wcom.com SIP/2.0 + Proxy->B1 Via: SIP/2.0/UDP wcom.com:5060; branch=1 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:UserB@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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 + + (100 Trying SIP/2.0 100 Trying + F3 Via: SIP/2.0/UDP here.com:5060 + Proxy->A) From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + 486 Busy SIP/2.0 486 Busy Here + Here F4 Via: SIP/2.0/UDP wcom.com:5060;branch=1 + B1->Proxy Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=123456 + + + +Campbell & Sparks Informational [Page 21] + +RFC 3087 SIP Service Control April 2001 + + + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + ACK F5 ACK sip: UserB1@wcom.com SIP/2.0 + Proxy->B Via: SIP/2.0/UDP wcom.com:5060; branch=1 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=123456 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + INVITE F6 INVITE sip:UserB-dep-fb@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060;branch=2 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:UserB@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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 + + 200 OK F7 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060; branch=2 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:UserB@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheLittleGuyVoiceMail <sip:UserB-dep- + fb@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.com + s=Session SDP + + + +Campbell & Sparks Informational [Page 22] + +RFC 3087 SIP Service Control April 2001 + + + 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 here.com:5060 + Record-Route: <sip:UserB@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact TheLittleGuyVoiceMail <sip:UserB-dep- + fb@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.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 F9 ACK sip:UserB@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route:<sip:UserB-dep-fb@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + ACK F10 ACK sip:UserB-dep-fb@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + /* RTP streams are established between A and B2. VM + system starts IVR dialog for message-deposit on busy + for UserB */ + + + + + +Campbell & Sparks Informational [Page 23] + +RFC 3087 SIP Service Control April 2001 + + + /* User A Hangs Up with VM system. Alternatively, the + VM system could initiate the BYE*/ + + BYE F11 BYE sip:UserB@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route: <sip:UserB-dep-fnb@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + BYE F12 BYE sip: UserB-dep-fnb@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F13 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F14 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuy <sip:UserB@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + +4.2.3 Direct call to a subscriber's mailbox + + User A calls UserB's mailbox directly. This flow assumes that + "sip:UserB-dep@vm.wcom.com" maps to UserB's mailbox and the behavior + of "generic message deposit" + + + + + + + + +Campbell & Sparks Informational [Page 24] + +RFC 3087 SIP Service Control April 2001 + + + User A Proxy VM Service + | | | + | INVITE F1 | | + |------------------>| | + | | INVITE F2 | + | (100 Trying) F3 |---------------------->| + |<------------------| | + | | 200 OK F4 | + | 200 OK F5 |<----------------------| + |<------------------| | + | | | + | ACK F6 | | + |------------------>| ACK F7 | + | |---------------------->| + | | | + | RTP Both Ways - Deposit Msg for B | + |<-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m->| + | | | + | BYE F8 | | + |------------------>| BYE F9 | + | |---------------------->| + | | | + | | 200 OK F10 | + | |<----------------------| + | 200 OK F11 | | + |<------------------| | + | | | + + Flow Id Comments + + INVITE F1 INVITE sip:UserB-VM@vm.wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB-VM@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Proxy-Authorization:Digest username="UserA", + realm="MCI WorldCom SIP", + nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", + uri="sip:UserB-VM@wcom.com", response=<appropriately + calculated hash goes here> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserA 2890844526 2890844526 IN IP4 client.here.com + s=Session SDP + + + +Campbell & Sparks Informational [Page 25] + +RFC 3087 SIP Service Control April 2001 + + + 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:UserB-dep@vm.wcom.com SIP/2.0 + Proxy->B1 Via: SIP/2.0/UDP wcom.com:5060; branch=1 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:UserB-VM@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB-VM@vm.wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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 + + (100 Trying SIP/2.0 100 Trying + F3 Via: SIP/2.0/UDP here.com:5060 + Proxy->A) From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB-VM@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + 200 OK F4 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060; branch=1 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:UserB-VM@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB- + VM@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheLittleGuyVoiceMail <sip:UserB- + dep@vm.wcom.com> + Content-Type: application/sdp + + + +Campbell & Sparks Informational [Page 26] + +RFC 3087 SIP Service Control April 2001 + + + Content-Length: <appropriate value> + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.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 F5 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:UserB-VM@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB- + VM@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact TheLittleGuyVoiceMail <sip:UserB- + dep@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.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 F6 ACK sip:UserB-VM@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route:<sip:UserB-dep@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB- + VM@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + ACK F7 ACK sip:UserB-dep@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB- + VM@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 ACK + + + +Campbell & Sparks Informational [Page 27] + +RFC 3087 SIP Service Control April 2001 + + + Content-Length: 0 + /* RTP streams are established between A and VM. VM + system starts IVR dialog for generic message-deposit + for UserB */ + + /* User A Hangs Up with VM system. Alternatively, the + VM system could initiate the BYE*/ + + BYE F8 BYE sip:UserB-VM@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route:<sip:UserB-dep@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB- + VM@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + BYE F9 BYE sip: UserB-dep@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB- + VM@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F10 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB- + VM@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F11 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: TheLittleGuyVoiceMail <sip:UserB- + VM@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + + + + +Campbell & Sparks Informational [Page 28] + +RFC 3087 SIP Service Control April 2001 + + +4.3 Message Retrieval Scenarios + +4.3.1 Call to retrieve messages believed to be from a known subscriber + + Some user uses a SIP client on UserA's desk to call the voice mail + system to retrieve messages. The SIP client has authenticated itself + to the proxy using credentials assigned to the device. The proxy can + make a weak assumption that the caller is the device owner. The URI + of "sip:UserA-retrieve@vm.wcom.com" maps to UserA's mailbox and the + behavior of "retrieve messages after prompting for and verifying + PIN." The VM System trusts the proxy, and will not accept calls from + an untrusted source. The proxy will not allow direct calls to + UserA-retrieve@vm.wcom.com. The proxy will forward calls placed to + VoiceMail@wcom.com to UserA-retrieve@vm.wcom.com only for calls + placed from a client device assigned to UserA. + + User A Proxy VM Service + | | | + | INVITE F1 | | + |------------------>| | + | | INVITE F2 | + | (100 Trying) F3 |---------------------->| + |<------------------| | + | | 200 OK F4 | + | 200 OK F5 |<----------------------| + |<------------------| | + | | | + | ACK F6 | | + |------------------>| ACK F7 | + | |---------------------->| + | | | + | RTP Both Ways - VM prompts for PIN + |<-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m->| + | | | + | BYE F8 | | + |------------------>| BYE F9 | + | |---------------------->| + | | | + | | 200 OK F10 | + | |<----------------------| + | 200 OK F11 | | + |<------------------| | + | | | + + + + + + + + +Campbell & Sparks Informational [Page 29] + +RFC 3087 SIP Service Control April 2001 + + + Flow Id Comments + + INVITE F1 INVITE sip:VoiceMail@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Proxy-Authorization:Digest username="UserAPhone", + realm="MCI WorldCom SIP", + nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", + uri="sip:VoiceMail@wcom.com", response=<appropriately + calculated hash goes here> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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:UserA-retrieve@vm.wcom.com SIP/2.0 + Proxy->B1 Via: SIP/2.0/UDP wcom.com:5060; branch=1 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:VoiceMail@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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 + + + + +Campbell & Sparks Informational [Page 30] + +RFC 3087 SIP Service Control April 2001 + + + (100 Trying SIP/2.0 100 Trying + F3 Via: SIP/2.0/UDP here.com:5060 + Proxy->A) From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + 200 OK F4 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060; branch=1 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:VoiceMail@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: VoiceMailSystem <sip:UserA- + retrieve@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.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 F5 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:VoiceMail@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact VoiceMailSystem <sip: UserA- + retrieve@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.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 + + + +Campbell & Sparks Informational [Page 31] + +RFC 3087 SIP Service Control April 2001 + + + ACK F6 ACK sip:VoiceMail@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route:<sip:UserA-retrieve@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + ACK F7 ACK sip:UserA-retrieve@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>; tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + /* RTP streams are established between A and VM. VM + determines that the call is likely from UserA, and + starts a message retrieval session, prompting for + PIN*/ + + /* User A Hangs Up with VM system. Alternatively, the + VM system could initiate the BYE*/ + + BYE F8 BYE sip: VoiceMail@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route:<sip:UserA-retrieve@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + BYE F9 BYE sip: UserA-retrieve@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F10 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + + + +Campbell & Sparks Informational [Page 32] + +RFC 3087 SIP Service Control April 2001 + + + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F11 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + +4.3.2 Call to retrieve messages from an authenticated subscriber + + UserA to call the voice mail system to retrieve messages. + Assumptions: The caller is authenticated using UserA's credentials. + "sip:UserA-retrieve-auth@vm.wcom.com" maps to UserA's mailbox and the + behavior of "retrieve messages." The voice mail service trusts the + proxy not to forward any calls to that URI unless the call is + authenticated to be from UserA. + + Given these assumptions, The VM service may choose not require a PIN + for calls to this URI. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Campbell & Sparks Informational [Page 33] + +RFC 3087 SIP Service Control April 2001 + + + User A Proxy VM Service + | | | + | INVITE F1 | | + |------------------>| | + | | INVITE F2 | + | (100 Trying) F3 |---------------------->| + |<------------------| | + | | 200 OK F4 | + | 200 OK F5 |<----------------------| + |<------------------| | + | | | + | ACK F6 | | + |------------------>| ACK F7 | + | |---------------------->| + | | | + | RTP Both Ways - Deposit Msg for B | + |<-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m-m->| + | | | + | BYE F8 | | + |------------------>| BYE F9 | + | |---------------------->| + | | | + | | 200 OK F10 | + | |<----------------------| + | 200 OK F11 | | + |<------------------| | + | | | + + Flow Id Comments + + INVITE F1 INVITE sip:VoiceMail@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Proxy-Authorization:Digest username="UserA", + realm="MCI WorldCom SIP", + nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", + uri="sip:VoiceMail@wcom.com", response=<appropriately + calculated hash goes here> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserA 2890844526 2890844526 IN IP4 client.here.com + s=Session SDP + + + +Campbell & Sparks Informational [Page 34] + +RFC 3087 SIP Service Control April 2001 + + + 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:UserA-retrieve-auth@vm.wcom.com SIP/2.0 + Proxy->B1 Via: SIP/2.0/UDP wcom.com:5060; branch=1 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:VoiceMail@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: TheBigGuy <sip:UserA@here.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + 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 + + (100 Trying SIP/2.0 100 Trying + F3 Via: SIP/2.0/UDP here.com:5060 + Proxy->A) From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com> + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Content-Length: 0 + + 200 OK F4 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060; branch=1 + Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:VoiceMail@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact: VoiceMailSystem <sip:UserA-retrieve- + auth@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + + +Campbell & Sparks Informational [Page 35] + +RFC 3087 SIP Service Control April 2001 + + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.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 F5 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + Record-Route: <sip:VoiceMail@wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 INVITE + Contact VoiceMailSystem <sip: UserA-retrieve- + auth@vm.wcom.com> + Content-Type: application/sdp + Content-Length: <appropriate value> + + v=0 + o=UserB 2890844527 2890844527 IN IP4 vm.wcom.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 F6 ACK sip:VoiceMail@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route: <sip:UserA-retrieve-auth@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + ACK F7 ACK sip:UserA-retrieve-auth@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>; tag=3145678 + Call-Id: 12345600@here.com + CSeq: 1 ACK + Content-Length: 0 + + + + + + +Campbell & Sparks Informational [Page 36] + +RFC 3087 SIP Service Control April 2001 + + + /* RTP streams are established between A and VM. VM + determines that the call is likely from UserA, and + starts a message retrieval session. Since the proxy + has already authenticated the identity of UserA, the + VM does not need to prompt for PIN. */ + + /* User A Hangs Up with VM system. Alternatively, the + VM system could initiate the BYE*/ + + BYE F8 BYE sip:VoiceMail@wcom.com SIP/2.0 + A->Proxy Via: SIP/2.0/UDP here.com:5060 + Route:<sip:UserA-retrieve-auth@vm.wcom.com> + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + BYE F9 BYE sip: UserA-retrieve-auth@vm.wcom.com SIP/2.0 + Proxy->VM Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F10 SIP/2.0 200 OK + VM->Proxy Via: SIP/2.0/UDP wcom.com:5060 + Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + 200 OK F11 SIP/2.0 200 OK + Proxy->A Via: SIP/2.0/UDP here.com:5060 + From: TheBigGuy <sip:UserA@here.com> + To: VoiceMail <sip:VoiceMail@wcom.com>;tag=3145678 + Call-Id: 12345600@here.com + CSeq: 2 BYE + Content-Length: 0 + + + + + + + + +Campbell & Sparks Informational [Page 37] + +RFC 3087 SIP Service Control April 2001 + + +5. Security Considerations + + This document discusses a usage of SIP/2.0 as defined by RFC 2543[1]. + It introduces no additions, modifications, or restrictions to the + protocol defined therein. Any implementation of the concepts in this + document is subject to the issues discussed there. + +6. Acknowledgments + + The authors would like to thank Chris Cunningham, Steve Donovan, Alan + Johnston, Henry Sinnreich, Kevin Summers, John Truetken, and Dean + Willis for their discussion of and contribution to this work. + +References + + [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, + "SIP: Session Initiation Protocol", RFC 2543, March 1999. + +Authors' Addresses + + Ben Campbell + dynamicsoft + 5100 Tennyson Parkway + Suite 1200 + Plano, TX 75024 + + EMail: bcampbell@dynamicsoft.com + + + Robert J. Sparks + dynamicsoft + 5100 Tennyson Parkway + Suite 1200 + Plano, TX 75024 + + EMail: rsparks@dynamicsoft.com + + + + + + + + + + + + + + + +Campbell & Sparks Informational [Page 38] + +RFC 3087 SIP Service Control April 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Campbell & Sparks Informational [Page 39] + |