[要約] RFC 7462は、SIPのAlert-InfoヘッダーフィールドのためのURNを定義しています。このRFCの目的は、SIPセッションのアラート情報を一意に識別するための標準化を提供することです。
Internet Engineering Task Force (IETF) L. Liess, Ed.
Request for Comments: 7462 R. Jesske
Updates: 3261 Deutsche Telekom AG
Category: Standards Track A. Johnston
ISSN: 2070-1721 Avaya
D. Worley
Ariadne
P. Kyzivat
Huawei
March 2015
URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）のAlert-InfoヘッダーフィールドのURN
Abstract
概要
The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the User Agent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification.
セッション開始プロトコル（SIP）は、ユーザーがアラートを受けたときにユーザーエージェント（UA）がアラート信号（たとえば、呼び出し音または呼び出し音）として使用する特定のレンダリングへの参照を提供する機能をサポートします。これは、Alert-Infoヘッダーフィールドを使用して行われます。ただし、参照（通常はURL）は、特定のレンダリングプロパティを持つ特定のネットワークリソースのみをアドレス指定します。現在、特定のレンダリングに関連付けられていない場合、アラート状況のセマンティクスまたはアラート信号の特性を記述するための標準識別子はサポートされていません。これらの制限を克服し、新しいアプリケーションをサポートするために、Alert-Infoヘッダーフィールド（および同様の要件を持つ状況）で使用するための新しいURNファミリーがこの仕様で定義されています。
This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values.
このドキュメントは、セッション開始プロトコル（SIP）を定義するRFC 3261を規範的に更新します。 INVITEに対する100以外の暫定応答での使用をさらに許可することにより、RFC 3261で定義されたAlert-Infoヘッダーフィールドの使用法を変更します。このドキュメントでは、プロキシがAlert-Infoヘッダーフィールドを追加または削除したり、Alert-Infoヘッダーフィールド値を追加または削除したりすることもできます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7462.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7462で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。この素材の一部の著作権を管理する人は、IETFトラストにそのような素材の変更を許可する権利を付与していない可能性がありますIETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得しない限り、このドキュメントはIETF標準プロセス外で変更できません。また、その派生物は、IETF標準プロセス外で作成できません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction ....................................................5
2. Requirements Language ...........................................7
3. Terminology .....................................................7
4. Updates to RFC 3261 .............................................7
4.1. Allow Alert-Info in Provisional Responses ..................7
4.2. Proxies May Alter Alert-Info Header Fields .................8
5. Requirements ....................................................8
6. Use Cases ......................................................10
6.1. PBX Ring Tones ............................................10
6.1.1. Normal .............................................10
6.1.2. External ...........................................10
6.1.3. Internal ...........................................11
6.1.4. Priority ...........................................11
6.1.5. Short ..............................................11
6.1.6. Delayed ............................................11
6.2. Service Tones .............................................11
6.2.1. Call Waiting .......................................11
6.2.2. Forward ............................................12
6.2.3. Transfer Recall ....................................12
6.2.4. Auto Callback ......................................12
6.2.5. Hold Recall ........................................12
6.3. Country-Specific Ringback Tone Indications for the
Public Switched ...........................................12
7. URN Specification for the "alert" Namespace Identifier .........12
8. "alert" URN Values .............................................18
8.1. <alert-category> Values ...................................18
8.2. <alert-indication> Values .................................18
8.2.1. <alert-indication> Values for the
<alert-category> "service" .........................19
8.2.2. <alert-indication> Values for the
<alert-category> "source" ..........................19
8.2.3. <alert-indication> Values for the
<alert-category> "priority" ........................19
8.2.4. <alert-Indication> Values for the
<alert-category> "duration" ........................20
8.2.5. <alert-indication> Values for the
<alert-category> "delay" ...........................20
8.2.6. <alert-indication> Values for the
<alert-category> "locale" ..........................20
9. IANA Considerations ............................................20
9.1. URN Namespace Identifier "alert" ..........................20
9.2. 'Alert URN Identifiers' Registry ..........................20
9.2.1. Initial IANA Registration ..........................21
9.2.1.1. The "service" <alert-category> and
<alert-identifier>s .......................22
9.2.1.2. The "source" <alert-category> and
<alert-identifier>s .......................23
9.2.1.3. The "priority" <alert-category>
and <alert-identifier>s ...................24
9.2.1.4. The "duration" <alert-category>
and <alert-identifier>s ...................24
9.2.1.5. The "delay" <alert-category> and
<alert-identifier>s .......................25
9.2.1.6. The "locale" <alert-category> and
<alert-identifier>s .......................25
9.3. 'Alert URN Providers' Registry ............................26
10. Extension Rules ...............................................26
10.1. General Extension Rules ..................................26
10.2. Private Extension Rules ..................................27
10.3. Examples .................................................28
10.3.1. Subsetting an Existing URN ........................28
10.3.2. A New Value within an <alert-category> ............29
10.3.3. A New <alert-category> ............................29
10.3.4. Subsetting a Private Extension URN ................29
11. Combinations of "alert" URNs ..................................30
11.1. Priority Rules ...........................................30
11.2. Multi-mode Signals .......................................31
12. Non-normative Algorithm for Handling Combinations of URNs .....32
12.1. Algorithm Description ....................................32
12.2. Examples of How the Algorithm Works ......................34
12.2.1. Example 1 .........................................34
12.2.2. Example 2 .........................................35
12.2.3. Example 3 .........................................37
12.2.4. Example 4 .........................................38
12.2.5. Example 5 .........................................39
13. User Agent Behaviour ..........................................40
14. Proxy Behaviour ...............................................41
15. Internationalization Considerations ...........................42
16. Security Considerations .......................................42
17. References ....................................................43
17.1. Normative References .....................................43
17.2. Informative References ...................................44
Acknowledgements ..................................................45
Authors' Addresses ................................................46
The Session Initiation Protocol (SIP) [RFC3261] includes a means to suggest to a User Agent (UA) a particular ringback tone or ring tone to be used during session establishment. In [RFC3261], this is done by including a URI, in the Alert-Info header field, that specifies a reference to the tone. The URI is most commonly the HTTP URL to an audio file. On the receipt of the Alert-Info header field, the UA may fetch the referenced ringback tone or ring tone and play it to the user.
セッション開始プロトコル（SIP）[RFC3261]には、セッションの確立中に使用される特定のリングバックトーンまたはリングトーンをユーザーエージェント（UA）に提案する手段が含まれています。 [RFC3261]では、これは、アラートへの参照を指定するURIをAlert-Infoヘッダーフィールドに含めることで行われます。 URIは、最も一般的には、オーディオファイルへのHTTP URLです。 UAはAlert-Infoヘッダーフィールドを受信すると、参照されている呼び出し音または呼び出し音をフェッチしてユーザーに再生します。
This mechanism hinders interoperability when there is no common understanding of the meaning of the referenced tone, which might be country- or vendor-specific. It can lead to problems for the user trying to interpret the tone and for the UA wanting to substitute its own tone (e.g., in accordance with user preferences) or provide an alternative alerting mode (e.g., for deaf and hard-of-hearing users). If the caller and the callee are from different countries, their understanding of the tones may differ significantly. Deaf or hard-of-hearing users may not sense the specific tone if it is provided as an audio file. The tone, per se, is also not useful for automata.
このメカニズムは、参照されるトーンの意味について共通の理解がない場合に相互運用性を妨げます。これは、国やベンダーに固有の場合があります。これは、トーンを解釈しようとしているユーザーにとって、およびUAが（例えば、ユーザーの好みに応じて）独自のトーンを置き換えたい場合や、代替のアラートモードを提供する場合（例えば、聴覚障害者や難聴のユーザー向け）につながる可能性があります。 ）。発信者と着信者が異なる国にいる場合、トーンの理解は大きく異なる場合があります。聴覚障害者や聴覚障害者のユーザーは、オーディオファイルとして提供されている場合、特定のトーンを感じることができません。トーン自体も、オートマトンには役立ちません。
Another limitation of using URLs of audio files is that the referenced tones are tied to particular renderings. There is no method to signal the semantic intention of the alert while enabling the recipient UA to choose the specific alert indication (such as a particular tone, vibration, or visual display) to use to signal the intention. Similarly, there is no method to signal particular rendering features (such as short duration, delay, or country-specific conventions).
オーディオファイルのURLを使用する際のもう1つの制限は、参照されるトーンが特定のレンダリングに関連付けられることです。受信側UAが特定のアラート表示（特定のトーン、バイブレーション、またはビジュアルディスプレイなど）を選択して意図の通知に使用できるようにする一方で、アラートの意味的意図を通知する方法はありません。同様に、特定のレンダリング機能（短い期間、遅延、国固有の規則など）を通知する方法はありません。
The issues with URLs that reference audio files can be avoided by using fixed URLs with specific meanings. However, this approach has its own interoperability issues. For example, consider the Private Branch Exchange (PBX) special ring tone for an external (to the PBX) caller. Different vendors use different approaches such as:
オーディオファイルを参照するURLの問題は、特定の意味を持つ固定URLを使用することで回避できます。ただし、このアプローチには独自の相互運用性の問題があります。たとえば、（PBXへの）外部の呼び出し元に対する構内交換機（PBX）の特別な呼び出しトーンについて考えてみます。ベンダーが異なれば、次のような異なるアプローチが使用されます。
Alert-Info: <file://ring.pcm>;alert=external
where ring.pcm is a dummy file name, or:
ここで、ring.pcmはダミーのファイル名、または：
Alert-Info: <file://external.ring.pcm>
Alert-Info: <sip:external-ringtone@example.com>
As a result, the Alert-Info header field currently only works when the same vendor provides a PBX and UA, and only then if the same artificial proprietary URI convention is used.
その結果、Alert-Infoヘッダーフィールドは現在、同じベンダーがPBXとUAを提供する場合にのみ機能し、同じ人工的な独自のURI規則が使用される場合にのみ機能します。
To solve the described issues, this specification defines the new URN namespace "alert" for the SIP Alert-Info header field that allows for programmatic user interface adaptation and for conversion of equivalent alerting tones in the Public Switched Telephone Network (PSTN) when the client is a gateway. The work to standardize an "alert" URN will increase SIP interoperability for this header field by replacing proprietary conventions used today.
説明されている問題を解決するために、この仕様では、プログラムによるユーザーインターフェイスの適合と、クライアントが公衆交換電話網（PSTN）での同等のアラートトーンの変換を可能にするSIP Alert-Infoヘッダーフィールドの新しいURN名前空間「アラート」を定義します。ゲートウェイです。 「アラート」URNを標準化する作業により、現在使用されている独自の規則が置き換えられ、このヘッダーフィールドのSIP相互運用性が向上します。
The "alert" namespace provides a syntax for several different application spaces, for example:
「アラート」名前空間は、いくつかの異なるアプリケーションスペースの構文を提供します。次に例を示します。
o Names for service indications, such as call waiting or automatic callback, not tied to any particular rendering.
o キャッチホンや自動コールバックなど、特定のレンダリングに関連付けられていないサービス表示の名前。
o Names for common ring tones generated by PBX phones for cases such as an internal enterprise caller, external caller, ringback tone after a transfer failure or expiration of a hold timer, etc.
o 内部企業の発信者、外部の発信者、転送の失敗または保留タイマーの期限切れ後のリングバックトーンなどの場合にPBX電話によって生成される一般的な呼び出しトーンの名前。
o Names for country-specific ringback tones.
o 国固有の呼び出し音の名前。
o Names for things with specific renderings that aren't purely audio. They might be static icons, video sequences, text, etc.
o 純粋にオーディオではない特定のレンダリングを持つものの名前。静的なアイコン、ビデオシーケンス、テキストなどです。
Some advantages of a URN rather than a URL of a downloadable resource:
ダウンロード可能なリソースのURLではなく、URNのいくつかの利点：
o There is no need to download it or deal with security issues associated with dereferencing.
o それをダウンロードしたり、逆参照に関連するセキュリティ問題に対処したりする必要はありません。
o There are no formatting or compatibility issues.
o フォーマットや互換性の問題はありません。
o There is no security risk of rendering something unexpected and undesirable.
o 予期しないものや望ましくないものをレンダリングするセキュリティ上のリスクはありません。
o The tone can be stored locally in whatever format and at whatever quality level is appropriate, because it is specified "by name" rather than "by value".
o トーンは「値」ではなく「名前」で指定されるため、適切なフォーマットと品質レベルでローカルに保存できます。
o It is easier to make policy decisions about whether or not to use it.
o それを使用するかどうかに関するポリシーを決定する方が簡単です。
o It facilitates translation for the deaf and hard of hearing.
o ろう者や難聴者のための翻訳を容易にします。
The downside is that if the recipient does not understand the URN, then it will only be able to render a default ringback tone or ring tone.
欠点は、受信者がURNを理解していない場合、デフォルトのリングバックトーンまたはリングトーンしかレンダリングできないことです。
This document creates a new URN namespace and registry for alert indications and registers some initial values.
このドキュメントは、アラート表示用の新しいURN名前空間とレジストリを作成し、いくつかの初期値を登録します。
In practice, this specification extends the usage of the Alert-Info header field in that it will cause the use of a new class of URIs and the use of multiple URIs. Backward compatibility issues are not expected, as devices that do not understand an "alert" URN should ignore it, and devices should not malfunction upon receiving multiple Alert-Info header field values (<alert-param>s in [RFC3261]) (which was syntactically permitted before, but rarely used).
実際には、この仕様は、新しいクラスのURIの使用と複数のURIの使用を引き起こすという点で、Alert-Infoヘッダーフィールドの使用法を拡張しています。 「アラート」URNを理解しないデバイスはそれを無視する必要があり、複数のAlert-Infoヘッダーフィールド値（[RFC3261]の<alert-param> s）を受信したときにデバイスが誤動作してはならないため、下位互換性の問題は予期されません。以前は構文的に許可されていましたが、ほとんど使用されていませんでした）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This specification uses a number of terms to refer to the roles involved in the use of alerting indications in SIP. A "specifier" sends an "alerting indication" (one or more URNs in an Alert-Info header field) to a "renderer", which then "renders" a "signal" or "rendering" based on the indication to a human user. A "category" is a characteristic whose "values" can be used to classify indications.
この仕様では、いくつかの用語を使用して、SIPでのアラート表示の使用に関連する役割を指します。 「指定子」は「アラート表示」（Alert-Infoヘッダーフィールドの1つ以上のURN）を「レンダラー」に送信します。レンダラーは、その指示に基づいて「ユーザー」への「信号」または「レンダリング」を「レンダリング」します。 「カテゴリ」は、その「値」を使用して適応症を分類できる特性です。
This specification uses the terms "ring tone" and "ringback tone". A "ring tone" or "calling signal" (terminology used in [E182]) is a signal generated by the callee's end device, advising the callee about an incoming call. A "ringback tone" or "ringing tone" (terminology used in [E182]) is a signal advising the caller that a connection has been made and that a ring tone is being rendered to the callee.
この仕様では、「呼び出し音」および「呼び出し音」という用語を使用します。 「呼び出し音」または「呼び出し信号」（[E182]で使用される用語）は、呼び出し先のエンドデバイスによって生成される信号で、呼び出しについて呼び出し先に通知します。 「呼び出し音」または「呼び出し音」（[E182]で使用される用語）は、接続が確立され、呼び出し音が呼び出し先に表示されていることを呼び出し元に通知する信号です。
This specification changes the usage of the Alert-Info header field defined in [RFC3261] by additionally allowing its use in any non-100 provisional response to INVITE.
この仕様は、[RFC3261]で定義されているAlert-Infoヘッダーフィールドの使用法を、INVITEに対する100以外の暫定応答での使用をさらに許可することによって変更します。
Previously, the Alert-Info header field was only permitted in 180 (Ringing) responses. But in telephony, other situations indicated by SIP provisional responses, such as 181 (Call Is Being Forwarded) and 182 (Call Is Being Queued), are often indicated by tones. Extending the applicability of the Alert-Info header field allows the telephony practice to be implemented in SIP.
以前は、Alert-Infoヘッダーフィールドは180（Ringing）応答でのみ許可されていました。ただし、テレフォニーでは、181（コールは転送中）や182（コールはキューイング中）など、SIP暫定応答によって示される他の状況がトーンで示されることがよくあります。 Alert-Infoヘッダーフィールドの適用範囲を拡張すると、テレフォニープラクティスをSIPに実装できます。
To support this change, the following paragraph replaces the the first paragraph of Section 20.4 of [RFC3261]:
この変更をサポートするために、[RFC3261]のセクション20.4の最初の段落を次の段落に置き換えます。
When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the User Agent Server (UAS). When present in a non-100 provisional response, the Alert-Info header field specifies an alternative ringback tone to the UAC. A typical usage is for a proxy to insert this header field to provide a distinctive ring feature.
INVITE要求に存在する場合、Alert-Infoヘッダーフィールドは、ユーザーエージェントサーバー（UAS）への代替呼び出し音を指定します。 100以外の暫定応答に存在する場合、Alert-Infoヘッダーフィールドは、UACへの代替リングバックトーンを指定します。典型的な使用法は、プロキシがこのヘッダーフィールドを挿入して、独特のリング機能を提供することです。
A SIP proxy MAY add or remove an Alert-Info header field, and it MAY add or remove Alert-Info header field values, in a SIP request or a non-100 provisional response.
SIPプロキシは、SIPリクエストまたは100以外の暫定応答でAlert-Infoヘッダーフィールドを追加または削除する場合があり、Alert-Infoヘッダーフィールド値を追加または削除する場合があります。
This section discusses the requirements for an alerting indication to transport the semantics of the alerting situation or the characteristics of the rendering.
このセクションでは、アラート状況のセマンティクスまたはレンダリングの特性を転送するアラート表示の要件について説明します。
REQ-1: The mechanism will allow UAs and proxies to provide in the Alert-Info header field an alerting indication that describes the semantics of the signaling situation or the characteristics of the rendering and allows the recipient to decide how to render the received information to the user.
REQ-1：このメカニズムにより、UAとプロキシはAlert-Infoヘッダーフィールドで、シグナリング状況のセマンティクスまたはレンダリングの特性を説明するアラート表示を提供し、受信者が受信した情報をレンダリングする方法を決定できるようにしますユーザー。
REQ-2: The mechanism will allow the alerting indication to be specified "by name" rather than "by value", to enable local policy decisions whether or not to use it.
REQ-2：このメカニズムにより、アラート表示を「値」ではなく「名前」で指定できるようになり、それを使用するかどうかのローカルポリシー決定が可能になります。
REQ-3: The mechanism will enable alerting indications to represent a wide variety of signals, which have many largely orthogonal characteristics.
REQ-3：このメカニズムにより、アラート表示が多種多様な信号を表現できるようになります。
REQ-4: The mechanism will enable the set of alerting indications to support extensibility by a wide variety of organizations that are not coordinated with each other. Extensions will be able to:
REQ-4：このメカニズムにより、一連のアラート表示が、相互に調整されていないさまざまな組織による拡張性をサポートできるようになります。拡張機能は次のことができるようになります。
add further values to any existing category
既存のカテゴリにさらに値を追加する
add further categories that are orthogonal to existing categories
既存のカテゴリに直交するカテゴリをさらに追加する
semantically subdivide the meaning provided by any existing indication
既存の適応によって提供される意味を意味的に細分する
REQ-5: The mechanism will be flexible, so new alerting indications can be defined in the future, when SIP-applications evolve. For example, "alert" URNs could identify specific media by name, such as "Beethoven's Fifth", and the end device could render some small part of it as a ring tone.
REQ-5：メカニズムは柔軟になるため、SIPアプリケーションが進化したときに、新しいアラート表示を将来定義することができます。たとえば、「アラート」URNは「ベートーベンの5番」などの名前で特定のメディアを識別でき、エンドデバイスはその一部を着信音としてレンダリングできます。
REQ-6: The mechanism will provide only an indication capability, not a negotiation capability.
REQ-6：メカニズムは、ネゴシエーション機能ではなく、表示機能のみを提供します。
REQ-7: The mechanism will not require an alerting indication to depend on context provided by a previous alerting indication in either direction.
REQ-7：メカニズムは、どちらの方向でも前のアラート表示によって提供されたコンテキストに依存するためにアラート表示を必要としません。
REQ-8: The mechanism will allow transmission in the Alert-Info header field of SIP INVITE requests and provisional 1xx responses excepting the 100 responses.
REQ-8：このメカニズムでは、SIP INVITE要求のAlert-Infoヘッダーフィールドでの送信と、100応答を除く暫定1xx応答が許可されます。
REQ-9: The mechanism will be able to accommodate both renderers that are customized with a limited or uncommon set of signals that they can render and renderers that are provided with a set of signals that have uncommon semantics. (The canonical example is a UA for the deaf and hard of hearing, customized with an alternative set of signals, video or text instead of audio. By REQ-6, the renderer has no way of transmitting this fact to the specifier.)
REQ-9：このメカニズムは、レンダリングできる限られた信号または珍しい信号のセットでカスタマイズされたレンダラーと、珍しいセマンティクスを持つ信号のセットが提供されたレンダラーの両方に対応できます。 （標準的な例は、聴覚障害者と聴覚障害者のためのUAであり、オーディオの代わりに信号、ビデオ、またはテキストの代替セットでカスタマイズされます。REQ-6により、レンダラーはこの事実を指定子に送信する方法がありません。）
REQ-10: The mechanism will allow an alerting indication to reliably carry all extensions if the specifier and the renderer have designs that are properly coordinated.
REQ-10：指定子とレンダラーが適切に調整されたデザインを持っている場合、このメカニズムにより警告表示がすべての拡張機能を確実に運ぶことができます。
REQ-11: The mechanism will allow a renderer to select a tone that approximates to that intended by the specifier if the renderer is unable to provide the precise tone indicated.
REQ-11：レンダラーが指定された正確なトーンを提供できない場合、このメカニズムにより、レンダラーは指定子が意図したトーンに近いトーンを選択できます。
REQ-12: The mechanism will support alerting indications relating to services such as call waiting, call forwarding, transfer recall, auto callback, and hold recall.
REQ-12：このメカニズムは、キャッチホン、自動転送、転送再呼び出し、自動コールバック、保留再呼び出しなどのサービスに関連するアラート表示をサポートします。
REQ-13: The mechanism will allow rendering common PBX ring tone types.
REQ-13：このメカニズムでは、一般的なPBX呼び出しトーンタイプをレンダリングできます。
REQ-14: The mechanism will allow rendering specific country ringback tones.
REQ-14：このメカニズムにより、特定の国のリングバックトーンをレンダリングできます。
REQ-15: The mechanism will allow rendering tones for emergency alerts. (Use cases and definitions of URN values for emergency calls are not a subject of this specification.)
REQ-15：このメカニズムにより、緊急警報のトーンをレンダリングできます。 （ユースケースと緊急通話のURN値の定義は、この仕様の対象ではありません。）
REQ-16: The mechanism will allow rendering using other means than tones, e.g., text or images.
REQ-16：このメカニズムでは、テキストや画像など、トーン以外の手段を使用してレンダリングできます。
REQ-17: The mechanism will allow PSTN gateways to map ring/ringback tones from legacy protocols to SIP at the edge of a network, e.g., national ring tones as defined in TIA/EIA-41-D and 3GPP2 A.S0014. (Use cases and values definition for this situation are not a subject of this specification.)
REQ-17：このメカニズムにより、PSTNゲートウェイは、ネットワークのエッジでレガシープロトコルからSIPにリング/リングバックトーンをマッピングできます（例：TIA / EIA-41-Dおよび3GPP2 A.S0014で定義されている国内リングトーン）。 （この状況のユースケースと値の定義は、この仕様の対象ではありません。）
REQ-18: The mechanism will ensure that if an UA receives "alert" URNs or portions of an "alert" URN it does not understand, it can ignore them.
REQ-18：このメカニズムは、UAが「アラート」URNまたは「アラート」URNの一部を理解できない場合、それらを確実に無視できるようにします。
REQ-19: The mechanism will allow storage of the actual encoding of the rendering locally rather than fetching it.
REQ-19：このメカニズムでは、レンダリングのフェッチではなく、レンダリングの実際のエンコーディングをローカルに保存できます。
REQ-20: The mechanism must provide a simple way to combine two or more alerting indications to produce an alerting indication that requests a combination of the intentions of the two alerting indications, where any contradictions or conflicts between the two alerting indications are resolved in favor of the intention of the first alerting indication.
REQ-20：このメカニズムは、2つ以上のアラート表示を組み合わせて、2つのアラート表示の意図の組み合わせを要求するアラート表示を生成する簡単な方法を提供する必要があります。ここで、2つのアラート表示間の矛盾または競合は優先的に解決されます。最初の警告表示の意図の。
This section describes some use cases for which the "alert" URN mechanism is needed today.
このセクションでは、今日「アラート」URNメカニズムが必要となるいくつかのユースケースについて説明します。
This section defines some commonly encountered ring tones on PBX or business phones. They are as listed in the following subsections.
このセクションでは、PBXまたは会社の電話でよく遭遇する呼び出し音をいくつか定義します。それらは、以下のサブセクションにリストされているとおりです。
This tone indicates that the default or normal ring tone should be rendered. This is essentially a no-operation "alert" URN and should be treated by the UA as if no "alert" URN is present. This is most useful when Alert-Info header field parameters are being used. For example, in [RFC7463], an Alert-Info header field needs to be present containing the "appearance" parameter, but no special ring tone needs to be specified.
このトーンは、デフォルトまたは通常の呼び出しトーンをレンダリングする必要があることを示します。これは本質的には操作なしの「アラート」URNであり、「アラート」URNが存在しないかのようにUAで処理する必要があります。これは、Alert-Infoヘッダーフィールドパラメータが使用されている場合に最も役立ちます。たとえば、[RFC7463]では、 "appearance"パラメータを含むAlert-Infoヘッダーフィールドが存在する必要がありますが、特別な呼び出し音を指定する必要はありません。
This tone is used to indicate that the caller is external to the enterprise or PBX system. This could be a call from the PSTN or from a SIP trunk.
このトーンは、発信者が企業またはPBXシステムの外部にいることを示すために使用されます。これは、PSTNまたはSIPトランクからのコールである可能性があります。
This tone is used to indicate that the caller is internal to the enterprise or PBX system. The call could have been originated from another user on this PBX or on another PBX within the enterprise.
このトーンは、発信者が企業またはPBXシステムの内部にいることを示すために使用されます。通話は、このPBX上の別のユーザーまたは企業内の別のPBXから発信された可能性があります。
A PBX tone needs to indicate that a priority level alert should be applied for the type of alerting specified (e.g., internal alerting).
PBXトーンは、指定されたアラートのタイプ（内部アラートなど）に優先度レベルのアラートを適用する必要があることを示す必要があります。
In this case, the alerting type specified (e.g., internal alerting) should be rendered shorter than normal. In contact centers, this is sometimes referred to as "abbreviated ringing" or a "zip tone".
この場合、指定されたアラートの種類（内部アラートなど）は、通常より短くする必要があります。コンタクトセンターでは、これは「短縮リンギング」または「ジップトーン」と呼ばれることがあります。
In this case, the alerting type specified should be rendered after a short delay. In some bridged-line/shared-line-appearance implementations, this is used so that the bridged line does not ring at exactly the same time as the main line but is delayed a few seconds.
この場合、指定されたアラートタイプは少し遅れてレンダリングされます。一部のブリッジドライン/シェアドラインアピアランスの実装では、これを使用して、ブリッジドラインがメインラインと同時に鳴るのではなく、数秒遅延するようにします。
These tones are used to indicate specific PBX and public network telephony services.
これらのトーンは、特定のPBXおよびパブリックネットワークテレフォニーサービスを示すために使用されます。
The call-waiting service [TS24.615] permits a callee to be notified of an incoming call while the callee is engaged in an active or held call. Subsequently, the callee can either accept, reject, or ignore the incoming call. There is an interest on the caller side to be informed about the call-waiting situation on the callee side. Having this information the caller can decide whether to continue waiting for callee to pickup or better to call some time later when it is estimated that the callee could have finished the ongoing conversation. To provide this information, a callee's UA (or proxy) that is aware of the call-waiting condition can add the call-waiting indication to the Alert-Info header field in the 180 (Ringing) response.
キャッチホンサービス[TS24.615]を使用すると、呼び出し先がアクティブコールまたは保留中のコールに従事しているときに、呼び出し先に着信コールを通知できます。その後、着信者は着信を受け入れるか、拒否するか、無視することができます。呼び出し側での呼び出し待機状況について通知される呼び出し側の関心があります。この情報があれば、呼び出し側は、呼び出し先がピックアップするのを待つか、呼び出し先が進行中の会話を終了した可能性があると推定されたときにしばらくしてから呼び出すかを決定できます。この情報を提供するために、呼び出し待機状態を認識している呼び出し先のUA（またはプロキシ）は、180（Ringing）応答のAlert-Infoヘッダーフィールドに呼び出し待機表示を追加できます。
This feature is used in a 180 (Ringing) response when a call forwarding feature has been initiated on an INVITE. Many PBX system implement a forwarding "beep" followed by normal ringing to indicate this. Note that a 181 response can be used in place of this URN.
この機能は、INVITEで自動転送機能が開始されたときの180（呼び出し）応答で使用されます。多くのPBXシステムは、転送の「ビープ」の後に通常の呼び出し音を実装してこれを示します。このURNの代わりに181応答を使用できることに注意してください。
This feature is used when a blind transfer [RFC5589] has been performed by a server on behalf of the transferor and fails. Instead of failing the call, the server calls back the transferor, giving them another chance to transfer or otherwise deal with the call. This service tone is used to distinguish this INVITE from a normal incoming call.
この機能は、ブラインド転送[RFC5589]が転送者に代わってサーバーによって実行され、失敗したときに使用されます。呼び出しに失敗する代わりに、サーバーは転送者にコールバックし、転送または別の方法で呼び出しに対処する機会を再度与えます。このサービストーンは、このINVITEを通常の着信コールと区別するために使用されます。
This feature is used when a user has utilized a server to implement an automatic callback service [RFC6910]. When the user is available, the server calls back the user and utilizes this service tone to distinguish this INVITE from a normal incoming call.
この機能は、ユーザーがサーバーを利用して自動コールバックサービス[RFC6910]を実装したときに使用されます。ユーザーが応答可能になると、サーバーはユーザーにコールバックし、このサービストーンを利用して、このINVITEを通常の着信と区別します。
This feature is used when a server implements a call hold timer on behalf of an endpoint. After a certain period of time of being on hold, the user who placed the call on hold is alerted to either retrieve the call or otherwise dispose of the call. This service tone is used to distinguish this case from a normal incoming call.
この機能は、サーバーがエンドポイントに代わって通話保留タイマーを実装するときに使用されます。一定の期間保留した後、通話を保留にしたユーザーには、通話を取得するか、通話を破棄するように警告が表示されます。このサービストーンは、このケースを通常の着信コールと区別するために使用されます。
6.3. Country-Specific Ringback Tone Indications for the Public Switched Telephone Network
6.3. 公衆交換電話網の国別のリングバックトーン表示
In the PSTN, different tones are used in different countries. End users are accustomed to hear the callee's country ringback tone and would like to have this feature for SIP.
PSTNでは、さまざまなトーンがさまざまな国で使用されています。エンドユーザーは、呼び出し先の国のリングバックトーンを聞くのに慣れており、この機能をSIPで使用したいと考えています。
This section provides the registration template for the "alert" URN namespace identifier (NID) according to [RFC2141] and [RFC3406].
このセクションでは、[RFC2141]と[RFC3406]に基づく「アラート」URN名前空間識別子（NID）の登録テンプレートについて説明します。
Namespace ID: alert
名前空間ID：アラート
Registration Information: Registration version: 1 Registration date: 2014-12-10
登録情報：登録バージョン：1登録日：2014-12-10
Declared registrant of the namespace: Registering organization: Real-time Applications and Infrastructure Area, IETF Designated contact: RAI Area Director Designated contact email: rai-ads@ietf.org
名前空間の登録者の宣言：登録組織：リアルタイムアプリケーションとインフラストラクチャエリア、IETF指定の連絡先：RAI Area Director指定の連絡先メールアドレス：rai-ads@ietf.org
Declaration of syntactic structure:
構文構造の宣言：
The Namespace Specific String (NSS) for the "alert" URNs is called an <alert-identifier> and has a hierarchical structure. The first colon-separated part after "alert" is called the <alert-category>; the parts to the right of that are <alert-ind-part>s, and together form the <alert-indication>. The general form is urn:alert:<alert-category>:<alert-indication>.
「アラート」URNの名前空間固有の文字列（NSS）は<alert-identifier>と呼ばれ、階層構造を持っています。 「alert」の後の最初のコロンで区切られた部分は、<alert-category>と呼ばれます。その右側の部分は<alert-ind-part>であり、一緒に<alert-indication>を形成します。一般的な形式はurn：alert：<alert-category>：<alert-indication>です。
The following <alert-category> identifiers are defined in this document: "service" , "priority" , "source" , "duration", "delay", and "locale". The <alert-category> set can be extended in the future, either by standardization or by private action. The <alert-category>s describe distinct features of alerting signals.
このドキュメントでは、次の<alert-category>識別子が定義されています：「service」、「priority」、「source」、「duration」、「delay」、および「locale」。 <alert-category>セットは、標準化またはプライベートアクションによって、将来拡張することができます。 <alert-category>は、アラート信号の異なる機能を説明します。
Any "alert" URN defined in this specification is syntactically valid for ring and ringback tones and can be used in SIP INVITE requests or in provisional 1xx responses excepting the 100 response.
この仕様で定義されている「アラート」URNは、リングトーンとリングバックトーンに対して構文的に有効であり、SIP INVITE要求または100応答を除く暫定1xx応答で使用できます。
The ABNF [RFC5234] for the "alert" URNs is shown below:
「アラート」URNのABNF [RFC5234]を以下に示します。
alert-URN = "urn:alert:" alert-identifier
alert-identifier = alert-category ":" alert-indication
alert-category = alert-name
alert-indication = alert-ind-part *(":" alert-ind-part)
alert-ind-part = alert-name
alert-name = alert-label / private-name
private-name = alert-label "@" provider
provider = alert-label
alert-label = let-dig [ *let-dig-hyp let-dig ]
let-dig-hyp = let-dig / "-"
let-dig = ALPHA / DIGIT
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
<alert-label>s MUST comply with the syntax for Non-Reserved LDH labels [RFC5890]. Registered URNs and components thereof MUST be transmitted as registered (including case).
<alert-label>は、非予約LDHラベルの構文[RFC5890]に準拠する必要があります。登録されたURNとそのコンポーネントは、登録された状態（ケースを含む）で送信する必要があります。
Relevant ancillary documentation: RFC 7462 Namespace considerations: This specification defines a URN namespace "alert" for URNs representing signals or renderings that are presented to users to inform them of events and actions. The initial usage is to specify ring tones and ringback tones when dialogs are established in SIP, but they can also be used for other communication-initiation protocols (e.g., H.323), and more generally, in any situation (e.g., web pages or endpoint device software configurations) to describe how a user should be signaled.
関連する付属文書：RFC 7462名前空間の考慮事項：この仕様は、ユーザーにイベントやアクションを通知するためにユーザーに提示される信号またはレンダリングを表すURNのURN名前空間「アラート」を定義します。最初の使用法は、SIPでダイアログが確立されたときに呼び出し音と呼び出し音を指定することですが、他の通信開始プロトコル（H.323など）、より一般的には、あらゆる状況（Webページなど）でも使用できます。またはエンドポイントデバイスのソフトウェア構成）を使用して、ユーザーへの通知方法を説明します。
An "alert" URN does not describe a complete signal, but rather it describes a particular characteristic of the event it is signaling or a feature of the signal to be presented. The complete specification of the signal is a sequence of "alert" URNs specifying the desired characteristics/significance of the signal in priority order, with the most important aspects specified by the earlier URNs. This allows the sender of a sequence of URNs to compose very detailed specifications from a restricted set of URNs, and to clearly specify which aspects of the specification it considers most important.
「アラート」URNは完全な信号を表すのではなく、それがシグナリングしているイベントの特定の特性または提示される信号の機能を表します。信号の完全な仕様は、優先順位で信号の望ましい特性/重要性を指定する一連の「アラート」URNであり、最も重要な側面は以前のURNで指定されていました。これにより、一連のURNの送信者は、URNの制限されたセットから非常に詳細な仕様を作成し、仕様のどの側面を最も重要と見なすかを明確に指定できます。
The initial scope of usage is in the Alert-Info header field, in initial INVITE requests (to indicate how the called user should be alerted regarding the call) and non-100 provisional (1xx) responses to those INVITE requests (to indicate the ringback, how the calling user should be alerted regarding the progress of the call).
最初の使用範囲は、Alert-Infoヘッダーフィールド、最初のINVITEリクエスト（コールに関して呼び出されたユーザーにどのようにアラートを送信する必要があるかを示す）、およびそれらのINVITEリクエストに対する非100暫定（1xx）応答（リングバックを示す）です。 、呼び出しの進行状況について呼び出し元のユーザーにどのように警告するか）。
In order to ensure widespread adoption of these URNs for indicating ring tones and ringback tones, the scheme must allow replication of the current diversity of these tones. Currently, these tones vary between the PSTNs of different nations and between equipment supplied by different vendors. Thus, the scheme must accommodate national variations and proprietary extensions in a way that minimizes the information that is lost during interoperation between systems that follow different national variations or that are supplied by different vendors.
リングトーンとリングバックトーンを示すためにこれらのURNの広範な採用を確実にするために、スキームはこれらのトーンの現在の多様性の複製を許可する必要があります。現在、これらのトーンは、異なる国のPSTN間および異なるベンダーによって提供される機器間で異なります。したがって、このスキームは、異なる国のバリエーションに従うシステムまたは異なるベンダーによって提供されるシステム間の相互運用中に失われる情報を最小限に抑える方法で、国のバリエーションおよび独自の拡張機能に対応する必要があります。
The scheme allows definition of private extension URNs that refine and extend the information provided by standard URNs. Private extension URNs can also refine and extend the information provided by other private extension URNs. Private extensions can also define entirely new categories of information about calls. We expect these extensions to be used extensively when existing PBX products are converted to support SIP operation.
このスキームでは、標準のURNによって提供される情報を改良および拡張するプライベート拡張URNを定義できます。プライベート拡張URNは、他のプライベート拡張URNによって提供される情報を改良および拡張することもできます。プライベート内線は、通話に関するまったく新しいカテゴリの情報を定義することもできます。これらの拡張は、既存のPBX製品がSIP操作をサポートするように変換されるときに広く使用されると予想されます。
The device that receives an Alert-Info header field containing a sequence of "alert" URNs provides to the user a rendering that represents the semantic content of the URNs. The device is given great leeway in choosing the rendering, but it is constrained by rules that maximize interoperability between systems that support different sets of private extensions. In particular, earlier URNs in the sequence have priority of expression over later URNs in the sequence, and URNs that are not usable in their entirety (because they contain unknown extensions or are incompatible with previous URNs) are successively truncated in attempt to construct a URN that retains some information and is renderable in the context.
「アラート」URNのシーケンスを含むAlert-Infoヘッダーフィールドを受信するデバイスは、URNのセマンティックコンテンツを表すレンダリングをユーザーに提供します。デバイスにはレンダリングの選択に大きな余裕がありますが、プライベートエクステンションのさまざまなセットをサポートするシステム間の相互運用性を最大化するルールによって制約されます。特に、シーケンス内の以前のURNは、シーケンス内の後続のURNよりも式の優先度が高く、URNを構築するために、全体で使用できない（不明な拡張子が含まれている、または以前のURNと互換性がないため）URNが連続的に切り捨てられます一部の情報を保持し、コンテキストでレンダリング可能です。
Due to the practical importance of private extensions for the adoption of URNs for alerting calls and the very specific rules for private extensions and the corresponding processing rules that allow quality interoperation in the face of private extensions, the requirements of the "alert" URN scheme cannot be met by a fixed enumeration of URNs and corresponding meanings. In particular, the existing namespace "urn:ietf:params" does not suffice (unless the private extension apparatus is applied to that namespace).
アラート呼び出しにURNを採用するためのプライベート拡張の実用的な重要性、プライベート拡張の非常に具体的なルール、およびプライベート拡張に直面して品質の相互運用を可能にする対応する処理ルールにより、「アラート」URNスキームの要件では、 URNと対応する意味の固定列挙によって満たされます。特に、既存のネームスペース「urn：ietf：params」では十分ではありません（プライベート拡張装置がそのネームスペースに適用されていない場合）。
There do not appear to be other URN namespaces that uniquely identify the semantic of a signal or rendering feature. Unlike most other currently registered URN namespaces, the "alert" URN does not identify documents and protocol objects (e.g., [RFC3044], [RFC3120], [RFC3187], [RFC3188], [RFC4179], [RFC4195], [RFC4198]), types of telecommunications equipment [RFC4152], people, or organizations [RFC3043].
信号またはレンダリング機能のセマンティクスを一意に識別する他のURN名前空間はないようです。他のほとんどの現在登録されているURN名前空間とは異なり、「アラート」URNはドキュメントおよびプロトコルオブジェクト（たとえば、[RFC3044]、[RFC3120]、[RFC3187]、[RFC3188]、[RFC4179]、[RFC4195]、[RFC4198]を識別しません。 ）、通信機器の種類[RFC4152]、人、または組織[RFC3043]。
The <alert-URN>s are hierarchical identifiers. An <alert-URN> asserts some fact or feature of the offered SIP dialog, or some fact or feature of how it should be presented to a user, or of how it is being presented to a user. Removing an <alert-ind-part> from the end of an <alert-URN> (which has more than one <alert-ind-part>) creates a shorter <alert-URN> with a less specific meaning; the set of dialogs to which the longer <alert-URN> applies is necessarily a subset of the set of dialogs to which the shorter <alert-URN> applies. (If the starting <alert-URN> contains only one <alert-ind-part>, and thus the <alert-ind-part> cannot be removed to make a shorter <alert-URN>, we can consider the set of dialogs to which the <alert-URN> applies to be a subset of the set of all dialogs.)
<alert-URN>は階層的な識別子です。 <alert-URN>は、提供されたSIPダイアログのいくつかの事実または機能、またはそれをユーザーに提示する方法、またはユーザーに提示する方法のいくつかの事実または機能を表明します。 <alert-URN>（複数の<alert-ind-part>がある）の末尾から<alert-ind-part>を削除すると、より具体的な意味のない短い<alert-URN>が作成されます。長い<alert-URN>が適用されるダイアログのセットは、短い<alert-URN>が適用されるダイアログのセットのサブセットである必要があります。 （最初の<alert-URN>に含まれる<alert-ind-part>が1つだけであるため、<alert-ind-part>を削除してより短い<alert-URN>を作成できない場合は、ダイアログのセットを検討できます。 <alert-URN>が適用されるすべてのダイアログのセットのサブセットになります）
The specific criteria defining the subset to which the longer <alert-URN> applies, within the larger set of dialogs, is considered to be the meaning of the final <alert-ind-part>. This meaning is relative to and depends upon the preceding <alert- category> and <alert-ind-part>s (if any). The meanings of two <alert-ind-part>s that are textually the same but are preceded by different <alert-category>s or <alert-ind-part>s have no necessary connection. (An <alert-category> considered alone has no meaning in this sense.)
長いダイアログのセット内で、より長い<alert-URN>が適用されるサブセットを定義する特定の基準は、最後の<alert-ind-part>の意味と見なされます。この意味は、先行する<alert- category>および<alert-ind-part>（存在する場合）に関連しており、これらに依存します。テキスト的には同じであるが、異なる<alert-category>または<alert-ind-part>が前に付いている2つの<alert-ind-part>の意味には、必要な接続はありません。 （単独で考えられている<アラートカテゴリ>は、この意味では意味がありません。）
The organization owning the <provider> within a <private-name> specifies the meaning of that <private-name> when it is used as an <alert-ind-part>. (The organization owning a <provider> is specified by the registry described in Section 9.3.)
<private-name>内で<provider>を所有する組織は、<alert-ind-part>として使用されるときのその<private-name>の意味を指定します。 （<プロバイダー>を所有する組織は、セクション9.3で説明されているレジストリによって指定されます。）
The organization owning the <provider> within a <private-name> (in either an <alert-category> or an <alert-ind-part>) specifies the meaning of each <alert-ind-part>, which is an <alert-label> that follows that <private-name> and that precedes the next <alert-ind-part> which is a <private-name> (if any).
<private-name>（<alert-category>または<alert-ind-part>内）内で<provider>を所有する組織は、各<alert-ind-part>の意味を指定します。 <private-name>に続く、<private-name>（存在する場合）である次の<alert-ind-part>に先行するalert-label>。
The meaning of all other <alert-ind-part>s (i.e., those that are not <private-name>s and do not follow a <private-name>) is defined by standardization.
他のすべての<alert-ind-part>の意味（つまり、<private-name>ではなく、<private-name>に従わないもの）は、標準化によって定義されています。
Community considerations: The "alert" URNs are relevant to a large cross-section of Internet users, namely those that initiate and receive communication connections via the Session Initiation Protocol. These users include both technical and non-technical users, on a variety of devices and with a variety of perception capabilities. The "alert" URNs will allow Internet users to receive more information about offered calls and enable them to better make decisions about accepting an offered call, and to get better feedback on the progress of a call they have made.
コミュニティの考慮事項：「アラート」URNは、インターネットユーザー、つまりセッション開始プロトコルを介して通信接続を開始および受信するユーザーの大きな断面に関連しています。これらのユーザーには、さまざまなデバイスを使用し、さまざまな認識機能を持つ、テクニカルユーザーと非テクニカルユーザーの両方が含まれます。 「アラート」URNを使用すると、インターネットユーザーは提供された呼び出しに関する詳細情報を受信し、提供された呼び出しの受け入れに関する決定を適切に行うことができ、行った呼び出しの進行状況についてより良いフィードバックを得ることができます。
User interfaces that utilize alternative sensory modes can better render the ring and ringback tones based on the "alert" URNs because the URNs provide more detailed information regarding the intention of communications than is provided by current SIP mechanisms.
URNは、現在のSIPメカニズムによって提供されるよりも通信の意図に関する詳細な情報を提供するため、代替の感覚モードを利用するユーザーインターフェイスは、「アラート」URNに基づいてリングおよびリングバックトーンをより適切にレンダリングできます。
Process of identifier assignment:
識別子割り当てのプロセス：
Assignment of standardized "alert" URNs is by insertion into the IANA registry described in Section 9.2. This process defines the meanings of <alert-ind-part>s that have standardized meanings, as described in "Namespace Considerations".
標準化された「アラート」URNの割り当ては、セクション9.2で説明されているIANAレジストリへの挿入によるものです。このプロセスでは、「名前空間の考慮事項」で説明されているように、標準化された意味を持つ<alert-ind-part>の意味を定義します。
A new URN MUST NOT be registered if it is equal by the comparison rules to an already registered URN.
新しいURNは、比較ルールによって、すでに登録されているURNと等しい場合は登録してはなりません（MUST NOT）。
Private extensions are "alert" URNs that include <alert-ind-part>s that are <private-name>s and <alert-label>s that appear after a <private-name> (either as an <alert-category> or an <alert-indication>). If such an <alert-ind-part> is a <private-name>, its meaning is defined by the organization that owns the <provider> that appears in the <private-name>. If the <alert-ind-part> is an <alert-label>, its meaning is defined by the organization that owns the <provider> that appears in the closest <private-name> preceding the <alert-label>. The organization owning a <provider> is specified by the registry described in Section 9.3.
プライベート拡張機能は、<private-name>である<alert-ind-part>と、<private-name>の後に表示される<alert-category>として<alert-label>を含む「アラート」URNですまたは<alert-indication>）。そのような<alert-ind-part>が<private-name>である場合、その意味は、<private-name>に表示される<provider>を所有する組織によって定義されます。 <alert-ind-part>が<alert-label>の場合、その意味は、<alert-label>の前の最も近い<private-name>に表示される<provider>を所有する組織によって定義されます。 <プロバイダー>を所有する組織は、セクション9.3で説明されているレジストリによって指定されます。
Identifier uniqueness and persistence considerations: An "alert" URN identifies a semantic feature of a call or a sensory feature of how the call alerting should be a rendered at the caller's or callee's end device.
識別子の一意性と永続性に関する考慮事項：「アラート」URNは、呼び出しのセマンティック機能または呼び出しアラートが呼び出し元または呼び出し先のエンドデバイスでどのようにレンダリングされるかに関する感覚機能を識別します。
For standardized <alert-ind-part>s in URNs, uniqueness and persistence of their meanings is guaranteed by the fact that they are registered with IANA in accordance with the procedures of Section 9.2; the feature identified by a particular "alert" URN is distinct from the feature identified by any other standardized "alert" URN.
URNの標準化された<alert-ind-part>の場合、その意味の一意性と永続性は、セクション9.2の手順に従ってIANAに登録されているという事実によって保証されます。特定の「アラート」URNによって識別される機能は、他の標準化された「アラート」URNによって識別される機能とは異なります。
Assuring uniqueness and persistence of the meanings of private extensions is delegated to the organizations that define private extension <alert-ind-part>s. The organization responsible for a particular <alert-ind-part> in a particular "alert" URN is the owner of a syntactically determined <provider> part within the URN.
プライベート拡張の意味の一意性と永続性の保証は、プライベート拡張<alert-ind-part>を定義する組織に委任されます。特定の「アラート」URN内の特定の<alert-ind-part>を担当する組織は、URN内で構文的に決定された<provider>パーツの所有者です。
An organization SHOULD use only one <provider> value for all of the <private-name>s it defines.
組織は、定義するすべての<private-name>に対して1つの<provider>値のみを使用する必要があります（SHOULD）。
Process for identifier resolution: The process of identifier resolution is the process by which a rendering device chooses a rendering to represent a sequence of "alert" URNs. The device is allowed great leeway in making this choice, but the process MUST obey the rules of Section 11.1. The device is expected to provide renderings that users associate with the meanings assigned to the URNs within their cultural context. A non-normative example resolution algorithm is given in Section 12.1.
識別子解決のプロセス：識別子解決のプロセスは、レンダリングデバイスが「アラート」URNのシーケンスを表すレンダリングを選択するプロセスです。デバイスは、この選択を行う際に大きな余裕がありますが、プロセスはセクション11.1の規則に従う必要があります。このデバイスは、ユーザーが文化的コンテキスト内でURNに割り当てられた意味と関連付けるレンダリングを提供することが期待されています。非規範的な解決アルゴリズムの例をセクション12.1に示します。
Rules for lexical equivalence: "alert" URNs are compared according to case-insensitive string equality.
字句の同等性の規則：「アラート」URNは、大文字と小文字を区別しない文字列の同等性に従って比較されます。
Conformance with URN syntax: All "alert" URNs must conform to the ABNF in the "Declaration of Syntactic Structure" in Section 7. That ABNF is a subset of the generic URN syntax [RFC2141]. <alert-label>s are constrained to be Non-Reserved LDH labels [RFC5890], that is, "ordinary ASCII labels". Future standardization may allow <alert-label>s that are A-labels [RFC5890], and so interpreters of "alert" URNs MUST operate correctly (per Section 11.1) when given such URNs as input.
URN構文への準拠：すべての「アラート」URNは、セクション7の「構文構造の宣言」のABNFに準拠する必要があります。そのABNFは、汎用URN構文[RFC2141]のサブセットです。 <alert-label>は、予約されていないLDHラベル[RFC5890]、つまり「通常のASCIIラベル」に制限されています。将来の標準化では、Aラベル[RFC5890]である<alert-label>が許可される可能性があるため、「アラート」URNのインタープリターは、そのようなURNを入力として指定した場合に正しく動作する必要があります（セクション11.1に従って）。
Validation mechanism: An "alert" URN containing no private extensions can be validated based on the IANA registry of standardized "alert" URNs. Validating an "alert" URN containing private extensions requires obtaining information regarding the private extensions defined by the organization that owns the <provider> in the relevant <private-name>. The identity of the organization can be determined from the IANA registry described in Section 9.2. However, if an "alert" URN contains at least one <alert-identifier> that precedes the first <private-name>, the portion of the "alert" URN that precedes the first <private-name> must itself be a valid standardized "alert" URN, which may be validated as above.
検証メカニズム：プライベート拡張を含まない「アラート」URNは、標準化された「アラート」URNのIANAレジストリに基づいて検証できます。プライベート拡張を含む「アラート」URNを検証するには、関連する<private-name>で<provider>を所有する組織によって定義されたプライベート拡張に関する情報を取得する必要があります。組織のIDは、セクション9.2で説明されているIANAレジストリから決定できます。ただし、「アラート」URNに最初の<private-name>の前にある少なくとも1つの<alert-identifier>が含まれている場合、最初の<private-name>の前の「アラート」URNの部分自体が有効な標準化されている必要があります。上記のように検証できる「アラート」URN。
Scope: The scope for this URN is public and global.
スコープ：このURNのスコープはパブリックおよびグローバルです。
The following <alert-category> values are defined in this document:
このドキュメントでは、次の<alert-category>値が定義されています。
- service - source - priority - duration - delay - locale
- サービス-ソース-優先度-期間-遅延-ロケール
This section describes the "alert" URN indication values for the <alert-category>s defined in this document.
このセクションでは、このドキュメントで定義されている<alert-category>の「アラート」URN指示値について説明します。
For each <alert-category>, a default <alert-indication> is defined, which is essentially a no-operation "alert" URN and should be treated by the UA as if no "alert" URN for the respective category is present. "alert" URN default indications are most useful when Alert-Info header field parameters are being used. For example, in
各<alert-category>に対して、デフォルトの<alert-indication>が定義されます。これは基本的に操作なしの「アラート」URNであり、UAはそれぞれのカテゴリーの「アラート」URNがないかのように処理する必要があります。 「アラート」URNデフォルト表示は、Alert-Infoヘッダーフィールドパラメータが使用されている場合に最も役立ちます。たとえば、
[RFC7463], an Alert-Info header field needs to be present containing the "appearance" parameter, but no special ringtone need be specified.
[RFC7463]、「外観」パラメーターを含むAlert-Infoヘッダーフィールドが存在する必要がありますが、特別な着信音を指定する必要はありません。
The <private-name> syntax is used for extensions defined by independent organizations, as described in Section 10.2.
セクション10.2で説明されているように、<private-name>構文は、独立した組織によって定義された拡張に使用されます。
- normal (default) - call-waiting - forward - recall:callback - recall:hold - recall:transfer - <private-name>
- 通常（デフォルト）-キャッチホン-転送-リコール：コールバック-リコール：保留-リコール：転送-<プライベート名>
Examples: <urn:alert:service:call-waiting> or <urn:alert:service:recall:transfer>.
例：<urn：alert：service：call-waiting>または<urn：alert：service：recall：transfer>。
- unclassified (default) - internal - external - friend - family - <private-name>
- 未分類（デフォルト）-internal-external-friend-family-<private-name>
(These <alert-indication>s will rarely be provided by the sending UA; rather they will usually be inserted by a proxy acting on behalf of the recipient UA to inform the recipient UA about the origins of a call.)
（これらの<alert-indication>は、送信側UAによって提供されることはめったにありません。通常、これらは、受信側UAに代わって動作するプロキシによって挿入され、受信側UAにコールの発信元を通知します。）
Examples: <urn:alert:source:external>.
例：<urn：alert：source：external>。
- normal (default) - low - high - <private-name>
- 通常（デフォルト）-低-高-<private-name>
Examples: <urn:alert:priority:high>.
例：<urn：alert：priority：high>。
- normal (default) - short - long - <private-name>
- 通常（デフォルト）-ショート-ロング-<プライベート名>
Examples: <urn:alert:duration:short>.
例：<urn：alert：duration：short>。
- none (default) - yes - <private-name>
- なし（デフォルト）-はい-<private-name>
Examples: <urn:alert:delay:yes>.
例：<urn：alert：delay：yes>。
- default (default) - country:<ISO 3166-1 country code> - <private-name>
- デフォルト（デフォルト）-国：<ISO 3166-1国コード>-<プライベート名>
The ISO 3166-1 country code [ISO3166-1] is used to inform the renderer on the other side of the call that a country-specific rendering should be used. For example, to indicate ringback tones from South Africa, the following URN would be used: <urn:alert:locale:country:za>.
ISO 3166-1国コード[ISO3166-1]は、通話の反対側にあるレンダラーに、国固有のレンダリングを使用する必要があることを通知するために使用されます。たとえば、南アフリカからのリングバックトーンを示すには、次のURNを使用します：<urn：alert：locale：country：za>。
This section registers a new URN namespace identifier (NID), "alert", in accordance with [RFC3406] with the registration template provided in Section 7.
このセクションでは、セクション7で提供された登録テンプレートを使用して、[RFC3406]に従って、新しいURN名前空間識別子（NID）である「アラート」を登録します。
Standard "alert" URNs are recorded as <alert-identifier>s in a new registry called "Alert URN Identifiers". Thus, creating a new standard "alert" URN requires IANA action. IANA manages the "Alert URN Identifiers" registry under the policy 'Specification Required' [RFC5226] following the guidelines in Section 10.1.
標準の「アラート」URNは、「アラートURN識別子」と呼ばれる新しいレジストリに<alert-identifier>として記録されます。したがって、新しい標準の「アラート」URNを作成するには、IANAアクションが必要です。 IANAは、セクション10.1のガイドラインに従って、ポリシー「Specification Required」[RFC5226]の下で「Alert URN Identifiers」レジストリを管理しています。
The registry contains entries in the following formats:
レジストリには、次の形式のエントリが含まれています。
<alert-category>/ Reference Description
<alert-identifier>
---------------------------------------------------------------
foo [RFCxyz] Description of the 'foo'
<alert-category>;
foo:bar [RFCabc] Description of the 'foo:bar'
<alert-identifier>
foo:<range> [RFCdef] Description of the
'foo:<category>' <alert-identifer>s (which will
reference the <range> value)
The first value in each row is the value that is registered, which is either: (1) an <alert-category> value, (2) an <alert-identifier> value, composed of an <alert-category> followed by an <alert-indication>, in turn composed of one or more <alert-label>s, or (3) a pattern for <alert-identifier> values (e.g., for the "locale" <alert-category> in Section 9.2.1.6).
各行の最初の値は、登録されている値で、（1）<alert-category>値、（2）<alert-category>の後に<alert-category>で構成される<alert-identifier>値のいずれかです。 <alert-indication>、1つ以上の<alert-label>で構成される、または（3）<alert-identifier>値のパターン（たとえば、セクション9.2の「ロケール」<alert-category>の場合）。 1.6）。
The second value in each row is the reference to the required specification for the value.
各行の2番目の値は、値に必要な仕様への参照です。
The third value in each row is a short description of the semantics of the value.
各行の3番目の値は、値のセマンティクスの簡単な説明です。
A new URN MUST NOT be registered if it is equal by the comparison rules (that is, case-insensitive string comparison) to an already registered URN.
新しいURNは、比較ルール（つまり、大文字と小文字を区別しない文字列の比較）によって、既に登録されているURNと等しい場合は登録してはなりません（MUST NOT）。
<alert-category> and <alert-identifier> values that contain <private-name>s are not managed by IANA. The process of assigning these values is described in Section 10.2.
<private-name>を含む<alert-category>および<alert-identifier>の値は、IANAによって管理されません。これらの値を割り当てるプロセスについては、セクション10.2で説明します。
This document defines the <alert-category>s 'service', 'source', 'priority', 'duration', 'delay' and 'locale'. The entries to be added to the 'Alert URN Identifiers' registry table for each <alert-category> are given in the respective sections below.
このドキュメントでは、<alert-category>の「サービス」、「ソース」、「優先度」、「期間」、「遅延」、および「ロケール」を定義しています。各<alert-category>の 'Alert URN Identifiers'レジストリテーブルに追加されるエントリは、以下のそれぞれのセクションに記載されています。
The following table contains the initial IANA registration for the "service" <alert-category> and <alert-identifier>s. The value of this indicator is set to a value different from "normal" if the caller or callee is informed that a specific telephony service has been initiated.
次の表には、「サービス」<alert-category>および<alert-identifier>の初期IANA登録が含まれています。このインジケーターの値は、特定のテレフォニーサービスが開始されたことが発信者または着信者に通知された場合、「通常」とは異なる値に設定されます。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
service RFC 7462 Specific telephony
service used in this
call
service:normal RFC 7462 Normal ring/ringback rendering (default value)
サービス：通常のRFC 7462通常のリング/リングバックレンダリング（デフォルト値）
service:call-waiting RFC 7462 Call waiting was initiated at the other side of the call
service：call-waiting RFC 7462通話待機が通話の反対側で開始されました
service:forward RFC 7462 Call has been forwarded
service：forward RFC 7462コールが転送されました
service:recall:callback RFC 7462 Recall due to callback
service：recall：callback RFC 7462コールバックによるリコール
service:recall:hold RFC 7462 Recall due to call hold
service：recall：hold通話保留によるRFC 7462 Recall
service:recall:transfer RFC 7462 Recall due to transfer
service：recall：transfer転送によるRFC 7462 Recall
The following table contains the initial IANA registration for the "source" <alert-category> and <alert-identifier>. The value of this indicator provides information about the user at the other side of the call.
次の表には、「ソース」<alert-category>および<alert-identifier>の初期IANA登録が含まれています。このインジケータの値は、通話の反対側にいるユーザーに関する情報を提供します。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
source RFC 7462 Classification
of the other party
to the call
source:unclassified RFC 7462 Unclassified ring/ringback rendering (default value)
ソース：未分類のRFC 7462未分類のリング/リングバックレンダリング（デフォルト値）
source:internal RFC 7462 User at the other side of the call is internal to the enterprise or PBX system
source：internal RFC 7462通話の反対側にいるユーザーは、企業またはPBXシステムの内部にいます
source:external RFC 7462 User at the other side of the call is external to the enterprise or PBX system
source：external RFC 7462通話の反対側にいるユーザーが企業またはPBXシステムの外部にいる
source:friend RFC 7462 User at the other side of the call is a friend
source：friend RFC 7462通話の反対側にいるユーザーは友達です
source:family RFC 7462 User at the other side of the call is a family member
source：family RFC 7462通話の反対側にいるユーザーは家族のメンバーです
The following table contains the initial IANA registration for the "priority" <alert-category> and <alert-identifier>s. The value of this indicator provides information about the priority the alerted user should give to the call.
次の表には、「優先度」の<alert-category>と<alert-identifier>の初期IANA登録が含まれています。このインジケーターの値は、アラートされたユーザーが通話に与える優先度に関する情報を提供します。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
priority RFC 7462 Priority of the
call
priority:normal RFC 7462 Normal ring/ringback rendering (default value)
優先度：通常のRFC 7462通常のリング/リングバックレンダリング（デフォルト値）
priority:low RFC 7462 Low priority call
優先度：低RFC 7462低優先度コール
priority:high RFC 7462 High priority call
優先度：高RFC 7462高優先度コール
The following table contains the initial IANA registration for the "duration" <alert-category> and <alert-identifier>s. The value of this indicator provides information about the duration of the alerting signals compared to the default alerting signals.
次の表は、「期間」<alert-category>および<alert-identifier>の初期IANA登録を示しています。このインジケーターの値は、デフォルトのアラート信号と比較したアラート信号の持続時間に関する情報を提供します。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
duration RFC 7462 Duration of alerting signal
duration:normal RFC 7462 Normal ring/ringback rendering (default value)
期間：通常のRFC 7462通常のリング/リングバックレンダリング（デフォルト値）
duration:short RFC 7462 Shorter than normal
期間：短いRFC 7462通常より短い
duration:long RFC 7462 Longer than normal
duration：long RFC 7462通常より長い
The following table contains the initial IANA registration for the "delay" <alert-category> and <alert-identifier>s. The value of this indicator provides information about whether the presentation of the alerting signal should be delayed compared to the default presentation process. For more details see Section 6.1.6.
次の表には、 "delay" <alert-category>および<alert-identifier>の初期IANA登録が含まれています。このインジケーターの値は、アラート信号の表示をデフォルトの表示プロセスと比較して遅らせる必要があるかどうかについての情報を提供します。詳細については、セクション6.1.6を参照してください。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
delay RFC 7462 Delay of rendering
of alerting signal
delay:none RFC 7462 Immediate alerting (default value)
遅延：なしRFC 7462即時アラート（デフォルト値）
delay:yes RFC 7462 Delayed alerting
遅延：はいRFC 7462遅延アラート
The following table contains the initial IANA registration for the "locale" <alert-category> and <alert-identifier>s. The value of this indicator provides information about whether the alerting signals characteristic of the specified location should be used.
次の表には、「ロケール」の<alert-category>と<alert-identifier>の初期IANA登録が含まれています。このインジケータの値は、指定された場所に特徴的な警告信号を使用する必要があるかどうかについての情報を提供します。
<alert-category>/ Reference Description
<alert-identifier>
-----------------------------------------------------------
locale RFC 7462 Location-specific
alerting signals
locale:default RFC 7462 Alerting not location specific (default value)
ロケール：デフォルトのRFC 7462アラートは場所固有ではありません（デフォルト値）
locale:country:<ISO 3166-1 country code> RFC 7462 Alerting according to the conventions of the specified country
locale：country：<ISO 3166-1国コード>指定された国の規則に従ったRFC 7462アラート
Values of <provider>, which are used to create <private-name>s, are recorded in a new registry called "Alert URN Providers". (Private extension "alert" URNs that are defined are not recorded by IANA.) The registry is managed by IANA under the policy 'First Come First Served' [RFC5226].
<private-name>の作成に使用される<provider>の値は、「アラートURNプロバイダー」と呼ばれる新しいレジストリに記録されます。 （定義されているプライベート拡張「アラート」URNはIANAによって記録されません。）レジストリは、ポリシー「先着順」[RFC5226]の下でIANAによって管理されます。
The registry contains entries in the following format:
レジストリには、次の形式のエントリが含まれています。
<provider> Registrant Contact URI
---------------------------------------------------------------------
example IETF rai-ads@ietf.org
The first value in each row is the <provider> value that is registered. This value is case-insensitive and MUST comply with the syntax for Non-Reserved LDH labels [RFC5890].
各行の最初の値は、登録されている<provider>の値です。この値は大文字と小文字を区別せず、Non-Reserved LDHラベルの構文[RFC5890]に準拠する必要があります。
The second value in each row is the name of the registrant of the value.
各行の2番目の値は、値の登録者の名前です。
The third value is a contact URI for the registrant.
3番目の値は、登録者の連絡先URIです。
The registry initially contains the one entry shown above, which can be used for constructing examples of private extension URNs.
レジストリには最初、上記の1つのエントリが含まれています。これは、プライベート拡張URNの例を構築するために使用できます。
The set of "alert" URNs is extensible. An extension "at the top level" creates a new <alert-category> (which represents a new alerting characteristic), an extension "at the second level" creates a new <alert-indication> value for an existing <alert-category>, an extension "at the third level" creates a subdivision of an existing <alert-indication> (that has one <alert-ind-part>), etc. URNs allow (in principle) indefinite subdivision of existing <alert-indication> values, although most of the standard "alert" URNs have only one level of subdivision and a few have two levels of subdivision.
「アラート」URNのセットは拡張可能です。 「トップレベル」の拡張は新しい<alert-category>（これは新しいアラート特性を表す）を作成し、「第2レベル」の拡張は既存の<alert-category>の新しい<alert-indication>値を作成します、「第3レベルでの」拡張は、既存の<alert-indication>のサブディビジョンを作成します（1つの<alert-ind-part>があります）、など。値。ただし、ほとんどの標準的な「アラート」URNには、1レベルのサブディビジョンしかないものもあれば、2レベルのサブディビジョンを持つものもあります。
Extensions, either standard or private, MUST conform to the following principles:
標準またはプライベートの拡張機能は、次の原則に準拠する必要があります。
A new <alert-category> is independent of all previously existing <alert-category>s: For any combination of one <alert-identifier> in the new <alert-category> with any one <alert-identifier> in any of the previously existing <alert-category>s, there are potential calls to which the combination can be meaningfully applied.
新しい<alert-category>は、既存のすべての<alert-category>から独立しています：新しい<alert-category>の1つの<alert-identifier>と、任意の1つの<alert-identifier>の組み合わせ以前に存在していた<alert-category>には、組み合わせを有効に適用できる潜在的な呼び出しがあります。
A new <alert-identifier> that has more than one <alert-ind-part> is a semantic refinement of a parent <alert-identifier>, the parent being obtained by deleting the final <alert-ind-part>. The new <alert-identifier> has as parent the most specific previously existing <alert-identifier> whose meaning includes all potential calls to which the new <alert-identifier> could be meaningfully applied.
複数の<alert-ind-part>を持つ新しい<alert-identifier>は、親<alert-identifier>のセマンティックリファインメントであり、最後の<alert-ind-part>を削除することで親が取得されます。新しい<alert-identifier>には、親として、最も具体的な既存の<alert-identifier>があり、その意味には、新しい<alert-identifier>を意味のある形で適用できるすべての潜在的な呼び出しが含まれます。
A new <alert-identifier> has no semantic overlap with any sibling <alert-identifier> (<alert-identifier>s that differ only in the final <alert-ind-part>). That is, there could be no call to which both <alert-identifier>s could be meaningfully applied.
新しい<alert-identifier>は、兄弟<alert-identifier>（最後の<alert-ind-part>のみが異なる<alert-identifier>）と意味的に重複していません。つまり、両方の<alert-identifier>を有効に適用できる呼び出しがない場合があります。
The process for defining new standard "alert" URNs is described in Section 9.2; all such definitions require registering a publicly available specification. The process for defining new "alert" URNs via the private extension mechanism is described in Section 10.2.
新しい標準の「アラート」URNを定義するプロセスについては、セクション9.2で説明します。このようなすべての定義では、公開されている仕様を登録する必要があります。プライベート拡張メカニズムを介して新しい「アラート」URNを定義するプロセスについては、セクション10.2で説明します。
The <private-name> syntax is used to create private extensions, extensions that are not registered with IANA. The <private-name> has the form of an <alert-label> followed by "@" and then a <provider> that designates the organization defining the extension. Both <alert-label> and <provider> have the same syntax as an ordinary ASCII DNS label. A private extension URN is created by using a <private-name> as either an <alert-category> or an <alert-ind-part>.
<private-name>構文は、プライベート拡張、つまりIANAに登録されていない拡張を作成するために使用されます。 <private-name>の形式は、<alert-label>の後に「@」が続き、次に、拡張を定義する組織を指定する<provider>です。 <alert-label>と<provider>の両方の構文は、通常のASCII DNSラベルと同じです。プライベート拡張URNは、<private-name>を<alert-category>または<alert-ind-part>として使用して作成されます。
If the <private-name> is used as an <alert-category>, the characteristic of the alerting signal that the <alert-category> describes is defined by the organization. If the <private-name> is used as the first <alert-ind-part>, the organization defines an alternative value for the standardized <alert-category> of the URN. If the <private-name> is used as the second or later <alert-ind-part>, the organization defines the meaning of the URN as a subset of the meaning of the shorter URN resulting when the <private-name> (and any subsequent <alert-ind-part>s) are removed.
<private-name>が<alert-category>として使用される場合、<alert-category>が記述するアラート信号の特性は組織によって定義されます。 <private-name>が最初の<alert-ind-part>として使用される場合、組織は、URNの標準化された<alert-category>の代替値を定義します。 <private-name>が2番目以降の<alert-ind-part>として使用されている場合、組織は、<private-name>の結果として得られる短いURNの意味のサブセットとしてURNの意味を定義します（および後続の<alert-ind-part> s）は削除されます。
Within a URN, all <alert-label> components that follow a <private-name> but are before any following <private-name>s are additional private extensions whose meaning is defined by the organization defining the nearest preceding <private-name>.
URN内で、<private-name>に続くが、その後に続く<private-name>の前にあるすべての<alert-label>コンポーネントは、最も近い先行する<private-name>を定義する組織によって意味が定義される追加のプライベート拡張です。 。
A URN that contains a private extension can be further subdivided by the private extension of a different organization: the second organization appends an <alert-ind-part> that is a <private-name> containing a the <provider> value for the second organization.
プライベート拡張を含むURNは、別の組織のプライベート拡張によってさらに分割できます。2番目の組織は、2番目の<provider>値を含む<private-name>である<alert-ind-part>を追加します組織。
The meaning of a <private-name> or an <alert-label> that is defined privately (because of a preceding <private-name>) is only fixed within the context provided by the sequence of preceding <alert-name>s; these components have no meaning in isolation and there is no necessary relationship between the meaning of textually identical <alert-name>s that are preceded by different sequences of <alert-name>s.
プライベートに定義された<private-name>または<alert-label>の意味（前の<private-name>のため）は、前の<alert-name>のシーケンスによって提供されるコンテキスト内でのみ修正されます。これらのコンポーネントは単独では意味がなく、異なる<alert-name>のシーケンスが前に付いているテキスト的に同一の<alert-name>の意味間に必要な関係はありません。
Creating private extension "alert" URNs is not a Standards Action and they are not registered with IANA.
プライベート拡張「アラート」URNの作成は標準アクションではなく、IANAに登録されていません。
The organization defining a private extension is responsible for ensuring persistence of the meaning of the private extension.
プライベート拡張を定義する組織は、プライベート拡張の意味の永続性を確保する責任があります。
Private extensions MUST conform to the principles of Section 10.1, both in regard to previously existing standard <alert-URN>s and in regard to any previously existing private extensions using the same <provider> value, and any other private extensions that the organization is aware of. In particular, a private extension MUST NOT duplicate any standard URN or any private extension that the organization is aware of. (In either of those cases, the organization MUST use the existing URN for its purposes.)
プライベート拡張は、以前に存在した標準の<alert-URN>と同じ<provider>値を使用する既存のプライベート拡張、および組織が持つその他のプライベート拡張の両方に関して、セクション10.1の原則に準拠する必要があります。知っている。特に、プライベート拡張は、組織が認識している標準URNまたはプライベート拡張を複製してはなりません。 （どちらの場合でも、組織はその目的のために既存のURNを使用する必要があります。）
An organization obtains a <provider> value for constructing <private-name>s by registering the value with IANA as provided in Section 9.3.
組織は、セクション9.3で規定されているように、IANAに値を登録することにより、<private-name>を構築するための<provider>値を取得します。
The organization registering the <provider> "example" can define distinctive versions of <urn:alert:service:call-waiting>:
<provider>の「example」を登録する組織は、<urn：alert：service：call-waiting>の異なるバージョンを定義できます。
urn:alert:service:call-waiting:abc@example
urn:alert:service:call-waiting:def@example
It can create a more specialized URN that applies to a subset of the situations to which the first URN above applies:
上記の最初のURNが適用される状況のサブセットに適用される、より特化したURNを作成できます。
urn:alert:service:call-waiting:abc@example:xyz
Because "xyz" follows "abc@example" (and there is no intervening <private-name>), its meaning is defined by the owner of the <provider> "example".
「xyz」は「abc @ example」の後に続くため（間に<private-name>はありません）、その意味は<provider>の「example」の所有者によって定義されます。
The organization registering the <provider> "example" can define URNs in the "service" category to express a new service that is not covered by any of the standardized URNs:
<provider>の「example」を登録する組織は、「service」カテゴリにURNを定義して、標準化されたURNのいずれにも含まれない新しいサービスを表現できます。
urn:alert:service:ghi@example
However, before defining such a URN, the organization should verify that the set of calls to which the URN applies is not a subset of the set of calls for some existing URN. If it is a subset, the extension URN should be a subdivision of the existing URN.
ただし、そのようなURNを定義する前に、組織は、URNが適用される一連の呼び出しが、一部の既存のURNの一連の呼び出しのサブセットでないことを確認する必要があります。サブセットの場合、拡張URNは既存のURNのサブディビジョンである必要があります。
The organization registering the <provider> "example" can define an extension <alert-category> named "jkl@example" with two <alert-indication>s "a1" and "a2":
<provider>の「example」を登録する組織は、2つの<alert-indication>が「a1」と「a2」の「jkl @ example」という名前の拡張<alert-category>を定義できます。
urn:alert:jkl@example:a1
urn:alert:jkl@example:a2
The organization registering the <provider> "foo" wants to define a set of URNs that specify the different ring patterns used by a "distinctive ring" service to alert for incoming calls that are directed to different directory numbers. These ring patterns are composed of groups of ring sounds that have particular patterns of lengths.
<provider>の "foo"を登録している組織は、異なるディレクトリ番号に向けられた着信呼び出しを警告するために、 "distingtive ring"サービスが使用するさまざまな呼び出し音パターンを指定する一連のURNを定義したいと考えています。これらの呼び出し音パターンは、特定の長さのパターンを持つ呼び出し音のグループで構成されています。
The company can create a private <alert-category> "distinctive@foo", and within it assign three 'alert' URNs that indicate the three different ring patterns used by the company's service:
会社はプライベート<alert-category> "distinctive @ foo"を作成でき、その中に会社のサービスで使用される3つの異なるリングパターンを示す3つの「アラート」URNを割り当てます。
urn:alert:distinctive@foo:long-long
urn:alert:distinctive@foo:short-long-short
urn:alert:distinctive@foo:short-short-long
Later, the company registering the <provider> "bar" wants to define an additional 'alert' URN for the ring pattern "short short", which it uses to support a fourth directory number for a phone instrument.
その後、<provider>の「bar」を登録する会社は、電話パターンの4番目の電話番号をサポートするために使用する呼び出しパターン「short short」の追加の「アラート」URNを定義する必要があります。
The company can create a <private-name> to be used with the "distinctive@foo" <alert-category>:
会社は、 "distinctive @ foo" <alert-category>で使用する<private-name>を作成できます。
urn:alert:distinctive@foo:short-short@bar
This section describes combination rules for the case when all the Alert-Info header fields only contain "alert" URNs. Other combinations of URIs in the Alert-Info header fields of the same SIP message are not defined in this specification.
このセクションでは、すべてのAlert-Infoヘッダーフィールドに「アラート」URNのみが含まれる場合の組み合わせ規則について説明します。同じSIPメッセージのAlert-Infoヘッダーフィールド内のURIの他の組み合わせは、この仕様では定義されていません。
In many cases, more than one URN will be needed to fully define a particular tone. This is done by including multiple "alert" URNs, in one or more Alert-Info header fields in a request or a response. For example, an internal, priority call could be indicated by Alert-Info: <urn:alert:source:internal>, <urn:alert:priority:high>. A priority call-waiting tone could be indicated by Alert-Info: <urn:alert:service:call-waiting>, <urn:alert:priority:high>.
多くの場合、特定のトーンを完全に定義するには、複数のURNが必要になります。これは、要求または応答の1つ以上のAlert-Infoヘッダーフィールドに複数の「アラート」URNを含めることによって行われます。たとえば、内部の優先呼び出しはAlert-Info：<urn：alert：source：internal>、<urn：alert：priority：high>で示されます。優先コールウェイティングトーンは、Alert-Info：<urn：alert：service：call-waiting>、<urn：alert：priority：high>で示すことができます。
The sender of the Alert-Info header field may include an arbitrary list of "alert" URNs, even if they are redundant or contradictory. An earlier URN has priority over any later contradictory URN. This allows any element to modify a list of URNs to require a feature value (by adding a URN at the beginning of the list) or to suggest a feature value (by adding a URN at the end of the list).
Alert-Infoヘッダーフィールドの送信者には、「アラート」URNの任意のリストを含めることができます。以前のURNは、それ以降の矛盾するURNよりも優先されます。これにより、すべての要素がURNのリストを変更して（リストの先頭にURNを追加することにより）機能値を要求したり、（リストの最後にURNを追加することにより）機能値を提案したりできます。
The receiving UA matches the received "alert" URN combination with the signal(s) it is able to render.
受信側UAは、受信した「アラート」URNの組み合わせを、レンダリング可能な信号と照合します。
The implementation is free to ignore an "alert" URN if it does not recognize the URN, or if it is incapable of rendering its effect in the context. Similarly, it can remove a final series of one or more <alert-ind-part>s of an "alert" URN to create a "more generic" URN that it recognizes and whose meaning it can render in the context.
実装は、URNを認識しない場合、またはコンテキストでその効果をレンダリングできない場合、「アラート」URNを自由に無視できます。同様に、「アラート」URNの1つ以上の<alert-ind-part>の最後のシリーズを削除して、認識し、コンテキストでレンダリングできる「より汎用的な」URNを作成できます。
The exact way in which a UA renders a received combination of "alert" URNs is left as an implementation issue. However, the implementation MUST comply to following rules:
UAが受信した「アラート」URNの組み合わせをレンダリングする正確な方法は、実装の問題として残されています。ただし、実装は次の規則に準拠する必要があります。
(a) Each "alert" URN has precedence over all URNs that follow it, and its interpretation is subordinate to all URNs that precede it.
（a）各「アラート」URNは、それに続くすべてのURNよりも優先され、その解釈は、それに先行するすべてのURNに従属します。
(b) If the UA cannot implement the effect of a URN (because it does not recognize the URN or the URN's effect is precluded by preceding URNs), the UA repeatedly removes the final <alert-ind-part> of the URN until either:
（b）UAがURNの効果を実装できない場合（URNを認識しないか、URNの効果が先行するURNによって妨げられているため）、UAは、次のいずれかになるまで、URNの最後の<alert-ind-part>を繰り返し削除します。 ：
(1) the resulting URN is recognized and can be given effect by some signal (without reducing the degree of expression of any preceding URN), or
（1）結果のURNが認識され、何らかの信号によって影響を与えることができます（先行するURNの発現の度合いを低下させることなく）、または
(2) the resulting URN is reduced to having no <alert-ind-part> in which case, that URN in the series cannot be given effect, and so is ignored.
（2）結果のURNは、<alert-ind-part>がないように縮小されます。その場合、シリーズのURNは効果を与えることができないため、無視されます。
(c) In case that after processing all the received URNs, the UA can generate more than one signal that are equally effective at expressing the URNs (under the preceding rules), one of those signals is selected. When selecting from the set of equally effective signals, the least specific signal in the set should be chosen: a signal should not be chosen if a less-specific signal is also in the set. (Specificity is to be judged based on the defined meanings of the signals to the user.) (For example, if each signal is considered to express certain <alert-indication>s of certain <alert-category>s, one signal is less-specific than a second signal if the first signal's <alert-indication>s are a subset or are prefixes of the second signal's <alert-indication>s.) However, a more-specific signal may be chosen if the choice is based on information derived from the containing SIP message. For example, a signal implying <urn:alert:priority:high> may be chosen if the SIP message contains the header field "Priority: urgent".
（c）受信したすべてのURNを処理した後、UAがURNの表現に同等に有効な複数の信号を生成できる場合（前述のルールの下）、それらの信号の1つが選択されます。同等に有効な信号のセットから選択する場合は、セット内の最も特異性の低い信号を選択する必要があります。より特異性の低い信号もセット内にある場合は、信号を選択しないでください。 （特定性は、ユーザーへの信号の定義された意味に基づいて判断されます。）（たとえば、各信号が特定の<alert-category>の特定の<alert-indication>を表すと見なされる場合、1つの信号は少なくなります最初の信号の<alert-indication>がサブセットであるか、2番目の信号の<alert-indication>のプレフィックスである場合、2番目の信号よりも固有です。ただし、選択が以下に基づいている場合は、より具体的な信号を選択できます。含まれているSIPメッセージから派生した情報。たとえば、SIPメッセージにヘッダーフィールド「Priority：urgent」が含まれている場合、<urn：alert：priority：high>を意味する信号を選択できます。
In all situations, the set of signals that can be rendered and their significances may change based on user preferences and local policy. In addition, the chosen signal may change based on the status of the UA. For example, if a call is active on the UA, all audible signals may become unavailable, or audible signals may be available only if <urn:alert:priority:high> is specified.
すべての状況で、レンダリングできる信号のセットとその重要性は、ユーザー設定とローカルポリシーに基づいて変化する可能性があります。さらに、選択した信号は、UAのステータスに基づいて変化する場合があります。たとえば、UAで通話がアクティブな場合、すべての可聴信号が利用できなくなったり、<urn：alert：priority：high>が指定されている場合にのみ可聴信号が利用可能になる場合があります。
There are cases when the device can render two signal modes (e.g., audio and visual, or video and text) at the same time.
デバイスが2つの信号モード（オーディオとビジュアル、またはビデオとテキストなど）を同時にレンダリングできる場合があります。
Formally, the device must be considered to be making its choice from the set of all combined signals that it can render (pairs of one signal from the first mode and one signal from the second mode), and that choice must conform to the above rules. However, it can be proven that if the device makes its rendering choice for each of the two modes independently, with each choice separately conforming to the above rules, its combined choice also conforms to the above rules, when it is regarded as a choice from among all possible combinations.
正式には、デバイスは、レンダリングできるすべての組み合わせ信号のセット（最初のモードからの1つの信号と2番目のモードからの1つの信号のペア）から選択していると見なされる必要があり、その選択は上記のルールに準拠する必要があります。ただし、デバイスが2つのモードのそれぞれについてレンダリングの選択を個別に行い、各選択が上記のルールに個別に準拠している場合、その組み合わせの選択も上記のルールに準拠し、すべての可能な組み合わせの中で。
In such a situation, it may simplify implementation to make each choice separately. It is an implementation decision whether to chose from among combined signals or to combine choices made from each signal mode.
このような状況では、各選択を個別に行うことで実装を簡素化できます。信号の組み合わせから選択するか、各信号モードからの選択を組み合わせるかは、実装の決定です。
The following text is a non-normative example of an algorithm for handling combinations of URNs that complies with the rules in Sections 10 and 11. Thus, it demonstrates that the rules are consistent and implementable. (Of course, a device may use any other algorithm that complies with Sections 10 and 11.)
次のテキストは、セクション10および11の規則に準拠するURNの組み合わせを処理するためのアルゴリズムの非規範的な例です。したがって、規則が一貫しており、実装可能であることを示しています。 （もちろん、デバイスはセクション10と11に準拠する他のアルゴリズムを使用できます。）
For each <alert-category> (feature) known by the implementation, there is a "feature tree" of the known <alert-indication>s for that <alert-category>, with the sequence of <alert-ind-part>s in an <alert-indication> specifying the path in the tree from the root to the node representing the <alert-indication>. For this description, we will name each tree and its root node by the <alert-category> name, and name each non-root node by the <alert-identifier>. Each URN thus corresponds to one non-root node in one feature tree. For example, there is a tree named "source", whose root node is also named "source", and which has the children source:internal, source:external, source:friend, and source:family. The URN <urn:alert:source:external> is placed at the node "source:external" in the "source" tree. If the implementation understands <urn:alert:source:foo@example>, there is a node source:foo@example that is a child of node "source". If the implementation understands <urn:alert:source:external:bar@example>, there is a node source:external:bar@example that is a child of node source:external. (Of course, there are an infinite number of potential additional nodes in the tree for private values, but we don't have to represent those nodes explicitly unless the device has a signal representing the private value.)
実装によって認識されている各<alert-category>（機能）には、その<alert-category>の既知の<alert-indication>の「機能ツリー」があり、<alert-ind-part>のシーケンスがあります。 ■<alert-indication>内のルートから、<alert-indication>を表すノードまでのツリー内のパスを指定します。この説明では、各ツリーとそのルートノードに<alert-category>の名前を付け、非ルートノードに<alert-identifier>の名前を付けます。したがって、各URNは1つの機能ツリー内の1つの非ルートノードに対応します。たとえば、「source」という名前のツリーがあり、そのルートノードも「source」という名前で、source：internal、source：external、source：friend、source：familyという子があります。 URN <urn：alert：source：external>は、「ソース」ツリーのノード「source：external」に配置されます。実装が<urn：alert：source：foo @ example>を理解している場合、ノード "source"の子であるノードsource：foo @ exampleがあります。実装が<urn：alert：source：external：bar @ example>を理解している場合、ノードsource：external：bar @ exampleがあり、ノードsource：externalの子です。 （もちろん、プライベート値のツリーには潜在的な追加ノードが無数にありますが、デバイスにプライベート値を表す信号がない限り、これらのノードを明示的に表す必要はありません。）
We assign similar locations to signals, but each signal has a position in *every* tree, describing the specific combination of meanings that it carries. If a signal has a simple meaning, such as "external source", its place in the "source" tree is source:external, showing that it carries the "external source" meaning, but its place in every other feature tree is at the root node, meaning that it has no particular meaning for those features.
同様の場所を信号に割り当てますが、各信号は、ツリーごとに位置を持ち、それが持つ意味の特定の組み合わせを記述します。信号に「外部ソース」などの単純な意味がある場合、「ソース」ツリー内のその場所はsource：externalであり、「外部ソース」という意味を持つことを示しますが、他のすべての機能ツリー内の場所はルートノード。これは、これらの機能に対して特定の意味がないことを意味します。
A signal that has a complex meaning may have non-root positions in more than one feature tree. For example, an "external, high priority" signal would be placed at source:external and priority:high in those trees, but be at the root in all other feature trees.
複雑な意味を持つ信号は、複数の機能ツリーでルート以外の位置にある場合があります。たとえば、「外部、高優先度」の信号は、これらのツリーではsource：externalおよびpriority：highに配置されますが、他のすべての機能ツリーではルートに配置されます。
In order to assure that the algorithm always selects at least one signal, we require that there is a "default" signal, whose position in every feature tree is at the root. This default signal will never be excluded from the set of acceptable signals for any set of URNs, but will be the lowest priority signal for any set of URNs.
アルゴリズムが常に少なくとも1つの信号を選択することを保証するために、すべての機能ツリーでの位置がルートにある「デフォルト」信号が必要です。このデフォルトの信号は、URNのセットの受け入れ可能な信号のセットから除外されることはありませんが、URNのセットの優先順位が最も低い信号になります。
The algorithm proceeds by considering each URN in the received Alert-Info header fields from left to right, while revising a set of signals. The set of signals starts as the entire set of signals available to the device. Each URN excludes some signals from the set, and "sorts" the signals that remain in the set according to how well they represent the URN. (The details of these operations are described below.) The first URN is the "major sort", and has the most influence on the position of a signal in the set. The second URN is a "minor sort", in that it arranges the orders of the signals that are tied within the first sort, the third URN arranges the orders of the signals that are tied within the first two sorts, etc.
アルゴリズムは、受信したAlert-Infoヘッダーフィールドの各URNを左から右に検討しながら進行し、一連の信号を修正します。信号のセットは、デバイスで使用できる信号のセット全体として始まります。各URNは、一部の信号をセットから除外し、それらがURNをどの程度適切に表しているかに従って、セットに残っている信号を「ソート」します。 （これらの操作の詳細については以下で説明します。）最初のURNは「メジャーソート」であり、セット内の信号の位置に最も影響を与えます。 2番目のURNは「マイナーソート」であり、最初のソート内で結び付けられている信号の順序を整理し、3番目のURNは最初の2つの並べ替え内で結び付けられている信号の順序を並べ替えます。
At the end of the algorithm, a final, "most minor" sort is done, which orders the signals that remain tied under all the sorts driven by the URNs. This final sort places the least specific signals (within their tied groups) "first". (If one signal's position in each feature tree is ancestral or the same as a second signal's position in that tree, the first signal is "less specific" than the second signal. Other cases are left to the implementation to decide.)
アルゴリズムの最後に、最後の「最もマイナーな」ソートが実行され、URNによって駆動されるすべてのソートの下で結合されたままの信号が順序付けられます。この最後の並べ替えでは、（特定のグループ内の）最も固有性の低い信号が「最初」に配置されます。 （各機能ツリー内の1つの信号の位置が祖先であるか、またはそのツリー内の2番目の信号の位置と同じである場合、最初の信号は2番目の信号よりも「特定性が低い」。他のケースは実装に任されます。）
Once all the URNs are processed and the sorting of the signals that have not been excluded is done, the device selects the first signal in the set.
すべてのURNが処理され、除外されていない信号の並べ替えが完了すると、デバイスはセット内の最初の信号を選択します。
Here is how a single sort step proceeds, examining a single URN to modify the set of signals (by excluding some signals and further sorting the signals that remain):
これは、単一の並べ替え手順がどのように進行するかであり、単一のURNを調べて信号のセットを変更します（一部の信号を除外し、残っている信号をさらに並べ替えます）。
o The URN specifies a specific node in a specific feature tree.
o URNは、特定の機能ツリー内の特定のノードを指定します。
o All signals in the set that are, within that feature tree, positioned at the URN's node, or at an ancestor node of the URN's node, are kept. All other signals are removed from the set (because they have meanings that are incompatible with the URN's meaning).
o その機能ツリー内でURNのノードまたはURNのノードの祖先ノードに配置されているセット内のすべての信号が保持されます。他のすべての信号はセットから削除されます（それらの意味はURNの意味と互換性がないため）。
o Each group of signals that are tied under the previous sorts are further sorted into groups based on how much of the URN's meaning they represent: those which are positioned at the node of the URN are tied for first position, those which are positioned at the parent node of the URN are tied for second position, etc., and those which are positioned at the root node of the feature tree are tied for last position.
o 前の並べ替えで関連付けられた信号の各グループは、それらが表すURNの意味に基づいてグループにさらに並べ替えられます。URNのノードに配置されている信号は最初の位置に関連付けられており、親に配置されている信号です。 URNのノードは2番目の位置などに関連付けられ、機能ツリーのルートノードに配置されているノードは最後の位置に関連付けられます。
The following examples show how the algorithm described in the previous section works:
次の例は、前のセクションで説明したアルゴリズムがどのように機能するかを示しています。
The device has a set of four alerting signals. We list their primary meanings, and the locations that they are placed in the feature trees:
デバイスには、4つのアラート信号のセットがあります。それらの主要な意味と、それらが機能ツリーに配置される場所をリストします。
Signal 1
信号1
Meaning: external Locations: - source:external - priority (that is, the root node of the priority tree)
意味：外部の場所：-source：external-優先度（つまり、優先度ツリーのルートノード）
Signal 2
信号2
Meaning: internal Locations: - source:internal - priority
意味：内部の場所：-ソース：内部-優先度
Signal 3
信号3
Meaning: low Locations: - source - priority:low
意味：低場所：-ソース-優先度：低
Signal 4
信号4
Meaning: high Locations: - source - priority:high
意味：高場所：-ソース-優先度：高
To which we add:
追加するもの：
Signal 5
信号5
Meaning: default Locations: - source - priority
意味：デフォルトの場所：-ソース-優先度
If the device receives <urn:alert:source:internal>, then the sort is:
デバイスが<urn：alert：source：internal>を受信した場合、並べ替えは次のようになります。
Signals at source:internal: (this is, first place)
ソースの信号：内部：（これは最初の場所です）
Signal 2: internal
信号2：内部
Signals at source: (tied for second place)
ソースでの信号：（2位に結び付けられています）
Signal 3: low Signal 4: high Signal 5: default
信号3：低信号4：高信号5：デフォルト
And these signals are excluded from the set:
そして、これらの信号はセットから除外されます：
Signal 1: external
信号1：外部
So, in this example, the sorting algorithm properly gives first place to Signal 2 "internal".
したがって、この例では、並べ替えアルゴリズムは、Signal 2の「内部」を適切に1位にします。
Let us add to the set of signals in Example 1 ones that express combinations like "internal, high priority", but let us specifically exclude the combination "internal, low priority" so as to set up some tricky examples. This enlarges our set of signals:
例1の信号のセットに「内部、高優先度」のような組み合わせを表すものを追加しますが、いくつかのトリッキーな例を設定するために、「内部、低優先度」の組み合わせを特に除外します。これにより、一連の信号が拡大されます。
Signal 1
信号1
Meaning: default Locations: - source - priority
意味：デフォルトの場所：-ソース-優先度
Signal 2
信号2
Meaning: external Locations: - source:external - priority
意味：外部の場所：-ソース：外部-優先度
Signal 3
信号3
Meaning: internal Locations: - source:internal - priority
意味：内部の場所：-ソース：内部-優先度
Signal 4
信号4
Meaning: low Locations: - source - priority:low
意味：低場所：-ソース-優先度：低
Signal 5
信号5
Meaning: high Locations: - source - priority:high
意味：高場所：-ソース-優先度：高
Signal 6
信号6
Meaning: external high Locations: - source:external - priority:high
意味：外部の高い場所：-ソース：外部-優先度：高
Signal 7
信号7
Meaning: external low Locations: - source:external - priority:low
意味：外部の低い場所：-ソース：外部-優先度：低
Signal 8
信号8
Meaning: internal high Locations: - source:internal - priority:high
意味：内部の高い場所：-ソース：内部-優先度：高
If the device receives <urn:alert:source:internal>, then the sort is:
デバイスが<urn：alert：source：internal>を受信した場合、並べ替えは次のようになります。
Signals at source:internal: (that is, tied for first place)
ソースの信号：内部：（つまり、最初の場所に関連付けられています）
- Signal 3: internal - Signal 8: internal high
- 信号3：内部-信号8：内部高
Signals at source: (tied for second place)
ソースでの信号：（2位に結び付けられています）
- Signal 4: low - Signal 5: high - Signal 1: default
- 信号4：低-信号5：高-信号1：デフォルト
Signals excluded from the set:
セットから除外された信号：
- Signal 2: external - Signal 7: external low - Signal 6: external high
- 信号2：外部-信号7：外部低-信号6：外部高
Two signals are tied for the first place, but the final sort orders them:
そもそも2つのシグナルが結びついていますが、最終的な並べ替えはそれらを並べ替えます。
- Signal 3: internal - Signal 8: internal high
- 信号3：内部-信号8：内部高
because it puts the least-specific signal first. So, the Signal 3 "internal" is chosen.
最も固有性の低い信号が最初に配置されるためです。したがって、信号3の「内部」が選択されます。
The same device receives <urn:alert:source:external>, <urn:alert:priority:low>. The first sort (due to <urn:alert:source:external>) is:
同じデバイスが<urn：alert：source：external>、<urn：alert：priority：low>を受信します。最初のソート（<urn：alert：source：external>による）は次のとおりです。
Signals at source:external:
ソースの信号：外部：
- Signal 2: external - Signal 7: external low - Signal 6: external high
- 信号2：外部-信号7：外部低-信号6：外部高
Signals at source:
ソースでの信号：
- Signal 4: low - Signal 5: high - Signal 1: default
- 信号4：低-信号5：高-信号1：デフォルト
Signals excluded:
除外される信号：
- Signal 3: internal - Signal 8: internal high
- 信号3：内部-信号8：内部高
The second sort (due to <urn:alert:priority:low>) puts signals at priority:low before signals at priority, and excludes signal at priority:high:
2番目の並べ替え（<urn：alert：priority：low>による）は、信号をpriority：lowにしてから信号をpriorityに置き、priority：highにある信号を除外します。
- Signal 7: external low - Signal 2: external - Signal 4: low - Signal 1: default
- 信号7：外部低-信号2：外部-信号4：低-信号1：デフォルト
Excluded:
除外：
- Signal 6: external high - Signal 5: high - Signal 3: internal - Signal 8: internal high
- 信号6：外部高-信号5：高-信号3：内部-信号8：内部高
So, we choose Signal 7 "external low".
したがって、Signal 7の「external low」を選択します。
Suppose the same device receives <urn:alert:source:internal>, <urn:alert:priority:low>. Note that there is no signal that corresponds to this combination.
同じデバイスが<urn：alert：source：internal>、<urn：alert：priority：low>を受信するとします。この組み合わせに対応する信号がないことに注意してください。
The first sort is based on source:internal, and results in this order:
最初のソートは、source：internalに基づいており、結果は次の順序になります。
- Signal 3: internal - Signal 8: internal high - Signal 4: low - Signal 5: high - Signal 1: default
- 信号3：内部-信号8：内部高-信号4：低-信号5：高-信号1：デフォルト
Excluded:
除外：
- Signal 2: external - Signal 7: external low - Signal 6: external high
- 信号2：外部-信号7：外部低-信号6：外部高
The second sort is based on priority:low, and results in this order:
2番目のソートは、priority：lowに基づいており、次の順序になります。
- Signal 3: internal - Signal 4: low - Signal 1: default
- 信号3：内部-信号4：低-信号1：デフォルト
Excluded:
除外：
- Signal 8: internal high - Signal 5: high - Signal 7: external low - Signal 2: external - Signal 6: external high
- 信号8：内部高-信号5：高-信号7：外部低-信号2：外部-信号6：外部高
So, we choose the Signal 3 "internal".
したがって、信号3の「内部」を選択します。
Note that <urn:alert:priority:low> could not be given effect because it followed <urn:alert:source:internal>. If the two URNs had appeared in the reverse order, the Signal 2 "external" would have been chosen, because <urn:alert:priority:low> would have been given precedence.
<urn：alert：priority：low>は<urn：alert：source：internal>に続いているため、効果が得られないことに注意してください。 2つのURNが逆の順序で出現した場合、<urn：alert：priority：low>が優先されるため、シグナル2の「外部」が選択されます。
Let us set up a simple set of signals, with three signals giving priority:
次の3つの信号を優先して、単純な信号のセットを設定してみましょう。
Signal 1
信号1
Meaning: default Locations: - priority
意味：デフォルトの場所：-優先度
Signal 2
信号2
Meaning: low Locations: - priority:low
意味：低場所：-優先度：低
Signal 3
信号3
Meaning: high Locations: - priority:high
意味：高場所：-優先度：高
Notice that we've used the "default" signal to cover "normal priority". That is so the signal will cover situations where no priority URN is present, as well as the ones with <urn:alert:priority:normal>. So, we're deliberately failing to distinguish "priority:normal" from the default priority.
「デフォルト」信号を使用して「通常の優先度」をカバーしていることに注意してください。つまり、シグナルは、優先URNが存在しない状況と、<urn：alert：priority：normal>の状況をカバーします。したがって、「priority：normal」とデフォルトの優先度を区別することは意図的に失敗しています。
If the device receives <urn:alert:priority:low>, the sort is:
デバイスが<urn：alert：priority：low>を受信した場合、ソートは次のとおりです。
- Signal 2: low - Signal 1: default
- 信号2：低-信号1：デフォルト
Excluded:
除外：
- Signal 3: high
- 信号3：高
and Signal 2 "low" is chosen.
信号2「低」が選択されています。
Similarly, if the device receives <urn:alert:priority:high>, Signal 3 is chosen.
同様に、デバイスが<urn：alert：priority：high>を受信した場合、信号3が選択されます。
If the device receives <urn:alert:priority:normal>, the sort is:
デバイスが<urn：alert：priority：normal>を受信した場合、ソートは次のとおりです。
-Signal 1 :default
-Signal 1：デフォルト
Excluded:
除外：
- Signal 2: low - Signal 3: high
- 信号2：低-信号3：高
and Signal 1 "default" is chosen.
信号1の「デフォルト」が選択されています。
If no "priority" URN is received, Signal 1 "default" will be put before Signal 2 "low" and Signal 3 "high" by the final sort, and so it will be chosen.
「優先度」のURNが受信されない場合、シグナル1の「デフォルト」がシグナル2の「低」およびシグナル3の「高」の前に配置され、最終的にソートされます。
A SIP UA MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to provide additional information about the call or about the provided service.
SIP UAは、コールまたは提供されたサービスに関する追加情報を提供する必要がある場合、SIPリクエストまたは暫定1xx応答（100応答を除く）のAlert-InfoヘッダーフィールドにURNまたは複数のURNを追加できます（MAY）。
Upon receiving a SIP INVITE request or a SIP provisional response with an Alert-Info header field that contains a combination of Alert-Info URNs, the UA attempts to match the received Alert- Info URNs combination with a signal it can render. The process the UA uses MUST conform to the rules described in Section 11. (A non-normative algorithm example for the process is described in Section 12.)
UAは、Alert-Info URNの組み合わせを含むAlert-Infoヘッダーフィールドを含むSIP INVITE要求またはSIP暫定応答を受信すると、受信したAlert-Info URNの組み合わせをレンダリング可能な信号と照合しようとします。 UAが使用するプロセスは、セクション11で説明されているルールに準拠する必要があります（プロセスの非規範的アルゴリズムの例はセクション12で説明されています）。
The UA must produce a reasonable rendering regardless of the combination of URIs (of any schemes) in the Alert-Info header field: it MUST produce a rendering based on the URIs that it can understand and act on (if any), interpreted as prescribed by local policy, and ignore the other URIs. In particular, unless the containing message is a request and is immediately rejected, the UA SHOULD provide some alert unless it is instructed not to (for example, by Alert-Info URIs that it understands, the presence of a Replaces or Joins header field, local policy, or direction of the user).
UAは、Alert-Infoヘッダーフィールド内の（スキームの）URIの組み合わせに関係なく、適切なレンダリングを生成する必要があります：規定どおりに解釈され、（もしあれば）理解して動作できるURIに基づいてレンダリングを生成する必要がありますローカルポリシーによって、他のURIを無視します。特に、含まれているメッセージが要求であり、すぐに拒否されない限り、UAは、通知されない限り（たとえば、Alert-Info URIが理解している、ReplacesまたはJoinsヘッダーフィールドの存在によって）、アラートを提供する必要があります。ローカルポリシー、またはユーザーの指示）。
Subsequent provisional responses, even within the same dialog, may contain different Alert-Info header field values. The Alert-Info header field values received within different provisional responses are treated independently. If subsequent provisional responses containing different Alert-Info header field values were received within the same dialog, the UA SHOULD render, at any time, the last received Alert-Info header field value. The handling of provisional responses containing different Alert-Info header field values that were not received within the same dialog is left as an implementation issue.
同じダイアログ内でも、後続の暫定応答には、異なるAlert-Infoヘッダーフィールド値が含まれる場合があります。異なる暫定応答内で受信されたAlert-Infoヘッダーフィールド値は、個別に処理されます。異なるAlert-Infoヘッダーフィールド値を含む後続の暫定応答が同じダイアログ内で受信された場合、UAはいつでも、最後に受信されたAlert-Infoヘッダーフィールド値をレンダリングする必要があります（SHOULD）。同じダイアログ内で受信されなかったさまざまなAlert-Infoヘッダーフィールド値を含む暫定応答の処理は、実装の問題として残されます。
A SIP proxy MAY add or remove an Alert-Info header field, and MAY add or remove Alert-Info header field values, in a SIP request or a non-100 provisional response when it needs to modify the information about the call or about the provided services.
SIPプロキシは、SIPリクエストまたは100以外の暫定応答で、コールまたはに関する情報を変更する必要がある場合に、Alert-Infoヘッダーフィールドを追加または削除することができます（MAY）。提供されたサービス。
There are many reasons a proxy may choose do this, for example, (1) to add indications based on information that the proxy can determine about the call, such as that it is coming from an external source, or that the INVITE contains a "Priority: urgent" header field; (2) to add indication that a particular service is being invoked at this end of the call; (3) to remove undesirable indications, such as possibly deceptive indications from untrusted sources; and (4) to remove indications that contain information that should be suppressed for privacy reasons.
プロキシがこれを行うことを選択する理由はたくさんあります。たとえば、（1）外部ソースからのものである、またはINVITEに "優先度：緊急」ヘッダーフィールド。 （2）特定のサービスが呼び出しのこの終わりに呼び出されていることの表示を追加します。 （3）信頼できないソースからの可能性のある不正な表示など、望ましくない表示を削除する。 （4）プライバシー上の理由で抑制すべき情報を含む表示を削除する。
The following example shows a typical example of a 180 (Ringing) provisional response that has been modified by a proxy. The response sent by the UAS to the proxy was very similar, but had no Alert-Info header field. The proxy has added Alert-Info header field values specifying both a network audio resource referenced by the HTTP URI and the URN indication for the call-waiting service. This allows the UAC to render the network audio resource, to choose a rendering based on the URN, or to perform some combination of these actions. Due to Section 10, the UAC must produce some reasonable rendering in this situation.
次の例は、プロキシによって変更された180（Ringing）暫定応答の典型的な例を示しています。 UASからプロキシに送信される応答は非常に似ていますが、Alert-Infoヘッダーフィールドがありませんでした。プロキシには、HTTP URIによって参照されるネットワークオーディオリソースと、キャッチホンサービスのURN表示の両方を指定するAlert-Infoヘッダーフィールド値が追加されています。これにより、UACはネットワークオーディオリソースをレンダリングしたり、URNに基づいてレンダリングを選択したり、これらのアクションのいくつかの組み合わせを実行したりできます。セクション10により、UACはこの状況で妥当なレンダリングを生成する必要があります。
SIP/2.0 180 Ringing
Alert-Info: <http://www.example.com/sound/moo.wav>,
<urn:alert:service:call-waiting>
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Via: SIP/2.0/UDP server10.biloxi.example.com;
branch=z9hG4bK4b43c2ff8.1
Content-Length: 0
The <alert-identifier> labels are protocol elements [RFC6365] and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 7.
<alert-identifier>ラベルはプロトコル要素[RFC6365]であり、通常ユーザーには表示されません。したがって、セクション7で説明するように、これらの要素の文字セットは制限されています。
Allowance has been made for the possibility of internationalizing <alert-identifier>s by allowing them to be A-labels: a processor that does not understand such <alert-identifier>s is required to ignore them as specified in Sections 7 and 11.1.
<alert-identifier>をAラベルにすることで、<alert-identifier>を国際化できるようになりました。このような<alert-identifier>を認識しないプロセッサは、セクション7および11.1で指定されているように、それらを無視する必要があります。
The URNs <urn:alert:locale:country:<ISO 3166-1 country code>> select renderings that are conventional in the specified country.
URN <urn：alert：locale：country：<ISO 3166-1国コード>>は、指定された国で一般的なレンダリングを選択します。
As an identifier, the "alert" URN does not appear to raise any particular security issues. The indications described by the "alert" URN are meant to be well-known.
識別子として、「アラート」URNは特定のセキュリティ問題を引き起こさないようです。 「アラート」URNによって示される表示は、よく知られていることを意味します。
However, the provision of specific indications may raise privacy issues by revealing information about the source UA, e.g., its nature, its dialog state, or services initiated at its end of the call. For example, call-waiting (Section 6.2.1) and call-forwarding (Section 6.2.2) services can reveal the dialog state of the UA. Such a provision SHALL always require authorization on behalf of the user of the source UA (usually through accessing configured policy). Authorization SHALL NOT assume that there is any limitation of the potential recipients of the indications without obtaining specific information about the SIP transaction.
ただし、特定の指示を提供すると、発信元UAに関する情報、たとえばその性質、ダイアログの状態、または通話の終了時に開始されたサービスが明らかになるため、プライバシーの問題が発生する可能性があります。たとえば、コールウェイティング（セクション6.2.1）およびコールフォワーディング（セクション6.2.2）サービスは、UAのダイアログ状態を明らかにすることができます。そのような規定は常に、ソースUAのユーザーに代わって（通常は構成されたポリシーへのアクセスを通じて）承認を必要とします。認可は、SIPトランザクションに関する特定の情報を取得せずに、通知の潜在的な受信者に何らかの制限があることを想定してはなりません。
Based on local policy, a UA MAY choose to ignore undesirable indications (e.g., possibly deceptive indications from untrusted sources), and it MAY choose not to send indications that are otherwise valid in the context (e.g., for privacy reasons). A proxy acting on behalf of a UA MAY add or delete indications going to or from the UA for the same reasons.
ローカルポリシーに基づいて、UAは望ましくない兆候（たとえば、信頼できないソースからの不正な兆候など）を無視することを選択してもよい（MAY）、また、コンテキスト（プライバシー上の理由など）で有効な指示を送信しないことを選択してもよい（MAY）。 UAに代わって動作するプロキシは、同じ理由でUAに出入りする表示を追加または削除する場合があります。
Since the alert indications can be sensitive, end-to-end SIP encryption mechanisms using S/MIME MAY be used to protect it. UAs that implement alert indications SHOULD also implement SIP over TLS [RFC5246] and the sips: scheme [RFC5630].
アラートの表示は機密である可能性があるため、S / MIMEを使用したエンドツーエンドのSIP暗号化メカニズムを使用して保護することができます（MAY）。アラート表示を実装するUAは、SIP over TLS [RFC5246]およびsips：スキーム[RFC5630]も実装する必要があります（SHOULD）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC2141] Moats、R。、「URN Syntax」、RFC 2141、1997年5月、<http://www.rfc-editor.org/info/rfc2141>。
[RFC3261] 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, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002, <http://www.rfc-editor.org/info/rfc3406>.
[RFC3406] Daigle、L.、van Gulik、D.、Iannella、R。、およびP. Faltstrom、「Uniform Resource Names（URN）Namespace Definition Mechanisms」、BCP 66、RFC 3406、2002年10月、<http：// www.rfc-editor.org/info/rfc3406>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月、<http://www.rfc-editor.org/info/rfc5246>。
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009, <http://www.rfc-editor.org/info/rfc5630>.
[RFC5630]オーデットF.、「セッション開始プロトコル（SIP）でのSIPS URIスキームの使用」、RFC 5630、2009年10月、<http://www.rfc-editor.org/info/rfc5630>。
[E182] ITU-T, "Application of tones and recorded announcements in telephone services", ITU-T Recommendation E.182, 1998, <http://www.itu.int/rec/T-REC-E.182-199803-I/en>.
[E182] ITU-T、「トーンの適用と電話サービスでのアナウンスの記録」、ITU-T勧告E.182、1998、<http://www.itu.int/rec/T-REC-E.182- 199803-I / en>。
[ISO3166-1] ISO, "English country names and code elements", ISO 3166-1, <http://www.iso.org/iso/ english_country_names_and_code_elements>.
[ISO3166-1] ISO、「英語の国名とコード要素」、ISO 3166-1、<http://www.iso.org/iso/ english_country_names_and_code_elements>。
[RFC3043] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001, <http://www.rfc-editor.org/info/rfc3043>.
[RFC3043] Mealling、M。、「The Network Solutions Personal Internet Name（PIN）：A URN Namespace for People and Organizations」、RFC 3043、2001年1月、<http://www.rfc-editor.org/info/rfc3043 >。
[RFC3044] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001, <http://www.rfc-editor.org/info/rfc3044>.
[RFC3044] Rozenfeld、S。、「ISSN-URN名前空間内でUSN（Uniform Resource Names）としてISSN（国際シリアル標準番号）を使用する」、RFC 3044、2001年1月、<http：//www.rfc-editor。 org / info / rfc3044>。
[RFC3120] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120, June 2001, <http://www.rfc-editor.org/info/rfc3120>.
[RFC3120] Best、K. and N. Walsh、 "A URN Namespace for XML.org"、RFC 3120、June 2001、<http://www.rfc-editor.org/info/rfc3120>。
[RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001, <http://www.rfc-editor.org/info/rfc3187>.
[RFC3187] Hakala、J.およびH. Walravens、「Using International Standard Book Numbers as Uniform Resource Names」、RFC 3187、2001年10月、<http://www.rfc-editor.org/info/rfc3187>。
[RFC3188] Hakala, J., "Using National Bibliography Numbers as Uniform Resource Names", RFC 3188, October 2001, <http://www.rfc-editor.org/info/rfc3188>.
[RFC3188] Hakala、J。、「Using National Bibliography Numbers as Uniform Resource Names」、RFC 3188、2001年10月、<http://www.rfc-editor.org/info/rfc3188>。
[RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code", RFC 4152, August 2005, <http://www.rfc-editor.org/info/rfc4152>.
[RFC4152] Tesink、K。およびR. Fox、「Common Language Equipment Identifier（CLEI）コードのUniform Resource Name（URN）名前空間」、RFC 4152、2005年8月、<http：//www.rfc-editor。 org / info / rfc4152>。
[RFC4179] Kang, S., "Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)", RFC 4179, October 2005, <http://www.rfc-editor.org/info/rfc4179>.
[RFC4179] Kang、S。、「Using Universal Content Identifier（UCI）as Uniform Resource Names（URN）」、RFC 4179、2005年10月、<http://www.rfc-editor.org/info/rfc4179>。
[RFC4195] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum", RFC 4195, October 2005, <http://www.rfc-editor.org/info/rfc4195>.
[RFC4195]亀山W。、「TV-AnytimeフォーラムのUniform Resource Name（URN）名前空間」、RFC 4195、2005年10月、<http://www.rfc-editor.org/info/rfc4195>。
[RFC4198] Tessman, D., "A Uniform Resource Name (URN) Namespace for Federated Content", RFC 4198, November 2005, <http://www.rfc-editor.org/info/rfc4198>.
[RFC4198] Tessman、D。、「フェデレーションコンテンツ用のUniform Resource Name（URN）名前空間」、RFC 4198、2005年11月、<http://www.rfc-editor.org/info/rfc4198>。
[RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009, <http://www.rfc-editor.org/info/rfc5589>.
[RFC5589] Sparks、R.、Johnston、A。、およびD. Petrie、「Session Initiation Protocol（SIP）Call Control-Transfer」、BCP 149、RFC 5589、2009年6月、<http：//www.rfc-editor .org / info / rfc5589>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J。、「Internationalized Domain Names for Applications（IDNA）：Definitions and Document Framework」、RFC 5890、2010年8月、<http://www.rfc-editor.org/info/rfc5890>。
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011, <http://www.rfc-editor.org/info/rfc6365>.
[RFC6365] Hoffman、P。およびJ. Klensin、「IETFの国際化で使用される用語」、BCP 166、RFC 6365、2011年9月、<http://www.rfc-editor.org/info/rfc6365>。
[RFC6910] Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev, "Completion of Calls for the Session Initiation Protocol (SIP)", RFC 6910, April 2013, <http://www.rfc-editor.org/info/rfc6910>.
[RFC6910] Worley、D.、Huelsemann、M.、Jesske、R。、およびD. Alexeitsev、「Completion of Calls for the Session Initiation Protocol（SIP）」、RFC 6910、2013年4月、<http：// www。 rfc-editor.org/info/rfc6910>。
[RFC7463] Johnston, A., Ed., Soroushnejad, M., Ed., and V. Venkataramanan, "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", RFC 7463, March 2015, <http://www.rfc-editor.org/info/rfc7463>.
[RFC7463] Johnston、A.、Ed。、Soroushnejad、M.、Ed。、and V. Venkataramanan、 "Shared Appearances of a Session Initiation Protocol（SIP）Address of Record（AOR）"、RFC 7463、March 2015、< http://www.rfc-editor.org/info/rfc7463>。
[TS24.615] 3GPP, "Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol Specification", 3GPP TS 24.615, September 2015.
[TS24.615] 3GPP、「IPマルチメディア（IM）コアネットワーク（CN）サブシステムを使用した通信待機（CW）、プロトコル仕様」、3GPP TS 24.615、2015年9月。
Acknowledgements
謝辞
The authors wish to thank Denis Alexeitsev, the editor of the initial version in BLISS, Anwar Siddiqui for his contributions to the document, Christer Holmberg for his careful review of the document, Adam Roach, Dean Willis, Martin Huelsemann, Shida Schubert, John Elwell, and Tom Taylor for their comments and suggestions and Alfred Hoenes for his extensive comments and proposals related to new namespace identifiers for URNs.
著者は、BLISSの初期バージョンの編集者であるDenis Alexeitsev、ドキュメントへの貢献に対するAnwar Siddiqui、ドキュメントの注意深いレビューに対するChrister Holmberg、Adam Roach、Dean Willis、Martin Huelsemann、Shida Schubert、John Elwellに感謝します。 、およびコメントと提案についてはTom Taylor、URNの新しい名前空間識別子に関連する彼の広範なコメントと提案についてはAlfred Hoenes。
Authors' Addresses
著者のアドレス
Laura Liess (editor) Deutsche Telekom AG Heinrich-Hertz Str 3-7 Darmstadt, Hessen 64295 Germany
Laura Liess（編集者）Deutsche Telekom AG Heinrich-Hertz Str 3-7ダルムシュタットヘッセン州ドイツ
Phone: +49 6151 5812761
EMail: laura.liess.dt@gmail.com
Roland Jesske Deutsche Telekom AG Heinrich-Hertz Str. 3-7 Darmstadt, Hessen 64295 Germany
Roland Jesske Deutsche Telekom AG Heinrich-Hertz Str。3-7 Darmstadt、Hessen 64295 Germany
Phone: +49 6151 5812766
EMail: r.jesske@telekom.de
Alan Johnston Avaya, Inc. St. Louis, MO United States
Alan Johnston Avaya、Inc.セントルイス、ミズーリ州アメリカ合衆国
EMail: alan.b.johnston@gmail.com
Dale R. Worley Ariadne Internet Services, Inc. 738 Main St. Waltham, MA 02451 United States
Dale R. Worley Ariadne Internet Services、Inc. 738 Main St. Waltham、MA 02451 United States
Phone: +1 781 647 9199
EMail: worley@ariadne.com
Paul Kyzivat Huawei United States
Paul Kyzivat Huaweiアメリカ合衆国
EMail: pkyzivat@alum.mit.edu