RFC 5628 - Registration Event Package Extension for Session Initiation Protocol (SIP) Globally Routable User Agent URIs (GRUUs) 日本語訳

URL : https://tools.ietf.org/html/rfc5628
タイトル : RFC 5628 - セッション開始プロトコル（SIP）グローバルにルーティング可能なユーザエージェントのURI（GRUUs）の登録イベントパッケージ拡張
翻訳編集 : 自動生成

Network Working Group                                         P. Kyzivat
Request for Comments: 5628                           Cisco Systems, Inc.
Category: Standards Track                                   October 2009

               Registration Event Package Extension for
                   Session Initiation Protocol (SIP)
               Globally Routable User Agent URIs (GRUUs)

Abstract

抽象

RFC 3680 defines a Session Initiation Protocol (SIP) event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including its registered contact.

RFC 3680には、登録状態のためのセッション開始プロトコル（SIP）イベントパッケージを定義します。このパッケージには、ウォッチャーは、その登録の接触を含むSIPレジストラによって保存された情報、学ぶことができます。

However, the registered contact is frequently unreachable and thus not useful for watchers. The Globally Routable User Agent URI (GRUU), defined in RFC 5627, is a URI that is capable of reaching a particular contact. However this URI is not included in the document format defined in RFC 3680. This specification defines an extension to the registration event package to include GRUUs assigned by the registrar.

しかし、登録した連絡先は、頻繁に到達不能とウォッチャーのために有用ではありません。 RFC 5627で定義されたグローバルにルーティング可能なユーザエージェントURI（GRUU）は、特定の連絡先に到達することが可能なURIです。しかしながら、このURIは、本明細書は、レジストラによって割り当てGRUUsを含むように、登録イベントパッケージへの拡張を定義するRFC 3680.に定義されている文書フォーマットに含まれていません。

Status of This Memo

このメモのステータス

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

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

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 BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

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.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Description  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Notifier Processing of SUBSCRIBE Requests  . . . . . . . . . .  4
   5.  Notifier Generation of NOTIFY Requests . . . . . . . . . . . .  4
   6.  Subscriber Processing of NOTIFY Requests . . . . . . . . . . .  5
     6.1.  Managing Temporary GRUU Lifetime . . . . . . . . . . . . .  5
   7.  Sample reginfo Document  . . . . . . . . . . . . . . . . . . .  7
   8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1.  Example: Welcome Notice  . . . . . . . . . . . . . . . . .  8
     8.2.  Example: Implicit Registration . . . . . . . . . . . . . .  8
   9.  XML Schema Definition  . . . . . . . . . . . . . . . . . . . . 11
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
     10.1. URN Sub-Namespace Registration . . . . . . . . . . . . . . 12
     10.2. XML Schema Registration  . . . . . . . . . . . . . . . . . 13
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     13.2. Informative References . . . . . . . . . . . . . . . . . . 14

1. Introduction

1. はじめに

RFC 3680 [2] defines a Session Initiation Protocol (SIP) [5] event package for registration state. This package allows a watcher to learn about information stored by a SIP registrar, including the registered contacts.

RFC 3680 [2]は、セッション開始プロトコル（SIP）登録状態[5]イベントパッケージを定義します。このパッケージには、ウォッチャーが登録の連絡先を含むSIPレジストラによって蓄積された情報を知ることができます。

However, a registered contact is frequently unreachable from hosts outside of the domain of the User Agent (UA). It is commonly a private address, or, when it is a public address, access to it may be blocked by firewalls.

しかし、登録コンタクトユーザエージェント（UA）のドメインの外部のホストから頻繁に到達できません。それはそれへのアクセスは、ファイアウォールによってブロックされることがあり、それがパブリックアドレスであるとき、一般的にプライベートアドレスである、または。

The Globally Routable User Agent URI (GRUU), defined in RFC 5627 [3], is a URI that reaches a particular UA instance, but is reachable by any host on the Internet. GRUUs assigned by the registrar represent additional registration state. However, GRUUs assigned by the registrar are not included in the notifications provided by RFC 3680. For many applications of the registration event package, a GRUU is needed, and not the registered contact.

RFC 5627で定義されたグローバルにルーティング可能なユーザエージェントURI（GRUU）は、[3]は、特定のUAインスタンスに到達するURIであるが、インターネット上の任意のホストによって到達可能です。レジストラによって割り当てGRUUsは、追加の登録状態を表します。しかし、レジストラによって割り当てられGRUUsが登録イベントパッケージの多くのアプリケーションでは、RFC 3680.が提供する通知に含まれていない、GRUUは、登録の接触を必要とされていません。

For example, the Welcome Notices example in [2] will only operate correctly if the contact address in the registration event notification is reachable by the sender of the welcome notice. When the registering device is using the GRUU extension, it is likely that the registered contact address will not be globally addressable, and a GRUU should be used as the target address for the MESSAGE.

登録イベント通知の連絡先アドレスは歓迎、通知の送信者によって到達可能である場合たとえば、ようこそ特記事項の例では、[2]のみ正常に動作します。登録デバイスは、GRUU拡張子を使用している場合は、登録した連絡先アドレスがグローバルにアドレス指定可能ではないだろうと思われる、とGRUUは、メッセージのターゲットアドレスとして使用する必要があります。

Another case where this feature may be helpful is within the Third Generation Partnership Project (3GPP) IP Multimedia Subsystem (IMS). IMS employs a technique where a REGISTER of a contact address to one Address of Record (AOR) causes the implicit registration of the same contact to other associated AORs. If GRUUs are requested and obtained as part of the registration request, then additional GRUUs will also be needed for the implicit registrations. While assigning the additional GRUUs is straightforward, informing the registering UA of them is not. In IMS, UAs typically subscribe to the registration event, and subscriptions to the registration event for an AOR result in notifications, each containing the registration state of all the associated AORs. The proposed extension provides a way to easily deliver the GRUUs for the associated AORs.

この機能が役立つかもしれないもう一つの場合は、第三世代パートナーシッププロジェクト（3GPP）、IPマルチメディアサブシステム（IMS）の範囲内です。 IMSは、レコード（AOR）の一つのアドレスへの連絡先のレジスタは、他の関連のAORに同じコンタクトの暗黙の登録の原因となる技術を採用しています。 GRUUsが要求され、登録要求の一部として取得されている場合は、追加GRUUsも暗黙の登録のために必要とされるであろう。追加GRUUsを割り当てることは簡単ですが、それらの登録UAではありません知らせます。 IMSにおいては、UAは、典型的には、それぞれが関連付けられているすべてのAORの登録状態を含む、通知にAOR結果の登録イベントに登録イベントをサブスクライブ、およびサブスクリプション。提案された拡張が容易関連のAORためGRUUsを送達する方法を提供します。

As specified in RFC 5627 [3], temporary GRUUs are invalidated when contact address bindings for the corresponding AOR and instance ID are not refreshed, or when a registration to the AOR and instance ID is performed with a new Call-ID. A UA cannot always determine with certainty which temporary GRUUs are valid based solely on the response to the REGISTER requests it has issued, or from notifications according to RFC 3680 [2]. The extension defined in this document provides sufficient information for a UA to determine which temporary GRUUs are valid.

RFC 5627で指定されるように[3]、一時GRUUsが無効化され、対応するAORとインスタンスIDの場合、コンタクトアドレスのバインディングが更新されない、またはAOR及びインスタンスIDへの登録は、新しいCall-IDを用いて行った場合。 UAは常に[2] RFC 3680に従っただけにREGISTERに対する応答に基づいて、一時GRUUsが有効である確実性は、それが発行した要求を持つ、または通知から判断することはできません。この文書で定義された拡張機能は、一時的なGRUUsが有効であるかを決定するためにUAのための十分な情報を提供します。

The registration event package has provisions for including extension elements within the <contact> element. This document defines new elements that may be used in that context to deliver the public and temporary GRUUs corresponding to the contact.

登録イベントパッケージは、<接点>要素内の拡張要素を含むための設備を有しています。この文書では、連絡先に対応する公開と一時GRUUsを提供するという文脈で使用することができる新しい要素を定義します。

2. Terminology

2.用語

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 RFC 2119. [1]

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]

3. Description

3.説明

Two new elements (<pub-gruu> and <temp-gruu>) are defined, each of which contains a GRUU. The <temp-gruu> element also identifies the oldest temporary GRUU that is currently valid.

二つの新しい要素（<パブGRUU>と<TEMP-GRUU>）GRUUが含まそれぞれが、定義されています。 <TEMP-GRUU>要素は、現在有効である最古の一時的なGRUUを識別します。

These optional elements may be included within the body of a NOTIFY for the registration event package when GRUUs are associated with the contact. The contact URI and the GRUUs are then all available to the watcher.

これらの任意の要素はGRUUsは、コンタクトに関連付けられている登録イベントパッケージのためのNOTIFYの本体内に含めることができます。連絡先URIとGRUUsは、すべての後、ウォッチャーにご利用いただけます。

4. Notifier Processing of SUBSCRIBE Requests

SUBSCRIBE要求の4通知処理

Unchanged from RFC 3680 [2].

RFC 3680から変わらない[2]。

5. Notifier Generation of NOTIFY Requests

NOTIFY要求の5 Notifierの世代

A notifier for the registration event package [2] SHOULD include the <pub-gruu> element when a contact has an instance ID and a public GRUU is associated with the combination of the AOR and the instance ID. When present, the <pub-gruu> element MUST be positioned as a child of the <contact> element.

接触は、インスタンスIDを有しており、公衆GRUUがAORの組み合わせおよびインスタンスIDに関連付けられている場合、登録イベントパッケージの通知[2] <パブ-GRUU>要素が含まれるべきです。存在する場合、<パブ-GRUU>要素は、<接点>要素の子として配置されなければなりません。

A notifier for the registration event package [2] MAY include the <temp-gruu> element when a contact has an instance ID and a temporary GRUU is associated with the combination of the AOR and the instance ID. This element SHOULD be included if the subscriber is also authorized to register to the AOR. This element SHOULD NOT be included if the subscriber is not authorized to register to the AOR, unless there is an explicitly configured policy directing that it be included. When present, the <temp-gruu> element MUST be positioned as a child of the <contact> element.

接触は、インスタンスIDを有しており、一時的GRUUがAORの組み合わせおよびインスタンスIDに関連付けられている場合、登録イベントパッケージの通知[2] <TEMP-GRUU>要素を含んでいてもよいです。加入者はまた、AORに登録することを許可されている場合は、この要素が含まれるべきです。それが含まれていることを指示する明示的に設定したポリシーがない限り、加入者は、AORに登録することを許可されていない場合は、この要素が含まれるべきではありません。存在する場合、<TEMP-GRUU>要素は、<接点>要素の子として配置されなければなりません。

Note that it is possible for multiple registered contacts to share the same instance ID. In such a case, each <contact> element will have child <pub-gruu> and <temp-gruu> elements, which are identical to the corresponding child elements in those other <contact> elements that share the same instance ID. Since a particular contact cannot be associated with more than one instance ID, a <contact> element will never have more than one <pub-gruu> and one <temp-gruu> child element.

複数登録した連絡先が同じインスタンスIDを共有することが可能であることに注意してください。このような場合に、各<接点>要素は、子<パブGRUU>と同じインスタンスIDを共有し、それらの他の<接点>要素に対応する子要素と同一である<TEMP-GRUU>要素を有することになります。特定の連絡先が複数のインスタンスIDに関連付けることはできませんので、<連絡先>要素は、複数の<パブGRUU>との<TEMP-GRUU>子要素を持っていることはありません。

If the notifier includes the <pub-gruu> element, it MUST populate the element with the public GRUU that is associated with the instance ID and AOR of the registered contact.

通知は、<パブGRUU>要素が含まれている場合、それは、登録コンタクトのインスタンスIDとAORと関連している公衆GRUUを持つ要素を移入する必要があります。

If the notifier includes the <temp-gruu> element, it MUST populate the element with the most recently assigned temporary GRUU that is associated with the instance ID and AOR of the registered contact. It MUST also populate the element with a "cseq" attribute corresponding to the first (oldest) currently active temporary GRUU that is associated with the instance ID and AOR of the registered contact. The value of the "cseq" attribute is set to the value of the CSeq header field of the REGISTER request that caused that first temporary GRUU to be assigned.

通知は、<TEMP-GRUU>要素が含まれている場合、それは登録の接触のインスタンスIDとAORと関連している最後に割り当てられた一時的なGRUUを持つ要素を移入する必要があります。また、登録された連絡先のインスタンスIDとAORと関連している最初の（最も古い）現在アクティブな一時的GRUUに対応する「のCSeq」属性を持つ要素を移入する必要があります。「のCSeq」属性の値は、第1の一時GRUUが割り当てられることに起因するREGISTERリクエストのCSeqヘッダーフィールドの値に設定されています。

6. Subscriber Processing of NOTIFY Requests

NOTIFYリクエストの6加入者処理

When a subscriber receives a registration event notification with a <contact> containing a <pub-gruu>, it MAY associate the public GRUU with the corresponding AOR and instance ID. Any previously received public GRUU for the same AOR and instance ID MUST be discarded. (It will no longer function.)

加入者が<パブGRUU>を含む<接点>の登録イベント通知を受信すると、対応するAORとインスタンスIDと公衆GRUUを関連付けることができます。同じAORとインスタンスIDのために、以前に受信した公開GRUUを捨てなければなりません。（それはもはや機能します。）

When a subscriber receives a registration event notification with a <contact> containing a <temp-gruu>, it MAY associate the temporary GRUU, together with the "callid" and "cseq" attributes, with the corresponding AOR and instance ID.

加入者が<TEMP-GRUU>を含む<接点>の登録イベント通知を受信すると、それは一緒に「callid」と、一時的GRUUを関連付けることができると「のCSeq」は、対応するAORとインスタンスIDと、属性。

Subscribers that are unaware of this extension will, as required by [2], ignore the <pub-gruu> and <temp-gruu> elements.

この拡張の気づいていない加入者は、によって必要とされる[2]、<パブGRUU>と<TEMP-GRUU>要素を無視します。

6.1. Managing Temporary GRUU Lifetime

6.1. 一時GRUUの寿命を管理します

Section 4.2 of RFC 5627 [3] gives guidance for developers of UAs on how to ensure that only valid temporary GRUUs are retained and used by the UA. A UA cannot always determine with certainty which temporary GRUUs are valid based solely on the information contained in responses to the REGISTER requests it has issued or from the information contained in notifications that conform solely to RFC 3680 [2]. The extension defined in this document provides sufficient

RFC 5627のセクション4.2には、[3]のみ有効な一時GRUUsが保持され、UAによって使用されていることを確認する方法についてのUAの開発者のためのガイダンスを提供します。 UAは常に一時的GRUUsは、単にそれが発行したREGISTER要求または単にRFC 3680に準拠した通知に含まれる情報からの応答に含まれる情報に基づいて有効な確信を持って判断することができない[2]。この文書で定義された拡張機能は、十分な提供します

added information for a UA to determine which temporary GRUUs are valid. The extension to RFC 3680 defined in this document provides added information to help with that process. The following are steps that the UA MAY take to ensure it only retains valid GRUUs:

UAが有効で、一時たGRUUsかを決定するための情報を追加しました。この文書で定義されたRFC 3680の拡張機能は、そのプロセスを支援するために追加情報を提供します。以下は、UAは、それが唯一の有効なGRUUsを維持することを確認するために取るかもしれない手順です。

o The UA should subscribe to the registration event package for the AOR it is registering.

O UAは、それが登録されたAORのための登録イベントパッケージに加入する必要があります。

o When a UA receives a 2xx response to a REGISTER request, it may extract and retain temporary GRUUs from the response for future use, as long as they remain valid. Appropriate GRUUs to retain are those corresponding to the contact address and instance ID it has registered. (Typically, the UA will register only one contact address, and so receive at most one temporary GRUU.)

UAはREGISTER要求への2xx応答を受信すると、O、それは限り、彼らは有効のままとして、将来の使用のために応答から一時的GRUUsを抽出して保持することができます。保持するための適切なGRUUsは、それが登録された連絡先とインスタンスIDに対応するものです。（一般的に、UAは、唯一の連絡先アドレスを登録し、その多くても1つの一時的なGRUUで受信します。）

o The UA may add the temporary GRUU to the set of valid temporary GRUUs associated with the AOR. (Note, in this case AOR is the To-address of the REGISTER request.) To aid in tracking validity, the UA should also associate a "callid" attribute and "cseq" attribute with the temporary GRUU, with values obtained respectively from the Call-ID and CSeq values of the REGISTER response containing the temporary GRUU.

O UAはAORに関連付けられている有効な一時GRUUsのセットに一時的GRUUを追加することができます。（注、この場合にはAORがREGISTERリクエストのTO-アドレスである。）の有効性を追跡するのを助けるために、UAはまた、それぞれから得られた値と、「callid」属性と一時GRUUと「のCSeq」属性を関連付ける必要がありますコールIDの一時GRUUを含むREGISTER応答のとのCSeq値。

o If the UA receives a registration event notification with an AOR (that it supports) and a <contact>, for a contact address and instance ID (that it has registered and that contains a <temp-gruu>), it may update its set of valid temporary GRUUs associated with the AOR, as follows:

O UAは、連絡先とインスタンスIDのためのAORの登録イベント通知（それがサポートしている）と<接点>を、受信する（それが登録されていること、それは、<TEMP-GRUU>を含む）、それを更新することができる場合、その以下のように、AORに関連付けられた有効な一時GRUUsのセット：

* It may add the temporary GRUU to the set. To aid in tracking validity, the UA should associate the "callid" and "cseq" attributes of the <contact> with the GRUU in the set.

*これは、セットに一時的GRUUを追加することができます。有効性を追跡することを助けるために、UAはセットにGRUUで「callid」と<連絡先>の「のCSeq」属性を関連付ける必要があります。

* It should remove any temporary GRUUs with a "callid" attribute value different from that in the value of the "callid" attribute of the <contact>, or with a "cseq" attribute with value less than the value of the "first-cseq" attribute of the <temp-gruu>.

*これは、<連絡先>の「callid」属性の値で、または「初段の値より小さい値を持つ「のCSeq」属性を持つものとは異なる「callid」属性値を持つ任意の一時的なGRUUsを削除する必要がありますCSeq」<TEMP-GRUU>の属性。

o If the UA receives a registration event notification with an AOR that it supports, and there are no <contact> entries for its instance ID, then it should discard all the temporary GRUUs it has saved for that AOR.

UAは、それがサポートしているAORと登録イベント通知を受信し、そのインスタンスIDには、<連絡先>エントリが存在しない場合は、O、それはそれはAORのために保存されているすべての一時GRUUsを破棄しなければなりません。

7. Sample reginfo Document

7.サンプルREGINFOドキュメント

      Note: This example and others in the following section are
      indented for readability by the addition of a fixed amount of
      whitespace to the beginning of each line.  This whitespace is not
      part of the example.  The conventions of [7] are used to describe
      representation of long message lines.

The following is an example registration information document that includes the new element:

以下は、新しい要素を含む例示登録情報文書であります：

<?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" xmlns:gr="urn:ietf:params:xml:ns:gruuinfo" version="0" state="full"> <registration aor="sip:user@example.com" id="as9" state="active"> <contact id="76" state="active" event="registered" duration-registered="36001" expires="3599" callid="1j9FpLxk3uxtm8tn@192.0.2.1" cseq="54321" q="0.8"> <uri>sip:user@192.0.2.1</uri> <allOneLine> <unknown-param name="+sip.instance"> "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" </unknown-param> </allOneLine> <allOneLine> <gr:pub-gruu uri="sip:user@example.com ;gr=hha9s8d-999a"/> </allOneLine> <allOneLine> <gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@example.com ;gr" first-cseq="54301"/> </allOneLine> </contact> </registration> </reginfo>

<？xml version = "1.0"？> <のxmlns = REGINFO "壷：IETF：のparams：XML：NSを：REGINFO"：GR = "壷：IETF：のparams：XML：NS：gruuinfo" バージョン= "0" の状態のxmlns = "フル"> <登録AOR = "SIP：user@example.com" ID = "AS9" 状態= "アクティブ"> <連絡先ID = "76" 状態= "アクティブ" イベント= "登録された" 持続登録= "36001" 期限が切れる= "3599" callid = "1j9FpLxk3uxtm8tn@192.0.2.1" のCSeq = "54321" Q = "0.8"> <URI> SIP：user@192.0.2.1 </ URI> <allOneLine> <未知のparamの名前= "+ sip.instance"> "＆LT; URN：UUID：f81d4fae-7dec-11D0-a765-00a0c91e6bf6＆GT;" </不明-param>の</ allOneLine> <allOneLine> <GR：パブ-GRUU URI = "SIP：user@example.com; GR = hha9s8d-999a" /> </ allOneLine> <allOneLine> <GR：temp- GRUU URI = "SIP：8ffkas08af7fasklzi9@example.com; GR" 第一のCSeq = "54301" /> </ allOneLine> </接触> </登録> </ REGINFO>

8. Examples

8.例

Note: In the following examples, the SIP messages have been simplified, removing headers that are not pertinent to the example.

注：以下の例では、SIPメッセージは、一例に該当されないヘッダを除去し、簡略化されています。

When the value of the Content-Length header field is "...", this means that the value should be the computed length of the body.

Content-Lengthヘッダフィールドの値が「...」は、この値は、本体の計算された長さでなければならないことを意味します。

8.1. Example: Welcome Notice

8.1. 例：ようこそお知らせ

Consider the Welcome Notices example in [2]. When the application server receives a notification of a new registration containing the reginfo shown in Section 7, it should address messages using the contained public GRUU as follows:

[2]ウェルカム通知の例を考えてみましょう。アプリケーションサーバは、セクション7に示すREGINFOを含む新規登録の通知を受信すると、それは次のように含まれている公開GRUUを使用してメッセージの宛先を指定する必要があります。

MESSAGE sip:user@example.com;gr=hha9s8d-999a SIP/2.0 To: <sip:user@example.com> From: "SIPland Notifier" <sip:notifier@example.com>;tag=7xy8 Content-Type: text/plain Content-Length: ...

MESSAGE SIP：user@example.com; GR = hha9s8d-999aのSIP / 2.0に：<SIP：user@example.com>から： "SIPland通知" <一口：notifier@example.com>;タグ= 7xy8のコンテンツタイプ：text / plainのコンテンツの長さ：...

Welcome to SIPland! Blah, blah, blah.

SIPlandへようこそ！何とか何とか何とか。

8.2. Example: Implicit Registration

8.2. 例：暗黙的な登録

In a 3GPP IMS setting, a UA may send a single register message, requesting assignment of GRUUs, as follows:

次のように3GPP IMS設定では、UAは、GRUUsの割り当てを要求する、単一のレジスタメッセージを送信することができます。

REGISTER sip:example.net SIP/2.0 From: <sip:user_aor_1@example.net>;tag=5ab4 To: <sip:user_aor_1@example.net> Call-ID: faif9a@ua.example.com CSeq: 23001 REGISTER Contact: <sip:ua.example.com> ;expires=3600 ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" Supported: path, gruu Content-Length: 0

example.netのSIP / 2.0から：SIPレジスタ<SIP：user_aor_1@example.net>;タグ= 5ab4に<SIP：user_aor_1@example.net>コールID：faif9a@ua.example.comのCSeq：23001 REGISTER連絡先：<SIP：ua.example.com>; = 3600を満了し; + sip.instance = "<壷：UUID：f81d4fae-7dec-11D0-a765-00a0c91e6bf6>" サポートされている：パス、GRUUのContent-Length：0

The response reports success of the registration and returns the GRUUs assigned for the combination of AOR, instance ID, and Contact. It also indicates (via the P-Associated-URI header [6]) that there are two other associated AORs that may have been implicitly registered using the same contact. Each of those implicitly registered AORs will have unique GRUUs assigned. The REGISTER response will not include those GRUUs; it will only include the GRUUs for the AOR and instance ID explicitly included in the registration.

応答は、登録の成功を報告し、AOR、インスタンスID、および連絡先の組み合わせに割り当てられGRUUsを返します。それはまた、暗黙同じコンタクトを使用して登録されていてもよい他の二つの関連のAORがあること（[6] P-関連-URIヘッダを介して）を示しています。これらの暗黙的に登録されたのAORは、それぞれ割り当てられた固有のGRUUsを持つことになります。 REGISTER応答は、これらのGRUUsは含まれません。それだけで明示的に登録に含まAORとインスタンスIDのためGRUUsが含まれます。

SIP/2.0 200 OK From: <sip:user_aor_1@example.net>;tag=5ab4 To: <sip:user_aor_1@example.net>;tag=373392 Call-ID: faif9a@ua.example.com CSeq: 23001 REGISTER Path: <sip:proxy.example.net;lr> Service-Route: <sip:proxy.example.net;lr>

SIP / 2.0 200 OKから<SIP：user_aor_1@example.net>;タグ= 5ab4に<SIP：user_aor_1@example.net>;タグ= 373392のCall-ID：faif9a@ua.example.comのCSeq：23001 REGISTERパス：<SIP：proxy.example.net; LR>サービス-ルート：<SIP：proxy.example.net; LR>

Contact: <sip:ua.example.com> ;expires=3600 ;+sip.instance="<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" ;pub-gruu="sip:user_aor_1@example.net;gr=hha9s8d-999a" ;temp-gruu="sip:8ffkas08af7fasklzi9@example.net;gr" P-Associated-URI: <sip:user_aor_2@example.net>, <sip:+358504821437@example.net;user=phone> Content-Length: 0

連絡先：<SIP：ua.example.com>; 3600 =期限が切れ; + sip.instance = "<壷：UUID：f81d4fae-7dec-11D0-a765-00a0c91e6bf6>";パブ-GRUU = "一口例：@ user_aor_1。ネット; GR = hha9s8d-999a」;一時-GRUU = "一口：8ffkas08af7fasklzi9@example.net; GR" P-関連-URI：<SIP：user_aor_2@example.net>、<SIP：+358504821437@example.net。ユーザー=電話>のContent-Length：0

The UA then subscribes to the registration event package as follows:

次のようにUAは、登録イベントパッケージに加入します：

SUBSCRIBE sip:user_aor_1@example.net SIP/2.0 From: <sip:user_aor_1@example.net>;tag=27182 To: <sip:user_aor_1@example.net> Call-ID: gbjg0b@ua.example.com CSeq: 45001 SUBSCRIBE Route: <sip:proxy.example.net;lr> Event: reg Expires: 3600 Accept: application/reginfo+xml Contact: <sip:user_aor_1@example.net;gr=hha9s8d-999a> Content-Length: 0

<SIP：user_aor_1@example.net>コール番号：gbjg0b@ua.example.comのCSeq：;からuser_aor_1@example.net SIP / 2.0：<SIP user_aor_1@example.net>タグ= 27182にSIPのSUBSCRIBE 45001は、ルートをSUBSCRIBE：<SIP：proxy.example.net; LR>イベント：regが有効期限：3600を受け入れ：アプリケーション/ REGINFO + XMLとの接触：<SIP：user_aor_1@example.net; GR = hha9s8d-999a>のContent-Length：0

(The successful response to the subscription is not shown.) Once the subscription is established, an initial notification is sent giving registration status. In IMS deployments, the response includes, in addition to the status for the requested URI, the status for the other associated URIs.

（サブスクリプションに成功した応答が示されていない。）サブスクリプションが確立されると、最初の通知は、登録ステータスを与えて送信されます。 IMSの展開では、応答は要求されたURI、他の関連するURIのステータスの状態に加えて、含まれています。

NOTIFY sip:user_aor_1@example.net;gr=hha9s8d-999a SIP/2.0 From: <sip:user_aor_1@example.net>;tag=27182 To: <sip:user_aor_1@example.net>;tag=262281 Call-ID: gbjg0b@ua.example.com CSeq: 633 NOTIFY Subscription-State: active;expires=3600 Event: reg Content-Type: application/reginfo+xml Contact: <sip:registrar.example.net> Content-Length: ...

SIPのNOTIFY：user_aor_1@example.net; GR = hha9s8d-999a SIP / 2.0 <SIP：user_aor_1@example.net>;タグ= 27182に<SIP：user_aor_1@example.net>;タグ= 262281コールID ：gbjg0b@ua.example.comのCSeq：633は、サブスクリプションのステートをNOTIFY：アクティブ; = 3600イベントの有効期限が切れます。regのContent-Type：アプリケーション/ REGINFO + xmlの連絡先：<SIP：registrar.example.net>のContent-Lengthを.. 。

<?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" xmlns:gr="urn:ietf:params:xml:ns:gruuinfo" version="1" state="full"> <registration aor="sip:user_aor_1@example.net" id="a7" state="active"> <contact id="92" state="active" event="registered" duration-registered="1" expires="3599" callid="faif9a@ua.example.com" cseq="23001"> <uri> sip:ua.example.com </uri> <allOneLine> <unknown-param name="+sip.instance"> "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" </unknown-param> </allOneLine> <allOneLine> <gr:pub-gruu uri="sip:user_aor_1@example.net ;gr=hha9s8d-999a"/> </allOneLine> <allOneLine> <gr:temp-gruu uri="sip:8ffkas08af7fasklzi9@example.net ;gr" first-cseq="54301"/> </allOneLine> </contact> </registration> <registration aor="sip:user_aor_2@example.net" id="a8" state="active"> <contact id="93" state="active" event="created" duration-registered="1" expires="3599" callid="faif9a@ua.example.com" cseq="23001"> <uri> sip:ua.example.com </uri> <allOneLine> <unknown-param name="+sip.instance"> "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" </unknown-param> </allOneLine> <allOneLine> <gr:pub-gruu uri="sip:user_aor_2@example.net ;gr=hha9s8d-999b"/> </allOneLine> <allOneLine> <gr:temp-gruu uri="sip:07hcovy36vp6vngvbia@example.net ;gr" first-cseq="54301"/> </allOneLine> </contact> </registration> <registration aor="sip:+358504821437@example.net;user=phone" id="a9" state="active"> <contact id="94" state="active" event="created" duration-registered="1" expires="3599" callid="faif9a@ua.example.com" cseq="23001"> <uri> sip:ua.example.com </uri> <allOneLine> <unknown-param name="+sip.instance"> "<urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>" </unknown-param> </allOneLine> <allOneLine> <gr:pub-gruu uri="sip:+358504821437@example.net ;user=phone;gr=hha9s8d-999c"/> </allOneLine> <allOneLine> <gr:temp-gruu uri="sip:h99egjbv17fe8ibvlka@example.net ;gr" first-cseq="54301"/> </allOneLine> </contact> </registration> </reginfo>

<？xml version = "1.0"？> <のxmlns = REGINFO "壷：IETF：のparams：XML：NSを：REGINFO"：GR = "壷：IETF：のparams：XML：NS：gruuinfo" バージョン= "1" の状態のxmlns = "フル"> <登録AOR = "SIP：user_aor_1@example.net" ID = "A7" 状態= "アクティブ"> <連絡先ID = "92" 状態= "アクティブ" イベント= "登録された" 持続登録= "1" 期限が切れる= "3599" callid = "faif9a@ua.example.com" のCSeq = "23001"> <URI> SIP：ua.example.com </ URI> <allOneLine> <未知のparamの名前= "+ sip.instance "> "＆LT; URN：UUID：f81d4fae-7dec-11D0-a765-00a0c91e6bf6＆GT;" </不明-param>の</ allOneLine> <allOneLine> <GR：パブ-GRUU URI = "SIP：user_aor_1@example.net; GR = hha9s8d-999a" /> </ allOneLine> <allOneLine> <GR：temp- GRUU URI = "SIP：8ffkas08af7fasklzi9@example.net; GR" 第一のCSeq = "54301" /> </ allOneLine> </接触> </登録> <登録AOR = "SIP：user_aor_2@example.net" ID = "A8" 状態= "アクティブ"> <連絡先ID = "93" 状態= "アクティブ" イベント= "作成された" 持続登録= "1" 期限が切れる= "3599" callid = "faif9a@ua.example.com" のCSeq = "23001"> <URI> SIP：ua.example.com </ URI> <allOneLine> <未知PARAM名= "+ sip.instance">「＆LT; URN：UUID：f81d4fae-7dec-11D0-a765 -00a0c91e6bf6＆GT;」 </不明-param>の</ allOneLine> <allOneLine> <GR：パブ-GRUU URI = "SIP：user_aor_2@example.net; GR = hha9s8d-999b" /> </ allOneLine> <allOneLine> <GR：temp- GRUU URI = "SIP：07hcovy36vp6vngvbia@example.net; GR" 第一のCSeq = "54301" /> </ allOneLine> </接触> </登録> <登録AOR =「SIP：+358504821437@example.net、ユーザUA @ "持続登録= "1" が満了し= "3599" callid = "faif9a作成=電話" ID = "A9" 状態= "アクティブ"> <連絡先ID = "94" 状態= "アクティブ" イベント="。 example.com "のCSeq = "23001"> <URI> SIP：ua.example.com </ URI> <allOneLine> <未知のparamの名前= "+ sip.instance">" ＆LT;壷：UUID：f81d4fae- 7dec-11D0-a765-00a0c91e6bf6＆GT;」 </不明-param>の</ allOneLine> <allOneLine> <GR：パブ-GRUU URI = "SIP：+358504821437@example.net;ユーザー=電話; GR = hha9s8d-999c" /> </ allOneLine> <allOneLine> <GR：TEMP-GRUU URI = "SIP：h99egjbv17fe8ibvlka@example.net; GR" 第一のCSeq = "54301" /> </ allOneLine> </接触> </登録> </ REGINFO>

The status indicates that the associated URIs all have the same contact registered. It also includes the unique GRUUs that have been assigned to each. The UA may then retain those GRUUs for use when establishing dialogs using the corresponding AORs.

ステータスは、関連のURIはすべて同じ連絡先が登録されていることを示しています。また、それぞれに割り当てられているユニークなGRUUsが含まれています。対応のAORを使用してダイアログを確立するときに、UAは、その後の使用のためにそれらGRUUsを保持することができます。

9. XML Schema Definition

9. XMLスキーマ定義

The <pub-gruu> and <temp-gruu> elements are defined within a new XML namespace URI. This namespace is "urn:ietf:params:xml:ns:gruuinfo". The schema for these elements is:

<パブ-GRUU>と<TEMP-GRUU>要素は、新しいXML名前空間URI内で定義されています。この名前空間は、 "URN：IETF：のparams：XML：NS：gruuinfo" です。これらの要素のスキーマは次のとおりです。

<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:gruuinfo" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn:ietf:params:xml:ns:gruuinfo"> <xs:complexType name="pubGruu"> <xs:attribute name="uri" type="xs:anyURI" use="required"/> </xs:complexType> <xs:complexType name="tempGruu"> <xs:complexContent> <xs:extension base="tns:pubGruu"> <xs:attribute name="first-cseq" type="xs:unsignedLong" use="required"/>

<？xml version = "1.0" エンコードは= "UTF-8"？> <XS：スキーマのtargetNamespaceは= "壷：IETF：のparams：XML：NS：gruuinfo" のelementFormDefault = "資格" attributeFormDefault = "非修飾" のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のxmlns：TNSは= "壷：IETF：のparams：XML：NS：gruuinfo"> <XS：complexTypeの名= "pubGruu"> <XS：属性名=」 URI」タイプ= "XS：anyURIの" 使用= "必要" /> </ XS：complexTypeの> <XS：complexTypeの名= "tempGruu"> <XS：complexContentを> <XS：増設ベースは= "TNS：pubGruu"> < XS：属性名= "第一のCSeq" タイプ= "XS：なunsignedLong" 使用= "必要" />

</xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="pub-gruu" type="tns:pubGruu"/> <xs:element name="temp-gruu" type="tns:tempGruu"/> </xs:schema>

</ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "パブ-GRUU" タイプ= "TNS：pubGruu" /> <XS：要素名= "TEMP-GRUU" タイプ= "TNS：tempGruu" /> </ XS：スキーマ>

10. IANA Considerations

10. IANAの考慮事項

There are two IANA considerations associated with this specification.

この仕様に関連する2つのIANAの考慮事項があります。

10.1. URN Sub-Namespace Registration

10.1. URNサブ名前空間の登録

This section registers a new XML namespace, per the guidelines in [4].

このセクションでは、[4]のガイドラインごとに、新しいXML名前空間を登録します。

URI: The URI for this namespace is urn:ietf:params:xml:ns:gruuinfo

URI：この名前空間のURIはURNです：IETF：のparams：XML：NS：gruuinfo

Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>

登録者連絡先：IETF、SIPPINGワーキンググループ、<sipping@ietf.org>、ポール・Kyzivat <pkyzivat@cisco.com>

XML:

XML：

         BEGIN
         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                   "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
         <html xmlns="http://www.w3.org/1999/xhtml">
         <head>
           <meta http-equiv="content-type"
              content="text/html;charset=iso-8859-1"/>
           <title>Reg Information GRUU Extension Namespace</title>
         </head>
         <body>
            <h1>Namespace for Reg Information GRUU Extension</h1>
            <h2>urn:ietf:params:xml:ns:gruuinfo</h2>
            <p>See <a href="http://www.rfc-editor.org/rfc/rfc5628.txt">
               RFC5628</a>.</p>
          </body>
         </html>
         END

10.2. XML Schema Registration

10.2. XML Schemaの登録

This section registers an XML schema per the procedures in [4].

このセクションでは、[4]の手順ごとにXMLスキーマを登録します。

URI: urn:ietf:params:xml:schema:gruuinfo.

URI：URN：IETF：のparams：XML：スキーマ：gruuinfo。

Registrant Contact: IETF, SIPPING working group, <sipping@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>

登録者連絡先：IETF、SIPPINGワーキンググループ、<sipping@ietf.org>、ポール・Kyzivat <pkyzivat@cisco.com>

The XML for this schema can be found in Section 9.

このスキーマのためのXMLは、セクション9に記載されています。

11. Security Considerations

11.セキュリティについての考慮事項

Security considerations for the registration event package are discussed in RFC 3680 [2], and those considerations apply here.

セキュリティ登録イベントパッケージのための考慮事項RFC 3680で説明されている[2]、及びそれらの考慮事項が適用されます。

If a contact address obtained via subscription to the registration event package is not reachable by the subscriber, then its disclosure may arguably be considered a minimal security risk. In that case, the inclusion of a GRUU may be considered to increase the risk by providing a reachable address. On the other hand, requests addressed to a GRUU are always first processed by the servicing proxy before they reach the intended User Agent. The proxy may control access as desired, just as it may for the AOR. For instance, the proxy servicing a GRUU may accept requests from senders whose identity appears on a white list, and reject other requests. In this respect, disclosing a GRUU presents no more risk than disclosing the AOR.

登録イベントパッケージへの加入を介して取得した連絡先アドレスは、加入者が到達できない場合、その開示は間違いなく、最小限のセキュリティリスクと見なすことができます。その場合、GRUUを含めることは、到達可能なアドレスを提供することによって、リスクを増加させると考えることができます。一方、要求は、彼らが意図したユーザーエージェントに到達する前に、必ず最初にサービスプロキシによって処理されGRUU宛。必要に応じて、プロキシはちょうどそれがAORのためかもしれないとして、アクセスを制御することができます。例えば、GRUUにサービスを提供するプロキシは、アイデンティティホワイトリストに表示される送信者からの要求を受け入れ、および他の要求を拒否することができます。この点で、GRUUを開示することはAORの開示を超えない危険性を提示しています。

Temporary GRUUs have an additional security consideration. The intent of the temporary GRUU is to provide a contact address that cannot be correlated to the identity of the calling party. The recipient of a call using a temporary GRUU may guess the identity of the calling party and then attempt to obtain the temporary GRUUs assigned to that caller to confirm the conjecture. Two possible approaches to obtaining the temporary GRUUs are:

一時的なGRUUsは、追加のセキュリティ配慮を持っています。一時的なGRUUの意図は、発信者の身元と相関させることができない連絡先を提供することです。一時的なGRUUを使用して通話の受信者は発信者の身元を推測して、推測を確認するために、その呼び出し側に割り当てられた一時的なGRUUsを取得しようとすることができます。一時的GRUUsを取得するには2つの可能なアプローチは、以下のとおりです。

o Send a REGISTER request to a conjectured caller.

O推測さ、発信者にREGISTERリクエストを送信します。

o Send a SUBSCRIBE request for the registration event package to the conjectured caller.

O推測さ、発信者への登録イベントパッケージのSUBSCRIBEリクエストを送信します。

Typically, REGISTER is restricted to devices or users that are authorized to originate and receive calls with the AOR. Anonymity among users of the same AOR is hard to achieve and typically unnecessary. It is recommended (see Section 5) that the authorization policy for the registration event package permit only those subscribers who are authorized to register to the AOR to receive temporary GRUUs. With this policy, the confidentiality of the temporary GRUU will be the same with and without the registration event package. User Agents that use a temporary GRUU should note that confidentiality does not extend to parties that are permitted to register to the AOR or to obtain the temporary GRUU when subscribing to the registration event package.

一般的に、REGISTERはAORとの通話を発信および受信を許可されたデバイスまたはユーザーに制限されています。同じAORのユーザー間で匿名性を達成するのは難しいと一般的に不要です。それは一時的なGRUUsを受け取るためにAORに登録することを許可されているのみの加入者登録イベントパッケージの許可の認可ポリシーこと（セクション5を参照）が推奨されます。このポリシーでは、一時的なGRUUの機密性を持つと登録イベントパッケージなしで同じになります。その機密性を注意する必要があり、一時的なGRUUを使用するユーザエージェントは、AORに登録したり、登録イベントパッケージに加入する際に、一時的なGRUUを取得することが許可されている関係者には適用されません。

12. Acknowledgements

12.謝辞

The author would like to thank Jonathan Rosenberg for help with this document, and Jari Urpalainen for assistance with the XML.

著者は、XMLの支援のために、このドキュメントのヘルプのためのジョナサン・ローゼンバーグ、およびヤリUrpalainenに感謝したいと思います。

13. References

13.参考文献

13.1. Normative References

13.1. 引用規格

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[2] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.

[2]ローゼンバーグ、J.、 "Aセッション開始プロトコル（SIP）登録のためのイベントパッケージ"、RFC 3680、2004年3月。

[3] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.

[3]ローゼンバーグ、J.、RFC 5627 "セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザエージェント（UA）のURI（GRUU）の取得と使用"、2009年10月。

[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[4] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。

13.2. Informative References

13.2. 参考文献

[5] 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.

[5]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。

[6] Garcia-Martin, M., Henrikson, E., and D. Mills, "Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)", RFC 3455, January 2003.

[6]ガルシア - マーチン、M.、Henrikson、E.、およびD.ミルズ、 "プライベートヘッダ（P-ヘッダ）第3世代パートナーシッププロジェクト（3GPP）のためのセッション開始プロトコル（SIP）の拡張"、RFC 3455、2003年1月。

[7] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006.

[7]、火花R.、Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）調教テストメッセージ"、RFC 4475、2006年5月。

Author's Address

著者のアドレス

Paul H. Kyzivat Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA

ポールH. Kyzivatシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA

EMail: pkyzivat@cisco.com

メールアドレス：pkyzivat@cisco.com