Caller Preferences for the Session Initiation Protocol (SIP)
RFC 3841

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 10

Network Working Group                                       J. Rosenberg
Request for Comments: 3841                                   dynamicsoft
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                              P. Kyzivat
                                                           Cisco Systems
                                                             August 2004

      Caller Preferences for the Session Initiation Protocol (SIP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes a set of extensions to the Session Initiation
   Protocol (SIP) which allow a caller to express preferences about
   request handling in servers.  These preferences include the ability
   to select which Uniform Resource Identifiers (URI) a request gets
   routed to, and to specify certain request handling directives in
   proxies and redirect servers.  It does so by defining three new
   request header fields, Accept-Contact, Reject-Contact, and Request-
   Disposition, which specify the caller's preferences.

Rosenberg, et al.           Standards Track                     [Page 1]
RFC 3841               Caller Preferences for SIP            August 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  4
   5.  UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  5
       5.1.  Request Handling Preferences . . . . . . . . . . . . . .  6
       5.2.  Feature Set Preferences  . . . . . . . . . . . . . . . .  6
   6.  UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . .  9
       7.1.  Request-Disposition Processing . . . . . . . . . . . . .  9
       7.2.  Preference and Capability Matching . . . . . . . . . . .  9
             7.2.1. Extracting Explicit Preferences . . . . . . . . . 10
             7.2.2. Extracting Implicit Preferences . . . . . . . . . 10
                    7.2.2.1. Methods. . . . . . . . . . . . . . . . . 10
                    7.2.2.2. Event Packages . . . . . . . . . . . . . 11
             7.2.3. Constructing Contact Predicates . . . . . . . . . 11
             7.2.4. Matching. . . . . . . . . . . . . . . . . . . . . 12
             7.2.5. Example . . . . . . . . . . . . . . . . . . . . . 16
   8.  Mapping Feature Parameters to a Predicate. . . . . . . . . . . 17
   9.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 19
       9.1.  Request Disposition  . . . . . . . . . . . . . . . . . . 20
       9.2.  Accept-Contact and Reject-Contact Header Fields  . . . . 21
   10. Augmented BNF  . . . . . . . . . . . . . . . . . . . . . . . . 22
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
       14.1. Normative References . . . . . . . . . . . . . . . . . . 24
       14.2. Informative References . . . . . . . . . . . . . . . . . 24
   15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
   16. Full Copyright Statements. . . . . . . . . . . . . . . . . . . 26

1.  Introduction

   When a Session Initiation Protocol (SIP) [1] server receives a
   request, there are a number of decisions it can make regarding the
   processing of the request.  These include:

   o  whether to proxy or redirect the request

   o  which URIs to proxy or redirect to

   o  whether to fork or not

   o  whether to search recursively or not

Rosenberg, et al.           Standards Track                     [Page 2]
RFC 3841               Caller Preferences for SIP            August 2004

   o  whether to search in parallel or sequentially

   The server can base these decisions on any local policy.  This policy
   can be statically configured, or can be based on execution of a
   program or database access.

   However, the administrator of the server is the not the only entity
   with an interest in request processing.  There are at least three
   parties which have an interest: (1) the administrator of the server,
   (2) the user that sent the request, and (3) the user to whom the