RFC4504 日本語訳
4504 SIP Telephony Device Requirements and Configuration. H.Sinnreich, Ed., S. Lass, C. Stredicke. May 2006. (Format: TXT=84849 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Sinnreich, Ed.
Request for Comments: 4504 pulver.com
Category: Informational S. Lass
Verizon
C. Stredicke
snom
May 2006
Network Working Group H. Sinnreich, Ed. Request for Comments: 4504 pulver.com Category: Informational S. Lass Verizon C. Stredicke snom May 2006
SIP Telephony Device Requirements and Configuration
SIP Telephony Device Requirements and Configuration
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 describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.
This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.
We present a glossary of the most common settings and some of the more widely used values for some settings.
We present a glossary of the most common settings and some of the more widely used values for some settings.
Table of Contents
Table of Contents
1. Introduction ....................................................3
1.1. Conventions used in this document ..........................4
2. Generic Requirements ............................................4
2.1. SIP Telephony Devices ......................................4
2.2. DNS and ENUM Support .......................................5
2.3. SIP Device Resident Telephony Features .....................5
2.4. Support for SIP Services ...................................8
2.5. Basic Telephony and Presence Information Support ...........9
2.6. Emergency and Resource Priority Support ....................9
2.7. Multi-Line Requirements ...................................10
2.8. User Mobility .............................................11
2.9. Interactive Text Support ..................................11
1. Introduction ....................................................3 1.1. Conventions used in this document ..........................4 2. Generic Requirements ............................................4 2.1. SIP Telephony Devices ......................................4 2.2. DNS and ENUM Support .......................................5 2.3. SIP Device Resident Telephony Features .....................5 2.4. Support for SIP Services ...................................8 2.5. Basic Telephony and Presence Information Support ...........9 2.6. Emergency and Resource Priority Support ....................9 2.7. Multi-Line Requirements ...................................10 2.8. User Mobility .............................................11 2.9. Interactive Text Support ..................................11
Sinnreich, et al. Informational [Page 1] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich, et al. Informational [Page 1] RFC 4504 SIP Telephony Device Requirements May 2006
2.10. Other Related Protocols ..................................12
2.11. SIP Device Security Requirements .........................13
2.12. Quality of Service .......................................13
2.13. Media Requirements .......................................14
2.14. Voice Codecs .............................................14
2.15. Telephony Sound Requirements .............................15
2.16. International Requirements ...............................15
2.17. Support for Related Applications .........................16
2.18. Web-Based Feature Management .............................16
2.19. Firewall and NAT Traversal ...............................16
2.20. Device Interfaces ........................................17
3. Glossary and Usage for the Configuration Settings ..............18
3.1. Device ID .................................................18
3.2. Signaling Port ............................................19
3.3. RTP Port Range ............................................19
3.4. Quality of Service ........................................19
3.5. Default Call Handling .....................................19
3.5.1. Outbound Proxy .....................................19
3.5.2. Default Outbound Proxy .............................20
3.5.3. SIP Session Timer ..................................20
3.6. Telephone Dialing Functions ...............................20
3.6.1. Phone Number Representations .......................20
3.6.2. Digit Maps and/or the Dial/OK Key ..................20
3.6.3. Default Digit Map ..................................21
3.7. SIP Timer Settings ........................................21
3.8. Audio Codecs ..............................................21
3.9. DTMF Method ...............................................22
3.10. Local and Regional Parameters ............................22
3.11. Time Server ..............................................22
3.12. Language .................................................23
3.13. Inbound Authentication ...................................23
3.14. Voice Message Settings ...................................23
3.15. Phonebook and Call History ...............................24
3.16. User-Related Settings and Mobility .......................24
3.17. AOR-Related Settings .....................................25
3.18. Maximum Connections ......................................25
3.19. Automatic Configuration and Upgrade ......................25
3.20. Security Configurations ..................................26
4. Security Considerations ........................................26
4.1. Threats and Problem Statement .............................26
4.2. SIP Telephony Device Security .............................27
4.3. Privacy ...................................................28
4.4. Support for NAT and Firewall Traversal ....................28
5. Acknowledgements ...............................................29
6. Informative References .........................................31
2.10. Other Related Protocols ..................................12 2.11. SIP Device Security Requirements .........................13 2.12. Quality of Service .......................................13 2.13. Media Requirements .......................................14 2.14. Voice Codecs .............................................14 2.15. Telephony Sound Requirements .............................15 2.16. International Requirements ...............................15 2.17. Support for Related Applications .........................16 2.18. Web-Based Feature Management .............................16 2.19. Firewall and NAT Traversal ...............................16 2.20. Device Interfaces ........................................17 3. Glossary and Usage for the Configuration Settings ..............18 3.1. Device ID .................................................18 3.2. Signaling Port ............................................19 3.3. RTP Port Range ............................................19 3.4. Quality of Service ........................................19 3.5. Default Call Handling .....................................19 3.5.1. Outbound Proxy .....................................19 3.5.2. Default Outbound Proxy .............................20 3.5.3. SIP Session Timer ..................................20 3.6. Telephone Dialing Functions ...............................20 3.6.1. Phone Number Representations .......................20 3.6.2. Digit Maps and/or the Dial/OK Key ..................20 3.6.3. Default Digit Map ..................................21 3.7. SIP Timer Settings ........................................21 3.8. Audio Codecs ..............................................21 3.9. DTMF Method ...............................................22 3.10. Local and Regional Parameters ............................22 3.11. Time Server ..............................................22 3.12. Language .................................................23 3.13. Inbound Authentication ...................................23 3.14. Voice Message Settings ...................................23 3.15. Phonebook and Call History ...............................24 3.16. User-Related Settings and Mobility .......................24 3.17. AOR-Related Settings .....................................25 3.18. Maximum Connections ......................................25 3.19. Automatic Configuration and Upgrade ......................25 3.20. Security Configurations ..................................26 4. Security Considerations ........................................26 4.1. Threats and Problem Statement .............................26 4.2. SIP Telephony Device Security .............................27 4.3. Privacy ...................................................28 4.4. Support for NAT and Firewall Traversal ....................28 5. Acknowledgements ...............................................29 6. Informative References .........................................31
Sinnreich, et al. Informational [Page 2] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich, et al. Informational [Page 2] RFC 4504 SIP Telephony Device Requirements May 2006
1. Introduction
1. Introduction
This document has the objective of focusing the Internet communications community on requirements for telephony devices using SIP.
This document has the objective of focusing the Internet communications community on requirements for telephony devices using SIP.
We base this information from developing and using a large number of SIP telephony devices in carrier and private IP networks and on the Internet. This deployment has shown the need for generic requirements for SIP telephony devices and also the need for some specifics that can be used in SIP interoperability testing.
We base this information from developing and using a large number of SIP telephony devices in carrier and private IP networks and on the Internet. This deployment has shown the need for generic requirements for SIP telephony devices and also the need for some specifics that can be used in SIP interoperability testing.
SIP telephony devices, also referred to as SIP User Agents (UAs), can be any type of IP networked computing user device enabled for SIP- based IP telephony. SIP telephony user devices can be SIP phones, adaptors for analog phones and for fax machines, conference speakerphones, software packages (soft clients) running on PCs, laptops, wireless connected PDAs, 'Wi-Fi' SIP mobile phones, as well as other mobile and cordless phones that support SIP signaling for real-time communications. SIP-PSTN gateways are not the object of this memo, since they are network elements and not end user devices.
SIP telephony devices, also referred to as SIP User Agents (UAs), can be any type of IP networked computing user device enabled for SIP- based IP telephony. SIP telephony user devices can be SIP phones, adaptors for analog phones and for fax machines, conference speakerphones, software packages (soft clients) running on PCs, laptops, wireless connected PDAs, 'Wi-Fi' SIP mobile phones, as well as other mobile and cordless phones that support SIP signaling for real-time communications. SIP-PSTN gateways are not the object of this memo, since they are network elements and not end user devices.
SIP telephony devices can also be instant messaging (IM) applications that have a telephony option.
SIP telephony devices can also be instant messaging (IM) applications that have a telephony option.
SIP devices MAY support various other media besides voice, such as text, video, games, and other Internet applications; however, the non-voice requirements are not specified in this document, except when providing enhanced telephony features.
SIP devices MAY support various other media besides voice, such as text, video, games, and other Internet applications; however, the non-voice requirements are not specified in this document, except when providing enhanced telephony features.
SIP telephony devices are highly complex IP endpoints that speak many Internet protocols, have audio and visual interfaces, and require functionality targeted at several constituencies: (1) end users, (2) service providers and network administrators, (3) manufacturers, and (4) system integrators.
SIP telephony devices are highly complex IP endpoints that speak many Internet protocols, have audio and visual interfaces, and require functionality targeted at several constituencies: (1) end users, (2) service providers and network administrators, (3) manufacturers, and (4) system integrators.
The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for standard PCs, analog feature phones, or mobile phones. Given the cost of some feature-rich display phones may approach the cost of PCs and PDAs, similar or even better ease of use as compared to personal computers and networked PDAs is expected by both end users and network administrators.
The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for standard PCs, analog feature phones, or mobile phones. Given the cost of some feature-rich display phones may approach the cost of PCs and PDAs, similar or even better ease of use as compared to personal computers and networked PDAs is expected by both end users and network administrators.
While some of the recommendations of this document go beyond what is currently mandated for SIP implementations within the IETF, this is believed necessary to support the specified operational objectives.
While some of the recommendations of this document go beyond what is currently mandated for SIP implementations within the IETF, this is believed necessary to support the specified operational objectives.
Sinnreich, et al. Informational [Page 3] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich, et al. Informational [Page 3] RFC 4504 SIP Telephony Device Requirements May 2006
However, it is also important to keep in mind that the SIP specifications are constantly evolving; thus, these recommendations need to be considered in the context of that change and evolution. Due to the evolution of IETF documents in the standards process, and the informational nature of this memo, the references are all informative.
However, it is also important to keep in mind that the SIP specifications are constantly evolving; thus, these recommendations need to be considered in the context of that change and evolution. Due to the evolution of IETF documents in the standards process, and the informational nature of this memo, the references are all informative.
1.1. Conventions used in this document
1.1. Conventions used in this document
This document is informational and therefore the key words "MUST", "SHOULD", "SHOULD NOT", and "MAY", in this document are not to be interpreted as described in RFC 2119 [1], but rather indicate the nature of the suggested requirement.
This document is informational and therefore the key words "MUST", "SHOULD", "SHOULD NOT", and "MAY", in this document are not to be interpreted as described in RFC 2119 [1], but rather indicate the nature of the suggested requirement.
2. Generic Requirements
2. Generic Requirements
We present here a minimal set of requirements that MUST be met by all SIP [2] telephony devices, except where SHOULD or MAY is specified.
We present here a minimal set of requirements that MUST be met by all SIP [2] telephony devices, except where SHOULD or MAY is specified.
2.1. SIP Telephony Devices
2.1. SIP Telephony Devices
This memo applies mainly to desktop phones and other special purpose SIP telephony hardware. Some of the requirements in this section are not applicable to PC/laptop or PDA software phones (soft phones) and mobile phones.
This memo applies mainly to desktop phones and other special purpose SIP telephony hardware. Some of the requirements in this section are not applicable to PC/laptop or PDA software phones (soft phones) and mobile phones.
Req-1: SIP telephony devices MUST be able to acquire IP network
settings by automatic configuration using Dynamic Host
Configuration Protocol (DHCP) [3].
Req-1: SIP telephony devices MUST be able to acquire IP network settings by automatic configuration using Dynamic Host Configuration Protocol (DHCP) [3].
Req-2: SIP telephony devices MUST be able to acquire IP network
settings by manual entry of settings from the device.
Req-2: SIP telephony devices MUST be able to acquire IP network settings by manual entry of settings from the device.
Req-3: SIP telephony devices SHOULD support IPv6. Some newer
wireless networks may mandate support for IPv6 and in such
networks SIP telephony devices MUST support IPv6.
Req-3: SIP telephony devices SHOULD support IPv6. Some newer wireless networks may mandate support for IPv6 and in such networks SIP telephony devices MUST support IPv6.
Req-4: SIP telephony devices MUST support the Simple Network Time
Protocol [4].
Req-4: SIP telephony devices MUST support the Simple Network Time Protocol [4].
Req-5: Desktop SIP phones and other special purpose SIP telephony
devices MUST be able to upgrade their firmware to support
additional features and the functionality.
Req-5: Desktop SIP phones and other special purpose SIP telephony devices MUST be able to upgrade their firmware to support additional features and the functionality.
Req-6: Users SHOULD be able to upgrade the devices with no special
applications or equipment; or a service provider SHOULD be
able to push the upgrade down to the devices remotely.
Req-6: Users SHOULD be able to upgrade the devices with no special applications or equipment; or a service provider SHOULD be able to push the upgrade down to the devices remotely.
Sinnreich, et al. Informational [Page 4] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich, et al. Informational [Page 4] RFC 4504 SIP Telephony Device Requirements May 2006
2.2. DNS and ENUM Support
2.2. DNS and ENUM Support
Req-7: SIP telephony devices MUST support RFC 3263 [5] for locating a
SIP server and selecting a transport protocol.
Req-7: SIP telephony devices MUST support RFC 3263 [5] for locating a SIP server and selecting a transport protocol.
Req-8: SIP telephony devices MUST incorporate DNS resolvers that are
configurable with at least two entries for DNS servers for
redundancy. To provide efficient DNS resolution, SIP
telephony devices SHOULD query responsive DNS servers and skip
DNS servers that have been non-responsive to recent queries.
Req-8: SIP telephony devices MUST incorporate DNS resolvers that are configurable with at least two entries for DNS servers for redundancy. To provide efficient DNS resolution, SIP telephony devices SHOULD query responsive DNS servers and skip DNS servers that have been non-responsive to recent queries.
Req-9: To provide efficient DNS resolution and to limit post-dial
delay, SIP telephony devices MUST cache DNS responses based on
the DNS time-to-live.
Req-9: To provide efficient DNS resolution and to limit post-dial delay, SIP telephony devices MUST cache DNS responses based on the DNS time-to-live.
Req-10: For DNS efficiency, SIP telephony devices SHOULD use the
additional information section of the DNS response instead of
generating additional DNS queries.
Req-10: For DNS efficiency, SIP telephony devices SHOULD use the additional information section of the DNS response instead of generating additional DNS queries.
Req-11: SIP telephony devices MAY support ENUM [6] in case the end
users prefer to have control over the ENUM lookup. Note: The
ENUM resolver can also be placed in the outgoing SIP proxy to
simplify the operation of the SIP telephony device. The
Extension Mechanisms for DNS (EDNSO) in RFC 2671 SHOULD also
be supported.
Req-11: SIP telephony devices MAY support ENUM [6] in case the end users prefer to have control over the ENUM lookup. Note: The ENUM resolver can also be placed in the outgoing SIP proxy to simplify the operation of the SIP telephony device. The Extension Mechanisms for DNS (EDNSO) in RFC 2671 SHOULD also be supported.
2.3. SIP Device Resident Telephony Features
2.3. SIP Device Resident Telephony Features
Req-12: SIP telephony devices MUST support RFC 3261 [2].
Req-12: SIP telephony devices MUST support RFC 3261 [2].
Req-13: SIP telephony devices SHOULD support the SIP Privacy header
by populating headers with values that reflect the privacy
requirements and preferences as described in "User Agent
Behavior", Section 4 of RFC 3323 [7].
Req-13: SIP telephony devices SHOULD support the SIP Privacy header by populating headers with values that reflect the privacy requirements and preferences as described in "User Agent Behavior", Section 4 of RFC 3323 [7].
Req-14: SIP telephony devices MUST be able to place an existing call
on hold, and initiate or receive another call, as specified
in RFC 3264 [8] and SHOULD NOT omit the sendrecv attribute.
Req-14: SIP telephony devices MUST be able to place an existing call on hold, and initiate or receive another call, as specified in RFC 3264 [8] and SHOULD NOT omit the sendrecv attribute.
Req-15: SIP telephony devices MUST provide a call waiting indicator.
When participating in a call, the user MUST be alerted
audibly and/or visually of another incoming call. The user
MUST be able to enable/disable the call waiting indicator.
Req-15: SIP telephony devices MUST provide a call waiting indicator. When participating in a call, the user MUST be alerted audibly and/or visually of another incoming call. The user MUST be able to enable/disable the call waiting indicator.
Req-16: SIP telephony devices MUST support SIP message waiting [9]
and the integration with message store platforms.
Req-16: SIP telephony devices MUST support SIP message waiting [9] and the integration with message store platforms.
Sinnreich, et al. Informational [Page 5] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich, et al. Informational [Page 5] RFC 4504 SIP Telephony Device Requirements May 2006
Req-17: SIP telephony devices MAY support a local dial plan. If a
dial plan is supported, it MUST be able to match the user
input to one of multiple pattern strings and transform the
input to a URI, including an arbitrary scheme and URI
parameters.
Req-17: SIP telephony devices MAY support a local dial plan. If a dial plan is supported, it MUST be able to match the user input to one of multiple pattern strings and transform the input to a URI, including an arbitrary scheme and URI parameters.
Example: If a local dial plan is supported, it SHOULD be configurable to generate any of the following URIs when "5551234" is dialed:
Example: If a local dial plan is supported, it SHOULD be configurable to generate any of the following URIs when "5551234" is dialed:
tel:+12125551234 sip:+12125551234@example.net;user=phone sips:+12125551234@example.net;user=phone sip:5551234@example.net sips:5551234@example.net tel:5551234;phone-context=nyc1.example.net sip:5551234;phone- context=nyc1.example.net@example.net;user=phone sips:5551234;phone- context=nyc1.example.net@example.net;user=phone sip:5551234;phone- context=nyc1.example.net@example.net;user=dialstring sips:5551234;phone- context=nyc1.example.net@example.net;user=dialstring tel:5551234;phone-context=+1212 sip:5551234;phone-context=+1212@example.net;user=phone sips:5551234;phone-context=+1212@example.net;user=phone sip:5551234;phone-context=+1212@example.net;user=dialstring sips:5551234;phone-context=+1212@example.net;user=dialstring
tel:+12125551234 sip:+12125551234@example.net;user=phone sips:+12125551234@example.net;user=phone sip:5551234@example.net sips:5551234@example.net tel:5551234;phone-context=nyc1.example.net sip:5551234;phone- context=nyc1.example.net@example.net;user=phone sips:5551234;phone- context=nyc1.example.net@example.net;user=phone sip:5551234;phone- context=nyc1.example.net@example.net;user=dialstring sips:5551234;phone- context=nyc1.example.net@example.net;user=dialstring tel:5551234;phone-context=+1212 sip:5551234;phone-context=+1212@example.net;user=phone sips:5551234;phone-context=+1212@example.net;user=phone sip:5551234;phone-context=+1212@example.net;user=dialstring sips:5551234;phone-context=+1212@example.net;user=dialstring
If a local dial plan is not supported, the device SHOULD be configurable to generate any of the following URIs when "5551234" is dialed:
If a local dial plan is not supported, the device SHOULD be configurable to generate any of the following URIs when "5551234" is dialed:
sip:5551234@example.net sips:5551234@example.net sip:5551234;phone- context=nyc1.example.net@example.net;user=dialstring sips:5551234;phone- context=nyc1.example.net@example.net;user=dialstring sip:5551234;phone-context=+1212@example.net;user=dialstring sips:5551234;phone-context=+1212@example.net;user=dialstring"
sip:5551234@example.net sips:5551234@example.net sip:5551234;phone- context=nyc1.example.net@example.net;user=dialstring sips:5551234;phone- context=nyc1.example.net@example.net;user=dialstring sip:5551234;phone-context=+1212@example.net;user=dialstring sips:5551234;phone-context=+1212@example.net;user=dialstring"
Req-18: SIP telephony devices MUST support URIs for telephone numbers
as per RFC 3966 [10]. This includes the reception as well as
the sending of requests. The reception may be denied
according to the configurable security policy of the device.
It is a reasonable behavior to send a request to a
preconfigured outbound proxy.
Req-18: SIP telephony devices MUST support URIs for telephone numbers as per RFC 3966 [10]. This includes the reception as well as the sending of requests. The reception may be denied according to the configurable security policy of the device. It is a reasonable behavior to send a request to a preconfigured outbound proxy.
Sinnreich, et al. Informational [Page 6] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich, et al. Informational [Page 6] RFC 4504 SIP Telephony Device Requirements May 2006
Req-19: SIP telephony devices MUST support REFER and NOTIFY for call
transfer [11], [12]. SIP telephony devices MUST support
escaped Replaces-Header (RFC 3891) and SHOULD support other
escaped headers in the Refer-To header.
Req-19: SIP telephony devices MUST support REFER and NOTIFY for call transfer [11], [12]. SIP telephony devices MUST support escaped Replaces-Header (RFC 3891) and SHOULD support other escaped headers in the Refer-To header.
Req-20: SIP telephony devices MUST support the unattended call
transfer flows as defined in [12].
Req-20: SIP telephony devices MUST support the unattended call transfer flows as defined in [12].
Req-21: SIP telephony devices MUST support the attended call transfer
as defined in [12].
Req-21: SIP telephony devices MUST support the attended call transfer as defined in [12].
Req-22: SIP telephony devices MAY support device-based 3-way calling
by mixing the audio streams and displaying the interactive
text of at least 2 separate calls.
Req-22: SIP telephony devices MAY support device-based 3-way calling by mixing the audio streams and displaying the interactive text of at least 2 separate calls.
Req-23: SIP telephony devices MUST be able to send dual-tone multi-
frequency (DTMF) named telephone events as specified by RFC
2833 [13].
Req-23: SIP telephony devices MUST be able to send dual-tone multi- frequency (DTMF) named telephone events as specified by RFC 2833 [13].
Req-24: Payload type negotiation MUST comply with RFC 3264 [8] and
with the registered MIME types for RTP payload formats in RFC
3555 [14].
Req-24: Payload type negotiation MUST comply with RFC 3264 [8] and with the registered MIME types for RTP payload formats in RFC 3555 [14].
Req-25: The dynamic payload type MUST remain constant throughout the
session. For example, if an endpoint decides to renegotiate
codecs or put the call on hold, the payload type for the re-
invite MUST be the same as the initial payload type. SIP
devices MAY support Flow Identification as defined in RFC
3388 [15].
Req-25: The dynamic payload type MUST remain constant throughout the session. For example, if an endpoint decides to renegotiate codecs or put the call on hold, the payload type for the re- invite MUST be the same as the initial payload type. SIP devices MAY support Flow Identification as defined in RFC 3388 [15].
Req-26: When acting as a User Agent Client (UAC), SIP telephony
devices SHOULD support the gateway model of RFC 3960 [16].
When acting as a User Agent Server (UAS), SIP telephony
devices SHOULD NOT send early media.
Req-26: When acting as a User Agent Client (UAC), SIP telephony devices SHOULD support the gateway model of RFC 3960 [16]. When acting as a User Agent Server (UAS), SIP telephony devices SHOULD NOT send early media.
Req-27: SIP telephony devices MUST be able to handle multiple early
dialogs in the context of request forking. When a confirmed
dialog has been established, it is an acceptable behavior to
send a BYE request in response to additional 2xx responses
that establish additional confirmed dialogs.
Req-27: SIP telephony devices MUST be able to handle multiple early dialogs in the context of request forking. When a confirmed dialog has been established, it is an acceptable behavior to send a BYE request in response to additional 2xx responses that establish additional confirmed dialogs.
Req-28: SIP devices with a suitable display SHOULD support the call-
info header and depending on the display capabilities MAY,
for example, display an icon or the image of the caller.
Req-28: SIP devices with a suitable display SHOULD support the call- info header and depending on the display capabilities MAY, for example, display an icon or the image of the caller.
Sinnreich, et al. Informational [Page 7] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich, et al. Informational [Page 7] RFC 4504 SIP Telephony Device Requirements May 2006
Req-29: To provide additional information about call failures, SIP
telephony devices with a suitable display MUST render the
"Reason Phrase" of the SIP message or map the "Status Code"
to custom or default messages. This presumes the language
for the reason phrase is the same as the negotiated language.
The devices MAY use an internal "Status Code" table if there
was a problem with the language negotiation.
Req-29: To provide additional information about call failures, SIP telephony devices with a suitable display MUST render the "Reason Phrase" of the SIP message or map the "Status Code" to custom or default messages. This presumes the language for the reason phrase is the same as the negotiated language. The devices MAY use an internal "Status Code" table if there was a problem with the language negotiation.
Req-30: SIP telephony devices MAY support music on hold, both in
receive mode and locally generated. See also "SIP Service
Examples" for a call flow with music on hold [17].
Req-30: SIP telephony devices MAY support music on hold, both in receive mode and locally generated. See also "SIP Service Examples" for a call flow with music on hold [17].
Req-31: SIP telephony devices MAY ring after a call has been on hold
for a predetermined period of time, typically 3 minutes.
Req-31: SIP telephony devices MAY ring after a call has been on hold for a predetermined period of time, typically 3 minutes.
2.4. Support for SIP Services
2.4. Support for SIP Services
Req-32: SIP telephony devices MUST support the SIP Basic Call Flow
Examples as per RFC 3665 [17].
Req-32: SIP telephony devices MUST support the SIP Basic Call Flow Examples as per RFC 3665 [17].
Req-33: SIP telephony devices MUST support the SIP-PSTN Service
Examples as per RFC 3666 [18].
Req-33: SIP telephony devices MUST support the SIP-PSTN Service Examples as per RFC 3666 [18].
Req-34: SIP telephony devices MUST support the Third Party Call
Control model [19], in the sense that they may be the
controlled device.
Req-34: SIP telephony devices MUST support the Third Party Call Control model [19], in the sense that they may be the controlled device.
Req-35: SIP telephony devices SHOULD support SIP call control and
multi-party usage [20].
Req-35: SIP telephony devices SHOULD support SIP call control and multi-party usage [20].
Req-36: SIP telephony devices SHOULD support conferencing services
for voice [21], [22] and interactive text [23] and if
equipped with an adequate display MAY also support instant
messaging (IM) and presence [24], [25].
Req-36: SIP telephony devices SHOULD support conferencing services for voice [21], [22] and interactive text [23] and if equipped with an adequate display MAY also support instant messaging (IM) and presence [24], [25].
Req-37: SIP telephony devices SHOULD support the indication of the
User Agent capabilities and MUST support the caller
capabilities and preferences as per RFC 3840 [26].
Req-37: SIP telephony devices SHOULD support the indication of the User Agent capabilities and MUST support the caller capabilities and preferences as per RFC 3840 [26].
Req-38: SIP telephony devices MAY support service mobility: Devices
MAY allow roaming users to input their identity so as to have
access to their services and preferences from the home SIP
server. Examples of user data to be available for roaming
users are: user service ID, dialing plan, personal directory,
and caller preferences.
Req-38: SIP telephony devices MAY support service mobility: Devices MAY allow roaming users to input their identity so as to have access to their services and preferences from the home SIP server. Examples of user data to be available for roaming users are: user service ID, dialing plan, personal directory, and caller preferences.
Sinnreich, et al. Informational [Page 8] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich, et al. Informational [Page 8] RFC 4504 SIP Telephony Device Requirements May 2006
2.5. Basic Telephony and Presence Information Support
2.5. Basic Telephony and Presence Information Support
The large color displays in some newer models make such SIP phones and applications attractive for a rich communication environment. This document is focused, however, only on telephony-specific features enabled by SIP Presence and SIP Events.
The large color displays in some newer models make such SIP phones and applications attractive for a rich communication environment. This document is focused, however, only on telephony-specific features enabled by SIP Presence and SIP Events.
SIP telephony devices can also support presence status, such as the traditional Do Not Disturb, new event state-based information, such as being in another call or being in a conference, typing a message, emoticons, etc. Some SIP telephony User Agents can support, for example, a voice session and several IM sessions with different parties.
SIP telephony devices can also support presence status, such as the traditional Do Not Disturb, new event state-based information, such as being in another call or being in a conference, typing a message, emoticons, etc. Some SIP telephony User Agents can support, for example, a voice session and several IM sessions with different parties.
Req-39: SIP telephony devices SHOULD support Presence information
[24] and SHOULD support the Rich Presence Information Data
Format [27] for the new IP communication services enabled by
Presence.
Req-39: SIP telephony devices SHOULD support Presence information [24] and SHOULD support the Rich Presence Information Data Format [27] for the new IP communication services enabled by Presence.
Req-40: Users MUST be able to set the state of the SIP telephony
device to "Do Not Disturb", and this MAY be manifested as a
Presence state across the network if the UA can support
Presence information.
Req-40: Users MUST be able to set the state of the SIP telephony device to "Do Not Disturb", and this MAY be manifested as a Presence state across the network if the UA can support Presence information.
Req-41: SIP telephony devices with "Do Not Disturb" enabled MUST
respond to new sessions with "486 Busy Here".
Req-41: SIP telephony devices with "Do Not Disturb" enabled MUST respond to new sessions with "486 Busy Here".
2.6. Emergency and Resource Priority Support
2.6. Emergency and Resource Priority Support
Req-42: Emergency calling: For emergency numbers (e.g., 911, SOS
URL), SIP telephony devices SHOULD support the work of the
ECRIT WG [28].
Req-42: Emergency calling: For emergency numbers (e.g., 911, SOS URL), SIP telephony devices SHOULD support the work of the ECRIT WG [28].
Req-43: Priority header: SIP devices SHOULD support the setting by
the user of the Priority header specified in RFC 3261 for
such applications as emergency calls or for selective call
acceptance.
Req-43: Priority header: SIP devices SHOULD support the setting by the user of the Priority header specified in RFC 3261 for such applications as emergency calls or for selective call acceptance.
Req-44: Resource Priority header: SIP telephony devices that are used
in environments that support emergency preparedness MUST also
support the sending and receiving of the Resource-Priority
header as specified in [29]. The Resource Priority header
influences the behavior for message routing in SIP proxies
and PSTN telephony gateways and is different from the SIP
Priority header specified in RFC 3261. Users of SIP
telephony devices may want to be interrupted in their lower-
priority communications activities if such an emergency
communication request arrives.
Req-44: Resource Priority header: SIP telephony devices that are used in environments that support emergency preparedness MUST also support the sending and receiving of the Resource-Priority header as specified in [29]. The Resource Priority header influences the behavior for message routing in SIP proxies and PSTN telephony gateways and is different from the SIP Priority header specified in RFC 3261. Users of SIP telephony devices may want to be interrupted in their lower- priority communications activities if such an emergency communication request arrives.
Sinnreich, et al. Informational [Page 9] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich, et al. Informational [Page 9] RFC 4504 SIP Telephony Device Requirements May 2006
Note: As of this writing, we recommend that implementers follow the work of the Working Group on Emergency Context Resolution with Internet Technologies (ecrit) in the IETF. The complete solution is for further study at this time. There is also work on the requirements for location conveyance in the SIPPING WG, see [30].
Note: As of this writing, we recommend that implementers follow the work of the Working Group on Emergency Context Resolution with Internet Technologies (ecrit) in the IETF. The complete solution is for further study at this time. There is also work on the requirements for location conveyance in the SIPPING WG, see [30].
2.7. Multi-Line Requirements
2.7. Multi-Line Requirements
A SIP telephony device can have multiple lines: One SIP telephony device can be registered simultaneously with different SIP registrars from different service providers, using different names and credentials for each line. The different sets of names and credentials are also called 'SIP accounts'. The "line" terminology has been borrowed from multi-line PSTN/PBX phones, except that for SIP telephony devices there can be different SIP registrars/proxies for each line, each of which may belong to a different service provider, whereas this would be an exceptional case for the PSTN and certainly not the case for PBX phones. Multi-line SIP telephony devices resemble more closely e-mail clients that can support several e-mail accounts.
A SIP telephony device can have multiple lines: One SIP telephony device can be registered simultaneously with different SIP registrars from different service providers, using different names and credentials for each line. The different sets of names and credentials are also called 'SIP accounts'. The "line" terminology has been borrowed from multi-line PSTN/PBX phones, except that for SIP telephony devices there can be different SIP registrars/proxies for each line, each of which may belong to a different service provider, whereas this would be an exceptional case for the PSTN and certainly not the case for PBX phones. Multi-line SIP telephony devices resemble more closely e-mail clients that can support several e-mail accounts.
Note: Each SIP account can usually support different Addresses of Record (AORs) with a different list of contact addresses (CAs), as may be convenient, for example, when having different SIP accounts for business and personal use. However, some of the CAs in different SIP accounts may point to the same devices.
Note: Each SIP account can usually support different Addresses of Record (AORs) with a different list of contact addresses (CAs), as may be convenient, for example, when having different SIP accounts for business and personal use. However, some of the CAs in different SIP accounts may point to the same devices.
Req-45: Multi-line SIP telephony devices MUST support a unique
authentication username, authentication password, registrar,
and identity to be provisioned for each line. The
authentication username MAY be identical with the user name
of the AOR and the domain name MAY be identical with the host
name of the registrar.
Req-45: Multi-line SIP telephony devices MUST support a unique authentication username, authentication password, registrar, and identity to be provisioned for each line. The authentication username MAY be identical with the user name of the AOR and the domain name MAY be identical with the host name of the registrar.
Req-46: Multi-line SIP telephony devices MUST be able to support the
state of the client to Do Not Disturb on a per line basis.
Req-46: Multi-line SIP telephony devices MUST be able to support the state of the client to Do Not Disturb on a per line basis.
Req-47: Multi-line SIP telephony devices MUST support multi-line call
waiting indicators. Devices MUST allow the call waiting
indicator to be set on a per line basis.
Req-47: マルチ系列SIP電話デバイスは、マルチラインコールが準備中表示であるとサポートしなければなりません。 デバイスは、キャッチホンインディケータが系列基礎あたりのaに設定されるのを許容しなければなりません。
Req-48: Multi-line SIP telephony devices MUST be able to support a
few different ring tones for different lines. We specify
here "a few", since provisioning different tones for all
lines may be difficult for phones with many lines.
Req-48: マルチ系列SIP電話デバイスは異なった系列のためにいくつかの異なった着信音をサポートすることができなければなりません。 電話に、すべての系列のために異なったトーンに食糧を供給するのが多くの系列によって難しいかもしれないので、私たちはここで「いくつか」を指定します。
Sinnreich, et al. Informational [Page 10] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[10ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
2.8. User Mobility
2.8. ユーザの移動性
The following requirements allow users with a set of credentials to use any SIP telephony device that can support personal credentials from several users, distinct from the identity of the device.
1セットの資格証明書をもっているユーザは以下の要件で数人のユーザから個人的な資格証明書をサポートすることができるどんなSIP電話デバイスも使用できます、デバイスのアイデンティティと、異なります。
Req-49: User-mobility-enabled SIP telephony devices MUST store static
credentials associated with the device in non-volatile
memory. This static profile is used during the power up
sequence.
Req-49: 移動性が可能にしたユーザSIP電話デバイスは非揮発性メモリーのデバイスに関連している静的な資格証明書を保存しなければなりません。 この静的なプロフィールはパワーアップ系列の間、使用されます。
Req-50: User-mobility-enabled SIP telephony devices SHOULD allow a
user to walk up to a device and input their personal
credentials. All user features and settings stored in home
SIP proxy and the associated policy server SHOULD be
available to the user.
Req-50: 移動性が可能にしたユーザSIP電話デバイスSHOULDはユーザにそれらの個人的な資格証明書をデバイスと入力まで歩かせます。 すべてのユーザの特徴と設定がホームSIPプロキシと関連方針サーバでSHOULDを保存しました。ユーザにとって、利用可能であってください。
Req-51: User-mobility-enabled SIP telephony devices registered as
fixed desktop with network administrator MUST use the local
static location data associated with the device for emergency
calls.
Req-51: ネットワーク管理者とのデスクトップが修理されているので登録された移動性が可能にしたユーザSIP電話デバイスは緊急通報にデバイスに関連しているローカルの静的な位置のデータを使用しなければなりません。
2.9. Interactive Text Support
2.9. 対話的なテキストサポート
SIP telephony devices supporting instant messaging based on SIMPLE [24] support text conversation based on blocks of text. However, continuous interactive text conversation may be sometimes preferred as a parallel to voice, due to its interactive and more streaming- like nature, and thus is more appropriate for real-time conversation. It also allows for text captioning of voice in noisy environments and for those who cannot hear well or cannot hear at all.
SIMPLE[24]に基づくインスタントメッセージングをサポートするSIP電話デバイスは、テキストがブロックのテキストに基づく会話であるとサポートします。 しかしながら、連続した対話的なテキストの会話は、平行線として時々好まれるかもしれなくて、リアルタイムの会話には、その結果、インタラクティブによる声と自然のようにさらに流れるより適切です。 また、それは騒がしい環境とよく聞くことができないか、または全く聞くことができない人のために声に関するテキストキャプションを考慮します。
Finally, continuous character-by-character text is preferred by emergency and public safety programs (e.g., 112 and 911) because of its immediacy, efficiency, lack of crossed messages problem, better ability to interact with a confused person, and the additional information that can be observed from watching the message as it is composed.
最終的に、非常時と公安プログラム(例えば、112と911)でキャラクタごとの連続したテキストは早急のために好まれます、効率、交差しているメッセージ問題の不足、混乱した人、およびそれが落ち着いているのでメッセージを見るのから観察できる追加情報と対話するより良い能力。
Req-52: SIP telephony devices such as SIP display phones and IP-
analog adapters SHOULD support the accessibility requirements
for deaf, hard-of-hearing and speech-impaired individuals as
per RFC 3351 [31] and also for interactive text conversation
[23], [32].
Req-52: SIPディスプレイ電話やIPアナログアダプターSHOULDなどのSIP電話デバイスはRFC3351[31]に従って聴覚障害の、そして、耳が遠くてスピーチによって損なわれた個人と対話的なテキストの会話[23]([32])のためにもアクセシビリティ要件をサポートします。
Sinnreich, et al. Informational [Page 11] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[11ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
Req-53: SIP telephony devices SHOULD provide a way to input text and
to display text through any reasonable method. Built-in user
interfaces, standard wired or wireless interfaces, and/or
support for text through a web interface are all considered
reasonable mechanisms.
Req-53: SIP電話デバイスSHOULDはテキストを入力して、どんな合理的なメソッドでもテキストを表示する方法を提供します。 ウェブインタフェースを通したテキストの内蔵のユーザインタフェース、標準のワイヤードであるかワイヤレスのインタフェース、そして/または、サポートは妥当なメカニズムであるとすべて考えられます。
Req-54: SIP telephony devices SHOULD provide an external standard
wired or wireless link to connect external input (keyboard,
mouse) and display devices.
Req-54: SIP電話デバイスSHOULDは、外部の入力(キーボード、マウス)とディスプレイ装置を接続するために外部の標準のワイヤードであるかワイヤレスのリンクを提供します。
Req-55: SIP telephony devices that include a display, or have a
facility for connecting an external display, MUST include
protocol support as described in RFC 4103 [23] for real-time
interactive text.
Req-55: 外部のディスプレイを接続するためにディスプレイを含んでいるか、または施設を持っているSIP電話デバイスはリアルタイムの対話的なテキストのためのRFC4103[23]で説明されるようにプロトコルサポートを含まなければなりません。
Req-56: There may be value in having RFC 4103 support in a terminal
also without a visual display. A synthetic voice output for
the text conversation may be of value for all who can hear,
and thereby provides the opportunity to have a text
conversation with other users.
Req-56: 端末に視覚ディスプレイなしでもRFC4103サポートを持つのにおいて値があるかもしれません。 テキストの会話のための合成音声出力は、聞くことができるすべてのための価値があるかもしれなくて、その結果、テキストの会話を持つ機会を他のユーザに提供します。
Req-57: SIP telephony devices MAY provide analog adaptor
functionality through an RJ-11 FXS port to support FXS
devices. If an RJ-11 (FXS) port is provided, then it MAY
support a gateway function from all text-telephone protocols
according to ITU-T Recommendation V.18 to RFC 4103 text
conversation (in fact, this is encouraged in the near term
during the transition to widespread use of SIP telephony
devices). If this gateway function is not included or fails,
the device MUST pass through all text-telephone protocols
according to ITU-T Recommendation V.18, November 2000, in a
transparent fashion.
Req-57: SIP電話デバイスは、FXSがデバイスであるとサポートするためにRJ-11 FXSポートを通してアナログのアダプターの機能性を提供するかもしれません。 RJ-11(FXS)ポートを提供するなら、それはITU-T Recommendation V.18に従ったすべてのテキスト電話プロトコルからRFC4103テキストの会話までゲートウェイ機能をサポートするかもしれません(事実上、これは近いうちにSIP電話デバイスの普及使用への変遷の間、奨励されます)。 このゲートウェイ機能が含まれていないか、または失敗するなら、ITU-T Recommendation V.18に応じて、デバイスはすべてのテキスト電話プロトコルを通り抜けなければなりません、2000年11月、見え透いたファッションで。
Req-58: SIP telephony devices MAY provide a 2.5 mm audio port, in
portable SIP devices, such as PDAs and various wireless SIP
phones.
Req-58: SIP電話デバイスは2.5mmのオーディオポートを提供するかもしれません、携帯用のSIPデバイスで、PDAや様々なワイヤレスのSIP電話のように。
2.10. Other Related Protocols
2.10. 他の関連プロトコル
Req-59: SIP telephony devices MUST support the Real-Time Protocol and
the Real-Time Control Protocol, RFC 3550 [33]. SIP devices
SHOULD use RTCP Extended Reports for logging and reporting on
network support for voice quality, RFC 3611 [34] and MAY also
support the RTCP summary report delivery [35].
Req-59: SIP電話デバイスは、レアル-時間プロトコルとレアル-時間がControlプロトコル、RFC3550[33]であるとサポートしなければなりません。 SIPデバイスSHOULDは伐採と音声の品質のネットワークサポートに関して報告するのにRTCP Extended Reportsを使用します、また、RFC3611[34]と5月はRTCP概略報告が配送[35]であるとサポートします。
Sinnreich, et al. Informational [Page 12] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[12ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
2.11. SIP Device Security Requirements
2.11. 一口デバイスセキュリティ要件
Req-60: SIP telephony devices MUST support digest authentication as
per RFC 3261. In addition, SIP telephony devices MUST
support Transport Layer Security (TLS) for secure transport
[36] for scenarios where the SIP registrar is located outside
the secure, private IP network in which the SIP UA may
reside. Note: TLS need not be used in every call, though.
Req-60: SIP電話デバイスはRFC3261に従ってダイジェスト認証をサポートしなければなりません。 さらに、SIP電話デバイスはSIP記録係が安全なプライベートアイピーネットワークに外SIP UAが住むかもしれない位置しているシナリオのための安全な輸送[36]のために、Transport Layer Security(TLS)をサポートしなければなりません。 以下に注意してください。 もっとも、TLSはあらゆる呼び出しに使用されなければならないというわけではありません。
Req-61: SIP telephony devices MUST be able to password protect
configuration information and administrative functions.
Req-61: SIP電話デバイスはパスワードにできるに違いありません。設定情報と行政機能を保護してください。
Req-62: SIP telephony devices MUST NOT display the password to the
user or administrator after it has been entered.
Req-62: それが入られた後にSIP電話デバイスはユーザか管理者にパスワードを表示してはいけません。
Req-63: SIP clients MUST be able to disable remote access, i.e.,
block incoming Simple Network Management Protocol (SNMP)
(where this is supported), HTTP, and other services not
necessary for basic operation.
Req-63: SIPクライアントは、すなわち、遠隔アクセス、ブロック入来が基本的な操作に必要でないSimple Network Managementプロトコル(SNMP)(これがサポートされるところ)と、HTTPと、他のサービスであると無効にすることができなければなりません。
Req-64: SIP telephony devices MUST support the option to reject an
incoming INVITE where the user-portion of the SIP request URI
is blank or does not match a provisioned contact. This
provides protection against war-dialer attacks, unwanted
telemarketing, and spam. The setting to reject MUST be
configurable.
Req-64: SIP電話デバイスは、SIP要求URIのユーザ部分が空白であるか、または食糧を供給された接触に合っていない入って来るINVITEを拒絶するためにオプションをサポートしなければなりません。 これはウォーダイヤラ攻撃、求められていないテレマーケティング、およびスパムに対する保護を提供します。 拒絶する設定は構成可能であるに違いありません。
Req-65: When TLS is not used, SIP telephony devices MUST be able to
reject an incoming INVITE when the message does not come from
the proxy or proxies where the client is registered. This
prevents callers from bypassing terminating call features on
the proxy. For DNS SRV specified proxy addresses, the client
must accept an INVITE from all of the resolved proxy IP
addresses.
Req-65: TLSが使用されていないとき、メッセージがプロキシかプロキシからクライアントが登録されているところに来ないとき、SIP電話デバイスは入って来るINVITEを拒絶できなければなりません。 これによって、訪問者はプロキシの上で終わり繰り上げ償還条項を迂回させることができません。 指定されたプロキシが扱うDNS SRVに関しては、クライアントは決心しているプロキシIPアドレスのすべてからINVITEを受け入れなければなりません。
2.12. Quality of Service
2.12. サービスの質
Req-66: SIP devices MUST support the IPv4 Differentiated Services
Code Point (DSCP) field for RTP streams as per RFC 2597 [37].
The DSCP setting MUST be configurable to conform with the
local network policy.
Req-66: SIPデバイスはRFC2597[37]に従ってRTPストリームのためにIPv4 Differentiated Services Code Point(DSCP)分野をサポートしなければなりません。 DSCP設定は企業内情報通信網方針に従うのにおいて構成可能であるに違いありません。
Req-67: If not specifically provisioned, SIP telephony devices SHOULD
mark RTP packets with the recommended DSCP for expedited
forwarding (codepoint 101110) and mark SIP packets with DSCP
AF31 (codepoint 011010).
Req-67: 明確に食糧を供給されないなら、SIP電話デバイスSHOULDは完全優先転送(codepoint101110)とマークSIPパケットのためにDSCP AF31(codepoint011010)と共にお勧めのDSCPをRTPパケットに付けます。
Sinnreich, et al. Informational [Page 13] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[13ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
Req-68: SIP telephony devices MAY support Resource Reservation
Protocol (RSVP) [38].
Req-68: SIP電話デバイスは、Resource予約プロトコル(RSVP)が[38]であるとサポートするかもしれません。
2.13. Media Requirements
2.13. メディア要件
Req-69: To simplify the interoperability issues, SIP telephony
devices MUST use the first matching codec listed by the
receiver if the requested codec is available in the called
device. See the offer/answer model in RFC 3261.
Req-69: 相互運用性問題を簡素化するために、SIP電話デバイスは呼ばれたデバイスで要求されたコーデックが利用可能であるなら受信機によって記載された最初の合っているコーデックを使用しなければなりません。 RFC3261の申し出/答えモデルを見てください。
Req-70: To reduce overall bandwidth, SIP telephony devices MAY
support active voice detection and comfort noise generation.
Req-70: 総合的な帯域幅を減少させるために、SIP電話デバイスは能動態検出と安らぎ雑音発生をサポートするかもしれません。
2.14. Voice Codecs
2.14. 音声コーデック
Internet telephony devices face the problem of supporting multiple codecs due to various historic reasons, on how telecom industry players have approached codec implementations and the serious intellectual property and licensing problems associated with most codec types. For example, RFC 3551 [39] lists 17 registered MIME subtypes for audio codecs.
インターネット電話デバイスは様々な歴史的な理由のため複数のコーデックをサポートするという問題に直面しています、通信業界のプレーヤーがどうほとんどのコーデックタイプに関連しているコーデック実装、重大な知的所有権、およびライセンシングに関する問題にアプローチしたかに関して。 例えば、RFC3551[39]はオーディオコーデックのために17の登録されたMIME血液型亜型を記載します。
Ideally, the more codecs can be supported in a SIP telephony device, the better, since it enhances the chances of success during the codec negotiation at call setup and avoids media intermediaries used for codec mediation.
理想的に、SIP電話デバイスで、より多くのコーデックをサポートすることができれば、より良いです、コーデック交渉の間、呼び出しセットアップで勝算を高めて、コーデック仲介に使用されるメディア仲介者を避けるので。
Implementers interested in a short list MAY, however, support a minimal number of codecs used in wireline Voice over IP (VoIP), and also codecs found in mobile networks for which the SIP UA is targeted. An ordered short list of preferences may look as follows:
しかしながら、短いリストに興味を持っているImplementersはワイヤーラインボイス・オーバー IP(VoIP)で使用されるコーデックの最少数をサポートして、また、SIP UAが狙うモバイルネットワークで見つけられたコーデックをサポートするかもしれません。 好みの規則正しい短いリストは以下の通りに見えるかもしれません:
Req-71: SIP telephony devices SHOULD support Audio/Video Transport
(AVT) payload type 0 (G.711 uLaw) as in [40] and its Annexes
1 and 2.
Req-71: SIP電話デバイスSHOULDは、[40]とそのAnnexes1と2のようにAudio/ビデオTransport(AVT)がペイロードタイプ0である(G.711 uLaw)とサポートします。
Req-72: SIP telephony devices SHOULD support the Internet Low Bit
Rate codec (iLBC) [41], [42].
Req-72: SIP電話デバイスSHOULDは、インターネットLow Bit Rateコーデック(iLBC)が[41]、[42]であるとサポートします。
Req-73: Mobile SIP telephony devices MAY support codecs found in
various wireless mobile networks. This can avoid codec
conversion in network-based intermediaries.
Req-73: モバイルSIP電話デバイスは様々なワイヤレスのモバイルネットワークで見つけられたコーデックをサポートするかもしれません。 これはネットワークベースの仲介者でコーデック変換を避けることができます。
Req-74: SIP telephony devices MAY support a small set of special
purpose codecs, such as G.723.1, where low bandwidth usage is
needed (for dial-up Internet access), Speex [43], or G.722
for high-quality audio conferences.
Req-74: SIP電話デバイスは高品質なオーディオ会議のために小さいセットの低い帯域幅用法が必要であるG.723.1などの専用コーデック(ダイヤルアップインターネットアクセスのための)、Speex[43]、またはG.722をサポートするかもしれません。
Sinnreich, et al. Informational [Page 14] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[14ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
Req-75: SIP telephony devices MAY support G.729 and its annexes.
Note: The G.729 codec is included here for backward
compatibility only, since the iLBC and the G.723.1 codecs are
preferable in bandwidth-constrained environments.
Req-75: SIP電話デバイスはG.729とその別館を支えるかもしれません。 以下に注意してください。 G.729コーデックは後方の互換性だけのためにここに含まれています、iLBCとG.723.1コーデックが帯域幅で強制的な環境で望ましいので。
Note: The authors believe the Internet Low Bit Rate codec
(iLBC) should be the default codec for Internet telephony.
以下に注意してください。 作者は、インターネットLow Bit Rateコーデック(iLBC)がインターネット電話のためのデフォルトコーデックであるべきであると信じています。
A summary count reveals up to 25 and more voice codec types
currently in use. The authors believe there is also a need
for a single multi-rate Internet codec, such as Speex or
similar that can effectively be substituted for all of the
multiple legacy G.7xx codec types, such as G.711, G.729,
G.723.1, G.722, etc., for various data rates, thus avoiding
the complexity and cost to implementers and service providers
alike who are burdened by supporting so many codec types,
besides the licensing costs.
概要カウントは、最大25と、より多くの音声コーデックタイプが現在使用中であることを明らかにします。 作者はまた、単一のマルチレートインターネットコーデックの必要があって、事実上、Speexか同様であるように複数のレガシーG.7xxコーデックタイプのすべてにそれは代入できると信じています、G.711、G.729、G.723.1、G.722などのように、様々なデータ信号速度のために、その結果、implementersもとても多くのコーデックタイプをサポートすることによって負われているサービスプロバイダーにも複雑さと費用を避けます、認可コスト以外に。
2.15. Telephony Sound Requirements
2.15. 電話音の要件
Req-76: SIP telephony devices SHOULD comply with the handset receive
comfort noise requirements outlined in the ANSI standards
[44], [45].
Req-76: SIP電話デバイスSHOULDは受話器に従います。ANSI規格[44]、[45]に概説された安らぎ雑音要件を受け取ってください。
Req-77: SIP telephony devices SHOULD comply with the stability or
minimum loss defined in ITU-T G.177.
Req-77: SIP電話デバイスSHOULDはITU-T G.177で定義される安定性か最小の損失に応じます。
Req-78: SIP telephony devices MAY support a full-duplex speakerphone
function with echo and side tone cancellation. The design of
high-quality side tone cancellation for desktop IP phones,
laptop computers, and PDAs is outside the scope of this memo.
Req-78: SIP電話デバイスはエコーとサイドトーンキャンセルで全二重スピーカーフォーン機能をサポートするかもしれません。 このメモの範囲の外にデスクトップIP電話、ラップトップコンピュータ、およびPDAのための高品質なサイドトーンキャンセルのデザインがあります。
Req-79: SIP telephony device MAY support different ring tones based
on the caller identity.
Req-79: SIP電話デバイスは訪問者のアイデンティティに基づく異なった着信音をサポートするかもしれません。
2.16. International Requirements
2.16. 国際社会の要求
Req-80: SIP telephony devices SHOULD indicate the preferred language
[46] using User Agent capabilities [26].
Req-80: SIP電話デバイスSHOULDは、[46] Userエージェント能力[26]を使用することで都合のよい言語を示します。
Req-81: SIP telephony devices intended to be used in various language
settings MUST support other languages for menus, help, and
labels.
Req-81: 様々な言語設定で使用されることを意図するSIP電話デバイスはメニュー、助け、およびラベルのために他の言語をサポートしなければなりません。
Sinnreich, et al. Informational [Page 15] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[15ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
2.17. Support for Related Applications
2.17. 関連出願のサポート
The following requirements apply to functions placed in the SIP telephony device.
以下の要件はSIP電話デバイスに置かれた機能に適用されます。
Req-82: SIP telephony devices that have a large display and support
presence SHOULD display a buddy list [24].
Req-82: 大画面を持って、存在SHOULDディスプレイに友達をサポートするSIP電話デバイスが[24]を記載します。
Req-83: SIP telephony devices MAY support Lightweight Directory
Access Protocol (LDAP) for client-based directory lookup.
Req-83: SIP電話デバイスはクライアントベースのディレクトリルックアップのために、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)をサポートするかもしれません。
Req-84: SIP telephony devices MAY support a phone setup where a URL
is automatically dialed when the phone goes off-hook.
Req-84: SIP電話デバイスは電話がフックに動いているとURLが自動的にダイヤルされる電話セットアップをサポートするかもしれません。
2.18. Web-Based Feature Management
2.18. ウェブを拠点とする特徴管理
Req-85: SIP telephony devices SHOULD support an internal web server
to allow users the option to manually configure the phone and
to set up personal phone applications such as the address
book, speed-dial, ring tones, and, last but not least, the
call handling options for the various lines and aliases, in a
user-friendly fashion. Web pages to manage the SIP telephony
device SHOULD be supported by the individual device, or MAY
be supported in managed networks from centralized web servers
linked from a URI.
Req-85: SIP電話デバイスSHOULDは、アドレス帳や、短縮ダイヤルや、着信音や、最後、しかし、特に呼び出しなどの手動で電話を構成して、個人的な電話アプリケーションをセットアップするためにユーザにオプションを許容する内部のウェブサーバー取り扱いが様々な系列と別名のためのオプションであるとサポートします、ユーザフレンドリーなファッションで。 SIP電話デバイスSHOULDを管理するウェブページは、個々のデバイスによってサポートされるか、またはURIからリンクされた集結されたウェブサーバーから管理されたネットワークでサポートされるかもしれません。
Managing SIP telephony devices SHOULD NOT require special
client software on the PC or require a dedicated management
console. SIP telephony devices SHOULD support https
transport for this purpose.
管理しているSIP電話デバイスSHOULD NOTはPCの上で特別なクライアントソフトウェアを必要とするか、または専用マネージメントコンソールを必要とします。 SIP電話デバイスSHOULDは、httpsが輸送であるとこのためにサポートします。
In addition to the Web Based Feature Management requirement,
the device MAY have an SNMP interface for monitoring and
management purposes.
ウェブBased Feature Management要件に加えて、デバイスには、モニターと管理目的のためのSNMPインタフェースがあるかもしれません。
2.19. Firewall and NAT Traversal
2.19. ファイアウォールとNAT縦断
The following requirements allow SIP clients to properly function behind various firewall architectures.
以下の要件で、SIPクライアントは様々なファイアウォールアーキテクチャの後ろで適切に機能できます。
Req-86: SIP telephony devices SHOULD be able to operate behind a
static Network Address Translation/Port Address Translation
(NAPT) device. This implies the SIP telephony device SHOULD
be able to 1) populate SIP messages with the public, external
address of the NAPT device; 2) use symmetric UDP or TCP for
signaling; and 3) use symmetric RTP [47].
Req-86: SIP電話デバイスSHOULD、静的なNetwork Address Translation/ポートAddress Translation(NAPT)デバイスの後ろで作動できてください。 これは、SIP電話デバイスSHOULDが1に)できるのを含意します。NAPTデバイスの公共の、そして、外部のアドレスでSIPメッセージに居住してください。 2) シグナリングに左右対称のUDPかTCPを使用してください。 そして、3は)左右対称のRTP[47]を使用します。
Sinnreich, et al. Informational [Page 16] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[16ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
Req-87: SIP telephony devices SHOULD support the Simple Traversal of
UDP through NATs (STUN) protocol [48] for determining the
NAPT public external address. A classification of scenarios
and NATs where STUN is effective is reported in [49].
Detailed call flows for interactive connectivity
establishment (ICE) [50] are given in [51].
Req-87: SIP電話デバイスSHOULDは、NAPTの公共の外部アドレスを決定するためにNATs(STUN)プロトコル[48]を通してUDPのSimple Traversalをサポートします。 STUNが有効であるシナリオとNATsの分類は[49]で報告されます。 [51]で対話的な接続性設立(ICE)[50]のための詳細な呼び出し流れを与えます。
Note: Developers are strongly advised to follow the document
on best current practices for NAT traversal for SIP [51].
以下に注意してください。 開発者がSIP[51]のためのNAT縦断のための最も良い現在の実務のドキュメントに従うように強くアドバイスされます。
Req-88: SIP telephony devices MAY support UPnP (http://www.upnp.org/)
for local NAPT traversal. Note that UPnP does not help if
there is NAPT in the network of the service provider.
Req-88: SIP電話デバイスは、地方のNAPT縦断のためにUPnPが( http://www.upnp.org/ )であるとサポートするかもしれません。 サービスプロバイダーのネットワークにNAPTがあればUPnPが助けないことに注意してください。
Req-89: SIP telephony devices MUST be able to limit the ports used
for RTP to a provisioned range.
Req-89: SIP電話デバイスはRTPに使用されるポートを食糧を供給された範囲に制限できなければなりません。
2.20. Device Interfaces
2.20. デバイス・インタフェース
Req-90: SIP telephony devices MUST support two types of addressing
capabilities, to enable end users to "dial" either phone
numbers or URIs.
Req-90: SIP電話デバイスは、エンドユーザが電話番号かURIのどちらかに「ダイヤルすること」を可能にするために2つのタイプのアドレス指定能力をサポートしなければなりません。
Req-91: SIP telephony devices MUST have a telephony-like dial-pad and
MAY have telephony-style buttons such as mute, redial,
transfer, conference, hold, etc. The traditional telephony
dial-pad interface MAY appear as an option in large-screen
telephony devices using other interface models, such as
Push-To-Talk in mobile phones and the Presence and IM
graphical user interface (GUI) found in PCs, PDAs, mobile
phones, and cordless phones.
Req-91: SIP電話デバイスは、電話のようなダイヤルパッドを持たなければならなくて、無言、リダイヤル、転送、会議、保持などの電話スタイルボタンを持っているかもしれません。 他のインタフェースを使用する大きいスクリーン電話デバイスのオプションがモデル化されるとき、伝統的な電話ダイヤルパッドインタフェースは現れるかもしれません、PC、PDA、携帯電話、およびコードレス電話で見つけられた携帯電話のPushから話や、PresenceやIMグラフィカルユーザーインターフェース(GUI)などのように。
Req-92: SIP telephony devices MUST have a convenient way for entering
SIP URIs and phone numbers. This includes all alphanumeric
characters allowed in legal SIP URIs. Possible approaches
include using a web page, display and keyboard entry, type-
ahead, or graffiti for PDAs.
Req-92: SIP電話デバイスには、SIP URIと電話番号を入れるための便利な方法がなければなりません。 これは法的なSIP URIで許容されたすべての英数字を含んでいます。 可能なアプローチは、PDAにウェブページかディスプレイとキーボード入力か、先のタイプか、落書きを使用するのを含んでいます。
Req-93: SIP telephony devices should allow phone number entry in
human-friendly fashion, with the usual separators and
brackets between digits and digit groups.
Req-93: ケタとケタグループの間には、普通の分離符と括弧がある状態で、SIP電話デバイスは人間に優しいファッションで電話番号エントリーを許容するはずです。
Sinnreich, et al. Informational [Page 17] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[17ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
3. Glossary and Usage for the Configuration Settings
3. 構成設定への用語集と用法
SIP telephony devices are quite complex, and their configuration is made more difficult by the widely diverse use of technical terms for the settings. We present here a glossary of the most common settings and some of the more widely used values for some settings.
SIP電話デバイスはかなり複雑です、そして、専門用語の設定の広く多様な使用でそれらの構成をより難しくします。 私たちはここに最も一般的な設定の用語集と広くより使用された値のいくつかをいくつかの設定に提示します。
Settings are the information on a SIP UA that it needs so as to be a functional SIP endpoint. The settings defined in this document are not intended to be a complete listing of all possible settings. It MUST be possible to add vendor-specific settings.
設定はそれが機能的なSIP終点になるように必要とするSIP UAの情報です。 本書では定義された設定はすべての可能な設定の完全なリストであることを意図しません。 ベンダー特有の設定を加えるのは可能であるに違いありません。
The list of available settings includes settings that MUST, SHOULD, or MAY be used by all devices (when present) and that make up the common denominator that is used and understood by all devices. However, the list is open to vendor-specific extensions that support additional settings, which enable a rich and valuable set of features.
利用可能な設定のリストはそうしなければならない設定、SHOULD、またはデバイス(存在しているとき)とそれが使用された共通点にするすべてによって使用された、すべてに解釈されるかもしれないデバイスを含んでいます。 しかしながら、リストは追加設定をサポートするベンダー特有の拡大に開かれています。設定は豊かで貴重なセットの特徴を可能にします。
Settings MAY be read-only on the device. This avoids the misconfiguration of important settings by inexperienced users generating service cost for operators. The settings provisioning process SHOULD indicate which settings can be changed by the end user and which settings should be protected.
設定はデバイスの上の書き込み禁止であるかもしれません。 これはオペレータのために勤務評価額を生成する未経験のユーザで重要な設定のmisconfigurationを避けます。 SHOULDが示すエンドユーザがどの設定を変えることができるか、そして、それの設定が保護されるべきであるプロセスに食糧を供給する設定。
In order to achieve wide adoption of any settings format, it is important that it should not be excessive in size for modest devices to use it. Any format SHOULD be structured enough to allow flexible extensions to it by vendors. Settings may belong to the device or to a SIP service provider and the Address of Record (AOR) registered there. When the device acts in the context of an AOR, it will first try to look up a setting in the AOR context. If the setting cannot be found in that context, the device will try to find the setting in the device context. If that also fails, the device MAY use a default value for the setting.
どんな設定形式の広い採用も達成するために、穏やかなデバイスがそれを使用するのが、サイズで過度でないことは、重要です。 いずれもSHOULDをフォーマットします。ベンダーでフレキシブルな拡大をそれに許すことができるくらい構造化されてください。 設定はデバイス、または、そこに登録されたRecord(AOR)のSIPサービスプロバイダーとAddressの所有、かもしれません。 デバイスがAORの文脈で作動するとき、それは最初に、AOR文脈で設定を見上げようとするでしょう。 その文脈で設定を見つけることができないと、デバイスはデバイスコンテキストで設定を見つけようとするでしょう。 また、それが失敗するなら、デバイスは設定にデフォルト値を使用するかもしれません。
The examples shown here are just of informational nature. Other documents may specify the syntax and semantics for the respective settings.
ここに示された例はまさしく情報的に自然です。 他のドキュメントはそれぞれの設定に構文と意味論を指定するかもしれません。
3.1. Device ID
3.1. デバイスID
A device setting MAY include some unique identifier for the device it represents. This MAY be an arbitrary device name chosen by the user, the MAC address, some manufacturer serial number, or some other unique piece of data. The Device ID SHOULD also indicate the ID type. Example: DeviceId="000413100A10;type=MAC"
デバイス設定はそれが表すデバイスのための何らかのユニークな識別子を含むかもしれません。 これはユーザ(MACアドレス、何らかのメーカー通し番号、またはある他のユニークなデータ)によって選ばれた任意の装置名であるかもしれません。 また、Device ID SHOULDはIDタイプを示します。 例: DeviceIdは「000413100A10; =MACをタイプすること」と等しいです。
Sinnreich, et al. Informational [Page 18] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[18ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
3.2. Signaling Port
3.2. シグナリングポート
The port that will be used for a specific transport protocol for SIP MAY be indicated with the SIP ports setting. If this setting is omitted, the device MAY choose any port within a range as specified in 3.3. For UDP, the port may also be used for sending requests so that NAT devices will be able to route the responses back to the UA. Example: SIPPort="5060;transport=UDP"
特定の輸送に使用されるポートはSIP MAYのために議定書を作ります。SIPポートがセットしている状態で、示されます。 この設定が省略されるなら、デバイスは3.3における指定されるとしての範囲の中のどんなポートも選ぶかもしれません。 UDPに関しては、また、NATデバイスがUAへの応答を発送できて、ポートは送付要求に使用されるかもしれません。 例: SIPPortは「5060; =UDPを輸送すること」と等しいです。
3.3. RTP Port Range
3.3. RTPポート範囲
A range of port numbers MUST be used by a device for the consecutive pairs of ports that MUST be used to receive audio and control information (RTP and RTCP) for each concurrent connection. Sometimes this is required to support firewall traversal, and it helps network operators to identify voice packets. Example: RTPPorts="50000-51000"
各同時接続のためのオーディオと制御情報(RTPとRTCP)を受け取るのに使用しなければならない連続した組のポートにデバイスでさまざまなポートナンバーを使用しなければなりません。 時々、これがファイアウォール縦断をサポートするのに必要です、そして、それはネットワーク・オペレータが音声パケットを特定するのを助けます。 例: RTPPortsは「50000-51000」と等しいです。
3.4. Quality of Service
3.4. サービスの質
The Quality of Service (QoS) settings for outbound packets SHOULD be configurable for network packets associated with call signaling (SIP) and media transport (RTP/RTCP). These settings help network operators in identifying voice packets in their network and allow them to transport them with the required QoS. The settings are independently configurable for the different transport layers and signaling, media, or administration. The QoS settings SHOULD also include the QoS mechanism.
Quality、外国行きのパケットSHOULDのためのService(QoS)設定では、呼び出しシグナリング(SIP)とメディア輸送(RTP/RTCP)に関連しているネットワークパケットにおいて、構成可能であってください。 これらの設定は、ネットワーク・オペレータがそれらのネットワークで音声パケットを特定するのを手伝って、彼らが必要なQoSと共にそれらを輸送するのを許容します。 異なったトランスポート層とシグナリングか、メディアか、管理には、設定は独自に構成可能です。 また、QoS設定SHOULDはQoSメカニズムを含んでいます。
For both categories of network traffic, the device SHOULD permit configuration of the type of service settings for both layer 3 (IP DiffServ) and layer 2 (for example, IEEE 802.1D/Q) of the network protocol stack. Example: RTPQoS="0xA0;type=DiffSrv,5;type=802.1DQ;vlan=324"
ネットワークトラフィックの両方のカテゴリ、両方のための設定が層にするサービスのタイプのデバイスSHOULD許可証構成のために、ネットワーク・プロトコルの3(IP DiffServ)と層2(例えば、IEEE 802.1D/Q)は積み重ねられます。 例: RTPQoSは「0xA0; タイプ=DiffSrv、5;タイプ=802.1DQ; vlan=324」と等しいです。
3.5. Default Call Handling
3.5. デフォルト呼び出し取り扱い
All of the call handling settings defined below can be defined here as default behaviors.
ここで以下で定義された呼び出し取り扱い設定のすべてをデフォルトの振舞いと定義できます。
3.5.1. Outbound Proxy
3.5.1. 外国行きのプロキシ
The outbound proxy for a device MAY be set. The setting MAY require that all signaling packets MUST be sent to the outbound proxy or that only in the case when no route has been received the outbound proxy MUST be used. This ensures that application layer gateways are in
デバイスのための外国行きのプロキシは用意ができるかもしれません。 設定は、すべてのシグナリングパケットを外国行きのプロキシに送らなければならないか、またはルートを全く受け取っていないときの場合だけに、外国行きのプロキシを使用しなければならないのを必要とするかもしれません。 これはゲートウェイがあるその応用層を確実にします。
Sinnreich, et al. Informational [Page 19] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[19ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
the signaling path. The second requirement allows the optimization of the routing by the outbound proxy. Example: OutboundProxy="sip:nat.proxy.com"
シグナリング経路。 2番目の要件は外国行きのプロキシによるルーティングの最適化を許容します。 例: OutboundProxyは「一口: nat.proxy.com」と等しいです。
3.5.2. Default Outbound Proxy
3.5.2. デフォルトの外国行きのプロキシ
The default outbound proxy SHOULD be a global setting (not related to a specific line). Example: DefaultProxy="sip:123@proxy.com"
デフォルト外国行きのプロキシSHOULD、グローバル設定(特定の系列に関連しない)になってください。 例: DefaultProxyは「一口: 123@proxy.com 」と等しいです。
3.5.3. SIP Session Timer
3.5.3. 一口セッションタイマ
The re-invite timer allows User Agents to detect broken sessions caused by network failures. A value indicating the number of seconds for the next re-invite SHOULD be used if provided. Example: SessionTimer="600;unit=seconds"
再招待タイマで、Userエージェントはネットワーク失敗によって引き起こされた中断したセッションを検出できます。 提供するなら次の再招待SHOULDの秒数を使用するのを示す値。 例: SessionTimerは「600;ユニットは何秒も等しいこと」と等しいです。
3.6. Telephone Dialing Functions
3.6. 機能にダイヤルする電話
As most telephone users are used to dialing digits to indicate the address of the destination, there is a need for specifying the rule by which digits are transformed into a URI (usually SIP URI or TEL URI).
ほとんどの電話使用者が目的地のアドレスを示すためにケタにダイヤルするのに慣れているとき、ケタがURI(通常SIP URIかTEL URI)に変えられる規則を指定する必要があります。
3.6.1. Phone Number Representations
3.6.1. 電話番号表現
SIP phones need to understand entries in the phone book of the most common separators used between dialed digits, such as spaces, angle and round brackets, dashes, and dots. Example: A phonebook entry of "+49(30)398.33-401" should be translated into "+493039833401".
SIP電話は、空間などのダイヤルされたケタの間で使用される中で最も一般的な分離符の電話帳におけるエントリーが括弧、ダッシュ、およびドットを傾けて、一周させるのを理解する必要があります。 例: 「」 +49 (30)398.33-401のphonebookエントリー」は「+493039833401」に翻訳されるべきです。
3.6.2. Digit Maps and/or the Dial/OK Key
3.6.2. ケタ地図、そして/または、ダイヤル/OKキー
A SIP UA needs to translate user input before it can generate a valid request. Digit maps are settings that describe the parameters of this process. If present, digit maps define patterns that when matched define the following:
SIP UAは、有効な要求を生成することができる前にユーザ入力を翻訳する必要があります。 ケタ地図はこのプロセスのパラメタについて説明する設定です。 存在しているなら、ケタ地図は合わせられていると以下を定義するパターンを定義します:
1) A rule by which the endpoint can judge that the user has completed
dialing, and
2) A rule to construct a URI from the dialed digits, and optionally
3) An outbound proxy to be used in routing the SIP INVITE.
1) 終点が、ユーザが、ダイヤルするのを完了したと判断できる規則、および2) ダイヤルされたケタからURIを任意に構成するために、3は)統治します。 SIP INVITEを発送する際に使用されるべき外国行きのプロキシ。
A critical timer MAY be provided that determines how long the device SHOULD wait before dialing if a dial plan contains a T (Timer) character. It MAY also provide a timer for the maximum elapsed time that SHOULD pass before dialing if the digits entered by the user
重要なタイマがそう、ダイヤルプランがT(タイマ)キャラクタを含んでいるならデバイスSHOULDがダイヤルする前にどれくらい長い間待つかを決定します。 また、ケタがユーザから入ったなら、それはSHOULDがダイヤルする前に過ぎる最大の経過時間の間、タイマを提供するかもしれません。
Sinnreich, et al. Informational [Page 20] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[20ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
match no dial plan. If the UA has a Dial or OK key, pressing this key will override the timer setting.
ダイヤルプランを全く合わせないでください。 UAにDialかOKキーがあると、このキーを押すと、タイマ設定はくつがえされるでしょう。
SIP telephony devices SHOULD have a Dial/OK key. After sending a request, the UA SHOULD be prepared to receive a 484 Address Incomplete response. In this case, the UA should accept more user input and try again to dial the number.
SIP電話デバイスSHOULDには、Dial/OKキーがあります。 要求、UA SHOULDをaに送った後に、484Address Incomplete応答を受けるように用意してください。 この場合、UAは、より多くのユーザ入力を受け入れて、再びその番号にかけようとするはずです。
An example digit map could use regular expressions like in DNS NAPTR (RFC 2915) to translate user input into a SIP URL. Additional replacement patterns like "d" could insert the domain name of the used AOR. Additional parameters could be inserted in the flags portion of the substitution expression. A list of those patterns would make up the dial plan:
例のケタ地図は、ユーザ入力をSIP URLに翻訳するのにDNS NAPTR(RFC2915)などのような正規表現を使用するかもしれません。 「d」が中古のAORのドメイン名を挿入するかもしれないように追加交換は型に基づいて作ります。 追加パラメタは代替式の旗の部分に挿入されるかもしれません。 それらのパターンのリストはダイヤルプランを作るでしょう:
|^([0-9]*)#$|sip:\1@\d;user=phone|outbound=proxy.com |^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+@.+)|sip:\1| |^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+)$|sip:\1@\d| |^(.*)$|sip:\1@\d|timeout=5
|^([0-9]*)#$|ちびちび飲んでください: \1@\d、ユーザは電話と等しいです。|外国行きの=proxy.com|^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+@.+)|一口: 1円| |^[1zA-Z0-9と=+\$、;、\-_. ~、*'()%]、+) $、'|一口: \1@\d| |^(.*)$|一口: \1@\d|タイムアウト=5
3.6.3. Default Digit Map
3.6.3. デフォルトケタ地図
The SIP telephony device SHOULD support the configuration of a default digit map. If the SIP telephony device does not support digit maps, it SHOULD at least support a default digit map rule to construct a URI from digits. If the endpoint does support digit maps, this rule applies if none of the digit maps match.
SIP電話デバイスSHOULDはデフォルトケタ地図の構成をサポートします。 SIP電話デバイスがそうしないなら、ケタが地図であるとサポートしてください、それ。SHOULDは、ケタからURIを構成するためにデフォルトケタ地図規則を少なくともサポートします。 終点がケタ地図をサポートして、ケタ地図のいずれも合っていないなら、この規則は適用されます。
For example, when a user enters "12345", the UA might send the request to "sip:12345@proxy.com;user=phone" after the user presses the OK key.
ユーザが「12345」に入るとき、例えば、ユーザがOKキーを押した後にUaは「ちびちび飲んでください: 12345@proxy.com;user は電話と等しく」要求を送るかもしれません。
3.7. SIP Timer Settings
3.7. 一口タイマ設定
The parameters for SIP (like timer T1) and other related settings MAY be indicated. An example of usage would be the reduction of the DNS SRV failover time. Example: SIPTimer="t1=100;unit=ms"
SIP(タイマT1のような)と他の関連する設定のためのパラメタは示されるかもしれません。 用法に関する例はDNS SRVフェイルオーバー時間の減少でしょう。 例: SIPTimer、= 「t1=100; ユニットはmsと等しいです」。
Note: The timer settings can be included in the digit map.
以下に注意してください。 ケタ地図にタイマ設定を含むことができます。
3.8. Audio Codecs
3.8. オーディオコーデック
In some cases, operators want to control which codecs may be used in their network. The desired subset of codecs supported by the device SHOULD be configurable along with the order of preference. Service providers SHOULD have the possibility of plugging in their own codecs
いくつかの場合、オペレータは、どのコーデックがそれらのネットワークに使用されるかもしれないかを制御したがっています。 コーデックの必要な部分集合はデバイスでSHOULDをサポートしました。よく使われる順と共に構成可能であってください。 サービスプロバイダーSHOULDには、それら自身のコーデックのプラグを差し込む可能性があります。
Sinnreich, et al. Informational [Page 21] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[21ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
of choice. The codec settings MAY include the packet length and other parameters like silence suppression or comfort noise generation.
選択について。 コーデック設定は沈黙抑圧や安らぎ雑音発生のようなパケット長と他のパラメタを含むかもしれません。
The set of available codecs will be used in the codec negotiation according to RFC 3264. Example: Codecs="speex/8000;ptime=20;cng=on,gsm;ptime=30"
RFC3264によると、利用可能なコーデックのセットはコーデック交渉に使用されるでしょう。 例: コーデックが等しい、「speex/8000;、ptime=20、;、= オンであることで、cngに、gsmに、ptimeが何30インチも等しい 」
The settings MUST include hints about privacy for audio using Secure Realtime Transport Protocol (SRTP) that either mandate or encourage the usage of secure RTP. Example: SRTP="mandatory"
安全なRTPの使用法を強制するか、または奨励するSecure Realtime Transportプロトコル(SRTP)を使用して、設定はオーディオのためのプライバシーに関してヒントを含まなければなりません。 例: SRTP=「義務的です」。
3.9. DTMF Method
3.9. DTMFメソッド
Keyboard interaction can be indicated with in-band tones or preferably with out-of-band RTP packets (RFC 2833 [13]). The method for sending these events SHOULD be configurable with the order of precedence. Settings MAY include additional parameters like the content-type that should be used. Example: DTMFMethod="INFO;type=application/dtmf, RFC2833".
キーボード相互作用はバンドにおけるトーンか望ましくはバンドの外がある示されたRTPがパケットであったならそうすることができます。(RFC2833[13])。 メソッド、これらのイベントにSHOULDを送るのにおいて、先行の注文で構成可能であってください。 設定は使用されるべきであるcontent typeのような追加パラメタを含むかもしれません。 例: DTMFMethodは「アプリケーション/dtmf、インフォメーション;タイプ=RFC2833」と等しいです。
3.10. Local and Regional Parameters
3.10. 地方の、そして、地方のパラメタ
Certain settings are dependent upon the regional location for the daylight saving time rules and for the time zone.
夏時間規則と時間帯において、ある設定は地方の位置に依存しています。
Time Zone and UTC Offset: A time zone MAY be specified for the user. Where one is specified; it SHOULD use the schema used by the Olson Time One database [52].
時間帯とUTCは相殺します: 時間帯はユーザに指定されるかもしれません。 1つが指定されるところ。 それ、SHOULDはオルソンTime Oneデータベース[52]によって使用される図式を使用します。
Examples of the database naming scheme are Asia/Dubai or America/Los Angeles where the first part of the name is the continent or ocean and the second part is normally the largest city in that time zone. Optional parameters like the UTC offset may provide additional information for UAs that are not able to map the time zone information to a internal database. Example: TimeZone="Asia/Dubai;offset=7200"
データベース命名体系に関する例は、名前の最初の部分が大陸か海洋であり、通常、第二部がその時の最も大きい都市であるアジア/ドバイかアメリカ/ロサンゼルスです。 UTCオフセットのような任意のパラメタは時間帯の情報を内部のデータベースに写像できないUAsのための追加情報を提供するかもしれません。 例: タイムゾーン、= 「アジア/ドバイ; =7200を相殺してください」
3.11. Time Server
3.11. 時間サーバ
A time server SHOULD be used. DHCP is the preferred way to provide this setting. Optional parameters may indicate the protocol that SHOULD be used for determining the time. If present, the DHCP time server setting has higher precedence than the time server setting. Example: TimeServer="12.34.5.2;protocol=NTP"
AはサーバSHOULDを調節します。使用されます。 DHCPはこの設定を提供する都合のよい方法です。 任意のパラメタは時間を決定するのにおいて使用されていた状態でSHOULDがあるプロトコルを示すかもしれません。 存在しているなら、DHCP時間サーバ設定には、時間サーバ設定より高い先行があります。 例: 日和見主義者=、「12.34、.5、.2; =NTPについて議定書の中で述べてください、」
Sinnreich, et al. Informational [Page 22] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[22ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
3.12. Language
3.12. 言語
Setting the correct language is important for simple installation around the globe.
地球の周りの簡単なインストールに、正確な言葉を設定するのは重要です。
A language setting SHOULD be specified for the whole device. Where it is specified, it MUST use the codes defined in RFC 3066 to provide some predictability. Example: Language="de"
指定されていて、全体のデバイスにSHOULDを設定する言語。 指定されるところでは、それは何らかの予見性を提供するためにRFC3066で定義されたコードを使用しなければなりません。 例: 言語は"de"と等しいです。
It is recommended to set the language as writable, so that the user MAY change this. This setting SHOULD NOT be AOR related.
書き込み可能であるとして言語を設定するのは、ユーザがこれを変えることができるように、お勧めです。 これ、関係づけられたAORになってくださいSHOULD NOTを設定して。
A SIP UA MUST be able to parse and accept requests containing international characters encoded as UTF-8 even if it cannot display those characters in the user interface.
SIP UA MUSTは、分析できて、要求が含んでいると受け入れます。ユーザーインタフェースでそれらのキャラクタを見せることができないでもUTF-8としてコード化された国際的な人物。
3.13. Inbound Authentication
3.13. 本国行きの認証
SIP allows a device to limit incoming signaling to those made by a predefined set of authorized users from a list and/or with valid passwords. Note that the inbound proxy from most service providers may also support the screening of incoming calls, but in some cases users may want to have control in the SIP telephony device for the screening.
SIPはデバイスに入って来るシグナリングをリスト有効なパスワードで事前に定義されたセットの認定ユーザによって作られたものに制限させます。 ほとんどのサービスプロバイダーからの本国行きのプロキシがまた、かかってきた電話の選別をサポートしますが、選別のためのSIP電話デバイスで何人かのケースユーザでコントロールを必要とするかもしれないことに注意してください。
A device SHOULD support the setting as to whether authentication (on the device) is required and what type of authentication is required. Example: InboundAuthentication="digest;pattern=*"
SHOULDが認証(デバイスの)が必要であるかどうかと、認証のタイプが何であるかに関して設定をサポートするデバイスが必要です。 例: InboundAuthenticationは「読みこなしてください; =*を型に基づいて作ってください」と等しいです。
If inbound authentication is enabled, then a list of allowed users and credentials to call this device MAY be used by the device. The credentials MAY contain the same data as the credentials for an AOR (i.e., URL, user, password digest, and domain). This applies to SIP control signaling as well as call initiation.
本国行きの認証が可能にされるなら、このデバイスを呼ぶ許容ユーザと資格証明書のリストはデバイスによって使用されるかもしれません。 資格証明書はAOR(すなわち、URL、ユーザ、パスワードダイジェスト、およびドメイン)のための資格証明書と同じデータを含むかもしれません。 これは呼び出し開始と同様に合図するSIPコントロールに適用されます。
3.14. Voice Message Settings
3.14. 音声メール設定
Various voice message settings require the use of URIs for the service context as specified in RFC 3087 [53].
様々な音声メール設定はURIのRFC3087[53]の指定されるとしてのサービス文脈の使用を必要とします。
The message waiting indicator (MWI) address setting controls where the client SHOULD SUBSCRIBE to a voice message server and what MWI summaries MAY be displayed [9]. Example: MWISubscribe="sip:mailbox01@media.proxy.com"
音声メールサーバへのクライアントSHOULD SUBSCRIBEとどんなMWI概要が待っているかでインディケータ(MWI)アドレス設定制御装置を待って、表示してください。メッセージ、[9]。 例: MWISubscribeは「一口: mailbox01@media.proxy.com 」と等しいです。
Sinnreich, et al. Informational [Page 23] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[23ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
User Agents SHOULD accept MWI information carried by SIP MESSAGE without prior subscription. This way the setup of voice message settings can be avoided.
ユーザエージェントSHOULDは先の購読なしでSIP MESSAGEによって運ばれたMWI情報を受け入れます。 このように、音声メール設定のセットアップを避けることができます。
3.15. Phonebook and Call History
3.15. Phonebookと呼び出し歴史
The UA SHOULD have a phonebook and keep a history of recent calls. The phonebook SHOULD save the information in permanent memory that keeps the information even after restarting the device or save the information in an external database that permanently stores the information.
UA SHOULDはphonebookを持って、最近の呼び出しの歴史を保管します。 phonebook SHOULDはデバイスを再開しながら情報を追い続けさえする永久的なメモリに情報を保存するか、または永久に情報を保存する外部のデータベースに情報を保存します。
3.16. User-Related Settings and Mobility
3.16. ユーザ関連の設定と移動性
A device MAY specify the user that is currently registered on the device. This SHOULD be an address-of-record URL specified in an AOR definition.
デバイスは現在デバイスに登録されるユーザを指定するかもしれません。 このSHOULD、AOR定義で指定された記録されている住所URLになってください。
The purpose of specifying which user is currently assigned to this device is to provide the device with the identity of the user whose settings are defined in the user section. This is primarily interesting with regards to user roaming. Devices MAY allow users to sign on to them and then request that their particular settings be retrieved. Likewise, a user MAY stop using a device and want to disable their AOR while not present. For the device to understand what to do, it MUST have some way of identifying users and knowing which user is currently using it. By separating the user and device properties, it becomes clear what the user wishes to enable or to disable. Providing an identifier in the configuration for the user gives an explicit handle for the user. For this to work, the device MUST have some way of identifying users and knowing which user is currently assigned to it.
どのユーザが現在このデバイスに選任されるかを指定する目的は設定がユーザ部で定義されるユーザのアイデンティティをデバイスに提供することです。 これはあいさつによって主としてユーザローミングにおもしろいです。 デバイスで、ユーザに彼らに署名して、次に、彼らの特定の設定が検索されるよう要求するかもしれません。 同様に、ユーザは、デバイスを使用するのを止めて、存在していない間、それらのAORを無効にしたがっているかもしれません。 デバイスが、何をしたらよいかを理解するように、それには、ユーザを特定して、どのユーザが現在それを使用しているかを知る何らかの方法がなければなりません。 ユーザとデバイスの特性を切り離すことによって、それはユーザが何を可能にしたいか、または無効にしたがっているかが明確になります。 ユーザのために識別子を構成に提供すると、明白なハンドルはユーザのために与えられます。 これが働くように、デバイスには、ユーザを特定して、どのユーザが現在それに選任されるかを知る何らかの方法がなければなりません。
One possible scenario for roaming is an agent who has definitions for several AORs (e.g., one or more personal AORs and one for each executive for whom the administrator takes calls) that they are registered for. If the agent goes to the copy room, they would sign on to a device in that room and their user settings including their AOR would roam with them.
ローミングのための1つの可能なシナリオが彼らが登録される数個のAORs(例えば、管理者が取る各幹部社員あたり1人以上の個人的なAORsと人が電話をする)のための定義を持っているエージェントです。 余地とそれらのAORを含むそれらのユーザー設定がそれらで移動するでしょう、したがって、エージェントがコピー部屋に行くなら、彼らはデバイスに署名するでしょう。
The alternative to this is to require the agent to individually configure each of the AORs (this would be particularly irksome using standard telephone button entry).
これへの代替手段はそれぞれ個別に構成するエージェントにAORsを要求する(これは標準の電話ボタンのエントリーを使用することで特に退屈でしょう)ことです。
The management of user profiles, aggregation of user or device AOR, and profile information from multiple management sources are configuration server concerns that are out of the scope of this document. However, the ability to uniquely identify the device and
ユーザ・プロファイルの管理、ユーザかデバイスAORの集合、および複合経営ソースからのプロフィール情報はこのドキュメントの範囲の外にある構成サーバ関心です。 そしてしかしながら、唯一デバイスを特定する能力。
Sinnreich, et al. Informational [Page 24] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[24ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
user within the configuration data enables easier server-based as well as local (i.e., on the device) configuration management of the configuration data.
コンフィギュレーション・データの中のユーザはコンフィギュレーション・データの、より簡単なサーバベースの、そして、地方(すなわち、デバイスの)の構成管理を可能にします。
3.17. AOR-Related Settings
3.17. AOR関連の設定
SIP telephony devices MUST use the AOR-related settings, as specified here.
SIP電話デバイスはここで指定されるとしてAOR関連の設定を使用しなければなりません。
There are many properties which MAY be associated with or SHOULD be applied to the AOR or signaling addressed to or from the AOR. AORs MAY be defined for a device or a user of the device. At least one AOR MUST be defined in the settings; this MAY pertain to either the device itself or the user. Example: AOR="sip:12345@proxy.com"
交際するかもしれない多くの特性かAORに当てはまられているか、またはAORかAORから扱われて、示すSHOULDがあります。 AORsはデバイスのデバイスかユーザのために定義されるかもしれません。 少なくとも1AOR MUST、設定で定義されてください。 これはデバイス自体かユーザのどちらかに関係するかもしれません。 例: AORは「一口: 12345@proxy.com 」と等しいです。
It MUST be possible to specify at least one set of domain, user name, and authentication credentials for each AOR. The user name and authentication credentials are used for authentication challenges.
少なくとも1セットのドメイン、ユーザ名、および認証資格証明書を各AORに指定するのは可能であるに違いありません。 ユーザ名と認証資格証明書は認証挑戦に使用されます。
3.18. Maximum Connections
3.18. 最大のコネクションズ
A setting defining the maximum number of simultaneous connections that a device can support MUST be used by the device. The endpoint might have some maximum limit, most likely determined by the media handling capability. The number of simultaneous connections may be also limited by the access bandwidth, such as of DSL, cable, and wireless users. Other optional settings MAY include the enabling or disabling of call waiting indication.
デバイスでデバイスがサポートすることができる同時接続の最大数を定義する設定を使用しなければなりません。 大部分は、終点には何らかの最大の限界があるかもしれないことをおそらく能力を処理するメディアで決定しました。 また、同時接続の数はアクセス帯域幅、DSL現在そのようなもの、ケーブル、およびワイヤレスユーザによって制限されるかもしれません。 他の任意の設定はキャッチホン指示を可能にするか無効にすることを含むかもしれません。
A SIP telephony device MAY support at least two connections for three-way conference calls that are locally hosted. Example: MaximumConnections="2;cwi=false;bw=128".
SIP電話デバイスは局所的に接待される3者間の電話会議のために少なくとも2つの接続をサポートするかもしれません。 例: MaximumConnectionsは「2; cwi=偽; bw=128」と等しいです。
See the recent work on connection reuse [54] and the guidelines for connection-oriented transport for SIP [55].
接続での近作がSIP[55]のために[54]と接続指向の輸送のためのガイドラインを再利用するのを見てください。
3.19. Automatic Configuration and Upgrade
3.19. 自動構成とアップグレード
Automatic SIP telephony device configuration SHOULD use the processes and requirements described in [56]. The user name or the realm in the domain name SHOULD be used by the configuration server to automatically configure the device for individual- or group-specific settings, without any configuration by the user. Image and service data upgrades SHOULD also not require any settings by the user.
自動SIP電話デバイス構成SHOULDは[56]で説明されたプロセスと要件を使用します。 ユーザ名か分野、ドメイン名SHOULDで構成サーバによって使用されて、自動的に個々の、または、グループ特有の設定にデバイスを構成してください、ユーザによる少しも構成なしで。 また、イメージとサービスデータアップグレードSHOULDはユーザで少しの設定も必要としません。
Sinnreich, et al. Informational [Page 25] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[25ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
3.20. Security Configurations
3.20. セキュリティ設定
The device configuration usually contains sensitive information that MUST be protected. Examples include authentication information, private address books, and call history entries. Because of this, it is RECOMMENDED to use an encrypted transport mechanism for configuration data. Where devices use HTTP, this could be TLS.
通常、デバイス構成は保護しなければならない機密情報を含んでいます。 例は認証情報、プライベート・アドレスの本、および呼び出し歴史エントリーを含んでいます。 これのために、それはコンフィギュレーション・データに暗号化された移送機構を使用するRECOMMENDEDです。 デバイスがHTTPを使用するところでは、これはTLSであるかもしれません。
For devices which use FTP or TFTP for content delivery this can be achieved using symmetric key encryption.
内容物配送にFTPかTFTPを使用するデバイスに関しては、対称鍵暗号化を使用することでこれを達成できます。
Access to retrieving configuration information is also an important issue. A configuration server SHOULD challenge a subscriber before sending configuration information.
また、設定情報を検索することへのアクセスは切迫した課題です。 SHOULDが設定情報を送りながら加入者に挑戦する構成サーバ。
The configuration server SHOULD NOT include passwords through the automatic configuration process. Users SHOULD enter the passwords locally.
構成サーバSHOULD NOTは自動コンフィギュレーションプロセスでパスワードを含んでいます。 ユーザSHOULDは局所的にパスワードを入力します。
4. Security Considerations
4. セキュリティ問題
4.1. Threats and Problem Statement
4.1. 脅威と問題声明
While Section 2.11 states the minimal security requirements and NAT/firewall traversal that have to be met respectively by SIP telephony devices, developers and network managers have to be aware of the larger context of security for IP telephony, especially for those scenarios where security may reside in other parts of SIP- enabled networks.
セクション2.11がSIP電話デバイスによってそれぞれ迎えられなければならない最小量のセキュリティ要件とNAT/ファイアウォール縦断を述べる間、IP電話技術において、開発者とネットワークマネージャはセキュリティの、より大きい文脈を意識していなければなりません、特にセキュリティがSIPの他の部分にあるかもしれないそれらのシナリオがネットワークを可能にしたので。
Users of SIP telephony devices are exposed to many threats [57] that include but are not limited to fake identity of callers, telemarketing, spam in IM, hijacking of calls, eavesdropping, and learning of private information such as the personal phone directory, user accounts and passwords, and the personal calling history. Various denial of service (DoS) attacks are possible, such as hanging up on other people's conversations or contributing to DoS attacks of others.
SIP電話デバイスのユーザは、それが含む多くの脅威[57]に暴露されますが、訪問者と、テレマーケティングと、IMのスパムと、呼び出しのハイジャックと、盗聴と、個人情報を知る個人的な電話帳や、ユーザアカウントやパスワードなどのアイデンティティ、および個人的な呼ぶ歴史を見せかけるために制限されません。 サービス(DoS)攻撃の様々な否定は可能です、他の人々の会話にハングアップするか、または他のもののDoS攻撃に貢献するのなどように。
Service providers are also exposed to many types of attacks that include but are not limited to theft of service by users with fake identities, DoS attacks, and the liabilities due to theft of private customer data and eavesdropping in which poorly secured SIP telephony devices or especially intermediaries such as stateful back-to-back user agents with media (B2BUA) may be implicated.
また、サービスプロバイダーがそれの不十分に機密保護しているSIP電話デバイスで含みますが、個人的な顧客データの窃盗のためにせのアイデンティティ、DoS攻撃、および負債でユーザによってサービスの窃盗に制限されないで、盗み聞かれる多くのタイプの攻撃に暴露されるか、または特にメディア(B2BUA)のstateful背中合わせのユーザエージェントなどの仲介者は巻き込まれるかもしれません。
Sinnreich, et al. Informational [Page 26] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[26ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
SIP security is a hard problem for several reasons:
いくつかの理由でSIPセキュリティは難問です:
o Peers can communicate across domains without any pre-arranged
trust relationship.
o There may be many intermediaries in the signaling path.
o Multiple endpoints can be involved in such telephony operations
as forwarding, forking, transfer, or conferencing.
o There are seemingly conflicting service requirements when
supporting anonymity, legal intercept, call trace, and privacy.
o Complications arise from the need to traverse NATs and
firewalls.
o 同輩はドメインの向こう側に少しも根回しされた信頼関係なしで交信できます。o Thereはシグナリング経路の多くの仲介者であるかもしれません。匿名、法的なインタセプト、呼び出し跡、およびプライバシーをサポートするとき、o Multiple終点は推進、分岐が移すような電話操作にかかわることができますか、会議o Thereが外観上闘争しているサービス要件です。o ComplicationsはNATsとファイアウォールを横断する必要性から起こります。
There are a large number of deployment scenarios in enterprise networks, using residential networks and employees using Virtual Private Network (VPN) access to the corporate network when working from home or while traveling. There are different security scenarios for each. The security expectations are also very different, say, within an enterprise network or when using a laptop in a public wireless hotspot, and it is beyond the scope of this memo to describe all possible scenarios in detail.
企業網には多くの展開シナリオがあって、Virtualを使用することで住宅のネットワークと従業員を使用して、兵士のNetwork(VPN)はホームから働いているとき、ネットワークに法人にアクセスするか、または旅行をゆったり過ごします。 それぞれのための異なったセキュリティシナリオがあります。 ラップトップを使用するとき、また、セキュリティ期待がたとえば企業網の中で非常に異なっているか、または詳細にすべての可能なシナリオについて説明するこのメモの範囲が向こうに公共のワイヤレスのホットスポット、およびそれに、あります。
The authors believe that adequate security for SIP telephony devices can be best implemented within protected networks, be they private IP networks or service provider SIP-enabled networks where a large part of the security threats listed here are dealt with in the protected network. A more general security discussion that includes network- based security features, such as network-based assertion of identity [58] and privacy services [7], is outside the scope of this memo, but must be well understood by developers, network managers, and service providers.
作者は、中に保護されたネットワークであるとSIP電話デバイスのための十分な安全性を実装することができると最も良い信じています、プライベートアイピーネットワークか軍事的脅威のかなりの部分がここに記載したサービスプロバイダーのSIPによって可能にされたネットワークが保護されたネットワークで取り引きされているか否かに関係なく。 このメモの範囲の外に開発者、ネットワークマネージャ、およびサービスプロバイダーによく解釈しなければならないのを除いて、ネットワークベースのアイデンティティ[58]の、そして、プライバシーサービス[7]の主張などのネットワークのベースのセキュリティ機能を含んでいるより一般的なセキュリティ議論があります。
In the following, some basic security considerations as specified in RFC 3261 are discussed as they apply to SIP telephony devices.
以下では、SIP電話デバイスに適用するとき、RFC3261の指定されるとしてのいくつかの基本的なセキュリティ問題について議論します。
4.2. SIP Telephony Device Security
4.2. 一口電話デバイスセキュリティ
Transport Level Security
SIP telephony devices that operate outside the perimeter of
secure private IP networks (this includes telecommuters and
roaming users) MUST use TLS to the outgoing SIP proxy for
protection on the first hop. SIP telephony devices that use
TLS must support SIPS in the SIP headers.
安全なプライベートアイピーネットワーク(これは在宅勤務者とローミングユーザを含んでいる)の周辺の外で作動する輸送Level Security SIP電話デバイスは保護に最初のホップの上で辞職しているSIPプロキシにTLSを使用しなければなりません。 TLSを使用するSIP電話デバイスはSIPヘッダーでSIPSをサポートしなければなりません。
Supporting large numbers of TLS channels to endpoints is quite
a burden for service providers and may therefore constitute a
premium service feature.
多くのTLSチャンネルを終点に支えるのは、サービスプロバイダーのためのかなりの負担であり、したがって、プレミアムサービス機能を構成するかもしれません。
Sinnreich, et al. Informational [Page 27] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[27ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
Digest Authentication
SIP telephony devices MUST support digest authentication to
register with the outgoing SIP registrar. This ensures proper
identity credentials that can be conveyed by the network to the
called party. It is assumed that the service provider
operating the outgoing SIP registrar has an adequate trust
relationship with its users and knows its customers well enough
(identity, address, billing relationship, etc.). The
exceptions are users of prepaid service. SIP telephony devices
that accept prepaid calls MUST place "unknown" in the "From"
header.
ダイジェストAuthentication SIP電話デバイスは、辞職しているSIP記録係とともに記名するためにダイジェスト認証をサポートしなければなりません。 これはネットワークが被呼者に伝えることができる適切なアイデンティティ資格証明書を確実にします。 辞職しているSIP記録係を運用するサービスプロバイダーがユーザとの適切な信頼関係を持っていて、顧客を十分よく(アイデンティティ、アドレス、支払い関係など)知っていると思われます。 例外は前払いのサービスのユーザです。 前払いの呼び出しを受け入れるSIP電話デバイスは「未知」を“From"ヘッダーに置かなければなりません。
End User Certificates
SIP telephony devices MAY store personal end user certificates
that are part of some Public Key Infrastructure (PKI) [59]
service for high-security identification to the outgoing SIP
registrar as well as for end-to-end authentication. SIP
telephony devices equipped for certificate-based authentication
MUST also store a key ring of certificates from public
certificate authorities (CAs).
エンドユーザCertificates SIP電話デバイスは辞職しているSIP記録係への高い機密保護コード識別機構と終わりから終わりへの認証のための何らかの公開鍵暗号基盤(PKI)[59]サービスの一部である個人的なエンドユーザ証明書を保存するかもしれません。 また、証明書ベースの認証のために備えていたSIP電話デバイスは公共の認証局(CAs)からの証明書のキーホルダーを保存しなければなりません。
Note the recent work in the IETF on certificate services that
do not require the telephony devices to store certificates
[60].
証明書[60]を保存するために電話デバイスを必要としない証明書サービスのときにIETFで近作に注意してください。
End-to-End Security Using S/MIME
S/MIME [61] MUST be supported by SIP telephony devices to sign
and encrypt portions of the SIP message that are not strictly
required for routing by intermediaries. S/MIME protects
private information in the SIP bodies and in some SIP headers
from intermediaries. The end user certificates required for
S/MIME ensure the identity of the parties to each other. Note:
S/MIME need not be used, though, in every call.
ルーティングのために仲介者によって厳密に必要とされないSIPメッセージの部分を、SIP電話デバイスで終わりから終わりへのSecurity Using S/MIME S/MIME[61]をサポートして、署名して、暗号化しなければなりません。 S/MIMEはSIPボディーと何人かのSIPヘッダーに仲介者から個人情報を保護します。 S/MIMEに必要であるエンドユーザ証明書はパーティーのアイデンティティを互いに保証します。 以下に注意してください。 もっとも、S/MIMEはあらゆる呼び出しに使用されなければならないというわけではありません。
4.3. Privacy
4.3. プライバシー
Media Encryption
Secure RTP (SRTP) [62] MAY be used for the encryption of media
such as audio, text, and video, after the keying information
has been passed by SIP signaling. Instant messaging MAY be
protected end-to-end using S/MIME.
メディアEncryption Secure RTP(SRTP)[62]はオーディオや、テキストや、ビデオなどのメディアの暗号化に使用されるかもしれません、合わせる情報がSIPシグナリングによって通過された後に。 インスタントメッセージングは、保護されたS/MIMEを使用する終わりから終わりであるかもしれません。
4.4. Support for NAT and Firewall Traversal
4.4. NATのサポートとファイアウォール縦断
The various NAT and firewall traversal scenarios require support in telephony SIP devices. The best current practices for NAT traversal for SIP are reviewed in [51]. Most scenarios where there are no SIP-enabled network edge NAT/firewalls or gateways in the enterprise
様々なNATとファイアウォール縦断シナリオは電話SIPデバイスで支持を要します。 SIPのためのNAT縦断のための最も良い現在の実務は[51]で再検討されます。 企業にはSIPによって可能にされたネットワーク縁のNAT/ファイアウォールかゲートウェイが全くないほとんどのシナリオ
Sinnreich, et al. Informational [Page 28] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[28ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
can be managed if there is a STUN client in the SIP telephony device and a STUN server on the Internet, maintained by a service provider. In some exceptional cases (legacy symmetric NAT), an external media relay must also be provided that can support the Traversal Using Relay NAT (TURN) protocol exchange with SIP telephony devices. Media relays such as TURN come at a high bandwidth cost to the service provider, since the bandwidth for many active SIP telephony devices must be supported. Media relays may also introduce longer paths with additional delays for voice.
SIP電話デバイスとSTUNサーバにSTUNクライアントがサービスプロバイダーによって維持されたインターネットにいれば、対処できます。 また、いくつかの例外的な場合(レガシーの左右対称のNAT)では、外部のメディアリレーはTraversal Using Relay NAT(TURN)が缶のサポートであればSIP電話デバイスで交換について議定書の中で述べるということであるに違いありません。 TURNなどのメディアリレーはサービスプロバイダーへの高帯域費用で来ます、多くのアクティブなSIP電話デバイスのための帯域幅をサポートしなければならないので。 また、メディアリレーは声のために追加遅れで、より長い経路を導入するかもしれません。
Due to these disadvantages of media relays, it is preferable to avoid symmetric and non-deterministic NATs in the network, so that only STUN can be used, where required. Reference [63] deals in more detail how NAT has to 'behave'.
メディアリレーのこれらの難点のために、ネットワークで左右対称の、そして、非決定論的なNATsを避けるのは望ましいです、STUNしか使用できないように、必要であるところで。 参照[63]はNATがさらに詳細にどう'振る舞わなければならないか'を取扱います。
It is not always obvious to determine the specific NAT and firewall scenario under which a SIP telephony device may operate.
SIP電話デバイスが作動するかもしれない特定のNATとファイアウォールシナリオを決定するのはいつも明白であるというわけではありません。
For this reason, the support for Interactive Connectivity Establishment (ICE) has been defined to be deployed in all devices that required end-to-end connectivity for SIP signaling and RTP media streams, as well as for streaming media using Real Time Streaming Protocol (RTSP). ICE makes use of existing protocols, such as STUN and TURN.
この理由で、Interactive Connectivity特権階級(ICE)のサポートはSIPシグナリングとRTPメディアストリームのために終わりから終わりへの接続性を必要としたすべてのデバイスで配布されるために定義されました、よくレアルTime Streamingプロトコル(RTSP)を使用するストリーミング・メディアのように。 ICEはSTUNやTURNなどの既存のプロトコルを利用します。
Call flows using SIP security mechanisms
The high-level security aspects described here are best
illustrated by inspecting the detailed call flows using SIP
security, such as in [64].
SIPセキュリティを使用することで詳細な呼び出し流れを点検することによってハイレベルのセキュリティ局面がここで説明したSIPセキュリティー対策を使用する呼び出し流れを例証するのが最も良い、[64]などのように。
Security enhancements, certificates, and identity management
As of this writing, recent work in the IETF deals with the SIP
Authenticated Identity Body (AIB) format [65], new S/MIME
requirements, enhancements for the authenticated identity, and
Certificate Management Services for SIP. We recommend
developers and network managers to follow this work as it will
develop into IETF standards.
セキュリティ増進、証明書、およびこの書くことのアイデンティティ管理As、SIP Authenticated Identity Body(AIB)とのIETF取引における近作は[65]、新しいS/MIME要件、認証されたアイデンティティのための増進、およびSIPのためのCertificate Management Servicesをフォーマットします。 それがIETF規格の上に伸びるとき、私たちは、開発者とネットワークマネージャがこの仕事の後をつけることを勧めます。
5. Acknowledgements
5. 承認
Paul Kyzivat and Francois Audet have made useful comments how to support to the dial plan requirements in Req-17. Mary Barnes has kindly made a very detailed review of version 04 that has contributed to significantly improving the document. Useful comments on version 05 have also been made by Ted Hardie, David Kessens, Russ Housley, and Harald Alvestrand that are reflected in this version of the document.
ポールKyzivatとフランソアAudetはReq-17でどうダイヤルプランに要件をサポートするかを役に立つコメントにしました。 メアリ・バーンズは親切にドキュメントをかなり改良するのに貢献したバージョン04の非常に詳細なレビューをしました。 また、バージョン05の役に立つコメントはドキュメントのこのバージョンに反映されるテッド・ハーディー、デヴィッドKessens、ラスHousley、およびハラルドAlvestrandによってされました。
Sinnreich, et al. Informational [Page 29] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[29ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
We would like to thank Jon Peterson for very detailed comments on the previous version 0.3 that has prompted the rewriting of much of this document. John Elwell has contributed with many detailed comments on version 04 of the document. Rohan Mahy has contributed several clarifications to the document and leadership in the discussions on support for the hearing disabled. These discussions have been concluded during the BOF on SIP Devices held during the 57th IETF, and the conclusions are reflected in the section on interactive text support for hearing- or speech-disabled users.
このドキュメントの多くの書き直しをうながした旧バージョン0.3の非常に詳細なコメントについてジョン・ピーターソンに感謝申し上げます。 ジョン・エルウェルはドキュメントのバージョン04の多くの詳細なコメントで貢献しました。 Rohanマーイは公聴会身体障害者のサポートについての議論でドキュメントとリーダーシップにいくつかの明確化を寄付しました。 これらの議論は第57IETFの間に持たれていたSIP Devicesの上のBOFの間、結論づけられています、そして、結論は公聴会かスピーチが障害があるユーザの対話的なテキストサポートのときにセクションに反映されます。
Gunnar Hellstrom, Arnoud van Wijk, and Guido Gybels have been instrumental in driving the specification for support of the hearing disabled.
グナー・ヘルストリョーム、Arnoudバンウェイク、およびグイドGybelsは公聴会のサポートのための仕様を障害があるようにする際に手段になっています。
The authors would also like to thank numerous persons for contributions and comments to this work: Henning Schulzrinne, Jorgen Bjorkner, Jay Batson, Eric Tremblay, David Oran, Denise Caballero McCann, Brian Rosen, Jean Brierre, Kai Miao, Adrian Lewis, and Franz Edler. Jonathan Knight has contributed significantly to earlier versions of the requirements for SIP phones. Peter Baker has also provided valuable pointers to TIA/EIA IS 811 requirements to IP phones that are referenced here.
また、作者はこの仕事への貢献とコメントについて多数の人々に感謝したがっています: ヘニングSchulzrinne、ヨルゲンBjorkner、ジェイBatson、エリック・トランブレー、デヴィッド・オラン、デニーズ・カバリェロ・マッキャン、ブライアン・ローゼン、ジーンBrierre、カイ・ミャオ、エードリアン・ルイス、およびフランツEdler。 ジョナサンKnightはSIP電話のための要件の以前のバージョンにかなり貢献しました。 また、ピーター・ベイカーはここで参照をつけられるIP電話へのTIA/EIA IS811要件に貴重な指針を提供しました。
Last but not least, the co-authors of the previous versions, Daniel Petrie and Ian Butcher, have provided support and guidance all along in the development of these requirements. Their contributions are now the focus of separate documents.
最後、しかし、特に、旧バージョンの共著者(ダニエル・ピートリーとイアンButcher)は、ずっとこれらの要件の開発にサポートと指導を提供しています。 現在、彼らの貢献は別々のドキュメントの焦点です。
Sinnreich, et al. Informational [Page 30] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[30ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
6. Informative References
6. 有益な参照
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] 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.
[2] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[3] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic
Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[3] レモンとT.とS.チェーシャー州、「Dynamic Host Configuration Protocol(DHCPv4)における長いオプションをコード化します」、RFC3396、2002年11月。
[4] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 4330, January 2006.
[4] 工場、D.、「IPv4、IPv6、およびOSIのための簡単なネットワーク時間プロトコル(SNTP)バージョン4」、RFC4330、2006年1月。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始は(一口)について議定書の中で述べます」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。
[6] Peterson, J., "enumservice registration for Session Initiation
Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
[6] ピーターソン、J.、「記録のSession Initiationプロトコル(SIP)アドレスのためのenumservice登録」、RFC3764、2004年4月。
[7] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[7] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[9] Mahy, R., "A Message Summary and Message Waiting Indication
Event Package for the Session Initiation Protocol (SIP)", RFC
3842, August 2004.
[9] マーイ、R.、「セッション開始のためのメッセージ概要とメッセージ待ち指示イベントパッケージは(一口)について議定書の中で述べます」、RFC3842、2004年8月。
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[10]Schulzrinne、2004年12月のH.、「Telephone民数記のためのtel URI」RFC3966。
[11] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[11] スパークス、R.、「セッション開始プロトコル(一口)はメソッドを参照する」RFC3515、2003年4月。
[12] Johnston, A., "SIP Service Examples", Work in Progress, March
2006.
[12] ジョンストン、A.、「一口サービスの例」が進歩、2006年3月に働いています。
[13] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[13] Schulzrinne、H.、およびS.Petrack(「DTMFケタ、電話トーン、および電話信号のためのRTP有効搭載量」、RFC2833)は2000がそうするかもしれません。
[14] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
[14]CasnerとS.とP.Hoschka、「RTP有効搭載量形式のMIMEの種類登録」、RFC3555、2003年7月。
Sinnreich, et al. Informational [Page 31] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[31ページ]のRFC4504は電話デバイス要件2006年5月にちびちび飲みます。
[15] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[15]キャマリロ、G.、エリクソン、G.、叫び声、J.、およびH.Schulzrinne、「メディアの組分けはセッション記述プロトコル(SDP)で立ち並んでいます」、RFC3388、2002年12月。
[16] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
Generation in the Session Initiation Protocol (SIP)", RFC 3960,
December 2004.
[16] キャマリロ、G.、およびH.Schulzrinne、「早くメディアと鳴るのはセッション開始プロトコル(一口)における世代に調子を変えます」、RFC3960、2004年12月。
[17] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", BCP 75, RFC 3665, December 2003.
[17] ジョンストン、A.、ドノヴァン、S.、スパークス、R.、カニンハム、C.、およびK.夏、「セッション開始プロトコル(一口)基本的な呼び出し流れの例」、BCP75、RFC3665、2003年12月。
[18] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Public Switched
Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December
2003.
[18] ジョンストン、A.、ドノヴァン、S.、スパークス、R.、カニンハム、C.、およびK.サマーズ、「セッション開始プロトコル(一口)公衆電話交換網(PSTN)呼び出しは流れます」、BCP76、RFC3666、2003年12月。
[19] 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.
[19] ローゼンバーグ、J.、ピーターソン、J.、Schulzrinne、H.、およびG.キャマリロ、「セッション開始という第三者呼び出しコントロール(3pcc)のための最も良い現在の実務は(一口)について議定書の中で述べます」、BCP85、RFC3725、2004年4月。
[20] Mahy, R., et al., "A Call Control and Multi-party usage
framework for the Session Initiation Protocol (SIP)", Work in
Progress, March 2006.
[20] マーイ、R.、他、「Session Initiationプロトコル(SIP)のためのCall ControlとMulti-パーティー用法枠組み」、Progress(2006年3月)のWork。
[21] Johnston, A. and O. Levin, "Session Initiation Protocol Call
Control - Conferencing for User Agents", Work in Progress,
October 2005.
[21] 「セッション開始プロトコルは、ユーザエージェントのためにコントロール--会議を召集する」というジョンストン、A.、およびO.レヴィンは進行中(2005年10月)で働いています。
[22] Even, R. and N. Ismail, "Conferencing Scenarios", Work in
Progress, September 2005.
[22] 「会議シナリオ」というR.とN.イスマイルは進歩、2005年9月に働きさえします。
[23] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
RFC 4103, June 2005.
[23] ヘルストリョームとG.とP.ジョーンズ、「テキストの会話のためのRTP有効搭載量」、RFC4103、2005年6月。
[24] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[24] キャンベル、B.、ローゼンバーグ、J.、Schulzrinne、H.、Huitema、C.、およびD.Gurle、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。
[25] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[25] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年8月。
[26] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
RFC 3840, August 2004.
[26] ローゼンバーグ、J.、Schulzrinne、H.、およびP.Kyzivat、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
Sinnreich, et al. Informational [Page 32] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[32ページ]のRFC4504は電話装置要件2006年5月にちびちび飲みます。
[27] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
"RPID: Rich Presence Extensions to the Presence Information Data
Format (PIDF)", Work in Progress, September 2005.
[27]Schulzrinne、H.、Gurbani、V.、Kyzivat、P.、およびJ.ローゼンバーグ、「RPID:」 「存在情報データの形式(PIDF)への豊かな存在拡大」は進歩、2005年9月に働いています。
[28] See the Working Group on Emergency Context Resolution with
Internet Technologies at
http://www.ietf.org/html.charters/ecrit-charter.html
[28] インターネット技術が http://www.ietf.org/html.charters/ecrit-charter.html にある状態で、非常時の文脈解決に作業部会を見てください。
[29] Schulzrinne, H. and J. Polk, "Communications Resource Priority
for the Session Initiation Protocol (SIP)", RFC 4412, February
2006.
[29]SchulzrinneとH.とJ.ポーク、「セッション開始プロトコル(一口)のためのコミュニケーションリソース優先権」、RFC4412、2006年2月。
[30] Polk, J. and B. Rosen, "Session Initiation Protocol Location
Conveyance", Work in Progress, July 2005.
[30] 「セッション開始プロトコル位置の運送」というポーク、J.、およびB.ローゼンは進歩、2005年7月に働いています。
[31] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van
Wijk, "User Requirements for the Session Initiation Protocol
(SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
Individuals", RFC 3351, August 2002.
[31] チャールトン、N.、Gasson、M.、Gybels、G.、Spanner、M.、およびA.はウェイク、「聴覚障害の、そして、耳が遠くてスピーチによって損なわれた個人を支持したセッション開始プロトコル(一口)のためのユーザ要件」をバンに積みます、RFC3351、2002年8月。
[32] van Wijk, A., "Framework of requirements for real-time text
conversation using SIP", Work in Progress, September 2005.
[32] 2005年9月にProgressでウェイク、A.、「SIPを使用するリアルタイムのテキストの会話のための要件の枠組み」、Workをバンに積んでください。
[33] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[33]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[34] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", RFC 3611, November 2003.
[34] フリードマン、T.、カセレス、R.、およびA.クラーク、「RTP制御プロトコルの拡張レポート(RTCP XR)」、RFC3611 2003年11月。
[35] Pendleton, A., "SIP Package for Quality Reporting Event", Work
in Progress, February 2006.
[35] ペンドルトン、A.、「出来事を報告する品質のための一口パッケージ」が進歩、2006年2月に働いています。
[36] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[36] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[37] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[37]HeinanenとJ.とベイカーとF.とウィス、W.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、1999年6月。
[38] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[38] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[39] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[39] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[40] ITU-T Recommendation G.711, available online at
http://www.itu.int.
[40] ITU-T Recommendation G.711、利用可能である、 http://www.itu.int では、オンラインです。
Sinnreich, et al. Informational [Page 33] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[33ページ]のRFC4504は電話装置要件2006年5月にちびちび飲みます。
[41] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and
J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951,
December 2004.
[41] アンダーセン、S.、Duric、A.、Astrom、H.、ハーゲン、R.、Kleijn、W.、およびJ.リンデン、「インターネット安値ビット伝送速度コーデック(iLBC)」、RFC3951(2004年12月)。
[42] Duric, A. and S. Andersen, "Real-time Transport Protocol (RTP)
Payload Format for internet Low Bit Rate Codec (iLBC) Speech",
RFC 3952, December 2004.
[42]DuricとA.とS.アンダーセン、「インターネットLow Bit Rate Codec(iLBC)スピーチのためのリアルタイムのTransportプロトコル(RTP)有効搭載量Format」、RFC3952、2004年12月。
[43] Herlein, G., et al., "RTP Payload Format for the Speex Codec",
Work in Progress, October 2005.
[43]Herlein、G.、他、「SpeexコーデックのためのRTP有効搭載量形式」、Progress、2005年10月のWork。
[44] TIA/EIA-810-A, "Transmission Requirements for Narrowband Voice
over IP and Voice over PCM Digital Wireline Telephones", July
2000.
[44]TIA/EIA-810-A、「PCMのデジタルワイヤーライン電話の上の狭帯域ボイス・オーバー IPと声のためのトランスミッション要件」、2000年7月。
[45] TIA-EIA-IS-811, "Terminal Equipment - Performance and
Interoperability Requirements for Voice-over-IP (VoIP) Feature
Telephones", July 2000.
[45] TIA-EIAが811歳であり、「端末装置--Voice-over-IP(VoIP)のためのパフォーマンスと相互運用性要件は電話を特集する」、7月2000日
[46] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[46]、BCP47、RFC3066、2001年1月。
[47] Wing, D., "Symmetric RTP and RTCP Considered Helpful", Work in
Progress, October 2004.
[47] 翼と、D.と、「左右対称のRTPと役立っていると考えられたRTCP」は進歩、2004年10月に機能します。
[48] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN -
Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs)", RFC 3489, March 2003.
[48] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、2003年3月。
[49] Jennings, C., "NAT Classification Test Results", Work in
Progress, July 2005.
[49] ジョニングス、C.、「NAT分類試験の成績」が進歩、2005年7月に働いています。
[50] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", Work in Progress, July 2005.
[50] ローゼンバーグ、J.、「対話的な接続性設立(氷):」 「申し出/答えプロトコルのためのネットワークアドレス変換機構(NAT)縦断のための方法論」、処理中の作業、2005年7月。
[51] Boulton, C. and J. Rosenberg, "Best Current Practices for NAT
Traversal for SIP", Work in Progress, October 2005.
[51] 「一口のためのNAT縦断のための最も良い現在の実務」というボールトン、C.、およびJ.ローゼンバーグは進歩、2005年10月に働いています。
[52] P. Eggert, "Sources for time zone and daylight saving time
data." Available at http://www.twinsun.com/tz/tz-link.htm.
[52] P.エッゲルト、「時間帯と夏時間データのためのソース。」 http://www.twinsun.com/tz/tz-link.htm では、利用可能です。
[53] Campbell, B. and R. Sparks, "Control of Service Context using
SIP Request-URI", RFC 3087, April 2001.
[53] キャンベルとB.とR.スパークス、「一口要求URIを使用するサービス文脈のコントロール」、RFC3087、2001年4月。
[54] Mahy, R., "Connection Reuse in the Session Initiation Protocol
(SIP)", Work in Progress, February 2006.
[54] マーイ、R.、「セッション開始プロトコル(一口)における接続再利用」が進歩、2006年2月に働いています。
Sinnreich, et al. Informational [Page 34] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[34ページ]のRFC4504は電話装置要件2006年5月にちびちび飲みます。
[55] Jennings, C. and R. Mahy, "Managing Client Initiated Connections
in the Session Initiation Protocol", Work in Progress, March
2006.
[55] 「セッション開始プロトコルのクライアントの開始しているコネクションズを管理し」て、ジョニングス、C.、およびR.マーイは進歩、2006年3月に働いています。
[56] Petrie, D., "A Framework for SIP User Agent Profile Delivery",
Work in Progress, July 2005.
[56] ピートリー、D.、「一口ユーザエージェントプロフィール配送のための枠組み」が進歩、2005年7月に働いています。
[57] Jennings, C., "SIP Tutorial: SIP Security", presented at the VON
Spring 2004 conference, March 29, 2004, Santa Clara, CA.
[57] ジョニングス、C.、「チュートリアルをちびちび飲んでください」 "SIP Security"は2004年3月29日にVON Spring2004会議にサンタクララ(カリフォルニア)を提示しました。
[58] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[58] ジョニングス、C.、ピーターソン、J.、およびM.ワトソン、「セッション開始への個人的な拡大は断言されたアイデンティティのために信じられたネットワークの中で(一口)について議定書の中で述べます」、RFC3325、2002年11月。
[59] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu,
"Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework", RFC 3647, November 2003.
[59] Chokhani、S.、フォード、W.、Sabett、R.、メリル、C.、およびS.ウー、「インターネットX.509公開鍵暗号基盤証明書方針と証明は枠組みを練習します」、RFC3647、2003年11月。
[60] Jennings, C. and J. Peterson, "Certificate Management Service
for The Session Initiation Protocol (SIP)", Work in Progress,
March 2006.
[60] 「セッション開始プロトコル(一口)のための証明書経営指導」というジョニングス、C.、およびJ.ピーターソンは進歩、2006年3月に働いています。
[61] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[61]Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[62] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
2004年の[62]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
[63] Audet, F. and C. Jennings, "NAT Behavioral Requirements for
Unicast UDP", Work in Progress, September 2005.
[63] 「ユニキャストUDPのためのNATの行動の要件」というAudet、F.、およびC.ジョニングスは進歩、2005年9月に働いています。
[64] Jennings, C., "Example call flows using SIP security
mechanisms", Work in Progress, February 2006.
[64] ジョニングス、C.、「SIPセキュリティー対策を使用する例の呼び出し流れ」、Progress、2006年2月のWork。
[65] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004.
[65] ピーターソン、J.、「セッション開始プロトコル(一口)はアイデンティティ本体(AIB)形式を認証した」RFC3893、2004年9月。
Sinnreich, et al. Informational [Page 35] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[35ページ]のRFC4504は電話装置要件2006年5月にちびちび飲みます。
Author's Addresses
作者のアドレス
Henry Sinnreich Pulver.com 115 Broadhollow Road Melville, NY 11747, USA
ニューヨーク 11747、ヘンリーSinnreich Pulver.com115Broadhollow Roadメルビル(米国)
EMail: henry@pulver.com Phone: +1-631-961-8950
メール: henry@pulver.com 電話: +1-631-961-8950
Steven Lass Verizon 1201 East Arapaho Road Richardson, TX 75081, USA
スティーブン少女ベライゾン1201の東アラパホRoadリチャードソン、テキサス 75081、米国
EMail: steven.lass@verizonbusiness.com Phone: +1-972-728-2363
メール: steven.lass@verizonbusiness.com 電話: +1-972-728-2363
Christian Stredicke snom technology AG Gradestrasse, 46 D-12347 Berlin, Germany
クリスチャンのStredicke snom技術株式会社Gradestrasse、46D-12347ベルリン(ドイツ)
EMail: cs@snom.de Phone: +49(30)39833-0
メール: cs@snom.de 電話: +49(30)39833-0
Sinnreich, et al. Informational [Page 36] RFC 4504 SIP Telephony Device Requirements May 2006
Sinnreich、他 情報[36ページ]のRFC4504は電話装置要件2006年5月にちびちび飲みます。
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)によって提供されます。
Sinnreich, et al. Informational [Page 37]
Sinnreich、他 情報[37ページ]
一覧
スポンサーリンク
