RFC4458 日本語訳
4458 Session Initiation Protocol (SIP) URIs for Applications such asVoicemail and Interactive Voice Response (IVR). C. Jennings, F.Audet, J. Elwell. April 2006. (Format: TXT=41378 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Jennings
Request for Comments: 4458 Cisco Systems
Category: Informational F. Audet
Nortel Networks
J. Elwell
Siemens plc
April 2006
コメントを求めるワーキンググループC.ジョニングス要求をネットワークでつないでください: 4458年のシスコシステムズカテゴリ: 情報のF.のNetworks J.エルウェルシーメンスplc Audetノーテル2006年4月
Session Initiation Protocol (SIP) URIs for Applications
such as Voicemail and Interactive Voice Response (IVR)
VoicemailやInteractive Voice ResponseなどのApplicationsのためのセッションInitiationプロトコル(SIP)URI(IVR)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
The Session Initiation Protocol (SIP) is often used to initiate connections to applications such as voicemail or interactive voice recognition systems. This specification describes a convention for forming SIP service URIs that request particular services based on redirecting targets from such applications.
Session Initiationプロトコル(SIP)は、ボイスメールか対話的な音声認識システムなどの応用に接続を開始するのにしばしば使用されます。この仕様は、そのようなアプリケーションから目標を向け直すことに基づいて特定のサービスを要求するSIPサービスURIを形成するためにコンベンションについて説明します。
Jennings, et al. Informational [Page 1] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[1ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
Table of Contents
目次
1. Introduction ....................................................3
2. Mechanism (User Agent Server and Proxy) .........................4
2.1. Target .....................................................4
2.2. Cause ......................................................4
2.3. Retrieving Messages ........................................5
3. Interaction with Request History Information ....................5
4. Limitations of Voicemail URI ....................................6
5. Syntax ..........................................................6
6. Examples ........................................................7
6.1. Proxy Forwards Busy to Voicemail ...........................7
6.2. Endpoint Forwards Busy to Voicemail ........................9
6.3. Endpoint Forwards Busy to TDM via a Gateway ...............11
6.4. Endpoint Forwards Busy to Voicemail with History Info .....13
6.5. Zero Configuration UM System ..............................14
6.6. Call Coverage .............................................15
7. IANA Considerations ............................................15
8. Security Considerations ........................................16
8.1. Integrity Protection of Forwarding in SIP .................16
8.2. Privacy Related Issues on the Second Call Leg .............17
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
1. 序論…3 2. メカニズム(ユーザエージェントサーバとプロキシ)…4 2.1. 狙います。4 2.2. 原因…4 2.3. メッセージを検索します…5 3. 要求履歴情報との相互作用…5 4. ボイスメールURIの制限…6 5. 構文…6 6. 例…7 6.1. ボイスメールに忙しいプロキシフォワード…7 6.2. ボイスメールに忙しい終点のフォワード…9 6.3. ゲートウェイを通したTDMへの終点Forwards Busy…11 6.4. 終点のフォワードは歴史でボイスメールとインフォメーションと忙しくします…13 6.5. 構成がない、えー、システム…14 6.6. 適用範囲に電話をしてください…15 7. IANA問題…15 8. セキュリティ問題…16 8.1. 一口における、推進の保全保護…16 8.2. プライバシーは第2呼び出し脚に問題を関係づけました…17 9. 承認…18 10. 参照…18 10.1. 標準の参照…18 10.2. 有益な参照…18
Jennings, et al. Informational [Page 2] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[2ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
1. Introduction
1. 序論
Many applications such as Unified Messaging (UM) systems and Interactive Voice Recognition (IVR) systems have been developed out of traditional telephony. They can be used for storing and interacting with voice, video, faxes, email, and instant messaging services. Users often use SIP to initiate communications with these applications. When a SIP call is routed to an application, it is necessary that the application be able to obtain several bits of information from the session initiation message so that it can deliver the desired services.
伝統的な電話からUnified Messaging(UM)システムやInteractive Voice Recognition(IVR)システムなどの多くの応用を開発してあります。 声、ビデオ、ファックス、メール、およびインスタントメッセージングサービスと格納して、対話するのにそれらを使用できます。 ユーザは、これらのアプリケーションとのコミュニケーションを開始するのにしばしばSIPを使用します。 SIP呼び出しがアプリケーションに発送されるとき、アプリケーションが必要なサービスを提供できるようにセッション開始メッセージから数ビットの情報を得ることができるのが必要です。
For the purpose of this document, we will use UM as the main example, but other applications may use the mechanism defined in this document. The UM needs to know what mailbox should be used and possible reasons for the type of service desired from the UM. Many voicemail systems provide different greetings depending whether the call went to voicemail because the user was busy or because the user did not answer. All of this information can be delivered in existing SIP signaling from the call control that retargets the call to the UM, but there are no conventions for describing how the desired mailbox and the service requested are expressed. It would be possible for every vendor to make this configurable so that any site could get it to work; however, this approach is unrealistic for achieving interoperability among call control, gateway, and unified messaging systems from different vendors. This specification describes a convention for describing this mailbox and service information in the SIP URI so that vendors and operators can build interoperable systems.
このドキュメントの目的のために、私たちは主な例としてUMを使用するつもりですが、他のアプリケーションは本書では定義されたメカニズムを使用するかもしれません。 UMは、どんなメールボックスがUMから必要にサービスのタイプの中古の、そして、可能な理由であるべきであるかを知る必要があります。 多くのボイスメールシステムがユーザが忙しかったので呼び出しがボイスメールに行ったか、またはユーザが答えなかったのでよる異なった挨拶を提供します。 既存のSIPシグナリングでこの情報のすべてを呼び出しを「再-狙」う呼び出しコントロールからUMまで渡すことができますが、必要なメールボックスと要求されたサービスがどう急送されるかを説明するためのコンベンションが全くありません。 すべての業者がこれを構成可能にするのは、どんなサイトも働かせることができるくらい可能でしょう。 しかしながら、呼び出しコントロール、ゲートウェイ、およびユニファイド・メッセージングシステムの中で異なった業者から相互運用性を達成するのに、このアプローチは非現実的です。 この仕様は、業者とオペレータが共同利用できるシステムを構築できるようにSIP URIのこのメールボックスとサービス情報について説明するためにコンベンションについて説明します。
If there were no need to interoperate with Time Division Multiplexing (TDM)-based voicemail systems or to allow TDM systems to use VoIP unified messaging systems, this problem would be a little easier to solve. The problem that is introduced in the Voice over IP (VoIP) to TDM case is as follows. The SIP system needs to tell a Public Switched Telephone Network (PSTN) gateway both the subscriber's mailbox identifier (which typically looks like a phone number) and the address of the voicemail system in the TDM network (again a phone number).
Time事業部Multiplexingと共に(TDM)ベースのボイスメールシステムを共同利用するか、またはTDMシステムがVoIPユニファイド・メッセージングシステムを使用するのを許容する必要は全くなければ、この問題は少し解決しやすいでしょうに。 ボイス・オーバー IP(VoIP)でTDMケースに取り入れられる問題は以下の通りです。 SIPシステムは、加入者のメールボックス識別子(電話番号に通常似ている)とTDMのボイスメールシステムのアドレスの両方がネットワークでつなぐPublic Switched Telephone Network(PSTN)ゲートウェイ(再び電話番号)を言う必要があります。
The question has been asked why the To header cannot be used to specify which mailbox to use. One problem is that the call control proxies cannot modify the To header, and the User Agent Clients (UACs) often set it incorrectly because they do not have information about the subscribers in the domain they are trying to call. This happens because the routing of the call often translates the URI multiple times before it results in an identifier for the desired user that is valid in the namespace that the UM system understands.
質問が、どのメールボックスを使用したらよいかを指定するためになぜToヘッダーを使用できないかを行われました。 1つの問題は呼び出しコントロールプロキシがToヘッダーを変更できないということです、そして、UserエージェントClients(UACs)は彼らが呼ぼうとしているドメインに加入者の情報を持っていないので、しばしば不当にそれを設定します。 UMシステムが分かるのが名前空間で有効な必要なユーザへの識別子に結果として生じる前に呼び出しのルーティングがしばしば複数の回URIを翻訳するので、これは起こります。
Jennings, et al. Informational [Page 3] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[3ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
2. Mechanism (User Agent Server and Proxy)
2. メカニズム(ユーザエージェントサーバとプロキシ)
The mechanism works by encoding the information for the desired service in the SIP Request-URI that is sent to the UM system. Two chunks of information are encoded, the first being the target mailbox to use and the second being the SIP status code that caused this retargeting and that indicates the desired service. The userinfo and hostport parts of the Request-URI will identify the voicemail service, the target mailbox can be put in the target parameter, and the reason can be put in the cause parameter. For example, if the proxy wished to use Bob's mailbox because his phone was busy, the URI sent to the UM system could be something like:
メカニズムは、UMシステムに送られるSIP Request-URIにおける必要なサービスのための情報をコード化することによって、動作します。 情報の2つの塊がコード化されます、1日による費やす目標メールボックスとこの「再-狙」いを引き起こして、必要なサービスを示すSIPステータスコードである秒であり。 Request-URIのuserinfoとhostportの部品はボイスメールサービスを特定するでしょう、そして、目標パラメタに目標メールボックスを入れることができます、そして、原因パラメタに理由は入れることができます。 例えば、彼の電話が忙しかったのでプロキシがボブのメールボックスを使用したいと思うなら、UMシステムに送られたURIは以下に似るかもしれないでしょうに。
sip:voicemail@example.com;target=bob%40example.com;cause=486
ボブの一口: voicemail@example.com;target =%40example.com; 原因=486
2.1. Target
2.1. 目標
Target is a URI parameter that indicates the address of the retargeting entity: in the context of UM, this can be the mailbox number. For example, in the case of a voicemail system on the PSTN, the user portion will contain the phone number of the voicemail system, while the target will contain the phone number of the subscriber's mailbox.
目標は「再-狙」い実体のアドレスを示すURIパラメタです: UMの文脈では、これはメールボックス番号であるかもしれません。 例えば、PSTNの上のボイスメールシステムの場合に、ユーザ部分はボイスメールシステムの電話番号を含むでしょう、目標が加入者のメールボックスの電話番号を含むでしょうが。
2.2. Cause
2.2. 原因
Cause is a URI parameter that is used to indicate the service that the User Agent Server (UAS) receiving the message should perform. The following values for this URI parameter are defined:
原因はUserエージェントServer(UAS)がメッセージを受け取る場合働くべきであるサービスを示すのに使用されるURIパラメタです。 このURIパラメタのための以下の値は定義されます:
+---------------------------------+-------+
| Redirecting Reason | Value |
+---------------------------------+-------+
| Unknown/Not available | 404 |
| User busy | 486 |
| No reply | 408 |
| Unconditional | 302 |
| Deflection during alerting | 487 |
| Deflection immediate response | 480 |
| Mobile subscriber not reachable | 503 |
+---------------------------------+-------+
+---------------------------------+-------+ | 理由を向け直します。| 値| +---------------------------------+-------+ | 利用可能でない未知/| 404 | | ユーザ忙しいです。| 486 | | 返信がありません。| 408 | | 無条件| 302 | | 警告の間の偏向| 487 | | 偏向即時型反応| 480 | | 携帯電話の契約者、届かない。| 503 | +---------------------------------+-------+
The mapping to PSTN protocols is important both for gateways that connect the IP network to existing TDM customer's equipment, such as Private Branch Exchanges (PBXs) and voicemail systems, and for gateways that connect the IP network to the PSTN network. Integrated Services Digital Network User Part (ISUP) has signaling encodings for
既存のTDM顧客の設備にIPネットワークを接続する兵士の支店Exchanges(PBXs)やボイスメールシステムなどのゲートウェイ、およびIPネットワークをPSTNネットワークに接続するゲートウェイに、PSTNプロトコルへのマッピングは重要です。 Digital Network User Part(ISUP)にはシグナリングencodingsがある統合Services
Jennings, et al. Informational [Page 4] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[4ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
this information that can be treated as roughly equivalent for the purposes here. For this reason, this specification uses the names of Redirecting Reason values defined in ITU-T Q.732.2-5 [8]. In this specification, the Redirecting Reason Values are referred to as "Causes". It should be understood that the term "Cause" has nothing to do with PSTN "Cause values" (as per ITU-T Q.850 [9] and RFC 3398 [5]) but are instead mapped to ITU-T Q.732.2-5 Redirecting Reasons. Since ISUP interoperates with other PSTN networks, such as Q.931 [10] and QSIG [11], using well-known rules, it makes sense to use the ISUP names as the most appropriate superset. If no appropriate mapping to a cause value defined in this specification exists in a network, it would be mapped to 302 "Unconditional". Similarly, if the mapping occurs from one of the causes defined in this specification to a PSTN system that does not have an equivalent reason value, it would be mapped to that network's equivalent of "Unconditional". If a new cause parameter needs to be defined, this specification will have to be updated.
目的のためにおよそ同等であるとしてここに扱うことができるこの情報。 この理由のために、この仕様はITU-T Q.732.2-5[8]で定義されたRedirecting Reason値の名前を使用します。 この仕様では、Redirecting Reason Valuesは「原因」と呼ばれます。 ITU-TのQ.850[9]とRFCに従ってしかし、3398[5])はそうです。「原因」という用語がPSTN「原因値」と関係ないのが理解されるべきである、(代わりにITU-T Q.732.2-5 Redirecting Reasonsに写像されています。 ISUPがQ.931[10]やQSIG[11]などの他のPSTNネットワークと共に共同利用するので、大部分がスーパーセットを当てるとき、周知の規則を使用して、それはISUP名を使用に理解できます。 この仕様に基づき定義された原因値へのどんな適切なマッピングもネットワークで存在していないなら、それは302に「無条件」の状態で写像されるでしょう。 同様に、マッピングがこの仕様に基づき定義された原因の1つ〜同等な理由値を持っていないPSTNシステムまで現れるなら、それはそのネットワークの「無条件」の同等物に写像されるでしょう。 新しい原因パラメタが、定義される必要があると、この仕様をアップデートしなければならないでしょう。
The user portion of the URI SHOULD be used as the address of the voicemail system on the PSTN, while the target SHOULD be mapped to the original redirecting number on the PSTN side.
URI SHOULDのユーザ部分がボイスメールシステムのアドレスとしてPSTNで使用されて、目標SHOULDである間、PSTN側で数を向け直すオリジナルに写像されてください。
The redirection counters SHOULD be set to one unless additional information is available.
リダイレクションはSHOULDを打ち返します。追加情報が利用可能でない場合、1つに用意ができてください。
2.3. Retrieving Messages
2.3. メッセージを検索します。
The UM system MAY use the fact that the From header is the same as the URI target as a hint that the user wishes to retrieve messages.
UMシステムはFromヘッダーがユーザがメッセージを検索したがっているというヒントとしてURI目標と同じであるという事実を使用するかもしれません。
3. Interaction with Request History Information
3. 要求履歴情報との相互作用
The Request History mechanism [6] provides more information relating to multiple retargetings. It is reasonable to have systems in which both the information in this specification and the History information are included and one or both are used.
Request歴史メカニズム[6]は複数のretargetingsに関連する詳しい情報を提供します。 この仕様による情報と歴史情報の両方が含まれていて、1か両方が使用されているシステムを持っているのは妥当です。
History-Info specifies a means of providing the UAS and UAC with information about the retargeting of a request. This information includes the initial Request-URI and any retarget-to URIs. This information is placed in the History-Info header field, which, except where prevented by privacy considerations, is built up as the request progresses and, upon reaching the UAS, is returned in certain responses.
歴史インフォメーションは要求の「再-狙」いの情報をUASとUACに提供する手段を指定します。 この情報が初期のRequest-URIといずれも含んでいる、「再-目標」、-、URI。 この情報は歴史インフォメーションヘッダーフィールドに置かれます。(UASに達するとき、それは、要求が進歩をするのに従ってプライバシー問題によって防がれるのを除いて、確立されて、ある応答で返されます)。
History-Info, when deployed at relevant SIP entities, is intended to provide a comprehensive trace of retargeting for a SIP request, along with the SIP response codes that led to retargeting.
関連SIP実体で配備されると、歴史インフォメーションがSIP要求のために「再-狙」う包括的な跡を提供することを意図します、「再-狙」うのに通じたSIP応答コードと共に。
Jennings, et al. Informational [Page 5] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[5ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
History-Info can complement this specification. In particular, when a proxy inserts a URI containing the parameters defined in this specification into the Request-URI of a forwarded request, the proxy can also insert a History-Info header field entry into the forwarded request, and the URI in that entry will incorporate these parameters. Therefore, even if the Request-URI is replaced as a result of rerouting by a downstream proxy, the History-Info header field will still contain these parameters, which may be of use to the UAS. Consequently, UASes that make use of this information may find the information in the History-Info header and/or in the Request-URI, depending on the capability of the proxy to support generation of History-Info or on the behavior of downstream proxies; therefore, applications need to take this into account.
歴史インフォメーションはこの仕様の補足となることができます。 また、プロキシがこの仕様に基づき転送された要求のRequest-URIと定義されたパラメタを含むURIを挿入するとき、特に、プロキシは歴史インフォメーションヘッダーフィールド入力を転送された要求に挿入できます、そして、そのエントリーにおけるURIはこれらのパラメタを取り入れるでしょう。 したがって、それでも、川下のプロキシによるコースを変更することの結果、Request-URIを取り替えても、歴史インフォメーションヘッダーフィールドはこれらのパラメタを含むでしょう。(パラメタはUASの役に立つかもしれません)。 その結果、この情報を利用するUASesは歴史インフォメーションヘッダーRequest-URIにおける情報を見つけるかもしれません、歴史インフォメーションの世代を支持するプロキシの能力、または、川下のプロキシの振舞いによって。 したがって、アプリケーションは、これを考慮に入れる必要があります。
4. Limitations of Voicemail URI
4. ボイスメールURIの制限
This specification requires the proxy that is requesting the service to understand whether the UM system it is targeting supports the syntax defined in this specification. Today, this information is provided to the proxy by configuration. For practical purposes, this means that the approach is unlikely to work in cases in which the proxy is not configured with information about the UM system or in which the UM is not in the same administrative domain.
この仕様はそれが狙っているUMシステムがこの仕様に基づき定義された構文をサポートするかどうか理解するようサービスに要求しているプロキシを必要とします。 今日、構成でこの情報をプロキシに提供します。 実用的な目的のために、これは、アプローチがプロキシがUMシステムの周りで情報によって構成されないか、またはUMが同じ管理ドメインにない場合で働いていそうにないことを意味します。
This approach only works when the service that the call control wants applied is fairly simple. For example, it does not allow the proxy to express information like "Do not offer to connect to the target's colleague because that address has already been tried".
呼び出しコントロール必需品が適用したサービスがかなり簡単であるときにだけ、このアプローチは働いています。 例えば、それで、プロキシは同類が「既にそのアドレスを試みてあるので目標の同僚に接すると申し出ない」という情報を言い表すことができません。
The limitations discussed in this section are addressed by History- Info [6].
このセクションで議論した制限は歴史インフォメーション[6]によって記述されます。
5. Syntax
5. 構文
The ABNF[4] grammar for these parameters is shown below. The definitions of pvalue and Status-Code are defined in the ABNF in RFC 3261[1].
これらのパラメタのためのABNF[4]文法は以下に示されます。 pvalueとStatus-コードの定義はRFC 3261[1]のABNFで定義されます。
target-param = "target" EQUAL pvalue
目標-paramは「目標」EQUAL pvalueと等しいです。
cause-param = "cause" EQUAL Status-Code
原因-paramは「原因」EQUAL Status-コードと等しいです。
Note that the ABNF requires some characters to be escaped if they occur in the value of the target parameters. For example, the "@" character needs to be escaped.
彼らが目標パラメタの値で起こるならABNFが、何人かのキャラクタ逃げられるのを必要とすることに注意してください。 例えば、"@"キャラクタは、逃げられる必要があります。
Jennings, et al. Informational [Page 6] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[6ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
6. Examples
6. 例
This section provides some example use cases for the solution proposed in this document. For the purpose of this document, UM is used as the main example, but other applications may use this mechanism. The examples are intended to highlight the potential applicability of this solution and are not intended to limit its applicability.
このセクションは本書では提案された解決策のために何らかの例の使用にケースを供給します。 このドキュメントの目的のために、UMは主な例として使用されますが、他のアプリケーションはこのメカニズムを使用するかもしれません。 例は、この解決策の潜在的適用性を強調することを意図して、適用性を制限することを意図しません。
Also, the examples show just service retargeting on busy, but can easily be adapted to show other forms of retargeting.
また、ただ忙しい状態で「再-狙」いを修理しますが、容易にショーを適合させることができる例は他のフォームの「再-狙」いを示しています。
In several of the examples, the URIs are broken across more than one line. This was only done for formatting and is not a valid SIP message. Some of the characters in the URIs are not correctly escaped to improve readability. The examples are all shown using sip: with UDP transport, for readability. It should be understood that using sips: with TLS transport is preferable.
いくつかの例では、URIは1つ以上の線の向こう側に壊されます。 これは、形式のためにしただけであり、有効なSIPメッセージではありません。 URIにおけるキャラクタの中には、読み易さを改良するために正しく逃げられない人もいます。 例は一口を使用するのがすべて示されます: 読み易さのためのUDP輸送で。 使用がちびちび飲まれるのが理解されるべきです: TLSがあるので、輸送は望ましいです。
6.1. Proxy Forwards Busy to Voicemail
6.1. ボイスメールに忙しいプロキシフォワード
In this example, Alice calls Bob. Bob's proxy determines that Bob is busy, and the proxy forwards the call to Bob's voicemail. Alice's phone is at 192.0.2.1, while Bob's phone is at 192.0.2.2. The important thing to note is the URI in message F7.
この例では、アリスは、ボブに電話をします。 ボブのプロキシは、ボブが忙しいと決心しています、そして、プロキシはボブのボイスメールに呼び出しを送ります。 ボブである間、電話は192.0でそうです。アリスの電話が192.0である、.2 .1、.2 .2。 注意する重要なことはメッセージF7のURIです。
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 486 Busy F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *
アリスProxyボブボイスメール| | | | | F1を招いてください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| F2を招待してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(100トライ) F3| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 486 忙しいF4| | | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK F5| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(181呼び出しはBeing Forwardedです) F6| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| F7を招待してください。| | |--------------------------------->| * *が示されなかった流れの残り
Jennings, et al. Informational [Page 7] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[7ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
F1: INVITE 192.0.2.1 -> proxy.example.com
F1: INVITE192.0.2、.1->proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE一口: + 15555551002@example.com;user は電話SIP/2.0Viaと等しいです: 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
F2: INVITE proxy.example.com -> 192.0.2.2
F2: INVITE proxy.example.com->192.0.2.2
INVITE sip:+15555551002@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE一口: + 15555551002@192.0.2.2 SIP/2.0Via: 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-1と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
F4: 486 192.0.2.2 -> proxy.example.com
F4: 486 192.0 .2、.2->proxy.example.com
SIP/2.0 486 Busy Here
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Content-Length: 0
ここで以下を通って/2.0 486忙しい状態でちびちび飲んでください。 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-1と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user =電話; =09xde23d80 Call IDにタグ付けをしてください: c3x842276298220188511 CSeq: 1 コンテンツの長さを招待してください: 0
Jennings, et al. Informational [Page 8] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[8ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
F7: INVITE proxy.example.com -> um.example.com
F7: INVITE proxy.example.com->um.example.com
INVITE sip:voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE一口: 目標=一口: voicemail@example.com; \の+15555551002%の40example.com; ユーザ=電話; \原因は486SIP/2.0Viaと等しいです: 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-2と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
6.2. Endpoint Forwards Busy to Voicemail
6.2. ボイスメールに忙しい終点のフォワード
In this example, Alice calls Bob. Bob is busy, but forwards the session directly to his voicemail. Alice's phone is at 192.0.2.1, while Bob's phone is at 192.0.2.2. The important thing to note is the URI in the Contact in message F3.
この例では、アリスは、ボブに電話をします。 ボブは、忙しいのですが、直接彼のボイスメールにセッションを送ります。 ボブである間、電話は192.0でそうです。アリスの電話が192.0である、.2 .1、.2 .2。 注意する重要なことはメッセージF3のContactのURIです。
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
| | 302 Moved F3 | |
| 302 Moved F4 |<-------------| |
|<---------------| | |
| ACK F5 | | |
|--------------->| ACK F6 | |
| |------------->| |
| INVITE F7 |
|-------------------------------------------------->|
* Rest of flow not shown *
アリスProxyボブボイスメール| | | | | F1を招いてください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| F2を招待してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 302 動くF3| | | 302 動くF4| <、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK F5| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| ACK F6| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| F7を招待してください。| |-------------------------------------------------->| * *が示されなかった流れの残り
Jennings, et al. Informational [Page 9] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[9ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
F1: INVITE 192.0.2.1 -> proxy.example.com
F1: INVITE192.0.2、.1->proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE一口: + 15555551002@example.com;user は電話SIP/2.0Viaと等しいです: 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
F2: INVITE proxy.example.com -> 192.0.2.2
F2: INVITE proxy.example.com->192.0.2.2
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE一口: line1@192.0.2.2 SIP/2.0Via: 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-1と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
F3: 302 192.0.2.2 -> proxy.example.com
F3: 302 192.0 .2、.2->proxy.example.com
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486;>
Content-Length: 0
一口/2.0 302は以下を通って一時動きました。 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-1と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user =電話; =09xde23d80 Call IDにタグ付けをしてください: c3x842276298220188511 CSeq: 1 接触を招いてください: <一口: 目標=一口: voicemail@example.com; \の+15555551002%の40example.com; ユーザは電話と等しいです; \原因=486>コンテンツの長さ: 0
Jennings, et al. Informational [Page 10] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[10ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
F7: INVITE proxy.example.com -> um.example.com
F7: INVITE proxy.example.com->um.example.com
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITEはちびちび飲みます: 目標=一口: voicemail@example.com; \の+15555551002%の40example.com; ユーザ=電話; \原因は486SIP/2.0Viaと等しいです: 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-2と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
6.3. Endpoint Forwards Busy to TDM via a Gateway
6.3. ゲートウェイを通したTDMへの終点Forwards Busy
In this example, the voicemail is reached via a gateway to a TDM network. Bob's number is +1 555 555-1002, while voicemail's number on the TDM network is +1-555-555-2000.
この例では、ボイスメールにTDMネットワークへのゲートウェイを通して達しています。 ボブの番号は+1 555 555-1002ですが、TDMネットワークのボイスメールの番号は+1-555-555-2000です。
The call flow is the same as in Section 6.2 except for the Contact URI in F4 and the Request URI in F7.
呼び出し流動はF4のContact URIとF7のRequest URI以外のセクション6.2と同じです。
Alice Proxy Bob voicemail
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| |------------->| |
|(100 Trying) F3 | | |
|<---------------| 302 Moved F4 | |
| |<-------------| |
| | ACK F5 | |
| |------------->| |
|(181 Call is Being Forwarded) F6 |
|<---------------| | INVITE F7 |
| |--------------------------------->|
* Rest of flow not shown *
アリスProxyボブボイスメール| | | | | F1を招いてください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| F2を招待してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(100トライ) F3| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 302 動くF4| | | | <、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK F5| | | |、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |(181呼び出しはBeing Forwardedです) F6| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| F7を招待してください。| | |--------------------------------->| * *が示されなかった流れの残り
Jennings, et al. Informational [Page 11] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[11ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
F4: 486 192.0.2.2 -> proxy.example.com
F4: 486 192.0 .2、.2->proxy.example.com
SIP/2.0 302 Moved temporarily
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone;tag=09xde23d80
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Contact: <sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486>
Content-Length: 0
SIP/2.0 302Moved、一時的である、Via: 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-1と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user =電話; =09xde23d80 Call IDにタグ付けをしてください: c3x842276298220188511 CSeq: 1 接触を招いてください: <一口: + 15555552000@example.com;user =電話; \目標=tel:+15555551002; 原因は486>のContent-長さと等しいです: 0
F7: INVITE proxy.example.com -> gw.example.com
F7: INVITE proxy.example.com->gw.example.com
INVITE sip:+15555552000@example.com;user=phone;\
target=tel:+15555551002;cause=486\
SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1;transport=tcp>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE一口: + 15555552000@example.com;user =電話; \目標=tel:+15555551002; 原因は486円のSIP/2.0Viaと等しいです: 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-2と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1;transport がtcpと等しい、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
Jennings, et al. Informational [Page 12] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[12ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
6.4. Endpoint Forwards Busy to Voicemail with History Info
6.4. 歴史インフォメーションでボイスメールに忙しい終点のフォワード
This example illustrates how History Info works in conjunction with service retargeting. The scenario is the same as Section 6.1.
この例は歴史Infoがどうサービスの「再-狙」いに関連して働いているかを例証します。 シナリオはセクション6.1と同じです。
F1: INVITE 192.0.2.1 -> proxy.example.com
F1: INVITE192.0.2、.1->proxy.example.com
INVITE sip:+15555551002@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE一口: + 15555551002@example.com;user は電話SIP/2.0Viaと等しいです: 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1 、gt;、歴史インフォメーション: <一口: + 15555551002@example.com;user =電話、gt;、; =1コンテントタイプに索引をつけてください: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
F2: INVITE proxy.example.com -> 192.0.2.2
F2: INVITE proxy.example.com->192.0.2.2
INVITE sip:line1@192.0.2.2 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4>;index=1.1
INVITE一口: line1@192.0.2.2 SIP/2.0Via: 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-1と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1 、gt;、歴史インフォメーション: <一口: + 15555551002@example.com;user =電話、gt;、;、<一口: =1、 line1@192.0.2.4 に索引をつけてください gt;、;=1.1に索引をつけてください
Content-Type: application/sdp
Content-Length: *Body length goes here*
コンテントタイプ: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
Jennings, et al. Informational [Page 13] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[13ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
F7: INVITE proxy.example.com -> um.example.com
F7: INVITE proxy.example.com->um.example.com
INVITE sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486 SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
History-Info: <sip:+15555551002@example.com;user=phone >;index=1,
<sip:line1@192.0.2.4?Reason=SIP%3Bcause%3D302;\
text="Moved Temporarily">;index=1.1
<sip: voicemail@example.com;\
target=sip:+15555551002%40example.com;user=phone;\
cause=486>;index=2
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITEはちびちび飲みます: 目標=一口: voicemail@example.com; \の+15555551002%の40example.com; ユーザ=電話; \原因は486SIP/2.0Viaと等しいです: 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-2と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1 、gt;、歴史インフォメーション: <一口: + 15555551002@example.com;user =電話、gt;、; インデックス=1、一口<一口: line1@192.0.2.4?Reason =%3Bcause%3D302;\テキストが等しい、「「>; =1.1<一口に索引をつけてください」一時動いて、 目標=一口: voicemail@example.com; \の+15555551002%の40example.com; ユーザ=電話; \原因は486>と等しいです; インデックスは2Contactと等しいです: <一口: alice@192.0.2.1 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
6.5. Zero Configuration UM System
6.5. 構成がない、えー、システム
In this example, the UM system has no configuration information specific to any user. The proxy is configured to pass a URI that provides the prompt to play and an email address in the user portion of the URI to which the recorded message is to be sent.
この例では、UMシステムで、設定情報は全くどんなユーザにとっても特定になりません。 プロキシは、送られる録音メッセージがことであるURIのユーザ部分でプレーするためにプロンプトを提供するURIとEメールアドレスを通過するために構成されます。
The call flow is the same as in Section 6.1, except that the URI in F7 changes to specify the user part as Bob's email address, and the Netann [7] URI play parameter specifies where the greeting to play can be fetched from.
呼び出し流動はセクション6.1と同じです、F7のURIがボブのEメールアドレスとしてユーザ部分を指定するために変化して、Netann[7]URIプレーパラメタが、どこからプレーする挨拶をとって来ることができるかを指定するのを除いて。
Jennings, et al. Informational [Page 14] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[14ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
F7: INVITE proxy.example.com -> voicemail.example.com
F7: INVITE proxy.example.com->voicemail.example.com
INVITE sip:voicemail@example.com;target=mailto:bob%40example.com;\
cause=486;play=http://www.example.com/bob/busy.wav SIP/2.0
Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-2
Via: SIP/2.0/TCP 192.0.2.1:5060;branch=z9hG4bK-74bf9
From: Alice <sip:+15555551001@example.com;user=phone>;tag=9fxced76sl
To: sip:+15555551002@example.com;user=phone
Call-ID: c3x842276298220188511
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:alice@192.0.2.1>
Content-Type: application/sdp
Content-Length: *Body length goes here*
INVITE一口: voicemail@example.com;target =mailto: ボブの%40example.com; \原因=486; = http://www.example.com/bob/busy.wav SIP/2.0Viaをプレーしてください: 一口/2.0/TCP192.0.2.4: 5060; ブランチは以下を通ってz9hG4bK-ik80k7g-2と等しいです。 一口/2.0/TCP192.0.2.1: 5060;ブランチ=z9hG4bK-74bf9From: アリス<一口: + 15555551001@example.com;user =電話、gt;、;=9fxced76sl To:にタグ付けをしてください 一口: + 15555551002@example.com;user は電話Call-IDと等しいです: c3x842276298220188511 CSeq: 1 前方へマックスを招待してください: 70 接触: <一口: alice@192.0.2.1 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: *ボディーの長さがここに行く、*
* SDP goes here*
* SDPがここに行く、*
In addition, if the proxy wished to indicate a Voice XML (VXML) script that the UM should execute, it could add a parameter to the URI in the above message that looked like:
さらに、プロキシがUMが作成するはずであるVoice XML(VXML)スクリプトを示したいなら、似ていた上記のメッセージのURIにパラメタを加えるかもしれないでしょうに:
voicexml=http://www.example.com/bob/busy.vxml
voicexmlは http://www.example.com/bob/busy.vxml と等しいです。
6.6. Call Coverage
6.6. 適用範囲に電話をしてください。
In a Call Coverage example, a user on the PSTN calls an 800 number. The gateway sends this to the proxy, which recognizes that the helpdesk is the target. Alice and Bob are staffing the help desk and are tried sequentially, but neither answers, so the call is forwarded to the helpdesk's voicemail.
Call Coverageの例では、PSTNの上のユーザはフリーダイヤルを呼びます。 ゲートウェイはこれをプロキシに送ります。(プロキシはヘルプデスクが目標であると認めます)。 アリスとボブをヘルプデスクを配置していて、連続して裁きますが、どちらも答えないので、ヘルプデスクのボイスメールに呼び出しを送ります。
The details of this flow are trivial and not shown. The key item in this example is that the INVITE to Alice and Bob looks as follows:
この流れの詳細は、些細で示されません。 この例の重要品目はアリスとボブへのINVITEが以下の通りに見えるということです:
INVITE sip:voicemail@example.com;target=helpdesk%40example.com;\
cause=302 SIP/2.0
ヘルプデスクINVITE一口: voicemail@example.com;target =%40example.com; \原因は302SIP/2.0と等しいです。
7. IANA Considerations
7. IANA問題
This specification adds two new values to the IANA registration in the "SIP/SIPS URI Parameters" registry as defined in [3].
この仕様は[3]で定義されるように「一口/一口URIパラメタ」登録でのIANA登録に2つの新しい値を加えます。
Parameter Name Predefined Values Reference
____________________________________________
target No [RFC4458]
cause Yes [RFC4458]
事前に定義されたパラメタ名は参照を評価します。____________________________________________ [RFC4458]原因を全く狙わないでください、はい。[RFC4458]
Jennings, et al. Informational [Page 15] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[15ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
8. Security Considerations
8. セキュリティ問題
This document discusses transactions involving at least three parties, which increases the complexity of the privacy issues.
このドキュメントは少なくとも3回のパーティーにかかわる取引について議論します(プライバシーの問題の複雑さを増加させます)。
The new URI parameters defined in this document are generally sent from a Proxy or call control system to a Unified Messaging (UM) system or to a gateway to the PSTN and then to a voicemail system. These new parameters tell the UM what service the proxy wishes to have performed. Just as any message sent from the proxy to the UM needs to be integrity protected, these messages need to be integrity protected to stop attackers from, for example, causing a voicemail meant for a company's CEO to go to an attacker's mailbox. RFC 3261 provides a TLS mechanism suitable for performing this integrity protection.
一般に、Proxyか呼び出し制御システムからUnified Messaging(UM)システムまでPSTNへのゲートウェイと、そして、そして、ボイスメールシステムに本書では定義された新しいURIパラメタを送ります。 これらの新しいパラメタは、プロキシがどんなサービスを実行したがっていたかをUMに言います。 ちょうどプロキシから保全であるUMの必要性に送られたどんなメッセージも保護されたように、これらのメッセージは、例えば、攻撃者が会社の最高経営責任者が攻撃者のメールボックスに行くことになっていたボイスメールを引き起こすのを止めるために保護された保全である必要があります。 RFC3261はこの保全保護を実行するのに適当なTLSメカニズムを提供します。
The signaling from the Proxy to the UM or gateway will reveal who is calling whom and possibly some information about a user's presence based on whether the call was answered or sent to voicemail. This information can be protected by encrypting the SIP traffic between the Proxy and UM or gateway. Again, RFC 3261 contains mechanisms for accomplishing this using TLS.
UMかProxyからゲートウェイまでのシグナリングはだれが呼び出しがボイスメールに答えられたか、または送られたかに基づくユーザの存在のだれに電話をするか、そして、ことによると何らかの情報であるかを明らかにするでしょう。 ProxyとUMかゲートウェイの間のSIP交通をコード化することによって、この情報を保護できます。 一方、RFC3261はTLSを使用することでこれを達成するためのメカニズムを含んでいます。
Implementations should implement and use TLS.
実現は、TLSを実行して、使用するべきです。
8.1. Integrity Protection of Forwarding in SIP
8.1. 一口における、推進の保全保護
The forwarding of a call in SIP brings up a very strange trust issue. Consider the normal case -- A calls B and the call gets forwarded to C by a network element in B's domain, and then C answers the call. A has called B but ended up talking to C. This scenario may be hard to separate from a man-in-the-middle attack.
SIPでの呼び出しの推進は非常に奇妙な信用問題を持って来ます。 正常なケースを考えてください--ビーズドメインでネットワーク要素で電話Bと電話をCに送ります、そして、次に、Cは呼び出しに答えます。 Aは、C.とBと呼びますが、結局、話しました。Thisシナリオは介入者攻撃と切り離すのが困難であるかもしれません。
There are two possible solutions. One is that B sends back information to A saying don't call me, call C, and signs it as B. The problem is that this solution involves revealing that B has forwarded to C, which B often may not want to do. For example, B may be a work phone that has been forwarded to a mobile or home phone. The user does not want to reveal their mobile or home phone number but, even more importantly, does not want to reveal that they are not in the office.
2つの可能な解決策があります。 1つはBがこの解決策が明らかにすることを伴うB. 問題がそれですが、私、呼び出しC、およびサインに電話をしないように言うAへのBがBがしばしばしたがっているかもしれないというわけではないCに転送した情報を返送するということです。 例えば、Bは可動であるか家の電話に送られた仕事電話であるかもしれません。 ユーザは、それらの可動であるか家の電話番号を明らかにしたくはありませんが、彼らがオフィスにいないのをさらに重要に明らかにしたがっていません。
The other possible solution is that A needs to trust B only to forward to a trusted identity. This requires a hop-by-hop transitive trust such that each hop will only send to a trusted next hop and each hop will only do things that the user at that hop desired. This
もう片方の可能な解決策はAが、進めるためには唯一のBを信じられたアイデンティティに任せる必要があるということです。 これはホップごとの次のホップと各ホップがするだけである各ホップがaに発信するだけであるようなものがそのホップのユーザが望んでいた事態を信じた他動な信用を必要とします。 これ
Jennings, et al. Informational [Page 16] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[16ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
solution is enforced in SIP using the SIPS URI and TLS-based hop-by-hop security. It protects from an off-axis attack, but if one of the hops is not trustworthy, the call may be diverted to an attacker.
解決策は、SIPでSIPS URIとホップごとのTLSベースのセキュリティを使用することで励行されます。 それはオフ軸の攻撃から保護されますが、ホップの1つが信頼できないなら、呼び出しは攻撃者に紛らされるかもしれません。
Any redirection of a call to an attacker's mailbox is serious. It is trivial for an attacker to make its mailbox seem very much like the real mailbox and forward the messages to the real mailbox so that the fact that the messages have been intercepted or even tampered with escapes detection. Approaches such as the SIPS URL and the History-Info[6] can help protect against these attacks.
攻撃者のメールボックスへの呼び出しのどんなリダイレクションも重大です。 攻撃者がメールボックスに本当のメールボックスとフォワードのように本当のメールボックスにメッセージを思えさせるのが、些細であるので、メッセージを傍受されるか、またはいじりさえするという事実は見つからずに済みます。 SIPS URLや歴史インフォメーション[6]などのアプローチは、これらの攻撃から守るのを助けることができます。
8.2. Privacy Related Issues on the Second Call Leg
8.2. プライバシーは第2呼び出し脚に問題を関係づけました。
In the case where A calls B and gets redirected to C, occasionally people suggest that there is a requirement for the call leg from B to C to be anonymous. The SIP case is not the PSTN, and there is no call leg from B to C; instead, there is a VoIP session between A and C. If A has put a To header field value containing B in the initial invite message, unless something special is done about it, C would see that To header field value. If the person who answers phone C says "I think you dialed the wrong number; who were you trying to reach?", A will probably specify B.
AがBと呼んで、Cに向け直される場合では、時折、人々は、BからCまでの呼び出し脚が匿名であるという要件があることを提案します。 SIPケースはPSTNではありません、そして、BからCまで呼び出し脚が全くありません。 代わりに、初期がAとC.で間、If AがBを含むToヘッダーフィールド価値を置いたメッセージを招待するVoIPセッションがあります、それに関して何か特別なことをしない場合Cは、そのToヘッダーが値をさばくのを見るでしょう。 電話Cに出る人が言うなら、「私は、あなたが電話をかけ違えたと思います」。 Aは、たぶん「達しようとしながら、あなたはだれでしたか?」と指定して、Bを指定してください。
If A does not want C to see that the call was to B, A needs a special relationship with the forwarding Proxy to induce it not to reveal that information. The call should go through an anonymization service that provides session or user level privacy (as described in RFC 3323 [2]) service before going to C. It is not hard to figure out how to meet this requirement, but it is unclear why anyone would want this service.
Aが、Cに、Bには呼び出しがあったのを見て欲しくないなら、Aは、その情報を明らかにしないのを引き起こすために推進Proxyとの特別な関係を必要とします。 呼び出しはセッションを提供するanonymizationサービスかユーザレベルプライバシーに直面するべきです。([2]) RFC3323で説明されるように、C.Itに行く前のサービスはこの必要条件を満たす方法を理解しにくくはありませんが、だれかなぜこのサービスが欲しいかは、不明瞭です。
The scenario in which B wants to make sure that C does not see that the call was to B is easier to deal with but a bit weird. The usual argument is that Bill wants to forward his phone to Monica but does not want Monica to find out his phone number. It is hard to imagine that Monica would want to accept all Bill's calls without knowing how to call Bill to complain. The only person Monica will be able to complain to is Hillary, when she tries to call Bill. Several popular web portals will send SMS alert messages about things like stock prices and weather to mobile phone users today. Some of these contain no information about the account on the web portal that initiated them, making it nearly impossible for the mobile phone owner to stop them. This anonymous message forwarding has turned out to be a really bad idea even where no malice is present. Clearly some people are fairly dubious about the need for this, but never mind: let's look at how it is solved.
Bが、Cが、Bには呼び出しがあったのを見ないのを確実にしたがっているシナリオは、対処するのが、より簡単ですが、少し奇妙です。 ビルが彼の電話をモニカに送りたがっているということですが、普通の議論は、モニカが彼の電話番号を突き止める必要がありません。 モニカが不平を言うためにビルに電話をする方法を知らないでビルの呼び出しを受け入れたがっていると想像しにくいです。 彼女が、ビルに電話をしようとするとき、モニカが不平を言うことができる唯一の人がヒラリーです。 いくつかのポピュラーなウェブ入り口が今日、携帯電話ユーザへの株価と天気のようなものに関する警告メッセージをSMSに送るでしょう。 これらの或るものはそれらを開始したウェブ入り口のアカウントの情報を全く含んでいません、携帯電話所有者がそれらを止めるのをほとんど不可能にして。 この匿名のメッセージ推進はどんな悪意もどこに存在してさえいないかという本当に悪い考えであると判明しました。 明確に何人かの人々がこの必要性に関してかなり疑わしいのですが、決して気にしないでください: それがどう解決されているかを見ましょう。
Jennings, et al. Informational [Page 17] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[17ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
In the general case, the proxy needs to route the call through an anonymization service and everything will be cleaned up. Any anonymization service that performs the "Privacy: Header" Service in RFC 3323 [2] must remove the cause and target URI parameters from the URI. Privacy of the parameters, when they form part of a URI within the History-Info header, is covered in History-Info [6].
一般的な場合では、プロキシは、anonymizationサービスで呼び出しを発送する必要があります、そして、すべてがきれいにされるでしょう。 働くどんなanonymizationサービス、も「プライバシー:」 RFC3323[2]の「ヘッダー」ServiceはURIから原因と目標URIパラメタを取り除かなければなりません。 歴史インフォメーションヘッダーの中にURIの一部を形成すると、パラメタのプライバシーは歴史インフォメーション[6]でカバーされています。
This specification does not discuss the security considerations of mapping to a PSTN Gateway. Security implications of mapping to ISUP, for example, are discussed in RFC 3398 [5].
この仕様はゲートウェイをPSTNに写像するセキュリティ問題について議論しません。 RFC3398[5]で例えば、ISUPへのマッピングのセキュリティ含意について議論します。
9. Acknowledgements
9. 承認
Many thanks to Mary Barnes, Steve Levy, Dean Willis, Allison Mankin, Martin Dolly, Paul Kyzivat, Erick Sasaki, Lyndsay Campbell, Keith Drage, Miguel Garcia, Sebastien Garcin, Roland Jesske, Takumi Ohba, and Rohan Mahy.
メアリ・バーンズ、スティーブLevy、ディーン・ウィリス、アリソン・マンキン、マーチン・ドリー、ポールKyzivat、エーリック・佐々木、Lyndsayキャンベル、キースDrage、ミゲル・ガルシア、セバスチアンGarcin、ローランドJesske、Takumiオオバ、およびRohanマーイをありがとうございます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[2] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
[3] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
December 2004.
[3] キャマリロ、G.、「セッション開始プロトコル(一口)のためのISOCの機関の一つで(IANA)Uniform Resource Identifier(URI)パラメタ登録」、BCP99、RFC3969(2004年12月)。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[4] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
10.2. Informative References
10.2. 有益な参照
[5] Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated
Services Digital Network (ISDN) User Part (ISUP) to Session
Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.
[5] キャマリロ(G.、ローチ、A.、ピーターソン、J.、およびL.オング)は、「サービスディジタル通信網(ISDN)ユーザ部分(ISUP)をセッション開始プロトコル(一口)マッピングと統合しました」、RFC3398、2002年12月。
[6] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244,
November 2005.
[6] バーンズ、M.、「要求履歴情報のためのセッション開始プロトコル(一口)への拡大」、RFC4244、2005年11月。
Jennings, et al. Informational [Page 18] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[18ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
[7] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media
Services with SIP", RFC 4240, December 2005.
2005年12月の[7] バーガーとE.とヴァンダイク、J.とA.スピッツァー、「一口との基本的なネットワークメディアサービス」RFC4240。
[8] "Stage 3 description for call offering supplementary services
using signalling system No. 7: Call diversion services", ITU-T
Recommendation Q.732.2-5, December 1999.
[8] 「合図システムNo.7を使用することで補っているサービスを提供する呼び出しのための3記述を上演してください」 「呼び出し転換サービス」、ITU-T Recommendation Q.732.2-5、1999年12月。
[9] "Usage of cause and location in the Digital Subscriber
Signalling System No. 1 and the Signalling System No. 7 ISDN
User Part", ITU-T Recommendation Q.850, May 1998.
[9] 「Digital Subscriber Signalling System No.1とSignalling System No.7ISDN User Partの原因と位置の用法」、ITU-T Recommendation Q.850(1998年5月)。
[10] "ISDN user-network interface layer 3 specification for basic
call control", ITU-T Recommendation Q.931, May 1998.
[10] 「基本的な呼び出しコントロールのためのISDNユーザネットワーク・インターフェース層の3仕様」、ITU-T Recommendation Q.931、1998年5月。
[11] "Information technology - Telecommunications and information
exchange between systems - Private Integrated Services Network
- Circuit mode bearer services - Inter-exchange signalling
procedures and protocol", ISO/IEC 11572, March 2000.
[11] 「情報技術--システムの間のテレコミュニケーションと情報交換--個人的なIntegrated Services Network(サーキットモード運搬人サービス)は相互合図手順を交換して、議定書を作ります」、ISO/IEC11572、2000年3月。
Jennings, et al. Informational [Page 19] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[19ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
Authors' Addresses
作者のアドレス
Cullen Jennings Cisco Systems 170 West Tasman Drive Mailstop SJC-21/2 San Jose, CA 95134 USA
西タスマン・ドライブMailstop SJC-21/2カレンジョニングスシスコシステムズ170カリフォルニア95134サンノゼ(米国)
Phone: +1 408 421-9990 EMail: fluffy@cisco.com
以下に電話をしてください。 +1 408 421-9990 メールしてください: fluffy@cisco.com
Francois Audet Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US
フランソアAudetノーテルは米国でParkwayサンタクララ、4655Great Americaカリフォルニア 95054をネットワークでつなぎます。
Phone: +1 408 495 3756 EMail: audet@nortel.com
以下に電話をしてください。 +1 3756年の408 495メール: audet@nortel.com
John Elwell Siemens plc Technology Drive Beeston, Nottingham NG9 1LA UK
ジョンエルウェルシーメンスplc Technology Driveビーストン、ノッティンガムNG9 1LA UK
EMail: john.elwell@siemens.com
メール: john.elwell@siemens.com
Jennings, et al. Informational [Page 20] RFC 4458 SIP Voicemail URI April 2006
ジョニングス、他 情報[20ページ]のRFC4458はボイスメールURI2006年4月にちびちび飲みます。
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)によって提供されます。
Jennings, et al. Informational [Page 21]
ジョニングス、他 情報[21ページ]
一覧
スポンサーリンク
