rfc3087.txt

RFC 的详细文档！

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:[e-mail]
      standard greeting       sip:[e-mail]
                                   sip:[e-mail];mode=deposit


      Deposit with on    sip:sub-rjs-deposit-busy.vm.wcom.com
      phone greeting          sip:[e-mail]
                                   sip:[e-mail];mode=3991243

      Deposit with       sip:[e-mail]
      special greeting        sip:[e-mail]
                                   sip:[e-mail];mode=sg

      Retrieve - SIP     sip:[e-mail]
      authentication          sip:[e-mail]
                                   sip:[e-mail];mode=retrieve

      Retrieve - prompt  sip:sub-rjs-retrieve-inpin.vm.wcom.com
      for PIN in-band         sip:[e-mail]
                                   sip:[e-mail];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:[e-mail]
      identify target         sip:[e-mail]
      mailbox by To:               sip:[e-mail]



Campbell & Sparks            Informational                      [Page 4]

RFC 3087                  SIP Service Control                 April 2001


      Retrieve -         sip:[e-mail]
      identify target         sip:[e-mail]
      mailbox by SIP               sip:[e-mail]
      authentication

      Deposit - prompt   sip:[e-mail]
      for target              sip:[e-mail]
      mailbox in-band              sip:[e-mail];mode=inband

      Retrieve - prompt  sip:[e-mail]
      for target              sip:[e-mail]
      mailbox and PIN              sip:[e-mail];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:[e-mail]) 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-
   [e-mail]).








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:[e-mail]).  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-
   [e-mail] 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:[e-mail]) to the appropriate voice mail service URI
   depending on the subscriber's current state.  The normal deposit URI