RFC4596 日本語訳
4596 Guidelines for Usage of the Session Initiation Protocol (SIP)Caller Preferences Extension. J. Rosenberg, P. Kyzivat. July 2006. (Format: TXT=82954 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg
Request for Comments: 4596 P. Kyzivat
Category: Informational Cisco Systems
July 2006
Network Working Group J. Rosenberg Request for Comments: 4596 P. Kyzivat Category: Informational Cisco Systems July 2006
Guidelines for Usage of the Session Initiation Protocol (SIP)
Caller Preferences Extension
Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension
Status of This Memo
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.
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 Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
Abstract
Abstract
This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841.
This document contains guidelines for usage of the Caller Preferences Extension to the Session Initiation Protocol (SIP). It demonstrates the benefits of caller preferences with specific example applications, provides use cases to show proper operation, provides guidance on the applicability of the registered feature tags, and describes a straightforward implementation of the preference and capability matching algorithm specified in Section 7.2 of RFC 3841.
Rosenberg & Kyzivat Informational [Page 1] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 1] RFC 4596 Caller Preferences Uses July 2006
Table of Contents
Table of Contents
1. Introduction ....................................................4
2. Motivations for Caller Preferences ..............................5
2.1. One-Number .................................................7
2.2. Direct-to-Voicemail ........................................7
3. Caller Preference Use Cases .....................................8
3.1. Routing of INVITE and MESSAGE to Different UA ..............8
3.1.1. Desired Behavior ....................................8
3.1.2. Solution ............................................9
3.2. Single Contact Not Matching Implicit Preferences ..........10
3.2.1. Desired Behavior ...................................10
3.2.2. Solution ...........................................10
3.3. Package-Based Routing .....................................11
3.3.1. Desired Behavior ...................................11
3.3.2. Solution ...........................................11
3.4. Package Routing II ........................................12
3.4.1. Desired Behavior ...................................12
3.4.2. Solution ...........................................13
3.5. Audio/Video vs. Audio Only ................................13
3.5.1. Desired Behavior ...................................13
3.5.2. Solution ...........................................14
3.6. Forcing Audio/Video .......................................15
3.6.1. Desired Behavior ...................................15
3.6.2. Solution ...........................................15
3.7. Third-Party Call Control: Forcing Media ...................16
3.7.1. Desired Behavior ...................................16
3.7.2. Solution ...........................................16
3.8. Maximizing Media Overlaps .................................17
3.8.1. Desired Behavior ...................................17
3.8.2. Solution ...........................................17
3.9. Multilingual Lines ........................................18
3.9.1. Desired Behavior ...................................18
3.9.2. Solution ...........................................19
3.10. I Hate Voicemail! ........................................20
3.10.1. Desired Behavior ..................................20
3.10.2. Solution ..........................................20
3.11. I Hate People! ...........................................21
3.11.1. Desired Behavior ..................................21
3.11.2. Solution ..........................................21
3.12. Prefer Voicemail .........................................22
3.12.1. Desired Behavior ..................................22
3.12.2. Solution ..........................................22
3.13. Routing to an Executive ..................................22
3.13.1. Desired Behavior ..................................22
3.13.2. Solution ..........................................22
1. Introduction ....................................................4 2. Motivations for Caller Preferences ..............................5 2.1. One-Number .................................................7 2.2. Direct-to-Voicemail ........................................7 3. Caller Preference Use Cases .....................................8 3.1. Routing of INVITE and MESSAGE to Different UA ..............8 3.1.1. Desired Behavior ....................................8 3.1.2. Solution ............................................9 3.2. Single Contact Not Matching Implicit Preferences ..........10 3.2.1. Desired Behavior ...................................10 3.2.2. Solution ...........................................10 3.3. Package-Based Routing .....................................11 3.3.1. Desired Behavior ...................................11 3.3.2. Solution ...........................................11 3.4. Package Routing II ........................................12 3.4.1. Desired Behavior ...................................12 3.4.2. Solution ...........................................13 3.5. Audio/Video vs. Audio Only ................................13 3.5.1. Desired Behavior ...................................13 3.5.2. Solution ...........................................14 3.6. Forcing Audio/Video .......................................15 3.6.1. Desired Behavior ...................................15 3.6.2. Solution ...........................................15 3.7. Third-Party Call Control: Forcing Media ...................16 3.7.1. Desired Behavior ...................................16 3.7.2. Solution ...........................................16 3.8. Maximizing Media Overlaps .................................17 3.8.1. Desired Behavior ...................................17 3.8.2. Solution ...........................................17 3.9. Multilingual Lines ........................................18 3.9.1. Desired Behavior ...................................18 3.9.2. Solution ...........................................19 3.10. I Hate Voicemail! ........................................20 3.10.1. Desired Behavior ..................................20 3.10.2. Solution ..........................................20 3.11. I Hate People! ...........................................21 3.11.1. Desired Behavior ..................................21 3.11.2. Solution ..........................................21 3.12. Prefer Voicemail .........................................22 3.12.1. Desired Behavior ..................................22 3.12.2. Solution ..........................................22 3.13. Routing to an Executive ..................................22 3.13.1. Desired Behavior ..................................22 3.13.2. Solution ..........................................22
Rosenberg & Kyzivat Informational [Page 2] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 2] RFC 4596 Caller Preferences Uses July 2006
3.14. Speak to the Executive ...................................23
3.14.1. Desired Behavior ..................................23
3.14.2. Solution ..........................................24
3.15. Mobile Phone Only ........................................24
3.15.1. Desired Behavior ..................................24
3.15.2. Solution ..........................................24
3.16. Simultaneous Languages ...................................25
3.16.1. Desired Behavior ..................................25
3.16.2. Solution ..........................................25
3.17. The Number You Have Called... ............................26
3.17.1. Desired Behavior ..................................26
3.17.2. Solution ..........................................26
3.18. The Number You Have Called, Take Two .....................27
3.18.1. Desired Behavior ..................................27
3.18.2. Solution ..........................................27
3.19. Forwarding to a Colleague ................................28
3.19.1. Desired Behavior ..................................28
3.19.2. Solution ..........................................28
4. Capability Use Cases ...........................................30
4.1. Web Redirect ..............................................30
4.2. Voicemail Icon ............................................30
5. Usage of the Feature Tags ......................................31
5.1. Traditional Cell Phone ....................................31
5.2. Traditional Work Phone ....................................32
5.3. PC Messaging Application ..................................32
5.4. Standalone Videophone .....................................33
6. Example of Implementation of Preference and Capability
Matching .......................................................33
6.1. Extracting a Feature Set from a Header ....................34
6.2. Extracting Values from a Feature Parameter ................35
6.3. Comparing Two Value-Ranges ................................36
6.4. Feature Set to Feature Set Matching .......................36
6.5. Selecting and Ordering Contacts Based on Caller
Preferences ...............................................37
6.5.1. Reject-Contact Processing ..........................37
6.5.2. Accept-Contact Processing ..........................37
7. Security Considerations ........................................38
8. Acknowledgements ...............................................38
9. Informative References .........................................38
3.14. Speak to the Executive ...................................23 3.14.1. Desired Behavior ..................................23 3.14.2. Solution ..........................................24 3.15. Mobile Phone Only ........................................24 3.15.1. Desired Behavior ..................................24 3.15.2. Solution ..........................................24 3.16. Simultaneous Languages ...................................25 3.16.1. Desired Behavior ..................................25 3.16.2. Solution ..........................................25 3.17. The Number You Have Called... ............................26 3.17.1. Desired Behavior ..................................26 3.17.2. Solution ..........................................26 3.18. The Number You Have Called, Take Two .....................27 3.18.1. Desired Behavior ..................................27 3.18.2. Solution ..........................................27 3.19. Forwarding to a Colleague ................................28 3.19.1. Desired Behavior ..................................28 3.19.2. Solution ..........................................28 4. Capability Use Cases ...........................................30 4.1. Web Redirect ..............................................30 4.2. Voicemail Icon ............................................30 5. Usage of the Feature Tags ......................................31 5.1. Traditional Cell Phone ....................................31 5.2. Traditional Work Phone ....................................32 5.3. PC Messaging Application ..................................32 5.4. Standalone Videophone .....................................33 6. Example of Implementation of Preference and Capability Matching .......................................................33 6.1. Extracting a Feature Set from a Header ....................34 6.2. Extracting Values from a Feature Parameter ................35 6.3. Comparing Two Value-Ranges ................................36 6.4. Feature Set to Feature Set Matching .......................36 6.5. Selecting and Ordering Contacts Based on Caller Preferences ...............................................37 6.5.1. Reject-Contact Processing ..........................37 6.5.2. Accept-Contact Processing ..........................37 7. Security Considerations ........................................38 8. Acknowledgements ...............................................38 9. Informative References .........................................38
Rosenberg & Kyzivat Informational [Page 3] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 3] RFC 4596 Caller Preferences Uses July 2006
1. Introduction
1. Introduction
The Session Initiation Protocol (SIP) [1] extension for Callee Capabilities [2] describes mechanisms that allow a UA (User Agent) to register its capabilities in a REGISTER request. A caller can express preferences, either explicitly or implicitly, about how that request is to be handled. This is accomplished with the Accept- Contact and Reject-Contact header fields described in Caller Preferences for the Session Initiation Protocol[3].
The Session Initiation Protocol (SIP) [1] extension for Callee Capabilities [2] describes mechanisms that allow a UA (User Agent) to register its capabilities in a REGISTER request. A caller can express preferences, either explicitly or implicitly, about how that request is to be handled. This is accomplished with the Accept- Contact and Reject-Contact header fields described in Caller Preferences for the Session Initiation Protocol[3].
The caller preferences extension can serve as a useful tool for supporting many applications. However, its generality makes it difficult to use correctly and effectively in any one situation. To remedy that, this document serves as a compendium of examples of the usage of the caller preferences extension.
The caller preferences extension can serve as a useful tool for supporting many applications. However, its generality makes it difficult to use correctly and effectively in any one situation. To remedy that, this document serves as a compendium of examples of the usage of the caller preferences extension.
NOTE: This document is intended to assist the reader in
understanding RFCs 3840 and 3841. It is not intended to serve as
a substitute for reading those documents. The examples presented
in this document cannot be fully understood without awareness of
the mechanisms defined in RFCs 3840 and 3841.
NOTE: This document is intended to assist the reader in understanding RFCs 3840 and 3841. It is not intended to serve as a substitute for reading those documents. The examples presented in this document cannot be fully understood without awareness of the mechanisms defined in RFCs 3840 and 3841.
First, Section 2 demonstrates the benefits of using caller preferences by describing several concrete applications that are enabled by the extension. Section 3 describes a set of detailed use cases for expressing caller preferences. Each use case presents a situation, describes how caller preferences can be used to handle the requirements for the situation, and verifies that the desired behavior occurs by showing the results of the matching operation. These use cases validate that the caller preferences specification is complete and capable of meeting a specific set of requirements. Since the caller preferences specification predates the SIP change process [4], no requirements document was ever published for it. To some degree, this document "backfills" requirements. However, this is not an academic exercise only, since the use cases described here did result in changes in the caller preferences document as it evolved. These use cases also help implementors figure out how to use caller preferences in their own applications.
First, Section 2 demonstrates the benefits of using caller preferences by describing several concrete applications that are enabled by the extension. Section 3 describes a set of detailed use cases for expressing caller preferences. Each use case presents a situation, describes how caller preferences can be used to handle the requirements for the situation, and verifies that the desired behavior occurs by showing the results of the matching operation. These use cases validate that the caller preferences specification is complete and capable of meeting a specific set of requirements. Since the caller preferences specification predates the SIP change process [4], no requirements document was ever published for it. To some degree, this document "backfills" requirements. However, this is not an academic exercise only, since the use cases described here did result in changes in the caller preferences document as it evolved. These use cases also help implementors figure out how to use caller preferences in their own applications.
Section 4 discusses applications for the callee capabilities specification. Section 5 discusses the example registrations of the feature tags described in [2]. Proper usage of the caller preferences extension depends on proper interpretation of the semantics of these tags. More detail is provided on the tags, and example registrations are included that show typical usage.
Section 4 discusses applications for the callee capabilities specification. Section 5 discusses the example registrations of the feature tags described in [2]. Proper usage of the caller preferences extension depends on proper interpretation of the semantics of these tags. More detail is provided on the tags, and example registrations are included that show typical usage.
Rosenberg & Kyzivat Informational [Page 4] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 4] RFC 4596 Caller Preferences Uses July 2006
Section 6 outlines an implementation approach to the matching algorithm that doesn't require RFC 2533 [6] to be implemented in all its generality.
Section 6 outlines an implementation approach to the matching algorithm that doesn't require RFC 2533 [6] to be implemented in all its generality.
2. Motivations for Caller Preferences
2. Motivations for Caller Preferences
At its core, SIP is a protocol that facilitates rendezvous of users. The caller and callee need to meet up in order to exchange session information, so that they may communicate. The rendezvous process is complicated by the fact that a user has multiple points of attachment to the network. A called user (callee) can have a cell phone, a PDA, a work phone, a home phone, and one of several PC-based communications applications. When someone calls that user, to which of these devices is the call routed?
At its core, SIP is a protocol that facilitates rendezvous of users. The caller and callee need to meet up in order to exchange session information, so that they may communicate. The rendezvous process is complicated by the fact that a user has multiple points of attachment to the network. A called user (callee) can have a cell phone, a PDA, a work phone, a home phone, and one of several PC-based communications applications. When someone calls that user, to which of these devices is the call routed?
Certainly, the call can be routed to all of them at the same time, a process known as parallel forking. However, that is not always the desired behavior. Users may prefer that their registered devices be tried in a particular order. As an example, a user might prefer that his cell phone ring first, and if no one answers, that his work phone ring next. Another user might prefer that her cell phone ring first, and then her home and work phones ring at the same time, and then, if no one answers either of those, that the call be forwarded to voicemail. These variations are all referred to as find-me/ follow-me features.
Certainly, the call can be routed to all of them at the same time, a process known as parallel forking. However, that is not always the desired behavior. Users may prefer that their registered devices be tried in a particular order. As an example, a user might prefer that his cell phone ring first, and if no one answers, that his work phone ring next. Another user might prefer that her cell phone ring first, and then her home and work phones ring at the same time, and then, if no one answers either of those, that the call be forwarded to voicemail. These variations are all referred to as find-me/ follow-me features.
SIP supports find-me/follow-me features in many ways. The most basic is through the SIP registration process. Each device at which a user can be contacted registers to the network. This registration associates the device with the canonical name of the user, called the address-of-record (AOR), which is a SIP URI. Each registration can include a preference value, indicating the relative preference for receiving calls at that device, compared to other devices. When someone makes a call to the AOR, proxies compliant to RFC 3261 will try the registered devices in order of preference, unless administrative policy overrides user preferences.
SIP supports find-me/follow-me features in many ways. The most basic is through the SIP registration process. Each device at which a user can be contacted registers to the network. This registration associates the device with the canonical name of the user, called the address-of-record (AOR), which is a SIP URI. Each registration can include a preference value, indicating the relative preference for receiving calls at that device, compared to other devices. When someone makes a call to the AOR, proxies compliant to RFC 3261 will try the registered devices in order of preference, unless administrative policy overrides user preferences.
Preference values in SIP registrations can only provide basic find- me/follow-me features. To support more complex features, the Call Processing Language (CPL) [5] has been specified. It is an XML script that provides specific call routing instructions. Users can upload these scripts to the network, instructing the servers how calls should be routed. As an example, a CPL script can instruct a proxy to route a call to the work phone during work hours (9 am - 5 pm) and then to the cell phone after hours, unless the call is from a family member, in which case it always goes to the cell phone.
Preference values in SIP registrations can only provide basic find- me/follow-me features. To support more complex features, the Call Processing Language (CPL) [5] has been specified. It is an XML script that provides specific call routing instructions. Users can upload these scripts to the network, instructing the servers how calls should be routed. As an example, a CPL script can instruct a proxy to route a call to the work phone during work hours (9 am - 5 pm) and then to the cell phone after hours, unless the call is from a family member, in which case it always goes to the cell phone.
Rosenberg & Kyzivat Informational [Page 5] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 5] RFC 4596 Caller Preferences Uses July 2006
It is important to note that both CPL scripts and preference values in registrations describe operation of a service from the perspective of the called party. That is, they describe how a call made to the called party should be routed by the network. However, the called party is not the only one with preferences. A caller will also have preferences for how they want their call to be routed. As an example, a caller will often want to reach a user on their cell phone. In the current telephone network, this is accomplished by requiring a user to have a separate number for each device. This way, when a caller wishes to reach the cell phone, they dial the number for the cell phone. This requires users to maintain lists of potential reach numbers for a user, and then select the appropriate one. A far better approach is for a user to maintain a single address-of-record. When someone wishes to reach them on their cell phone, they call the AOR, but indicate a preference for the call to be routed to the cell phone.
It is important to note that both CPL scripts and preference values in registrations describe operation of a service from the perspective of the called party. That is, they describe how a call made to the called party should be routed by the network. However, the called party is not the only one with preferences. A caller will also have preferences for how they want their call to be routed. As an example, a caller will often want to reach a user on their cell phone. In the current telephone network, this is accomplished by requiring a user to have a separate number for each device. This way, when a caller wishes to reach the cell phone, they dial the number for the cell phone. This requires users to maintain lists of potential reach numbers for a user, and then select the appropriate one. A far better approach is for a user to maintain a single address-of-record. When someone wishes to reach them on their cell phone, they call the AOR, but indicate a preference for the call to be routed to the cell phone.
A caller may actually have a wide variety of preferences for how a call should be routed. They may prefer to go right to voicemail. They may prefer never to reach voicemail. The may prefer to reach the user on a device that supports video (because a video-conference is desired). They may wish to reach a device that has an attendant who can answer if the user is not there.
A caller may actually have a wide variety of preferences for how a call should be routed. They may prefer to go right to voicemail. They may prefer never to reach voicemail. The may prefer to reach the user on a device that supports video (because a video-conference is desired). They may wish to reach a device that has an attendant who can answer if the user is not there.
The SIP caller preferences extension allows a caller to express these preferences for the way in which their calls are handled. These preferences are expressed in terms of properties of the desired device. These properties are name-value pairs that convey some kind of information about a device. One example is the property "mobility", which can have the values "mobile" or "fixed". When a caller wishes to reach a cell phone, they include information in their call setup request (the INVITE method) which indicates that the call should be routed to a device that has the property "mobility" set to "mobile". When devices register to the network, they include their properties (also known as callee capabilities) as part of the registration. In this way, a proxy can match the caller's preferences against the capabilities of the various devices registered to the user and route the call appropriately.
The SIP caller preferences extension allows a caller to express these preferences for the way in which their calls are handled. These preferences are expressed in terms of properties of the desired device. These properties are name-value pairs that convey some kind of information about a device. One example is the property "mobility", which can have the values "mobile" or "fixed". When a caller wishes to reach a cell phone, they include information in their call setup request (the INVITE method) which indicates that the call should be routed to a device that has the property "mobility" set to "mobile". When devices register to the network, they include their properties (also known as callee capabilities) as part of the registration. In this way, a proxy can match the caller's preferences against the capabilities of the various devices registered to the user and route the call appropriately.
While this document addresses the preferences of a caller, it does so from the perspective of a SIP User Agent representing the caller. Caller preferences are herein represented via syntactic elements placed in a SIP request. This document does not attempt to address how preferences might be conveyed by a human user to the User Agent. Thus this document is likely to be of most value to the developer of a User Agent.
While this document addresses the preferences of a caller, it does so from the perspective of a SIP User Agent representing the caller. Caller preferences are herein represented via syntactic elements placed in a SIP request. This document does not attempt to address how preferences might be conveyed by a human user to the User Agent. Thus this document is likely to be of most value to the developer of a User Agent.
Rosenberg & Kyzivat Informational [Page 6] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 6] RFC 4596 Caller Preferences Uses July 2006
The caller preferences extension can support a wide variety of call routing applications and features. Two particularly important examples are "one-number" and "direct-to-voicemail".
The caller preferences extension can support a wide variety of call routing applications and features. Two particularly important examples are "one-number" and "direct-to-voicemail".
2.1. One-Number
2.1. One-Number
In today's circuit-switched telephony networks, users have multiple devices, and each device is associated with its own phone number. A user will typically list all of these numbers on a business card: cell phone, work phone, home office phone, and so on. Other users need to store and manage all of these numbers. It is difficult to keep these numbers complete and up-to-date. Worse, when you want to call someone, you need to pick a number to try. Sometimes, you want a specific device (the cell phone); and other times, you just want to reach them wherever they are. In the latter case, a user is forced to try each number, one at a time. This is inefficient, and difficult to do while driving, for example.
In today's circuit-switched telephony networks, users have multiple devices, and each device is associated with its own phone number. A user will typically list all of these numbers on a business card: cell phone, work phone, home office phone, and so on. Other users need to store and manage all of these numbers. It is difficult to keep these numbers complete and up-to-date. Worse, when you want to call someone, you need to pick a number to try. Sometimes, you want a specific device (the cell phone); and other times, you just want to reach them wherever they are. In the latter case, a user is forced to try each number, one at a time. This is inefficient, and difficult to do while driving, for example.
As an alternative, a user can have a single address. This is the one and only address they give out to other users on their business cards. If a caller wishes to reach that user on their cell phone, they select that one address, and then access a pull-down menu of device types. This menu would include home phone, work phone, and cell phone. The caller can select cell-phone, and then the call is placed to the cell phone. There is no need to manage or maintain more than one number for the user -- a single number will suffice.
As an alternative, a user can have a single address. This is the one and only address they give out to other users on their business cards. If a caller wishes to reach that user on their cell phone, they select that one address, and then access a pull-down menu of device types. This menu would include home phone, work phone, and cell phone. The caller can select cell-phone, and then the call is placed to the cell phone. There is no need to manage or maintain more than one number for the user -- a single number will suffice.
If, on the other hand, the caller wishes to reach the user wherever they are, they make a call to that one number without a selection of a preferred device. The network will ring all devices at the same time, and therefore reach the user as fast as possible.
If, on the other hand, the caller wishes to reach the user wherever they are, they make a call to that one number without a selection of a preferred device. The network will ring all devices at the same time, and therefore reach the user as fast as possible.
This one-number service makes use of caller preferences. To express a preference for the cell phone, the caller's device would include a header in the SIP INVITE request, indicating a desire to reach a device with "mobility" equal to "mobile".
This one-number service makes use of caller preferences. To express a preference for the cell phone, the caller's device would include a header in the SIP INVITE request, indicating a desire to reach a device with "mobility" equal to "mobile".
2.2. Direct-to-Voicemail
2.2. Direct-to-Voicemail
Frequently, a busy executive on the road wants to quickly pass a message to a colleague by voice. As an example, a boss might want to instruct an employee to call a specific customer and resolve a pending issue. In such a case, the user doesn't actually want to talk to the person; they just want to leave a voice message. Having a phone conversation may require too much time, whereas a voice message can be quick and to the point. The voice message can also serve as a record of exactly what is desired, whereas a fleeting voice conversation can be forgotten or misremembered.
Frequently, a busy executive on the road wants to quickly pass a message to a colleague by voice. As an example, a boss might want to instruct an employee to call a specific customer and resolve a pending issue. In such a case, the user doesn't actually want to talk to the person; they just want to leave a voice message. Having a phone conversation may require too much time, whereas a voice message can be quick and to the point. The voice message can also serve as a record of exactly what is desired, whereas a fleeting voice conversation can be forgotten or misremembered.
Rosenberg & Kyzivat Informational [Page 7] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 7] RFC 4596 Caller Preferences Uses July 2006
In today's circuit-switched telephone networks, there is often no way to go directly to someone's voicemail and leave a message. Sometimes, you can dial the main number for the voicemail system, enter in the extension of the desired party, and leave a message by entering a specific prompt. This is time consuming, and requires the caller to know the main voicemail number.
In today's circuit-switched telephone networks, there is often no way to go directly to someone's voicemail and leave a message. Sometimes, you can dial the main number for the voicemail system, enter in the extension of the desired party, and leave a message by entering a specific prompt. This is time consuming, and requires the caller to know the main voicemail number.
Instead, an address book in a cell phone can have an option called "leave voice message", available for each entry in the address book. When this option is selected, a call is made directly to the voicemail for that user, which immediately picks up and prompts for a message. In fact, a rapid greeting is played, so that the caller can go directly to the recording procedure.
Instead, an address book in a cell phone can have an option called "leave voice message", available for each entry in the address book. When this option is selected, a call is made directly to the voicemail for that user, which immediately picks up and prompts for a message. In fact, a rapid greeting is played, so that the caller can go directly to the recording procedure.
This saves time for the caller, making it very easy to quickly leave recorded messages for a large number of people.
This saves time for the caller, making it very easy to quickly leave recorded messages for a large number of people.
This feature is possible using the caller preferences extension. When the user selects the "leave voice message" option, the phone sends a SIP INVITE request, and includes a caller preferences header field that indicates a preference for devices whose "msgserver" attribute has a value of "true". This will cause the proxy to route the call directly to a registered voicemail service. Furthermore, the voicemail server will see that the caller asked to go directly to voicemail, and can therefore play an abbreviated greeting explicitly designed for this case.
This feature is possible using the caller preferences extension. When the user selects the "leave voice message" option, the phone sends a SIP INVITE request, and includes a caller preferences header field that indicates a preference for devices whose "msgserver" attribute has a value of "true". This will cause the proxy to route the call directly to a registered voicemail service. Furthermore, the voicemail server will see that the caller asked to go directly to voicemail, and can therefore play an abbreviated greeting explicitly designed for this case.
3. Caller Preference Use Cases
3. Caller Preference Use Cases
Each use case is described as a situation along with a desired behavior. Then, it demonstrates how the various caller preferences headers and the proxy processing logic would result in the appropriate decision.
Each use case is described as a situation along with a desired behavior. Then, it demonstrates how the various caller preferences headers and the proxy processing logic would result in the appropriate decision.
3.1. Routing of INVITE and MESSAGE to Different UA
3.1. Routing of INVITE and MESSAGE to Different UA
3.1.1. Desired Behavior
3.1.1. Desired Behavior
Address of Record (AOR) Y has two contacts, Y1 and Y2. Y1 is a phone and supports the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but does not support MESSAGE, whereas Y2 is a pager and supports only OPTIONS and MESSAGE. Caller X wants to send pages to Y. There is a lot of traffic in the network of both calls and pages, so there is a goal not to unnecessarily fork messages to devices that can't support them. So, this is done by ensuring that INVITEs of Y are delivered only to Y1, while MESSAGEs to Y are delivered only to Y2.
Address of Record (AOR) Y has two contacts, Y1 and Y2. Y1 is a phone and supports the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but does not support MESSAGE, whereas Y2 is a pager and supports only OPTIONS and MESSAGE. Caller X wants to send pages to Y. There is a lot of traffic in the network of both calls and pages, so there is a goal not to unnecessarily fork messages to devices that can't support them. So, this is done by ensuring that INVITEs of Y are delivered only to Y1, while MESSAGEs to Y are delivered only to Y2.
Rosenberg & Kyzivat Informational [Page 8] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 8] RFC 4596 Caller Preferences Uses July 2006
3.1.2. Solution
3.1.2. Solution
Y1 will create a registration that looks like, in part:
Y1 will create a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact:<sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="mobile"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact:<sip:Y1@pc.example.com> ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL" ;uri-user="<Y1>" ;uri-domain="example.com" ;audio ;schemes="sip" ;mobility="mobile"
Y2 will create a registration that looks like, in part:
Y2 will create a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="OPTIONS,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;+sip.message
;schemes="sip,im"
;mobility="mobile"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y2@pc.example.com> ;methods="OPTIONS,MESSAGE" ;uri-user="<Y2>" ;uri-domain="example.com" ;+sip.message ;schemes="sip,im" ;mobility="mobile"
When a UAC (User Agent Client) sends an INVITE, it will arrive at the proxy for example.com. There are no caller preferences in the request. However, per Section 7.2.2 of [3], the proxy will construct an implicit require-flagged Accept-Contact preference that looks like:
When a UAC (User Agent Client) sends an INVITE, it will arrive at the proxy for example.com. There are no caller preferences in the request. However, per Section 7.2.2 of [3], the proxy will construct an implicit require-flagged Accept-Contact preference that looks like:
(& (sip.methods="INVITE"))
(& (sip.methods="INVITE"))
Applying the matching algorithm of RFC 2533 [6] to this feature set and those registered by Y1 and Y2, the feature set of Y1 alone matches. Because the Accept-Contact predicate has its require flag set, Y2 is discarded, and the INVITE is routed to Y1.
Applying the matching algorithm of RFC 2533 [6] to this feature set and those registered by Y1 and Y2, the feature set of Y1 alone matches. Because the Accept-Contact predicate has its require flag set, Y2 is discarded, and the INVITE is routed to Y1.
If the request was MESSAGE, the proxy constructs an implicit Accept- Contact preference with its require flag set (require-flagged) that looks like:
If the request was MESSAGE, the proxy constructs an implicit Accept- Contact preference with its require flag set (require-flagged) that looks like:
(& (sip.methods="MESSAGE"))
(& (sip.methods="MESSAGE"))
which matches the feature set of Y2, but not Y1. Thus, Y1 is discarded, and the request is routed to Y2.
which matches the feature set of Y2, but not Y1. Thus, Y1 is discarded, and the request is routed to Y2.
Rosenberg & Kyzivat Informational [Page 9] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 9] RFC 4596 Caller Preferences Uses July 2006
3.2. Single Contact Not Matching Implicit Preferences
3.2. Single Contact Not Matching Implicit Preferences
3.2.1. Desired Behavior
3.2.1. Desired Behavior
AOR Y has a single contact, Y1. It's a phone, and therefore supports the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but does not support MESSAGE. A caller X sends a MESSAGE request. The desired behavior is that the request is still routed to the solitary contact so that it can generate a 405 response.
AOR Y has a single contact, Y1. It's a phone, and therefore supports the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL but does not support MESSAGE. A caller X sends a MESSAGE request. The desired behavior is that the request is still routed to the solitary contact so that it can generate a 405 response.
3.2.2. Solution
3.2.2. Solution
The single contact Y1 will generate a registration that looks like, in part:
The single contact Y1 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y1@pc.example.com> ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL" ;uri-user="<Y1>" ;uri-domain="example.com" ;audio ;schemes="sip" ;mobility="fixed" ;class="personal"
X sends a MESSAGE request. There are no explicit caller preferences. This results in an implicit require-flagged Accept-Contact preference:
X sends a MESSAGE request. There are no explicit caller preferences. This results in an implicit require-flagged Accept-Contact preference:
(& (sip.methods="MESSAGE"))
(& (sip.methods="MESSAGE"))
Since Y1 doesn't match and the Accept-Contact predicate is require- flagged, it is discarded. However, according to section 7.2.4 of RFC 3841, if there are no matching targets, the original target set is used. Thus, the request is sent to the one original target, Y1, as desired. Y1 then responds with a 405.
Since Y1 doesn't match and the Accept-Contact predicate is require- flagged, it is discarded. However, according to section 7.2.4 of RFC 3841, if there are no matching targets, the original target set is used. Thus, the request is sent to the one original target, Y1, as desired. Y1 then responds with a 405.
If there were multiple contacts, and none of them matched the Accept- Contact predicate, then the original target set including all of the contacts would be restored. Then all the contacts would be processed according to Section 16.6 of RFC 3261.
If there were multiple contacts, and none of them matched the Accept- Contact predicate, then the original target set including all of the contacts would be restored. Then all the contacts would be processed according to Section 16.6 of RFC 3261.
Rosenberg & Kyzivat Informational [Page 10] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 10] RFC 4596 Caller Preferences Uses July 2006
3.3. Package-Based Routing
3.3. Package-Based Routing
3.3.1. Desired Behavior
3.3.1. Desired Behavior
AOR Y has a number of contacts, Y1, Y2, ..., Yn, that can each support the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL and can also support SUBSCRIBE for the "dialog" event package [7]. Y also has another contact, Yp, that is a presence agent (PA) [8]: it can accept only SUBSCRIBE requests for the "presence" event package. The goal is for SUBSCRIBE requests for presence to be routed to Yp while INVITEs and SUBSCRIBEs for the dialog package are forked to Y1...Yn.
AOR Y has a number of contacts, Y1, Y2, ..., Yn, that can each support the standard operations INVITE, ACK, OPTIONS, BYE, and CANCEL and can also support SUBSCRIBE for the "dialog" event package [7]. Y also has another contact, Yp, that is a presence agent (PA) [8]: it can accept only SUBSCRIBE requests for the "presence" event package. The goal is for SUBSCRIBE requests for presence to be routed to Yp while INVITEs and SUBSCRIBEs for the dialog package are forked to Y1...Yn.
3.3.2. Solution
3.3.2. Solution
Y1..Yn will generate REGISTER requests that look like, in part:
Y1..Yn will generate REGISTER requests that look like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yi@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE"
;events="dialog"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Yi@pc.example.com> ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE" ;events="dialog" ;uri-user="<Yi>" ;uri-domain="example.com" ;audio ;schemes="sip" ;mobility="fixed" ;class="personal"
and Yp will generate a REGISTER request that looks like, in part:
and Yp will generate a REGISTER request that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yp@pc.example.com>;methods="SUBSCRIBE"
;events="presence"
;uri-user="<Yp>"
;uri-domain="example.com"
;schemes="sip,pres"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Yp@pc.example.com>;methods="SUBSCRIBE" ;events="presence" ;uri-user="<Yp>" ;uri-domain="example.com" ;schemes="sip,pres" ;mobility="fixed" ;class="business"
A SUBSCRIBE request for presence will arrive at the proxy for example.com. Since there are no explicit preferences, it constructs an implicit require-flagged Accept-Contact preference from the request:
A SUBSCRIBE request for presence will arrive at the proxy for example.com. Since there are no explicit preferences, it constructs an implicit require-flagged Accept-Contact preference from the request:
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
Rosenberg & Kyzivat Informational [Page 11] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 11] RFC 4596 Caller Preferences Uses July 2006
Following Section 7.2.4 of RFC 3841, this feature set only matches the one registered by Yp. Because the require flag is set, the contacts which do not match are removed from the target set. Therefore, Y1..Yn are discarded. The request is sent to the remaining contact, Yp, representing the PA.
Following Section 7.2.4 of RFC 3841, this feature set only matches the one registered by Yp. Because the require flag is set, the contacts which do not match are removed from the target set. Therefore, Y1..Yn are discarded. The request is sent to the remaining contact, Yp, representing the PA.
An INVITE request without explicit preferences results in an implicit require-flagged Accept-Contact preference:
An INVITE request without explicit preferences results in an implicit require-flagged Accept-Contact preference:
(& (sip.methods="INVITE"))
(& (sip.methods="INVITE"))
The implicit Accept-Contact feature set matches Y1..Yn, but does not match Yp. Using the scoring algorithm from Section 7.2.4 of RFC 3841, the score for Y1..Yn against this predicate is 1.0. As a result, the caller preference Qa for each contact is 1.0. The registrations did not contain q-values, so the default q-value of 1.0 is applied to each Contact URI. Since the caller and callee preferences are the same and all equal to 1.0, there is no reordering of contacts. The result is that the proxy will consider Y1..Yn each as equally good targets for the request and possibly fork the request to each.
The implicit Accept-Contact feature set matches Y1..Yn, but does not match Yp. Using the scoring algorithm from Section 7.2.4 of RFC 3841, the score for Y1..Yn against this predicate is 1.0. As a result, the caller preference Qa for each contact is 1.0. The registrations did not contain q-values, so the default q-value of 1.0 is applied to each Contact URI. Since the caller and callee preferences are the same and all equal to 1.0, there is no reordering of contacts. The result is that the proxy will consider Y1..Yn each as equally good targets for the request and possibly fork the request to each.
A SUBSCRIBE request for the dialog event package without explicit preferences will result in an implicit require-flagged Accept-Contact preference:
A SUBSCRIBE request for the dialog event package without explicit preferences will result in an implicit require-flagged Accept-Contact preference:
(& (sip.methods="SUBSCRIBE") (sip.events="dialog"))
(& (sip.methods="SUBSCRIBE") (sip.events="dialog"))
This only matches Y1..Yn, so Yp is discarded, and the request is routed to the remaining contacts just as the INVITE was.
This only matches Y1..Yn, so Yp is discarded, and the request is routed to the remaining contacts just as the INVITE was.
3.4. Package Routing II
3.4. Package Routing II
3.4.1. Desired Behavior
3.4.1. Desired Behavior
This case is nearly identical to that of Section 3.3. However, Y1..Yn omit the "events" feature tag from their registration. Yp registers as in Section 3.3. A SUBSCRIBE for the presence event package should still preferentially route to Yp.
This case is nearly identical to that of Section 3.3. However, Y1..Yn omit the "events" feature tag from their registration. Yp registers as in Section 3.3. A SUBSCRIBE for the presence event package should still preferentially route to Yp.
Rosenberg & Kyzivat Informational [Page 12] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 12] RFC 4596 Caller Preferences Uses July 2006
3.4.2. Solution
3.4.2. Solution
The registration from Y1..Yn will look like:
The registration from Y1..Yn will look like:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Yi@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE"
;uri-user="<Yi>"
;uri-domain="example.com"
;audio
;schemes="sip"
;mobility="fixed"
;class="personal"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Yi@pc.example.com> ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE" ;uri-user="<Yi>" ;uri-domain="example.com" ;audio ;schemes="sip" ;mobility="fixed" ;class="personal"
When the caller sends a SUBSCRIBE for the presence event package (without explicit preferences), the proxy computes an implicit preference:
When the caller sends a SUBSCRIBE for the presence event package (without explicit preferences), the proxy computes an implicit preference:
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
(& (sip.methods="SUBSCRIBE") (sip.events="presence"))
This predicate matches Y1..Yn and Yp. However, the score for Y1..Yn against this predicate is 0.5, and the score of Yp is 1.0. The result is a caller preference Qa of 0.5 for Y1..Yn, and a caller preference Qa of 1.0 for Yp. Since the callee provided no q-values, the proxy will assume a default of 1.0. Thus, all contacts are in the same equivalence class. They are then sorted by Qa, so that Yp is first, followed by Y1 through Yn. It will therefore route the request first to Yp, and if that should fail, to Y1..Yn.
This predicate matches Y1..Yn and Yp. However, the score for Y1..Yn against this predicate is 0.5, and the score of Yp is 1.0. The result is a caller preference Qa of 0.5 for Y1..Yn, and a caller preference Qa of 1.0 for Yp. Since the callee provided no q-values, the proxy will assume a default of 1.0. Thus, all contacts are in the same equivalence class. They are then sorted by Qa, so that Yp is first, followed by Y1 through Yn. It will therefore route the request first to Yp, and if that should fail, to Y1..Yn.
3.5. Audio/Video vs. Audio Only
3.5. Audio/Video vs. Audio Only
3.5.1. Desired Behavior
3.5.1. Desired Behavior
X sends an invitation to Y to initiate an audio/video call, including both m=audio and m=video lines in the SDP. AOR Y has two contacts, Y1 and Y2. Y1 represents a normal audio phone, where Y prefers to receive their calls. It will answer an audio/video call, refusing the video. Y2 represents an audio/video phone that should only used when needed. The caller really wants the call answered by a device that supports video, but will accept an audio-only call as a second choice.
X sends an invitation to Y to initiate an audio/video call, including both m=audio and m=video lines in the SDP. AOR Y has two contacts, Y1 and Y2. Y1 represents a normal audio phone, where Y prefers to receive their calls. It will answer an audio/video call, refusing the video. Y2 represents an audio/video phone that should only used when needed. The caller really wants the call answered by a device that supports video, but will accept an audio-only call as a second choice.
Rosenberg & Kyzivat Informational [Page 13] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 13] RFC 4596 Caller Preferences Uses July 2006
3.5.2. Solution
3.5.2. Solution
Y1 will generate a registration that looks like, in part:
Y1 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y1@pc.example.com>;q=1.0 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" ;uri-user="<Y1>" ;uri-domain="example.com" ;audio ;schemes="sip,tel" ;mobility="fixed" ;class="business"
Y2 will generate a registration that looks like, in part:
Y2 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y2@pc.example.com>;q=0.6 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" ;uri-user="<Y2>" ;uri-domain="example.com" ;audio ;video ;schemes="sip,tel" ;mobility="fixed" ;class="business"
Note the different q-values, allowing Y2 to be selected as a device of "last resort".
Note the different q-values, allowing Y2 to be selected as a device of "last resort".
To have the call preferentially routed to a device that supports video, the caller X sends an INVITE that looks like, in part:
To have the call preferentially routed to a device that supports video, the caller X sends an INVITE that looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *
;methods="INVITE"
;video
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: * ;methods="INVITE" ;video
The proxy will convert this to a feature set. This feature set matches Y2 and Y1. However, the score for Y2 is 1.0, and 0.5 for Y1. The two contacts are then ordered by q-value and broken into equivalence classes. There are two equivalence classes, each with one contact. As a result, the caller preference values have no impact on the ordering. The call will first try the higher priority Y1, which will answer the call and reject the video stream. Thus, the desired behavior is not achieved.
The proxy will convert this to a feature set. This feature set matches Y2 and Y1. However, the score for Y2 is 1.0, and 0.5 for Y1. The two contacts are then ordered by q-value and broken into equivalence classes. There are two equivalence classes, each with one contact. As a result, the caller preference values have no impact on the ordering. The call will first try the higher priority Y1, which will answer the call and reject the video stream. Thus, the desired behavior is not achieved.
Rosenberg & Kyzivat Informational [Page 14] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 14] RFC 4596 Caller Preferences Uses July 2006
The desired behavior could be achieved by adding the "explicit" and "require" tags to the Accept-Contact header field in the INVITE, as is done in Section 3.6. However, doing so may result in calls failing when they could occur, but without video. As discussed in [3], both the "require" and "explicit" tags are generally used only when the request cannot be serviced in any way unless the preferences are met. That is not the case here.
The desired behavior could be achieved by adding the "explicit" and "require" tags to the Accept-Contact header field in the INVITE, as is done in Section 3.6. However, doing so may result in calls failing when they could occur, but without video. As discussed in [3], both the "require" and "explicit" tags are generally used only when the request cannot be serviced in any way unless the preferences are met. That is not the case here.
3.6. Forcing Audio/Video
3.6. Forcing Audio/Video
3.6.1. Desired Behavior
3.6.1. Desired Behavior
This case is similar to that of Section 3.5. However, X requires an audio/video call and would like the call to fail if this is not possible, rather than succeed with audio only.
This case is similar to that of Section 3.5. However, X requires an audio/video call and would like the call to fail if this is not possible, rather than succeed with audio only.
3.6.2. Solution
3.6.2. Solution
The solution is similar to that of Section 3.5; however, the Accept- Contact header field now includes the "explicit" and "require" tags, guaranteeing that the call is never established to any UA that had not explicitly indicated support for video:
The solution is similar to that of Section 3.5; however, the Accept- Contact header field now includes the "explicit" and "require" tags, guaranteeing that the call is never established to any UA that had not explicitly indicated support for video:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;video;require;explicit
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;video;require;explicit
This arrives at the example.com proxy. This explicit feature set matches the feature set for Y2 and Y1. However, the match for Y1 did not have a score of 1. Since the "explicit" and "require" tags are present, the contact is discarded. That leaves Y2 only. The call will therefore get routed to the videophone, and if the user is not there, the audio phone will never ring.
This arrives at the example.com proxy. This explicit feature set matches the feature set for Y2 and Y1. However, the match for Y1 did not have a score of 1. Since the "explicit" and "require" tags are present, the contact is discarded. That leaves Y2 only. The call will therefore get routed to the videophone, and if the user is not there, the audio phone will never ring.
Because both the "require" and "explicit" flags are present, a contact will also be discarded if it does not include a feature tag indicating support for video. Thus, a UA that can do video, but neglected to indicate it, would not be reached in this case. This is why it is important for a UA to indicate all of its capabilities. Note that this is only true for a contact that indicated some capabilities but not the video capability. Contacts that don't indicate any capabilities are "immune" from caller preferences filtering and would not be discarded.
Because both the "require" and "explicit" flags are present, a contact will also be discarded if it does not include a feature tag indicating support for video. Thus, a UA that can do video, but neglected to indicate it, would not be reached in this case. This is why it is important for a UA to indicate all of its capabilities. Note that this is only true for a contact that indicated some capabilities but not the video capability. Contacts that don't indicate any capabilities are "immune" from caller preferences filtering and would not be discarded.
Rosenberg & Kyzivat Informational [Page 15] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 15] RFC 4596 Caller Preferences Uses July 2006
3.7. Third-Party Call Control: Forcing Media
3.7. Third-Party Call Control: Forcing Media
3.7.1. Desired Behavior
3.7.1. Desired Behavior
Z is a third-party call control controller (3pcc) [9] trying to establish an audio/video call from X to Y. X has contacts X1 and X2, and Y has contacts Y1 and Y2. X1 and X2 have capabilities identical to Y1 and Y2, respectively. Z needs to send an offerless invite to X and use the offer proposed by X to send an invite to Y. When sending the offerless invite to X, the 3pcc controller must ensure that an audio/video contact (X2) is chosen over an audio only contact (X1).
Z is a third-party call control controller (3pcc) [9] trying to establish an audio/video call from X to Y. X has contacts X1 and X2, and Y has contacts Y1 and Y2. X1 and X2 have capabilities identical to Y1 and Y2, respectively. Z needs to send an offerless invite to X and use the offer proposed by X to send an invite to Y. When sending the offerless invite to X, the 3pcc controller must ensure that an audio/video contact (X2) is chosen over an audio only contact (X1).
3.7.2. Solution
3.7.2. Solution
X1 will generate a registration that looks like, in part:
X1 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X1@pc.example.com>;q=1.0
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0 To: sip:X@example.com Contact: <sip:X1@pc.example.com>;q=1.0 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" ;uri-user="<X1>" ;uri-domain="example.com" ;audio ;schemes="sip,tel" ;mobility="fixed" ;class="business"
X2 will generate a registration that looks like, in part:
X2 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:X@example.com
Contact: <sip:X2@pc.example.com>;q=0.6
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<X2>"
;uri-domain="example.com"
;audio
;video
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0 To: sip:X@example.com Contact: <sip:X2@pc.example.com>;q=0.6 ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" ;uri-user="<X2>" ;uri-domain="example.com" ;audio ;video ;schemes="sip,tel" ;mobility="fixed" ;class="business"
Z would include, in its INVITE, an Accept-Contact header field:
Z would include, in its INVITE, an Accept-Contact header field:
INVITE sip:X@example.com SIP/2.0
Accept-Contact: *;audio;video;require;explicit
INVITE sip:X@example.com SIP/2.0 Accept-Contact: *;audio;video;require;explicit
Rosenberg & Kyzivat Informational [Page 16] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 16] RFC 4596 Caller Preferences Uses July 2006
This caller preference matches both X1 and X2. However, it matches X1 with a score of .5 and X2 with a score of 1. Because of the "require" and "explicit" tags, X1 is discarded despite X's preference for it. Thus, the call is routed to X2.
This caller preference matches both X1 and X2. However, it matches X1 with a score of .5 and X2 with a score of 1. Because of the "require" and "explicit" tags, X1 is discarded despite X's preference for it. Thus, the call is routed to X2.
The same caveats apply here as do in Section 3.6. Generally, it is not advisable to mandate support for features (such as video) that are not strictly necessary for the request to proceed.
The same caveats apply here as do in Section 3.6. Generally, it is not advisable to mandate support for features (such as video) that are not strictly necessary for the request to proceed.
3.8. Maximizing Media Overlaps
3.8. Maximizing Media Overlaps
3.8.1. Desired Behavior
3.8.1. Desired Behavior
AOR Y has two contacts: Y1, which is a regular audio phone, and Y2, which is a PC capable of supporting both audio and session-oriented IM [10]. X is a PC with capability to support audio, video, and session-oriented IM. X calls Y for the purpose of establishing a voice call. However, X wishes to connect to the device that has the maximal overlap with its media capabilities, in order to maximize the functionality available to the caller.
AOR Y has two contacts: Y1, which is a regular audio phone, and Y2, which is a PC capable of supporting both audio and session-oriented IM [10]. X is a PC with capability to support audio, video, and session-oriented IM. X calls Y for the purpose of establishing a voice call. However, X wishes to connect to the device that has the maximal overlap with its media capabilities, in order to maximize the functionality available to the caller.
3.8.2. Solution
3.8.2. Solution
Y1 will generate a registration that looks like, in part:
Y1 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@phone.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"
;uri-user="<Y1>"
;uri-domain="example.com"
;audio
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y1@phone.example.com> ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL" ;uri-user="<Y1>" ;uri-domain="example.com" ;audio ;schemes="sip,tel" ;mobility="fixed" ;class="business"
Rosenberg & Kyzivat Informational [Page 17] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 17] RFC 4596 Caller Preferences Uses July 2006
Y2 will generate a registration that looks like, in part:
Y2 will generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,MESSAGE"
;uri-user="<Y2>"
;uri-domain="example.com"
;audio
;+sip.message
;schemes="sip,tel"
;mobility="fixed"
;class="business"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y2@pc.example.com> ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,MESSAGE" ;uri-user="<Y2>" ;uri-domain="example.com" ;audio ;+sip.message ;schemes="sip,tel" ;mobility="fixed" ;class="business"
The solution requires the caller to support caller preferences. The caller would include, in their INVITE, an Accept-Contact header field that lists all the media types they support. In this case:
The solution requires the caller to support caller preferences. The caller would include, in their INVITE, an Accept-Contact header field that lists all the media types they support. In this case:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;audio;video;+sip.message
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;audio;video;+sip.message
Both Y1 and Y2 match the predicate. Y1 matches with a score of 0.33, and Y2 matches with a score of 0.66. Since there is only one Accept- Contact predicate, the Qa for each contact is equal to the score. The registered contacts are then sorted by q-value and broken into equivalence classes. There is a single equivalence class with q-value of 1.0. The two contacts in that class are then re-ordered based on the values of Qa. Y2 has a higher Qa, so it is used first, followed by Y1. The result is that the call is routed to the device with the maximum overlap in media capabilities, as desired.
Both Y1 and Y2 match the predicate. Y1 matches with a score of 0.33, and Y2 matches with a score of 0.66. Since there is only one Accept- Contact predicate, the Qa for each contact is equal to the score. The registered contacts are then sorted by q-value and broken into equivalence classes. There is a single equivalence class with q-value of 1.0. The two contacts in that class are then re-ordered based on the values of Qa. Y2 has a higher Qa, so it is used first, followed by Y1. The result is that the call is routed to the device with the maximum overlap in media capabilities, as desired.
Note that neither "require" nor "explicit" tags are used because there is no intent to exclude contacts, only to order them.
Note that neither "require" nor "explicit" tags are used because there is no intent to exclude contacts, only to order them.
3.9. Multilingual Lines
3.9. Multilingual Lines
3.9.1. Desired Behavior
3.9.1. Desired Behavior
AOR Y represents a shared line in an office. Several employees in the office have phones registered for Y. Some of the employees speak only English, some speak Spanish fluently and have some limited capability for English, and some speak both English and Spanish fluently. Calls from callers that speak only English should be parallel forked to all office workers that speak fluent English. If the call isn't picked up, then the phones of workers that speak English marginally should be rung. Calls from callers that speak only Spanish should be forked only to workers that speak Spanish.
AOR Y represents a shared line in an office. Several employees in the office have phones registered for Y. Some of the employees speak only English, some speak Spanish fluently and have some limited capability for English, and some speak both English and Spanish fluently. Calls from callers that speak only English should be parallel forked to all office workers that speak fluent English. If the call isn't picked up, then the phones of workers that speak English marginally should be rung. Calls from callers that speak only Spanish should be forked only to workers that speak Spanish.
Rosenberg & Kyzivat Informational [Page 18] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 18] RFC 4596 Caller Preferences Uses July 2006
3.9.2. Solution
3.9.2. Solution
A user at phone Y1 that speaks English only would generate a REGISTER that looks like, in part:
A user at phone Y1 that speaks English only would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;languages="en"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y1@pc.example.com>;languages="en"
A user at a phone Y2 that speaks Spanish and a little bit of English would generate a REGISTER that looks like, in part:
A user at a phone Y2 that speaks Spanish and a little bit of English would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2-es@pc2.example.com>;languages="es"
Contact: <sip:Y2-en@pc2.example.com>;languages="en";q=0.2
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y2-es@pc2.example.com>;languages="es" Contact: <sip:Y2-en@pc2.example.com>;languages="en";q=0.2
Y2 has registered two contacts. Both of them route to the same device (pc2.example.com), but they differ in their language support and relative q-values. Multiple contacts are needed whenever a UA wishes to express differing preferences for being reached for different feature collections.
Y2 has registered two contacts. Both of them route to the same device (pc2.example.com), but they differ in their language support and relative q-values. Multiple contacts are needed whenever a UA wishes to express differing preferences for being reached for different feature collections.
A user at phone Y3 that speaks English and Spanish fluently would generate a REGISTER that looks like, in part:
A user at phone Y3 that speaks English and Spanish fluently would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;languages="es,en"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y3@pc3.example.com>;languages="es,en"
Notice that only a single contact is needed because the same q-value is applied across all feature collections.
Notice that only a single contact is needed because the same q-value is applied across all feature collections.
For the language-based routing to occur, the caller must indicate its language preferences explicitly:
For the language-based routing to occur, the caller must indicate its language preferences explicitly:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="en";require
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;languages="en";require
The predicate derived from this looks like:
The predicate derived from this looks like:
(& (languages="en"))
(& (languages="en"))
This matches the one contact for Y1, the second contact registered for Y2, and the one contact for Y3, all with a score of 1.0. The first contact registered by Y2 does not match, and because of the "require" flag, is discarded. The remaining contacts are sorted by q-value and divided into equivalence classes. There are two
This matches the one contact for Y1, the second contact registered for Y2, and the one contact for Y3, all with a score of 1.0. The first contact registered by Y2 does not match, and because of the "require" flag, is discarded. The remaining contacts are sorted by q-value and divided into equivalence classes. There are two
Rosenberg & Kyzivat Informational [Page 19] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 19] RFC 4596 Caller Preferences Uses July 2006
equivalence classes. The first contains Y1 and Y3 with a q-value of 1.0, and the second contains Y2-en with a q-value of 0.2. The contacts in the first class are ordered by Qa. However, since all contacts have the same value of Qa (1.0), there is no change in ordering. Thus, Y1 and Y3 are tried first, followed by Y2-en. This is the desired behavior.
equivalence classes. The first contains Y1 and Y3 with a q-value of 1.0, and the second contains Y2-en with a q-value of 0.2. The contacts in the first class are ordered by Qa. However, since all contacts have the same value of Qa (1.0), there is no change in ordering. Thus, Y1 and Y3 are tried first, followed by Y2-en. This is the desired behavior.
An "explicit" tag is not used because that would cause the exclusion of a contact that does not mention language.
An "explicit" tag is not used because that would cause the exclusion of a contact that does not mention language.
A caller that speaks Spanish only would specify their preference thusly:
A caller that speaks Spanish only would specify their preference thusly:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;languages="es";require
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;languages="es";require
This matches the first contact of Y2 phones, and Y3 phones, all with a score of 1.0. The English contact of Y2, Y2-en, doesn't match and is discarded because of the "require" flag. The remaining contacts are sorted by q-values (Y3, Y2-es) and broken into a single equivalence class containing both contacts. Since the Qa for both contacts is the same (1.0) there is no reordering. The result is that the call is routed to either Y3 or Y2-es.
This matches the first contact of Y2 phones, and Y3 phones, all with a score of 1.0. The English contact of Y2, Y2-en, doesn't match and is discarded because of the "require" flag. The remaining contacts are sorted by q-values (Y3, Y2-es) and broken into a single equivalence class containing both contacts. Since the Qa for both contacts is the same (1.0) there is no reordering. The result is that the call is routed to either Y3 or Y2-es.
3.10. I Hate Voicemail!
3.10. I Hate Voicemail!
3.10.1. Desired Behavior
3.10.1. Desired Behavior
AOR Y has two contacts, a phone Y1 and a voicemail service Y2. X wishes to call Y and talk in person. X does not want to be sent to voicemail under any circumstances.
AOR Y has two contacts, a phone Y1 and a voicemail service Y2. X wishes to call Y and talk in person. X does not want to be sent to voicemail under any circumstances.
3.10.2. Solution
3.10.2. Solution
The phone would register with a Contact that looks like, in part:
The phone would register with a Contact that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>
;audio
;mobility="fixed"
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y1@pc.example.com> ;audio ;mobility="fixed"
Rosenberg & Kyzivat Informational [Page 20] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 20] RFC 4596 Caller Preferences Uses July 2006
and the voicemail server would register with a Contact that looks like, in part:
and the voicemail server would register with a Contact that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc.example.com>
;msgserver
;automata
;attendant
;audio
;q=0.2
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y2@pc.example.com> ;msgserver ;automata ;attendant ;audio ;q=0.2
The voicemail server registers with a lower q-value so that it is used only after the phone itself is rung. Note that the voicemail server need not actually register. There can be a configured contact and feature set defined for it instead.
The voicemail server registers with a lower q-value so that it is used only after the phone itself is rung. Note that the voicemail server need not actually register. There can be a configured contact and feature set defined for it instead.
A caller that wishes to avoid voicemail can include an explicit preference to avoid it. A caller would do this with the Reject- Contact header field:
A caller that wishes to avoid voicemail can include an explicit preference to avoid it. A caller would do this with the Reject- Contact header field:
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;msgserver
INVITE sip:Y@example.com SIP/2.0 Reject-Contact: *;msgserver
Since this feature set contains a feature tag that is not contained in the registration for Y1, the feature set is discarded when examining Y1. However, the registration for Y2 contains all feature tags listed in the feature set, and so the rule is considered. There is a match, and therefore, Y2 is discarded. The result is that the user is never routed to voicemail.
Since this feature set contains a feature tag that is not contained in the registration for Y1, the feature set is discarded when examining Y1. However, the registration for Y2 contains all feature tags listed in the feature set, and so the rule is considered. There is a match, and therefore, Y2 is discarded. The result is that the user is never routed to voicemail.
3.11. I Hate People!
3.11. I Hate People!
3.11.1. Desired Behavior
3.11.1. Desired Behavior
The situation is similar to Section 3.10, except the caller wishes only to leave a message, not actually speak to the person.
The situation is similar to Section 3.10, except the caller wishes only to leave a message, not actually speak to the person.
3.11.2. Solution
3.11.2. Solution
The caller would send an INVITE that looks like, in part:
The caller would send an INVITE that looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;msgserver;require;explicit
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;msgserver;require;explicit
This caller preference matches both Y1 and Y2. Y1 matches, but with a score of zero. Y2 matches with a score of 1. Since both the
This caller preference matches both Y1 and Y2. Y1 matches, but with a score of zero. Y2 matches with a score of 1. Since both the
Rosenberg & Kyzivat Informational [Page 21] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 21] RFC 4596 Caller Preferences Uses July 2006
"require" and "explicit" flags are set, Y1 is discarded. Therefore, the call is routed to Y2, the voicemail server, as desired.
"require" and "explicit" flags are set, Y1 is discarded. Therefore, the call is routed to Y2, the voicemail server, as desired.
Because of the presence of the "require" and "explicit" tags, if these preferences are used with a user that doesn't have voicemail or that fails to indicate it with a msgserver capability, the call will fail completely with a 480 Temporarily Unavailable error, rather than connect to the user.
Because of the presence of the "require" and "explicit" tags, if these preferences are used with a user that doesn't have voicemail or that fails to indicate it with a msgserver capability, the call will fail completely with a 480 Temporarily Unavailable error, rather than connect to the user.
3.12. Prefer Voicemail
3.12. Prefer Voicemail
3.12.1. Desired Behavior
3.12.1. Desired Behavior
The situation is similar to that of Section 3.10. However, the caller prefers to leave a message. If voicemail is not available, they are willing to talk to a person.
The situation is similar to that of Section 3.10. However, the caller prefers to leave a message. If voicemail is not available, they are willing to talk to a person.
3.12.2. Solution
3.12.2. Solution
It had been hoped that RFC 3841 could provide a solution for this case, but it does not, because doing so would require a re-ordering of the callee contacts, which is not done. The caller may achieve the intended effect by making two call attempts:
It had been hoped that RFC 3841 could provide a solution for this case, but it does not, because doing so would require a re-ordering of the callee contacts, which is not done. The caller may achieve the intended effect by making two call attempts:
o First, make an attempt requiring voicemail, as described in
Section 3.11.
o First, make an attempt requiring voicemail, as described in Section 3.11.
o If that fails with a 480 error, send an invitation with no Accept-
Contact or Reject-Contact headers.
o If that fails with a 480 error, send an invitation with no Accept- Contact or Reject-Contact headers.
3.13. Routing to an Executive
3.13. Routing to an Executive
3.13.1. Desired Behavior
3.13.1. Desired Behavior
Y is the AOR of an executive. It has three contacts. Y1 is the phone on the executive's desk. Y2 is the phone on the desk of the executive's assistant. Y3 is the address of an auto-attendant system that can answer general questions, route calls to other parties, etc. By default, calls to Y should be directed to Y2, and if that fails, to Y3. If Y3 doesn't answer, then Y1 should ring.
Y is the AOR of an executive. It has three contacts. Y1 is the phone on the executive's desk. Y2 is the phone on the desk of the executive's assistant. Y3 is the address of an auto-attendant system that can answer general questions, route calls to other parties, etc. By default, calls to Y should be directed to Y2, and if that fails, to Y3. If Y3 doesn't answer, then Y1 should ring.
3.13.2. Solution
3.13.2. Solution
This is primarily a called party feature and is best accomplished with a CPL (Call Processing Language) script [5]. However, it can be accomplished with caller preferences alone by properly setting the q-values across the three devices. Assuming this coordination is possible, here are the settings that would be made:
This is primarily a called party feature and is best accomplished with a CPL (Call Processing Language) script [5]. However, it can be accomplished with caller preferences alone by properly setting the q-values across the three devices. Assuming this coordination is possible, here are the settings that would be made:
Rosenberg & Kyzivat Informational [Page 22] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 22] RFC 4596 Caller Preferences Uses July 2006
Y1 would generate a REGISTER that looks like, in part:
Y1 would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y1@pc.example.com>;q=0.1
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y1@pc.example.com>;q=0.1
Y2 would generate a REGISTER that looks like, in part:
Y2 would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y2@pc2.example.com>;attendant;q=1.0
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y2@pc2.example.com>;attendant;q=1.0
Y3 would generate a REGISTER that looks like, in part:
Y3 would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y3@pc3.example.com>;attendant;automata;q=0.5
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y3@pc3.example.com>;attendant;automata;q=0.5
Note that, in reality, the automated attendant would probably not use REGISTER. Since the attendant would be used for every employee in the company, a static contact would probably be added administratively for each user in the enterprise. However, the information in that static contact would be identical to the information in the registration above.
Note that, in reality, the automated attendant would probably not use REGISTER. Since the attendant would be used for every employee in the company, a static contact would probably be added administratively for each user in the enterprise. However, the information in that static contact would be identical to the information in the registration above.
When X makes a call to the executive, Y, and expresses no preference, the proxy computes an implicit preference to support INVITE. All three contacts match such a preference, even though they have not indicated explicit support for INVITE. Thus, no contacts are discarded. Since each contact has a different q-value, the caller preferences do not cause any reordering. The result is that the call is first routed to Y2, then Y3, then Y1, all as a result of the proper setting of the q-values.
When X makes a call to the executive, Y, and expresses no preference, the proxy computes an implicit preference to support INVITE. All three contacts match such a preference, even though they have not indicated explicit support for INVITE. Thus, no contacts are discarded. Since each contact has a different q-value, the caller preferences do not cause any reordering. The result is that the call is first routed to Y2, then Y3, then Y1, all as a result of the proper setting of the q-values.
3.14. Speak to the Executive
3.14. Speak to the Executive
3.14.1. Desired Behavior
3.14.1. Desired Behavior
This case is similar to that of Section 3.13, but this time the caller, X, has a preference. X calls Y, but wants to speak directly to the executive. X doesn't want the call to ring either the assistant or the auto attendant (automaton).
This case is similar to that of Section 3.13, but this time the caller, X, has a preference. X calls Y, but wants to speak directly to the executive. X doesn't want the call to ring either the assistant or the auto attendant (automaton).
Rosenberg & Kyzivat Informational [Page 23] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 23] RFC 4596 Caller Preferences Uses July 2006
3.14.2. Solution
3.14.2. Solution
X's INVITE would look like, in part:
X's INVITE would look like, in part:
INVITE sip:Y@example.com SIP/2.0
Reject-Contact: *;attendant
Reject-Contact: *;automata
INVITE sip:Y@example.com SIP/2.0 Reject-Contact: *;attendant Reject-Contact: *;automata
Note that the caller uses two separate Reject-Contact header field values, rather than a single one with two separate feature parameters. The distinction is important. If X had to use a single value with two parameters, a matching UA would need to declare that it was BOTH an attendant and an automaton. If it only declared that it was one of these, based on the matching rules in the caller preferences specification, it would not be rejected.
Note that the caller uses two separate Reject-Contact header field values, rather than a single one with two separate feature parameters. The distinction is important. If X had to use a single value with two parameters, a matching UA would need to declare that it was BOTH an attendant and an automaton. If it only declared that it was one of these, based on the matching rules in the caller preferences specification, it would not be rejected.
The above request would result in the elimination of both Y2 and Y3 as contacts. The call would then be routed to Y1, as desired.
The above request would result in the elimination of both Y2 and Y3 as contacts. The call would then be routed to Y1, as desired.
This case indicates why a CPL script, or some other programmed version of the feature, is preferable. With caller preferences, a caller can override the desired ring sequence and disturb the executive without any kind of authorization. A proper version of this service would simply not permit caller preferences to force the call to go directly to the executive.
This case indicates why a CPL script, or some other programmed version of the feature, is preferable. With caller preferences, a caller can override the desired ring sequence and disturb the executive without any kind of authorization. A proper version of this service would simply not permit caller preferences to force the call to go directly to the executive.
3.15. Mobile Phone Only
3.15. Mobile Phone Only
3.15.1. Desired Behavior
3.15.1. Desired Behavior
The situation is similar to that in Section 3.13. However, the executive also has a mobile phone that they have registered. Caller X knows that the owner of Y is traveling, and that an assistant is covering the office phone. X wants to call Y and ring only the mobile phone.
The situation is similar to that in Section 3.13. However, the executive also has a mobile phone that they have registered. Caller X knows that the owner of Y is traveling, and that an assistant is covering the office phone. X wants to call Y and ring only the mobile phone.
3.15.2. Solution
3.15.2. Solution
The mobile phone would generate a registration that looks like, in part:
The mobile phone would generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:Y4@mobile.example.com>;mobility="mobile";q=0.1
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:Y4@mobile.example.com>;mobility="mobile";q=0.1
Rosenberg & Kyzivat Informational [Page 24] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 24] RFC 4596 Caller Preferences Uses July 2006
The caller would express their preference by generating an INVITE that looks like, in part:
The caller would express their preference by generating an INVITE that looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;mobility="mobile";require;explicit
All four contacts match. However, Y1 through Y3 match with a score of zero. Y4 matches with a score of 1. Because of the "require" and "explicit" tags, Y1 through Y3 are discarded, and only Y4 is used, as desired.
All four contacts match. However, Y1 through Y3 match with a score of zero. Y4 matches with a score of 1. Because of the "require" and "explicit" tags, Y1 through Y3 are discarded, and only Y4 is used, as desired.
Note that this only works if the mobile phone specifies the mobility feature in its registration.
Note that this only works if the mobile phone specifies the mobility feature in its registration.
3.16. Simultaneous Languages
3.16. Simultaneous Languages
3.16.1. Desired Behavior
3.16.1. Desired Behavior
AOR Y is as in Section 3.9. Caller X, fluent in both English and Spanish, has discovered that the company's Spanish language documentation is inconsistent with the English language documentation and wants to discuss the differences between the two. So X wants to speak with one of the workers that is fluent in both English and Spanish.
AOR Y is as in Section 3.9. Caller X, fluent in both English and Spanish, has discovered that the company's Spanish language documentation is inconsistent with the English language documentation and wants to discuss the differences between the two. So X wants to speak with one of the workers that is fluent in both English and Spanish.
3.16.2. Solution
3.16.2. Solution
The caller would generate an INVITE that looks like, in part:
The caller would generate an INVITE that looks like, in part:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en";require
Accept-Contact: *;language="es";require
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;language="en";require Accept-Contact: *;language="es";require
This will require a Contact URI to match both constraints. That means it needs to support English and Spanish. This will achieve the desired property.
This will require a Contact URI to match both constraints. That means it needs to support English and Spanish. This will achieve the desired property.
Note that there are two separate Accept-Contact header fields. If the caller had instead used this INVITE:
Note that there are two separate Accept-Contact header fields. If the caller had instead used this INVITE:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;language="en,es";require
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;language="en,es";require
It would have connected them to a UA that speaks either English or Spanish, which is not what is desired here.
It would have connected them to a UA that speaks either English or Spanish, which is not what is desired here.
An "explicit" option is not used, because it would bypass contacts that do not include a language tag.
An "explicit" option is not used, because it would bypass contacts that do not include a language tag.
Rosenberg & Kyzivat Informational [Page 25] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 25] RFC 4596 Caller Preferences Uses July 2006
3.17. The Number You Have Called...
3.17. The Number You Have Called...
3.17.1. Desired Behavior
3.17.1. Desired Behavior
Consider once more the case of the executive, where the caller wishes to reach only their mobile phone (Section 3.15). However, there is a twist. The callee Y has moved to new address YY, and all the configuration described for the callee now applies to YY. The old address Y remains with a pair of statically assigned contacts. One contact is YY. The other is M, referencing an automaton that generates a voice message reporting that the number has been changed. The caller is unaware of the move and calls Y, requesting to reach the mobile phone in exactly the same way they did in Section 3.15. The call should connect to the mobile.
Consider once more the case of the executive, where the caller wishes to reach only their mobile phone (Section 3.15). However, there is a twist. The callee Y has moved to new address YY, and all the configuration described for the callee now applies to YY. The old address Y remains with a pair of statically assigned contacts. One contact is YY. The other is M, referencing an automaton that generates a voice message reporting that the number has been changed. The caller is unaware of the move and calls Y, requesting to reach the mobile phone in exactly the same way they did in Section 3.15. The call should connect to the mobile.
3.17.2. Solution
3.17.2. Solution
There would be four registrations against YY:
There would be four registrations against YY:
YY1, the executive, would generate a REGISTER that looks like, in part:
YY1, the executive, would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY1@pc.example.com>;q=0.1
REGISTER sip:example.com SIP/2.0 To: sip:YY@example.com Contact: <sip:YY1@pc.example.com>;q=0.1
YY2, the attendant, would generate a REGISTER that looks like, in part:
YY2, the attendant, would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY2@pc2.example.com>;attendant;q=1.0
REGISTER sip:example.com SIP/2.0 To: sip:YY@example.com Contact: <sip:YY2@pc2.example.com>;attendant;q=1.0
YY3, the answering service, would generate a REGISTER that looks like, in part:
YY3, the answering service, would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY3@pc3.example.com>;attendant;automata;q=0.5
REGISTER sip:example.com SIP/2.0 To: sip:YY@example.com Contact: <sip:YY3@pc3.example.com>;attendant;automata;q=0.5
YY4, the mobile, would generate a REGISTER that looks like, in part:
YY4, the mobile, would generate a REGISTER that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:YY@example.com
Contact: <sip:YY4@mobile.example.com>;mobility="mobile";q=0.5
REGISTER sip:example.com SIP/2.0 To: sip:YY@example.com Contact: <sip:YY4@mobile.example.com>;mobility="mobile";q=0.5
Rosenberg & Kyzivat Informational [Page 26] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 26] RFC 4596 Caller Preferences Uses July 2006
Although it would be configured administratively, there are two registered contacts for Y. The first is for the forwarding:
Although it would be configured administratively, there are two registered contacts for Y. The first is for the forwarding:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:YY@example.com>;q=1.0
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:YY@example.com>;q=1.0
and the second for the automated answering service:
and the second for the automated answering service:
REGISTER sip:example.com SIP/2.0
To: sip:Y@example.com
Contact: <sip:machine@example.com>;automata;q=0.5
REGISTER sip:example.com SIP/2.0 To: sip:Y@example.com Contact: <sip:machine@example.com>;automata;q=0.5
The caller, not knowing that Y has moved, calls Y and asks for their mobile phone:
The caller, not knowing that Y has moved, calls Y and asks for their mobile phone:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;mobility="mobile";require;explicit
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;mobility="mobile";require;explicit
This reaches the example.com proxy, which finds two registrations. Only one of these (the automaton) is associated with feature parameters. The other has no feature parameters and is therefore immune to caller preferences processing. The caller preferences are applied to the automaton's contact. The feature sets match, but have a score of zero. Since the "require" and "explicit" tags are present, the contact for the automaton is dropped. The other contact, YY@example.com, is then added back in as the sole contact. The proxy therefore sends the call to sip:YY@example.com. There, there are four registrations, all of which are associated with feature parameters. The caller preferences are applied. Only YY4 matches explicitly, however. Because of the presence of the "require" and "explicit" flags, all other contacts are dropped. As such, the call is forwarded to YY4, and the mobile phone rings.
This reaches the example.com proxy, which finds two registrations. Only one of these (the automaton) is associated with feature parameters. The other has no feature parameters and is therefore immune to caller preferences processing. The caller preferences are applied to the automaton's contact. The feature sets match, but have a score of zero. Since the "require" and "explicit" tags are present, the contact for the automaton is dropped. The other contact, YY@example.com, is then added back in as the sole contact. The proxy therefore sends the call to sip:YY@example.com. There, there are four registrations, all of which are associated with feature parameters. The caller preferences are applied. Only YY4 matches explicitly, however. Because of the presence of the "require" and "explicit" flags, all other contacts are dropped. As such, the call is forwarded to YY4, and the mobile phone rings.
3.18. The Number You Have Called, Take Two
3.18. The Number You Have Called, Take Two
3.18.1. Desired Behavior
3.18.1. Desired Behavior
This use case is nearly identical to that of Section 3.17. However, this time, the caller wishes to contact the personal phone of Y. They don't feel strongly about it, and will accept other devices.
This use case is nearly identical to that of Section 3.17. However, this time, the caller wishes to contact the personal phone of Y. They don't feel strongly about it, and will accept other devices.
3.18.2. Solution
3.18.2. Solution
The INVITE generated by the caller in this case will look like:
The INVITE generated by the caller in this case will look like:
INVITE sip:Y@example.com SIP/2.0
Accept-Contact: *;class="personal"
INVITE sip:Y@example.com SIP/2.0 Accept-Contact: *;class="personal"
Rosenberg & Kyzivat Informational [Page 27] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 27] RFC 4596 Caller Preferences Uses July 2006
This reaches the example.com proxy. Once more, the first registration (which forwards to the address-of-record for YY) is unaffected by the caller preferences computation. The other contact, for the automaton, is a match, but its score is zero. Its caller preference Qa equals zero. The other contact is added back in with a Qa of 1.0. The contacts are sorted based on q-value, resulting in YY (q=1.0) followed by machine (q=0.5). These are broken into equivalence classes. There are two classes, one for each contact. As a result, the caller's preferences have no impact on the ordering, and the call is routed to YY.
This reaches the example.com proxy. Once more, the first registration (which forwards to the address-of-record for YY) is unaffected by the caller preferences computation. The other contact, for the automaton, is a match, but its score is zero. Its caller preference Qa equals zero. The other contact is added back in with a Qa of 1.0. The contacts are sorted based on q-value, resulting in YY (q=1.0) followed by machine (q=0.5). These are broken into equivalence classes. There are two classes, one for each contact. As a result, the caller's preferences have no impact on the ordering, and the call is routed to YY.
When the request for YY@example.com is processed, all four contacts match. However, the score for all of them is zero (none are the personal phone). As such, the contacts are ordered based on q-value. Each contact has a different q-value, so no reordering based on caller preference is possible (not that the caller preference would cause a reordering; all contacts have a Qa of 0.0). Thus, the highest q-value contact is tried, which is the executive assistant.
When the request for YY@example.com is processed, all four contacts match. However, the score for all of them is zero (none are the personal phone). As such, the contacts are ordered based on q-value. Each contact has a different q-value, so no reordering based on caller preference is possible (not that the caller preference would cause a reordering; all contacts have a Qa of 0.0). Thus, the highest q-value contact is tried, which is the executive assistant.
3.19. Forwarding to a Colleague
3.19. Forwarding to a Colleague
3.19.1. Desired Behavior
3.19.1. Desired Behavior
Alice wants to forward her phone to Bob, but doesn't want folks calling her to get Bob's voicemail if he doesn't answer. She wants her callers to get her voicemail.
Alice wants to forward her phone to Bob, but doesn't want folks calling her to get Bob's voicemail if he doesn't answer. She wants her callers to get her voicemail.
3.19.2. Solution
3.19.2. Solution
Alice would create three registrations. The first, Y1, represents Alice's phone. The second is Bob's AOR. The third is a voicemail server. The three contacts have decreasing q-values. The registration for Bob's AOR contains an embedded Reject-Contact header field, which rejects message servers.
Alice would create three registrations. The first, Y1, represents Alice's phone. The second is Bob's AOR. The third is a voicemail server. The three contacts have decreasing q-values. The registration for Bob's AOR contains an embedded Reject-Contact header field, which rejects message servers.
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:Y1@192.0.2.150>;q=1.0
REGISTER sip:example.com To: <sip:alice@example.com> Contact: <sip:Y1@192.0.2.150>;q=1.0
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:bob@example.com?Reject-Contact=*;msgserver>;q=0.3
REGISTER sip:example.com To: <sip:alice@example.com> Contact: <sip:bob@example.com?Reject-Contact=*;msgserver>;q=0.3
Rosenberg & Kyzivat Informational [Page 28] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 28] RFC 4596 Caller Preferences Uses July 2006
REGISTER sip:example.com
To: <sip:alice@example.com>
Contact: <sip:alice-drop@msgcenter.example.com>
;msgserver;
;automata
;attendant
;q=0.1
REGISTER sip:example.com To: <sip:alice@example.com> Contact: <sip:alice-drop@msgcenter.example.com> ;msgserver; ;automata ;attendant ;q=0.1
Meanwhile, Bob is registered as follows:
Meanwhile, Bob is registered as follows:
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob3@192.0.2.212>;q=0.8
REGISTER sip:example.com To: <sip:bob@example.com> Contact: <sip:bob3@192.0.2.212>;q=0.8
REGISTER sip:example.com
To: <sip:bob@example.com>
Contact: <sip:bob-drop@msgcenter.example.com>
;msgserver
;automata
;attendant
;q=0.2
REGISTER sip:example.com To: <sip:bob@example.com> Contact: <sip:bob-drop@msgcenter.example.com> ;msgserver ;automata ;attendant ;q=0.2
Carol calls Alice and doesn't include any caller preference parameters. As such, the example.com proxy constructs an implicit preference for INVITE. This preference matches all three registered contacts, with a score of zero. Because each contact has a different q-value, there is no reordering of contacts. So, the proxy tries the highest q-value Contact, Alice's desk phone (Y1). The proxy cancels after a few seconds (no answer). The proxy then tries the next Contact, which is Bob's AOR. When constructing the request for this Contact, the proxy includes the embedded Reject-Contact header field in the INVITE. This INVITE undergoes caller preferences processing based on Bob's registered Contacts.
Carol calls Alice and doesn't include any caller preference parameters. As such, the example.com proxy constructs an implicit preference for INVITE. This preference matches all three registered contacts, with a score of zero. Because each contact has a different q-value, there is no reordering of contacts. So, the proxy tries the highest q-value Contact, Alice's desk phone (Y1). The proxy cancels after a few seconds (no answer). The proxy then tries the next Contact, which is Bob's AOR. When constructing the request for this Contact, the proxy includes the embedded Reject-Contact header field in the INVITE. This INVITE undergoes caller preferences processing based on Bob's registered Contacts.
Bob has two registered Contacts. The second is a message server, and it matches the Reject-Contact in the INVITE. Thus, this contact is discarded. The other remaining Contact, Bob's phone, is tried. Bob is not around, so his phone rings for a while. Upon timeout, the proxy determines it is unable to reach Bob's AOR. So, the proxy handling Alice tries the final remaining contact, which is Alice's message server.
Bob has two registered Contacts. The second is a message server, and it matches the Reject-Contact in the INVITE. Thus, this contact is discarded. The other remaining Contact, Bob's phone, is tried. Bob is not around, so his phone rings for a while. Upon timeout, the proxy determines it is unable to reach Bob's AOR. So, the proxy handling Alice tries the final remaining contact, which is Alice's message server.
Rosenberg & Kyzivat Informational [Page 29] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 29] RFC 4596 Caller Preferences Uses July 2006
4. Capability Use Cases
4. Capability Use Cases
The callee capabilities spec [2] allows the Contact header field in OPTIONS responses and dialog initiating messages to contain capabilities of the UA. These capabilities can be very useful for developing new applications. In the subsections below, several usages are outlined.
The callee capabilities spec [2] allows the Contact header field in OPTIONS responses and dialog initiating messages to contain capabilities of the UA. These capabilities can be very useful for developing new applications. In the subsections below, several usages are outlined.
4.1. Web Redirect
4.1. Web Redirect
A caller sends an INVITE to the called party. However, the called party is not present. The proxy server representing the called party would like to redirect the caller to a web page, where they can find out more information on how to reach the called party. However, the proxy needs to know whether or not the caller supports redirects to web pages. If it doesn't, the proxy would connect the user to an interactive voice response (IVR) device, which would execute an answering machine application.
A caller sends an INVITE to the called party. However, the called party is not present. The proxy server representing the called party would like to redirect the caller to a web page, where they can find out more information on how to reach the called party. However, the proxy needs to know whether or not the caller supports redirects to web pages. If it doesn't, the proxy would connect the user to an interactive voice response (IVR) device, which would execute an answering machine application.
The proxy could make such a determination if the caller included the "schemes" feature tag in the Contact header field of its INVITE:
The proxy could make such a determination if the caller included the "schemes" feature tag in the Contact header field of its INVITE:
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="http,sip,sips,tel"
INVITE sip:callee@example.com SIP/2.0 Contact: <sip:host22.example.com>;schemes="http,sip,sips,tel"
This tells the proxy that the UAC can be redirected to an http URI. The INVITE from a normal "black phone" that lacked this capability would look like:
This tells the proxy that the UAC can be redirected to an http URI. The INVITE from a normal "black phone" that lacked this capability would look like:
INVITE sip:callee@example.com SIP/2.0
Contact: <sip:host22.example.com>;schemes="sip,sips,tel"
INVITE sip:callee@example.com SIP/2.0 Contact: <sip:host22.example.com>;schemes="sip,sips,tel"
This indicates that it needs to be connected to the IVR.
This indicates that it needs to be connected to the IVR.
4.2. Voicemail Icon
4.2. Voicemail Icon
On the circuit network, when a user makes a call, and an answering machine picks up, the caller usually requires several seconds to determine that they are speaking to an answering machine. It would be helpful if a phone could display an icon immediately on call completion that indicated that an answering machine was reached.
On the circuit network, when a user makes a call, and an answering machine picks up, the caller usually requires several seconds to determine that they are speaking to an answering machine. It would be helpful if a phone could display an icon immediately on call completion that indicated that an answering machine was reached.
This indication can be provided by the "msgserver" feature parameter. When the answering machine picks up, its 200 OK looks like, in part:
This indication can be provided by the "msgserver" feature parameter. When the answering machine picks up, its 200 OK looks like, in part:
SIP/2.0 200 OK
Contact: <sip:server33.example.com>;msgserver;automata;attendant
SIP/2.0 200 OK Contact: <sip:server33.example.com>;msgserver;automata;attendant
Rosenberg & Kyzivat Informational [Page 30] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 30] RFC 4596 Caller Preferences Uses July 2006
This tells the caller that it's an answering machine.
This tells the caller that it's an answering machine.
5. Usage of the Feature Tags
5. Usage of the Feature Tags
The caller preferences extension briefly enumerates a list of media feature tags that can be registered by a device and included in the Accept-Contact and Reject-Contact header fields in a request. Proper operation of caller preferences depends strongly on consistent interpretation of these feature tags by the caller and the callee. In this section, we provide some guidelines on the usage of these feature tags.
The caller preferences extension briefly enumerates a list of media feature tags that can be registered by a device and included in the Accept-Contact and Reject-Contact header fields in a request. Proper operation of caller preferences depends strongly on consistent interpretation of these feature tags by the caller and the callee. In this section, we provide some guidelines on the usage of these feature tags.
Generally speaking, the more information a device provides when it registers, the more effective the caller preferences extension is. This is why the callee capabilities extension recommends that a device register as much information as it can. This point cannot be overstated.
Generally speaking, the more information a device provides when it registers, the more effective the caller preferences extension is. This is why the callee capabilities extension recommends that a device register as much information as it can. This point cannot be overstated.
If devices explicitly registered features that they don't support, such as 'video="false"', the operation of RFC 3841 would be improved. However, given the open-ended nature of capabilities, it will never be possible to ensure the registration of negative values for all capabilities of interest to a caller. Furthermore, attempting to do so would significantly bloat registrations. Instead, it is recommended that all "unusual" capabilities be explicitly registered.
If devices explicitly registered features that they don't support, such as 'video="false"', the operation of RFC 3841 would be improved. However, given the open-ended nature of capabilities, it will never be possible to ensure the registration of negative values for all capabilities of interest to a caller. Furthermore, attempting to do so would significantly bloat registrations. Instead, it is recommended that all "unusual" capabilities be explicitly registered.
The subsections below show example registrations from typical devices.
The subsections below show example registrations from typical devices.
5.1. Traditional Cell Phone
5.1. Traditional Cell Phone
A VoIP cell phone capable of making voice calls would generate a registration that looks like, in part:
A VoIP cell phone capable of making voice calls would generate a registration that looks like, in part:
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:cell-phone@example.com>
;audio
;class="business"
;duplex="full"
;+sip.extensions="100rel,path"
;mobility="mobile"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<cell-phone>"
;uri-domain="example.com"
REGISTER sip:example.com SIP/2.0 To: sip:user@example.com Contact: <sip:cell-phone@example.com> ;audio ;class="business" ;duplex="full" ;+sip.extensions="100rel,path" ;mobility="mobile" ;methods="INVITE,BYE,OPTIONS,CANCEL,ACK" ;schemes="sip,sips,tel" ;uri-user="<cell-phone>" ;uri-domain="example.com"
Rosenberg & Kyzivat Informational [Page 31] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 31] RFC 4596 Caller Preferences Uses July 2006
5.2. Traditional Work Phone
5.2. Traditional Work Phone
A traditional landline IP PBX phone would generate a registration that looks like:
A traditional landline IP PBX phone would generate a registration that looks like:
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:ippbx-phone@example.com>
;audio
;class="business"
;duplex="full"
;events="dialog"
;+sip.extensions="100rel,privacy"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK,SUBSCRIBE"
;schemes="sip,sips,tel"
;uri-user="<ippbx-phone>"
;uri-domain="example.com"
REGISTER sip:example.com SIP/2.0 To: sip:user@example.com Contact: <sip:ippbx-phone@example.com> ;audio ;class="business" ;duplex="full" ;events="dialog" ;+sip.extensions="100rel,privacy" ;mobility="fixed" ;methods="INVITE,BYE,OPTIONS,CANCEL,ACK,SUBSCRIBE" ;schemes="sip,sips,tel" ;uri-user="<ippbx-phone>" ;uri-domain="example.com"
This device also supports the dialog event package and several SIP extensions that would be typical in an IP PBX phone.
This device also supports the dialog event package and several SIP extensions that would be typical in an IP PBX phone.
5.3. PC Messaging Application
5.3. PC Messaging Application
A PC messenger client, capable of just doing presence and IM (no voice) would generate a registration that looks like:
A PC messenger client, capable of just doing presence and IM (no voice) would generate a registration that looks like:
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:pc-msgr@example.com>
;class="personal"
;mobility="fixed"
;methods="OPTIONS,MESSAGE,NOTIFY"
;schemes="sip,sips,im,pres"
;uri-user="<pc-msgr>"
;uri-domain="example.com"
REGISTER sip:example.com SIP/2.0 To: sip:user@example.com Contact: <sip:pc-msgr@example.com> ;class="personal" ;mobility="fixed" ;methods="OPTIONS,MESSAGE,NOTIFY" ;schemes="sip,sips,im,pres" ;uri-user="<pc-msgr>" ;uri-domain="example.com"
Rosenberg & Kyzivat Informational [Page 32] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 32] RFC 4596 Caller Preferences Uses July 2006
5.4. Standalone Videophone
5.4. Standalone Videophone
A standalone IP videophone, capable of audio and video, would generate a registration that looks like, in part
A standalone IP videophone, capable of audio and video, would generate a registration that looks like, in part
REGISTER sip:example.com SIP/2.0
To: sip:user@example.com
Contact: <sip:vp@example.com>
;audio
;video
;class="business"
;duplex="full"
;mobility="fixed"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip,sips,tel"
;uri-user="<vp>"
;uri-domain="example.com"
REGISTER sip:example.com SIP/2.0 To: sip:user@example.com Contact: <sip:vp@example.com> ;audio ;video ;class="business" ;duplex="full" ;mobility="fixed" ;methods="INVITE,BYE,OPTIONS,CANCEL,ACK" ;schemes="sip,sips,tel" ;uri-user="<vp>" ;uri-domain="example.com"
6. Example of Implementation of Preference and Capability Matching
6. Example of Implementation of Preference and Capability Matching
RFC 3841 [3] utilizes the definitions and feature matching algorithm defined in RFC 2533 [6]. This provides a precise normative specification of the algorithm. However, that specification isn't ideal as a guideline for implementation because it is more complex than is required for the restricted use employed by RFC 3841. (The simplification is primarily because a particular feature tag may only appear once in each Contact, Accept-Contact, or Reject-Contact header.)
RFC 3841 [3] utilizes the definitions and feature matching algorithm defined in RFC 2533 [6]. This provides a precise normative specification of the algorithm. However, that specification isn't ideal as a guideline for implementation because it is more complex than is required for the restricted use employed by RFC 3841. (The simplification is primarily because a particular feature tag may only appear once in each Contact, Accept-Contact, or Reject-Contact header.)
This section provides a sample approach to implementing the matching of caller preferences to callee capabilities; it does not require the use of the notation and techniques of RFC 2533. It is not normative, but is believed to be consistent with that definition. It may be considered an alternative for that portion of RFC 3841 beginning with Section 7.2.3 and extending to the end of page 13 in the middle of Section 7.2.4.
This section provides a sample approach to implementing the matching of caller preferences to callee capabilities; it does not require the use of the notation and techniques of RFC 2533. It is not normative, but is believed to be consistent with that definition. It may be considered an alternative for that portion of RFC 3841 beginning with Section 7.2.3 and extending to the end of page 13 in the middle of Section 7.2.4.
In this section, there are frequent references to syntactic elements defined by ABNF in RFC 3840, Section 9, and RFC 3841, Section 10. Here, ABNF elements are enclosed to single quotes -- for example, 'feature-param'. Such a reference identifies a sequence of octets within a SIP request that match the corresponding ABNF element when the sip request is parsed according to RFCs 3261, 3840, and 3841.
In this section, there are frequent references to syntactic elements defined by ABNF in RFC 3840, Section 9, and RFC 3841, Section 10. Here, ABNF elements are enclosed to single quotes -- for example, 'feature-param'. Such a reference identifies a sequence of octets within a SIP request that match the corresponding ABNF element when the sip request is parsed according to RFCs 3261, 3840, and 3841.
Rosenberg & Kyzivat Informational [Page 33] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 33] RFC 4596 Caller Preferences Uses July 2006
6.1. Extracting a Feature Set from a Header
6.1. Extracting a Feature Set from a Header
Contact header fields, Accept-Contact header fields, and Reject- Contact header fields each contain zero or more 'feature-param's, each in turn may contain one or more 'tag-value's, or a 'string- value'. The first step is to extract from each header field a more useful representation as a feature set, herein called an FS. (This FS representation of a feature set representation differs from that in RFC 2533.) This process is the same for each type of header.
Contact header fields, Accept-Contact header fields, and Reject- Contact header fields each contain zero or more 'feature-param's, each in turn may contain one or more 'tag-value's, or a 'string- value'. The first step is to extract from each header field a more useful representation as a feature set, herein called an FS. (This FS representation of a feature set representation differs from that in RFC 2533.) This process is the same for each type of header.
An FS consists of a set of one or more feature params denoted by FP. Each FP has a name, denoted FP.NAME, and a set of one or more value ranges denoted by VR. Each VR consists of:
An FS consists of a set of one or more feature params denoted by FP. Each FP has a name, denoted FP.NAME, and a set of one or more value ranges denoted by VR. Each VR consists of:
o A type (VR.TYPE): either token (TOKEN-TYPE), string (STRING-TYPE),
or number-range (RANGE-TYPE)
o A type (VR.TYPE): either token (TOKEN-TYPE), string (STRING-TYPE), or number-range (RANGE-TYPE)
o A negation flag (VR.NEGATION): either NEGATED, or NON-NEGATED
o A negation flag (VR.NEGATION): either NEGATED, or NON-NEGATED
o The actual value, differing by type:
o The actual value, differing by type:
* For TOKEN-TYPE and STRING-TYPE, a sequence of octets
(VR.OCTETS)
* For TOKEN-TYPE and STRING-TYPE, a sequence of octets (VR.OCTETS)
* For RANGE-TYPE, a pair of signed real numbers (VR.LB and VR.UB)
representing the lower and upper bounds on the range,
inclusive.
* For RANGE-TYPE, a pair of signed real numbers (VR.LB and VR.UB) representing the lower and upper bounds on the range, inclusive.
A single FS is created to represent the features of one header. (Contact, Accept-Contact, Reject-Contact.) Within the FS, an FP is created for each 'feature-param' in the header. To create an FP, a 'feature-param' is examined as follows:
A single FS is created to represent the features of one header. (Contact, Accept-Contact, Reject-Contact.) Within the FS, an FP is created for each 'feature-param' in the header. To create an FP, a 'feature-param' is examined as follows:
o If the 'feature-param' contains an instance of 'other-tags', then
FP.NAME is the value matched by 'ftag-name'.
o If the 'feature-param' contains an instance of 'other-tags', then FP.NAME is the value matched by 'ftag-name'.
o Otherwise, the 'feature-param' contains an instance of 'base-
tags'. If the value matched by 'base-tags' is "language" or
"type", then FP.NAME is just the value matched by 'base-tags'. If
not, then FP.NAME is the value matched by 'base-tags' and prefixed
with "sip.".
o Otherwise, the 'feature-param' contains an instance of 'base- tags'. If the value matched by 'base-tags' is "language" or "type", then FP.NAME is just the value matched by 'base-tags'. If not, then FP.NAME is the value matched by 'base-tags' and prefixed with "sip.".
o The value of the 'feature-param', if any, is processed (according
to the rules in the next section) to extract a set of one or more
VRs that are associated with the FP.
o The value of the 'feature-param', if any, is processed (according to the rules in the next section) to extract a set of one or more VRs that are associated with the FP.
Rosenberg & Kyzivat Informational [Page 34] RFC 4596 Caller Preferences Uses July 2006
Rosenberg & Kyzivat Informational [Page 34] RFC 4596 Caller Preferences Uses July 2006
6.2. Extracting Values from a Feature Parameter
6.2. Extracting Values from a Feature Parameter
The value of a 'feature-param' is an encoded representation (as specified in RFC 3840) of one or more value ranges of the corresponding feature. There are several data types that these values may take on: boolean, token, string, number, or numeric range. The type is determined by the encoded form of the value. (These types and their representations are specific to this implementation.)
The value of a 'feature-param' is an encoded representation (as specified in RFC 3840) of one or more value ranges of the corresponding feature. There are several data types that these values may take on: boolean, token, string, number, or numeric range. The type is determined by the encoded form of the value. (These types and their representations are specific to this implementation.)
(Note: numeric values can explicitly represent a range of values. The other types only represent single value: a degenerate range. The term value range is used to encompass all of these.)
(Note: numeric values can explicitly represent a range of values. The other types only represent single value: a degenerate range. The term value range is used to encompass all of these.)
The value of the 'feature-param' ('string-value', 'tag-value-list',
or none) is converted to VR form as follows:
The value of the 'feature-param' ('string-value', 'tag-value-list', or none) is converted to VR form as follows:
o If there is no value, then a single new VR is created with VR.TYPE
= TOKEN-TYPE, VR.NEGATION = NON-NEGATED, and VR.OCTETS set to
"true".
o 値が全くなければ、独身の新しいVRはVR.TYPE=TOKEN-TYPEと共に作成されました、そして、VR.NEGATIONはNON-NEGATEDと等しいです、そして、VR.OCTETSは「本当に」セットしました。
o If the 'feature-param' contains a 'string-value', then a single
new VR is created with VR.TYPE = STRING-TYPE, VR.NEGATION =
NON-NEGATED, and VR.OCTETS is set to the octets matching 'qdtext'.
o '特徴-param'が'ストリング値'を含んでいるなら、独身の新しいVRはVR.TYPE=STRING-TYPEと共に作成されます、そして、VR.NEGATIONはNON-NEGATEDと等しいです、そして、VR.OCTETSは'qdtext'に合っている八重奏に用意ができています。
o Otherwise the 'feature-param' contains a 'tag-value-list', and a
new VR is created for each 'tag-value' in the 'tag-value-list', as
follows:
o さもなければ、'特徴-param'は'タグ値のリスト'を含んでいます、そして、新しいVRは'タグ値のリスト'の各'タグ値'のために以下の通り作成されます:
o If the 'tag-value' begins with "!", VR.NEGATION = NEGATED;
otherwise, VR.NEGATION = NON-NEGATED.
o 'タグ値'が“!"で始まるなら、VR.NEGATION=は否定しました。 さもなければ、VR.NEGATIONはNON-NEGATEDと等しいです。
o If the 'tag-value' contains a 'boolean' or 'token-nobang', then
VR.TYPE = TOKEN-TYPE, and VR.OCTETS is set to the octets matched
by 'boolean' or 'token-nobang'.
o 'タグ値'が'論理演算子'か'象徴-nobang'を含んでいるなら、VR.TYPEはTOKEN-TYPEと等しいです、そして、VR.OCTETSは'論理演算子'か'象徴-nobang'によって合われていた八重奏に用意ができています。
o If the 'tag-value' contains a 'numeric', VR.TYPE = RANGE-TYPE and:
o そして、'タグ値'が'数値'を含んでいるなら、VR.TYPEがRANGE-TYPEと等しい、:
* If 'numeric-relation' is "<=", VR.UB is set to the numeric
value matching 'number'. VR.LB is set to MIN-REAL (a negative
number with the largest expressible magnitude.)
* '数値関係'が「<=」であるなら、VR.UBは数値の合っている'数'に用意ができています。 VR.LBはMIN-レアルに用意ができています。(最も大きい表現できる大きさに従った負数。)
* If 'numeric-relation' is "=", both VR.LB and VR.UB are set to
the numeric value matching 'number'.
* '数値関係'が「=」であるなら、VR.LBとVR.UBの両方が数値の合っている'数'に用意ができています。
* If 'numeric-relation' is ">=", VR.LB is set to the numeric
value matching 'number' plus a small epsilon. VR.UB is set to
MAX-REAL (a positive number with the largest expressible
magnitude).
* '数値関係'が「>=」であるなら、VR.LBは数値の合っている'数'と小さいεへのセットです。 VR.UBはマックス-レアル(最も大きい表現できる大きさに従った正の数)に用意ができています。
Rosenberg & Kyzivat Informational [Page 35] RFC 4596 Caller Preferences Uses July 2006
ローゼンバーグとKyzivatの情報の[35ページ]RFC4596訪問者好みの用途2006年7月
* Else the 'numeric-relation' consists of two 'number's separated
by a colon. In this case, VR.LB is set to the numeric value of
the smaller of the two numbers, and VR.UB is set to the numeric
value of the larger of the two numbers.
* ほかに、'数値関係'は'数はコロンで切り離した'2から成ります。 この場合、VR.LBは2つの番号について、より小さいことの数値に用意ができています、そして、VR.UBは2つの番号について、より大きいことの数値に用意ができています。
6.3. Comparing Two Value-Ranges
6.3. 2つの値範囲を比較します。
Two VRs match if their ranges overlap. The comparison is done according to type, and only comparisons between like types are defined. When two VRs of differing types are compared, they are considered not to overlap. Either or both of the VRs may be NEGATED. Comparison proceeds as follows:
彼らの範囲が重なるなら、2VRsが合っています。 タイプに従って、比較します、そして、同様のタイプでの比較だけを定義します。 異なったタイプの2VRsが比べるとき、彼らが重ならないと考えられます。 VRsのどちらかか両方がNEGATEDであるかもしれません。 比較は以下の通り続きます:
o If the VRs are of different types, the match is false.
o 異なったタイプにVRsがあるなら、マッチは偽です。
o Otherwise:
o そうでなければ:
* Two VRs with VR.TYPE = RANGE-TYPE match if max(VR1.LB, VR2.LB)
<= min(VR1.UB, VR2.UB).
* VR.TYPEと2VRsが最大(VR1.LB、VR2.LB)<=分(VR1.UB、VR2.UB)であるならRANGE-TYPEマッチと等しいです。
* Two VRs with VR.TYPE = TOKEN-TYPE match if their respective
VR.OCTETS values compare equal by case-insensitive comparison.
* 彼らのそれぞれのVR.OCTETS値が大文字と小文字を区別しない比較で同輩を比較するなら、VR.TYPEと2VRs=TOKEN-TYPEは合っています。
* Two VRs with VR.TYPE = STRING-TYPE match if their respective
VR.OCTETS values compare equal by case-sensitive comparison.
* 彼らのそれぞれのVR.OCTETS値が大文字と小文字を区別する比較で同輩を比較するなら、VR.TYPEと2VRsがSTRING-TYPEマッチと等しいです。
o The result (true/false) is then negated if VR1.NEGATION = NEGATED,
and negated again if VR2.NEGATION = NEGATED.
o VR2.NEGATIONがNEGATEDと等しいなら、結果(本当の、または、誤った)は、次に、VR1.NEGATIONがNEGATEDと等しいなら否定されて、再び否定されます。
6.4. Feature Set to Feature Set Matching
6.4. 特徴は、セットマッチングを特徴とするようにセットしました。
In RFC 2533, the matching of two feature sets is commutative, but as applied to caller preferences matching it is not. In this application, one feature set comes from an Accept-Contact or Reject- Contact header, and the other comes from a Contact header. For purposes of this description, these will be termed the preferred- features (FSp) and the capability-features (FSc), respectively. Non-commutativity arises from explicit tests for the presence among capability-params of feature param names used in preferred-features.
RFC2533では、2つの特徴セットのマッチングは交換可能ですが、訪問者好みに適用されるように、それはマッチングではありません。 このアプリケーションでは、1つの特徴セットがAccept-接触かReject接触ヘッダーから来ます、そして、もう片方がContactヘッダーから来ます。 この記述の目的のために、これらはそれぞれ都合のよい特徴(FSp)と能力機能(FSc)と呼ばれるでしょう。 非可換性は都合のよい特徴で使用される特徴param名の能力-paramsの中の存在のための明白なテストから起こります。
A preferred-features feature set FSp may be matched to one capability-features feature set FSc, and this yields the following metrics:
都合のよい特徴特徴セットFSpは1能力機能特徴セットFScに合わせられるかもしれません、そして、これは以下の測定基準をもたらします:
o NPF - The number of preferred-features.
o NPF--都合のよい特徴の数。
o NCF - The number of preferred-features for which there is a
capability-feature of the same name.
o NCF--同じ名前の能力機能がある都合のよい特徴の数。
Rosenberg & Kyzivat Informational [Page 36] RFC 4596 Caller Preferences Uses July 2006
ローゼンバーグとKyzivatの情報の[36ページ]RFC4596訪問者好みの用途2006年7月
o NVM - The number of value matches between corresponding features
of the two feature sets.
o NVM--2機能の対応する特徴の間の値のマッチの数はセットします。
For a particular pair of FPp and FPc, these metrics are computed as follows:
FPpとFPcの特定の組において、これらの測定基準は以下の通り計算されます:
o All the metrics are set to zero.
o すべての測定基準がゼロに設定されます。
o The following steps are applied for each feature param (FPp) of
the FSp:
o 以下のステップはFSpのそれぞれの特徴param(FPp)のために適用されます:
* NPF is incremented.
* NPFは増加されています。
* A corresponding FP with the same name is sought (using case-
insensitive comparison) in the FSc.
* 同じ名前がある対応するFPはFScで探されます(ケースの神経の鈍い比較を使用します)。
* If a corresponding feature param (FPc) is found:
* 対応する特徴param(FPc)が見つけられるなら:
+ NCF is incremented.
+ NCFは増加されています。
+ Every VR of FPp is matched to every VR of FPc.
+ FPpのあらゆるVRがFPcのあらゆるVRに合わせられています。
+ If any of those matches succeed, NVM is incremented.
もしあればそれらのマッチの+は成功して、NVMは増加されています。
6.5. Selecting and Ordering Contacts Based on Caller Preferences
6.5. 接触を訪問者好みに基礎づけるよう選択して、命令します。
6.5.1. Reject-Contact Processing
6.5.1. 廃棄物接触処理
The reject processing specified in Section 7.4.2 of RFC 3841 may be performed as follows:
.2セクション7.4RFC3841で指定された廃棄物処理は以下の通り実行されるかもしれません:
o For each candidate Contact in the target set, match the feature
set of each Reject-Contact to it.
o 目標セットの各候補者Contactには、それとのそれぞれのReject-接触の特徴セットを合わせてください。
o If (NVM == NPF) & (NCF == NPF), remove the contact URI from the
target set.
o (NVM=NPF)と(NCF=NPF)であるなら、目標セットから接触URIを取り除いてください。
6.5.2. Accept-Contact Processing
6.5.2. 接触を受け入れている処理
The matching of an Accept-Contact against a Contact and subsequent scoring of the match specified in Section 7.4.2 of RFC 3841 may be performed as follows:
Contactに対するAccept-接触のマッチングと.2セクション7.4RFC3841で指定されたマッチのその後の得点は以下の通り実行されるかもしれません:
o Match the feature set of the Accept-Contact to that of the Contact
as specified in Section 6.4.
o セクション6.4における指定されるとしてのContactのものとのAccept-接触の特徴セットを合わせてください。
Rosenberg & Kyzivat Informational [Page 37] RFC 4596 Caller Preferences Uses July 2006
ローゼンバーグとKyzivatの情報の[37ページ]RFC4596訪問者好みの用途2006年7月
o If (NVM < NCF), then the match failed. If the Accept-Contact had
its "require" flag set, then discard the corresponding contact URI
from the target set.
o (NVM<NCF)であるなら、マッチは失敗しました。 Accept-接触で「必要」旗を設定したなら、目標セットから対応する接触URIを捨ててください。
o Compute the score as NVM/NPF.
o NVM/NPFとしてスコアを計算してください。
o Apply the "require" and "explicit" flags as specified in the text
and Figure 7 of RFC 3841.
o RFC3841のテキストと図7の指定されるとしての「必要」と「明白な」旗を適用してください。
7. Security Considerations
7. セキュリティ問題
This document provides explanation and examples of the use and implementation of RFCs 3840 and 3841. The security considerations sections of those documents apply to the material presented here.
このドキュメントはRFCs3840と3841年の使用と実現に関する説明と例を提供します。 それらのドキュメントのセキュリティ問題部はここで寄贈された材料に適用されます。
8. Acknowledgements
8. 承認
The authors would like to thank Rohan Mahy for his input in this specification.
作者はこの仕様による彼の入力についてRohanマーイに感謝したがっています。
9. Informative References
9. 有益な参照
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[2] ローゼンバーグ、J.、Schulzrinne、H.、およびP.Kyzivat、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[3] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[3] ローゼンバーグ、J.、Schulzrinne、H.、およびP.Kyzivat、「セッション開始プロトコル(一口)のための訪問者好み」、RFC3841、2004年8月。
[4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", BCP 67, RFC 3427, December 2002.
[4] マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼンは「セッション開始プロトコル(一口)のために過程を変えます」、BCP67、RFC3427、2002年12月。
[5] Lennox, J. and H. Schulzrinne, "Call Processing Language
Framework and Requirements", RFC 2824, May 2000.
[5] レノックス、J.、H.Schulzrinne、および「呼び出し処理言語枠組みと要件」(RFC2824)は2000がそうするかもしれません。
[6] Klyne, G., "A Syntax for Describing Media Feature Sets",
RFC 2533, March 1999.
[6]Klyne、G.、「特徴が設定するメディアを説明するための構文」、RFC2533、1999年3月。
[7] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[7] ローゼンバーグ、J.、Schulzrinne、H.、およびR.マーイ、「招待はセッション開始プロトコル(一口)のために対話イベントパッケージを開始しました」、RFC4235、2005年11月。
Rosenberg & Kyzivat Informational [Page 38] RFC 4596 Caller Preferences Uses July 2006
ローゼンバーグとKyzivatの情報の[38ページ]RFC4596訪問者好みの用途2006年7月
[8] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年8月。
[9] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004.
[9] ローゼンバーグ、J.、ピーターソン、J.、Schulzrinne、H.、およびG.キャマリロ、「セッション開始という第三者呼び出しコントロール(3pcc)のための最も良い現在の実務は(一口)について議定書の中で述べます」、BCP85、RFC3725、2004年4月。
[10] Campbell, B., "The Message Session Relay Protocol", Work in
Progress, July 2006.
[10] キャンベル、B.、「メッセージセッションリレープロトコル」が進歩、2006年7月に働いています。
Authors' Addresses
作者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaニュージャージー07054パーシッパニー(米国)
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Paul Kyzivat Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 US
ポールKyzivatシスコシステムズ1414マサチューセッツ通りBoxborough、MA01719米国
Phone: +1 978 936-1881 EMail: pkyzivat@cisco.com
以下に電話をしてください。 +1 978 936-1881 メールしてください: pkyzivat@cisco.com
Rosenberg & Kyzivat Informational [Page 39] RFC 4596 Caller Preferences Uses July 2006
ローゼンバーグとKyzivatの情報の[39ページ]RFC4596訪問者好みの用途2006年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rosenberg & Kyzivat Informational [Page 40]
ローゼンバーグとKyzivat情報です。[40ページ]
一覧
スポンサーリンク
