[要約] RFC 5630は、SIP（セッション開始プロトコル）でSIPS URIスキームの使用に関するガイドラインです。このRFCの目的は、セキュアなSIPセッションの確立と通信の保護を促進することです。
Network Working Group F. Audet
Request for Comments: 5630 Skype Labs
Updates: 3261, 3608 October 2009
Category: Standards Track
The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）でのSIPSURIスキームの使用
Abstract
概要
This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP.
このドキュメントは、セッション開始プロトコル（SIP）でのSIPS URIスキームの使用に関する明確化とガイドラインを提供します。また、SIPに規範的な変更を加えます。
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）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright and License Notice
著作権とライセンス通知
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 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 BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Background ......................................................3
3.1. Models for Using TLS in SIP ................................3
3.1.1. Server-Provided Certificate .........................3
3.1.2. Mutual Authentication ...............................4
3.1.3. Using TLS with SIP Instead of SIPS ..................4
3.1.4. Usage of the transport=tls URI Parameter and
the TLS Via Parameter ...............................5
3.2. Detection of Hop-by-Hop Security ...........................6
3.3. The Problems with the Meaning of SIPS in RFC 3261 ..........7
4. Overview of Operations ..........................................9
4.1. Routing ...................................................11
5. Normative Requirements .........................................13
5.1. General User Agent Behavior ...............................13
5.1.1. UAC Behavior .......................................13
5.1.1.1. Registration ..............................14
5.1.1.2. SIPS in a Dialog ..........................15
5.1.1.3. Derived Dialogs and Transactions ..........15
5.1.1.4. GRUU ......................................16
5.1.2. UAS Behavior .......................................17
5.2. Registrar Behavior ........................................18
5.2.1. GRUU ...............................................18
5.3. Proxy Behavior ............................................18
5.4. Redirect Server Behavior ..................................20
6. Call Flows .....................................................21
6.1. Bob Registers His Contacts ................................22
6.2. Alice Calls Bob's SIPS AOR ................................27
6.3. Alice Calls Bob's SIP AOR Using TCP .......................36
6.4. Alice Calls Bob's SIP AOR Using TLS .......................50
7. Further Considerations .........................................51
8. Security Considerations ........................................52
9. IANA Considerations ............................................52
10. Acknowledgments ...............................................52
11. References ....................................................53
11.1. Normative References .....................................53
11.2. Informative References ...................................53
Appendix A. Bug Fixes for RFC 3261 ..............................55
The meaning and usage of the SIPS URI scheme and of Transport Layer Security (TLS) [RFC5246] are underspecified in SIP [RFC3261] and have been a source of confusion for implementers.
SIPS URIスキームと輸送層のセキュリティ（TLS）[RFC5246]の意味と使用は、SIP [RFC3261]では基づいており、実装者にとって混乱の原因となっています。
This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP (including both [RFC3261] and [RFC3608].
このドキュメントは、セッション開始プロトコル（SIP）でのSIPS URIスキームの使用に関する明確化とガイドラインを提供します。また、SIP（[RFC3261]と[RFC3608]の両方を含むSIP）に規範的な変更を加えます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This section describes briefly the usage of TLS in SIP.
このセクションでは、SIPでのTLSの使用について簡単に説明します。
In this model, only the TLS server provides a certificate during the TLS handshake. This is applicable only between a user agent (UA) and a proxy, where the UA is the TLS client and the proxy is the TLS server, and hence the UA uses TLS to authenticate the proxy but the proxy does not use TLS to authenticate the UA. If the proxy needs to authenticate the UA, this can be achieved by SIP HTTP digest authentication. This directionality implies that the TLS connection always needs to be set up by the UA (e.g., during the registration phase). Since SIP allows for requests in both directions (e.g., an incoming call), the UA is expected to keep the TLS connection alive, and that connection is expected to be reused for both incoming and outgoing requests.
このモデルでは、TLSハンドシェイク中にTLSサーバーのみが証明書を提供します。これは、ユーザーエージェント（UA）とプロキシの間でのみ適用されます。ここでは、UAはTLSクライアントであり、プロキシはTLSサーバーです。ua。プロキシがUAを認証する必要がある場合、これはSIP HTTPダイジェスト認証によって達成できます。この方向性は、TLS接続を常にUAによって（登録段階で）設定する必要があることを意味します。SIPは両方向（着信コールなど）でのリクエストを可能にするため、UAはTLS接続を生かし続けることが期待されており、その接続は受信要求と発信要求の両方で再利用されると予想されます。
This solution of having the UA always initiate and keep alive the connection also solves the Network Address Translation (NAT) and firewall problem as it ensures that responses and further requests will always be deliverable on the existing connection.
UAが常に開始して生存するというこのソリューションは、接続を常に解決し、ネットワークアドレスの変換（NAT）とファイアウォールの問題を解決します。これにより、応答とさらなる要求が既存の接続で常に配信可能になることを保証します。
[RFC5626] provides the mechanism for initiating and maintaining outbound connections in a standard interoperable way.
[RFC5626]は、標準的な相互運用可能な方法でアウトバウンド接続を開始および維持するメカニズムを提供します。
In this model, both the TLS client and the TLS server provide a certificate in the TLS handshake phase. When used between a UA and a proxy (or between two UAs), this implies that a UA is in possession of a certificate. When sending a SIP request when there is not already a suitable TLS connection in place, a user agent client (UAC) takes on the role of TLS client in establishing a new TLS connection. When establishing a TLS connection for receipt of a SIP request, a user agent server (UAS) takes on the role of TLS server. Because in SIP a UA or a proxy acts both as UAC and UAS depending on if it is sending or receiving requests, the symmetrical nature of mutual TLS is very convenient. This allows for TLS connections to be set up or torn down at will and does not rely on keeping the TLS connection alive for further requests.
このモデルでは、TLSクライアントとTLSサーバーの両方が、TLSハンドシェイクフェーズで証明書を提供します。UAとプロキシ（または2つのUAの間）の間で使用される場合、これはUAが証明書を所有していることを意味します。まだ適切なTLS接続が存在しない場合にSIPリクエストを送信する場合、ユーザーエージェントクライアント（UAC）が新しいTLS接続の確立においてTLSクライアントの役割を引き受けます。SIPリクエストを受信するためのTLS接続を確立するとき、ユーザーエージェントサーバー（UAS）がTLSサーバーの役割を引き受けます。SIPでは、UAまたはプロキシは、リクエストの送信または受信のかどうかに応じてUACとUAの両方として機能するため、相互TLSの対称性は非常に便利です。これにより、TLS接続を自由に設定または取り壊すことができ、さらにリクエストのためにTLS接続を生かし続けることに依存しません。
However, there are some significant limitations.
ただし、いくつかの大きな制限があります。
The first obvious limitation is not with mutual authentication per se, but with the model where the underlying TCP connection can be established by either side, interchangeably, which is not possible in many environments. For examples, NATs and firewalls will often allow TCP connections to be established in one direction only. This includes most residential SIP deployments, for example. Mutual authentication can be used in those environments, but only if the connection is always started by the same side, for example, by using [RFC5626] as described in Section 3.1.1. Having to rely on [RFC5626] in this case negates many of the advantages of mutual authentication.
最初の明らかな制限は、相互認証自体ではなく、基礎となるTCP接続をどちらの側でも同じ意味で確立できるモデルであり、多くの環境では不可能です。たとえば、NATとファイアウォールは、多くの場合、TCP接続を一方向のみで確立できるようにします。これには、たとえば、ほとんどの住宅SIP展開が含まれます。相互認証は、これらの環境で使用できますが、セクション3.1.1で説明されているように、[RFC5626]を使用するなど、接続が常に同じ側によって開始される場合のみです。この場合、[RFC5626]に頼らなければならないことは、相互認証の多くの利点を無効にします。
The second significant limitation is that mutual authentication requires both sides to exchange a certificate. This has proven to be impractical in many environments, in particular for SIP UAs, because of the difficulties of setting up a certificate infrastructure for a wide population of users.
2番目の重要な制限は、相互認証が証明書を交換するために双方が必要であることです。これは、多くの環境、特にSIP UASでは非現実的であることが証明されています。これは、幅広いユーザーのために証明書インフラストラクチャを設定するのが難しいためです。
For these reasons, mutual authentication is mostly used in server-to-server communications (e.g., between SIP proxies, or between proxies and gateways or media servers), and in environments where using certificates on both sides is possible (e.g., high-security devices used within an enterprise).
これらの理由から、相互認証は、主にサーバー間通信（例：SIPプロキシ、プロキシ、ゲートウェイ、またはメディアサーバーの間）、および両側で証明書を使用する環境（例えば、高セキュリティ）で使用されます。エンタープライズ内で使用されるデバイス）。
Because a SIPS URI implies that requests sent to the resource identified by it be sent over each SIP hop over TLS, SIPS URIs are not suitable for "best-effort TLS": they are only suitable for "TLS-only" requests. This is recognized in Section 26.2.2 of [RFC3261].
SIPS URIは、それによって特定されたリソースに送信されるリクエストを各SIPホップにTLSに渡すことを意味するため、SIPは「ベストエフォートTLS」には適していません。「TLSのみの」リクエストにのみ適しています。これは、[RFC3261]のセクション26.2.2で認識されています。
Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports.
SIPS URIを録音住所として配布するユーザーは、不安定なトランスポートよりもリクエストを拒否するデバイスを操作することを選択できます。
If one wants to use "best-effort TLS" for SIP, one just needs to use a SIP URI, and send the request over TLS.
SIPに「Best-Effort TLS」を使用したい場合は、SIP URIを使用してTLSを介してリクエストを送信する必要があります。
Using SIP over TLS is very simple. A UA opens a TLS connection and uses SIP URIs instead of SIPS URIs for all the header fields in a SIP message (From, To, Request-URI, Contact header field, Route, etc.). When TLS is used, the Via header field indicates TLS.
TLSを介してSIPを使用することは非常に簡単です。UAはTLS接続を開き、SIP urisの代わりにSIP URIを使用します。TLSを使用すると、ViaヘッダーフィールドはTLSを示します。
[RFC3261], Section 26.3.2.1, states:
[RFC3261]、セクション26.3.2.1、状態：
When a UA comes online and registers with its local administrative domain, it SHOULD establish a TLS connection with its registrar (...). Once the registration has been accepted by the registrar, the UA SHOULD leave this TLS connection open provided that the registrar also acts as the proxy server to which requests are sent for users in this administrative domain. The existing TLS connection will be reused to deliver incoming requests to the UA that had just completed registration.
UAがオンラインになり、ローカル管理ドメインで登録すると、レジストラ（...）とのTLS接続を確立する必要があります。登録がレジストラによって受け入れられると、レジストラがこの管理ドメインのユーザーにリクエストが送信されるプロキシサーバーとしても機能する場合、UAはこのTLS接続を開いたままにしておく必要があります。既存のTLS接続は再利用され、登録が完了したばかりのUAに着信要求を提供します。
[RFC5626] describes how to establish and maintain a TLS connection in environments where it can only be initiated by the UA.
[RFC5626]は、UAによってのみ開始できる環境でTLS接続を確立および維持する方法を説明しています。
Similarly, proxies can forward requests using TLS if they can open a TLS connection, even if the route set used SIP URIs instead of SIPS URIs. The proxies can insert Record-Route header fields using SIP URIs even if it uses TLS transport. [RFC3261], Section 26.3.2.2, explains how interdomain requests can use TLS.
同様に、ルートセットがSIP URISの代わりにSIP URIを使用した場合でも、TLSがTLS接続を開くことができる場合、TLSを使用してプロキシを転送できます。プロキシは、TLSトランスポートを使用している場合でも、SIP URIを使用してレコードルートヘッダーフィールドを挿入できます。[RFC3261]、セクション26.3.2.2は、ドメイン間要求がTLSを使用する方法を説明しています。
Some user agents, redirect servers, and proxies might have local policies that enforce TLS on all connections, independently of whether or not SIPS is used.
一部のユーザーエージェント、リダイレクトサーバー、およびプロキシには、SIPが使用されるかどうかに関係なく、すべての接続にTLSを実施するローカルポリシーがある場合があります。
[RFC3261], Section 26.2.2 deprecated the "transport=tls" URI transport parameter in SIPS or SIP URIs:
[RFC3261]、セクション26.2.2は、SIPまたはSIP URIで「Transport = TLS」URI Transportパラメーターを非推奨しました。
Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=TCP" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543.
SIPS URIスキームでは、TransportはTLSとは無関係であり、したがって「SIPS：ALICE@ATLANTA.COM; TRANSPREST = TCP」と「SIPS：ALICE@ATLANTA.COM; TRASTRESTNG = SCTP」は両方とも有効であることに注意してください（ただし）UDPは、SIPの有効なトランスポートではありません）。その結果、「Transport = TLS」の使用は、それが要求の単一のホップに固有のものであったためです。これは、RFC 2543以来の変更です。
The "tls" parameter has not been eliminated from the ABNF in [RFC3261], Section 25, since the parameter needs to remain in the ABNF for backward compatibility in order for parsers to be able to process the parameter correctly. The transport=tls parameter has never been defined in an RFC, but only in some of the Internet drafts between [RFC2543] and [RFC3261].
パラメーターがパラメーターを正しく処理できるようにするためには、パラメーターが後方互換性のためにABNFに留まる必要があるため、[RFC3261]の[RFC3261]のABNFから「TLS」パラメーターは排除されていません。Transport = TLSパラメーターはRFCで定義されたことはありませんが、[RFC2543]と[RFC3261]の間のインターネットドラフトの一部でのみ定義されています。
This specification does not make use of the transport=tls parameter.
この仕様では、Transport = TLSパラメーターを使用しません。
The reinstatement of the transport=tls parameter, or an alternative mechanism for indicating the use of the TLS on a single hop in a URI, is outside the scope of this specification.
トランスポート= TLSパラメーターの回復、またはURIでの1つのホップでのTLSの使用を示すための代替メカニズムは、この仕様の範囲外です。
For Via header fields, the following transport protocols are defined in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS-SCTP".
ヘッダーフィールドを介して、次の輸送プロトコルは[RFC3261]、「UDP」、「TCP」、「TLS」、「SCTP」、および[RFC4168]：「TLS-SCTP」で定義されています。
The presence of a SIPS Request-URI does not necessarily indicate that the request was sent securely on each hop. So how does a UAS know if SIPS was used for the entire request path to secure the request end-to-end? Effectively, the UAS cannot know for sure. However, [RFC3261], Section 26.4.4, recommends how a UAS can make some checks to validate the security. Additionally, the History-Info header field [RFC4244] could be inspected for detecting retargeting from SIP and SIPS. Retargeting from SIP to SIPS by a proxy is an issue because it can leave the receiver of the request with the impression that the request was delivered securely on each hop, while in fact, it was not.
SIPSリクエスト-URIの存在は、各ホップでリクエストが安全に送信されたことを必ずしも示しているわけではありません。では、リクエストパス全体にSIPがエンドツーエンドを保護するために、SIPが要求パス全体に使用されたかどうかをどのようにして知るのでしょうか？事実上、UASは確実に知ることができません。ただし、[RFC3261]、セクション26.4.4は、UASがセキュリティを検証するためにいくつかのチェックを行う方法を推奨しています。さらに、SIPやSIPからのリターゲティングを検出するために、History-INFOヘッダーフィールド[RFC4244]を検査できます。プロキシによるSIPからSIPへのリターゲティングは、リクエストの受信者に各ホップで安全に配信されたという印象を残すことができるため、問題ですが、実際にはそうではありませんでした。
To emphasize, all the checking can be circumvented by any proxies or back-to-back user agents (B2BUAs) on the path that do not follow the rules and recommendations of this specification and of [RFC3261].
強調するために、すべてのチェックは、この仕様と[RFC3261]のルールと推奨事項に従っていないパスについて、プロキシまたは連続したユーザーエージェント（B2BUA）によって回避できます。
Proxies can have their own policies regarding routing of requests to SIP or SIPS URIs. For example, some proxies in some environments can be configured to only route SIPS URIs. Some proxies can be configured to detect non-compliances and reject unsecure requests. For example, proxies could inspect Request-URIs, Path, Record-Route, To, From, Contact header fields, and Via header fields to enforce SIPS.
プロキシは、urisを飲んだりSIPしたりするリクエストのルーティングに関する独自のポリシーを持つことができます。たとえば、一部の環境の一部のプロキシは、SIPS URIのみをルーティングするように構成できます。一部のプロキシは、非補完を検出し、安全でないリクエストを拒否するように構成できます。たとえば、プロキシは、Request-uris、Path、Record-route、to、From、Contact Headerフィールド、およびヘッダーフィールドを介してSIPを強制することができます。
[RFC3261], Section 26.4.4, explains that S/MIME can also be used by the originating UAC to ensure that the original form of the To header field is carried end-to-end. While not specifically mentioned in [RFC3261], Section 26.4.4, this is meant to imply that [RFC3893] would be used to "tunnel" important header fields (such as To and From) in an encrypted and signed S/MIME body, replicating the information in the SIP message, and allowing the UAS to validate the content of those important header fields. While this approach is certainly legal, a preferable approach is to use the SIP Identity mechanism defined in [RFC4474]. SIP Identity creates a signed identity digest, which includes, among other things, the Address of Record (AOR) of the sender (from the From header field) and the AOR of the original target (from the To header field).
[RFC3261]、セクション26.4.4は、S/MIMEを発信元のUACで使用して、元の形式のヘッダーフィールドがエンドツーエンドで運ばれるようにすることもできることを説明しています。[RFC3261]、セクション26.4.4で特別に言及されていませんが、これは[RFC3893]が暗号化されたS/MIMEボディの重要なヘッダーフィールド（andなど）を「トンネル」するために使用されることを意味することを意図しています。SIPメッセージの情報を複製し、UASがそれらの重要なヘッダーフィールドのコンテンツを検証できるようにします。このアプローチは確かに合法ですが、好ましいアプローチは[RFC4474]で定義されているSIP IDメカニズムを使用することです。SIP IDは、送信者のレコード（AOR）のアドレス（ヘッダーフィールドから）と元のターゲットのAOR（ヘッダーフィールドからヘッダーフィールドへ）を含む署名されたIDダイジェストを作成します。
[RFC3261], Section 19.1, describes a SIPS URI as follows:
[RFC3261]、セクション19.1は、SIPS URIを次のように説明しています。
A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. From there, secure communications are used to reach the user, where the specific security mechanism depends on the policy of the domain.
SIPS URIは、リソースに安全に接触することを指定します。これは、特に、TLSがUACとURIを所有するドメインの間で使用されることを意味します。そこから、安全な通信が使用され、特定のセキュリティメカニズムがドメインのポリシーに依存するユーザーに到達します。
Section 26.2.2 re-iterates it, with regards to Request-URIs:
セクション26.2.2は、リクエストウリスに関して、それを繰り返します。
When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address-of-record of the target), SIPS dictates that the entire request path to the target domain be so secured.
リクエストのリクエスト-URIとして使用される場合、SIPSスキームは、リクエストがリクエスト-URIのドメイン部分を担当するSIPエンティティに到達するまで、リクエストが転送される各ホップをTLSで保護する必要があることを意味します。問題のドメインに到達すると、ローカルセキュリティおよびルーティングポリシーに従って処理され、おそらく最後のホップにUASにTLSを使用します。リクエストのオリジネーターが使用する場合（ターゲットの録音アドレスとしてSIPS URIを使用した場合の場合と同様）、SIPSは、ターゲットドメインへの要求パス全体が非常に確保されることを決定します。
Let's take the classic SIP trapezoid to explain the meaning of a sips:b@B URI. Instead of using real domain names like example.com and example.net, logical names like "A" and "B" are used, for clarity.
SIPの意味を説明するために、古典的なSIP台形を取りましょう：B@b uri。example.comやemble.netなどの実際のドメイン名を使用する代わりに、「A」や「B」などの論理名が明確に使用されます。
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . Policy-based .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UAC a | . . | UAS b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
SIP trapezoid with last-hop exception
ラストホップ例外を除いて、シップ台形
According to [RFC3261], if a@A is sending a request to sips:b@B, the following applies:
[rfc3261]によると、a@aがsipsにリクエストを送信している場合、b@bには次のものが適用されます。
o TLS is required between UA a@A and Proxy A
o UA A@AとプロキシAの間にTLSが必要です
o TLS is required between Proxy A and Proxy B
o TLSは、プロキシAとプロキシbの間で必要です
o TLS is required between Proxy B and UA b@B, depending on local policy.
o TLSは、ローカルポリシーに応じて、プロキシBとUA B@Bの間で必要です。
One can then wonder why TLS is mandatory between UA a@A and Proxy A but not between Proxy B and UA b@B. The main reason is that [RFC3261] was written before [RFC5626]. At that time, it was recognized that in many practical deployments, Proxy B might not be able to establish a TLS connection with UA b because only Proxy B would have a certificate to provide and UA b would not. Since UA b would be the TLS server, it would then not be able to accept the incoming TLS connection. The consequence is that an [RFC3261]- compliant UAS b, while it might not need to support TLS for incoming requests, will nevertheless have to support TLS for outgoing requests as it takes the UAC role. Contrary to what many believed erroneously, the last-hop exception was not created to allow for using a SIPS URI to address a UAS that does not support TLS: the last-hop exception was an attempt to allow for incoming requests to not be transported over TLS when a SIPS URI is used, and it does not apply to outgoing requests. The rationale for this was somewhat flawed, and since then, [RFC5626] has provided a more satisfactory solution to this problem. [RFC5626] also solves the problem that if UA b is behind a NAT or firewall, Proxy B would not even be able to establish a TCP session in the first place.
次に、なぜua a@aとプロキシAの間でTLSが必須であるのか疑問に思うことができますが、プロキシBとUA B@Bの間ではありません。主な理由は、[RFC3261]が[RFC5626]の前に書かれていたことです。当時、多くの実用的な展開では、プロキシBのみが提供する証明書を持っていてUA Bがそうではないため、プロキシBがUA BとのTLS接続を確立できない可能性があることが認識されていました。UA BはTLSサーバーになるため、着信TLS接続を受け入れることができません。その結果、[RFC3261] - 準拠のUAS Bは、着信要求のためにTLSをサポートする必要はないかもしれませんが、それにもかかわらず、UACの役割を担うため、発信要求のためにTLSをサポートする必要があります。多くの人が誤って信じていたこととは反対に、TLSをサポートしていないSIPS URIを使用してUASに対処することを許可するためにラストホップ例外は作成されませんでした。最終ホップ例外は、着信要求を輸送しないようにする試みでした。TLS SIPS URIが使用されている場合、発信リクエストには適用されません。これの理論的根拠はやや欠陥があり、それ以来、[RFC5626]はこの問題に対してより満足のいく解決策を提供しました。[RFC5626]は、UA BがNATまたはファイアウォールの背後にある場合、プロキシBがそもそもTCPセッションを確立することさえできないという問題も解決します。
Furthermore, consider the problem of using SIPS inside a dialog. If a@A sends a request to b@B using a SIPS Request-URI, then, according to [RFC3261], Section 8.1.1.8, "the Contact header field MUST contain a SIPS URI as well". This means that b@B, upon sending a new Request within the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS URI. If there is no Record-Route entry, or if the last Record-Route entry consists of a SIPS URI, this implies that b@B is expected to understand SIPS in the first place, and is required to also support TLS. If the last Record-Route entry however is a sip URI, then b would be able to send requests without using TLS (but b would still have to be able to handle SIPS schemes when parsing the message). In either case, the Request-URI in the request from b@B to B would be a SIPS URI.
さらに、ダイアログ内でSIPを使用する問題を考慮してください。A@AがSIPSリクエスト-URIを使用してB@Bにリクエストを送信する場合、[RFC3261]に従ってセクション8.1.1.8に従って、「コンタクトヘッダーフィールドにもSIPS URIを含める必要があります」。これは、ダイアログ内で新しいリクエストを送信すると、b@bが（たとえば、a byeまたはre invite）がSIPS URIを使用する必要があることを意味します。レコードルートエントリがない場合、または最後のレコードルートエントリがSIPS URIで構成されている場合、これはB@BがそもそもSIPを理解することが期待され、TLSもサポートする必要があることを意味します。ただし、最後のレコードルートエントリがSIP URIである場合、BはTLSを使用せずにリクエストを送信できます（ただし、メッセージを解析するときにBはSIPSスキームを処理できる必要があります）。どちらの場合でも、B@BからBへのリクエストのリクエスト-URIは、SIPS URIになります。
Because of all the problems described in Section 3.3, this specification deprecates the last-hop exception when forwarding a request to the last hop (see Section 5.3). This will ensure that TLS is used on all hops all the way up to the remote target.
セクション3.3で説明されているすべての問題のため、この仕様は、リクエストを最後のホップに転送する際に最終ホップの例外を非難します（セクション5.3を参照）。これにより、TLSがすべてのホップでリモートターゲットまで使用されることが保証されます。
.......................... ...........................
. . . .
. +-------+ . . +-------+ .
. | | . . | | .
. | Proxy |-----TLS---- | Proxy | .
. | A | . . | B | .
. | | . . | | .
. / +-------+ . . +-------+ \ .
. / . . \ .
. / . . \ .
. TLS . . TLS .
. / . . \ .
. / . . \ .
. / . . \ .
. +-------+ . . +-------+ .
. | | . . | | .
. | UAC a | . . | UAS b | .
. | | . . | | .
. +-------+ . . +-------+ .
. Domain A . . Domain B .
.......................... ...........................
SIP trapezoid without last-hop exception
ラストホップの例外なしでは、シップ台形
The SIPS scheme implies transitive trust. Obviously, there is nothing that prevents proxies from cheating (see [RFC3261], Section 26.4.4). While SIPS is useful to request that a resource be contacted securely, it is not useful as an indication that a resource was in fact contacted securely. Therefore, it is not appropriate to infer that because an incoming request had a Request-URI (or even a To header field) containing a SIPS URI, that it necessarily guarantees that the request was in fact transmitted securely on each hop. Some have been tempted to believe that the SIPS scheme was equivalent to an HTTPS scheme in the sense that one could provide a visual indication to a user (e.g., a padlock icon) to the effect that the session is secured. This is obviously not the case, and therefore the meaning of a SIPS URI is not to be oversold. There is currently no mechanism to provide an indication of end-to-end security for SIP. Other mechanisms can provide a more concrete indication of some level of security. For example, SIP Identity [RFC4474] provides an authenticated identity mechanism and a domain-to-domain integrity protection mechanism.
SIPSスキームは、推移的な信頼を意味します。明らかに、プロキシが不正行為を防ぐものは何もありません（[RFC3261]、セクション26.4.4を参照）。SIPSはリソースに安全に接触するように要求するのに役立ちますが、リソースが実際に安全に接触したことを示すこととして役立ちません。したがって、SIPS URIを含むリクエスト-URI（またはヘッダーフィールドまで）があり、要求が実際に各ホップで安全に送信されたことを必然的に保証することを、受信リクエストにはリクエスト-URI（またはヘッダーフィールドからヘッダーフィールドまで）があったために適切ではありません。SIPSスキームは、セッションが保護されているという効果に対するユーザー（たとえば、南京錠のアイコン）に視覚的な表示を提供できるという意味で、HTTPSスキームと同等であると信じるように誘惑されています。これは明らかにそうではありません。したがって、SIPS URIの意味は売られすぎてはいけません。現在、SIPのエンドツーエンドのセキュリティを示すメカニズムはありません。他のメカニズムは、ある程度のセキュリティのより具体的な兆候を提供することができます。たとえば、SIPアイデンティティ[RFC4474]は、認証されたアイデンティティメカニズムとドメインからドメインへの完全性保護メカニズムを提供します。
Some have asked why is SIPS useful in a global open environment such as the Internet, if (when used in a Request-URI) it is not an absolute guarantee that the request will in fact be delivered over TLS on each hop? Why is SIPS any different from just using TLS transport with SIP? The difference is that using a SIPS URI in a Request-URI means that if you are instructing the network to use TLS over each hop and if it is not possible to reject the request, you would rather have the request fail than have the request delivered without TLS. Just using TLS with a SIP Request-URI instead of a SIPS Request-URI implies a "best-effort" service: the request can but need not be delivered over TLS on each hop.
インターネットなどのグローバルなオープン環境でSIPSが役立つ理由を尋ねる人もいます。（リクエスト-URIで使用された場合）、各ホップでリクエストが実際にTLSを介して配信されるという絶対的な保証ではない場合は、なぜ尋ねましたか？SIPがSIPでTLSトランスポートを使用することとは異なるのはなぜですか？違いは、リクエスト-URIでSIPS URIを使用することは、各ホップでTLSを使用するようにネットワークに指示している場合、リクエストを拒否することが不可能な場合、リクエストがリクエストを配信するよりもむしろリクエストが失敗することを意味することです。TLSなし。SIPのリクエスト-URIの代わりにSIPリクエスト-URIを使用してTLSを使用するだけで、「ベストエフォート」サービスが意味されます。各ホップでTLSを介して配信する必要はありませんが、リクエストは配信する必要はありません。
Another common question is why not have a Proxy-Require and Require option tag forcing the use of TLS instead? The answer is that it would only be functionally equivalent to using SIPS in a Request-URI. SIPS URIs however can be used in many other header fields: in Contact for registration, Contact in dialog-creating requests, Route, Record-Route, Path, From, To, Refer-To, Referred-By, etc. SIPS URIs can also be used in human-usable format (e.g., business cards, user interface). SIPS URIs can even be used in other protocols or document formats that allow for including SIPS URIs (e.g., HTML).
別の一般的な質問は、代わりにTLSの使用を強制するオプションタグを必要としないのはなぜですか？答えは、リクエスト-URIでSIPを使用することと機能的に同等であるということです。SIPS URIは、他の多くのヘッダーフィールドで使用できます。登録のために連絡して、ダイアログ作成リクエスト、ルート、レコードルート、パス、from、from、from、refered、refered-byなどの連絡先も使用できます。使用可能な形式（名刺、ユーザーインターフェイスなど）で使用します。SIPS URIは、SIPS URI（HTMLなど）を含めることを可能にする他のプロトコルまたはドキュメント形式でも使用できます。
This document specifies that SIPS means that the SIP resource designated by the target SIPS URI is to be contacted securely, using TLS on each hop between the UAC and the remote UAS (as opposed to only to the proxy responsible for the target domain of the Request-URI). It is outside of the scope of this document to specify what happens when a SIPS URI identifies a UAS resource that "maps" outside the SIP network, for example, to other networks such as the Public Switched Telephone Network (PSTN).
このドキュメントは、SIPSがターゲットSIPS URIによって指定されたSIPリソースが安全に連絡することを意味することを指定します。UACとリモートUASの間の各ホップでTLSを使用して（リクエストのターゲットドメインの責任者の責任者のみとは対照的ではありません-uri）。このドキュメントの範囲外で、SIPS URIがSIPネットワークの外側に「マップ」するUASリソースが、たとえば、パブリックスイッチド電話ネットワーク（PSTN）などの他のネットワークに「マップ」する場合に何が起こるかを指定することです。
SIP and SIPS URIs that are identical except for the scheme itself (e.g., sip:alice@example.com and sips:alice@example.com) refer to the same resource. This requirement is implicit in [RFC3261], Section 19.1, which states that "any resource described by a SIP URI can be 'upgraded' to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely". This does not mean that the SIPS URI will necessarily be reachable, in particular, if the proxy cannot establish a secure connection to a client or another proxy. This does not suggest either that proxies would arbitrarily "upgrade" SIP URIs to SIPS URIs when forwarding a request (see Section 5.3). Rather, it means that when a resource is addressable with SIP, it will also be addressable with SIPS.
スキーム自体を除いて同一のSIPおよびSIPS Uris（例：sip：alice@example.comおよびsips：alice@example.com）を参照してください。この要件は[RFC3261]、セクション19.1で暗黙的であり、「SIP URIによって説明されているリソースは、そのリソースと安全に通信することが望まれる場合、SIPS URIに「アップグレード」することができる」と述べています。これは、特にプロキシがクライアントまたは他のプロキシへの安全な接続を確立できない場合、SIPS URIが必ずしも到達可能であることを意味しません。これは、プロキシがリクエストを転送するときにurisにarbitrarily意的に「アップグレード」することを示唆していません（セクション5.3を参照）。むしろ、リソースがSIPでアドレス指定できる場合、SIPでもアドレス指定できることを意味します。
For example, consider the case of a UA that has registered with a SIPS Contact header field. If a UAC later addresses a request using a SIP Request-URI, the proxy will forward the request addressed to a SIP Request-URI to the UAS, as illustrated by message F13 in Sections 6.3 and in 6.4. The proxy forwards the request to the UA using a SIP Request-URI and not the SIPS Request-URI used in registration. The proxy does this by replacing the SIPS scheme that was used in the registered Contact header field binding with a SIP scheme while leaving the rest of the URI as is, and then by using this new URI as the Request-URI. If the proxy did not do this, and instead used a SIPS Request-URI, then the response (e.g., a 200 to an INVITE) would have to include a SIPS Contact header field. That SIPS Contact header field would then force the other UA to use a SIPS Contact header field in any mid-dialog request, including the ACK (which would not be possible if that UA did not support SIPS).
たとえば、SIPS連絡先ヘッダーフィールドに登録されているUAの場合を検討してください。UACが後でSIPリクエストURIを使用してリクエストを扱う場合、プロキシは、セクション6.3および6.4のメッセージF13で示されているように、SIPリクエストURIにアドレス指定されたリクエストをUASに転送します。プロキシは、登録で使用されるSIPリクエスト-URIではなく、SIPリクエスト-URIを使用してRequestをUAに転送します。プロキシは、登録されたコンタクトヘッダーフィールドで使用されたSIPSスキームをSIPスキームでバインディングし、残りのURIをそのままにしてから、この新しいURIをリクエスト-URIとして使用することにより、これを行います。プロキシがこれを行わず、代わりにSIPS request-uriを使用した場合、応答（たとえば、招待までの200）には、SIPS連絡先ヘッダーフィールドを含める必要があります。そのSIPSコンタクトヘッダーフィールドは、他のUAに、ACKを含むMid-DialogリクエストでSIPSコンタクトヘッダーフィールドを使用するように強制されます（UAがSIPSをサポートしていない場合は不可能です）。
This specification mandates that when a proxy is forwarding a request, a resource described by a SIPS Request-URI cannot be "downgraded" to a SIP URI by changing the scheme, or by sending the associated request over a nonsecure link. If a request needs to be rejected because otherwise it would be a "downgrade", the request would be rejected with a 480 (Temporarily Unavailable) response (potentially with a Warning header with warn-code 380 "SIPS Not Allowed"). Similarly, this specification mandates that when a proxy is forwarding a request, a resource described by a SIP Request-URI cannot be "upgraded" to a SIPS URI by changing the scheme (otherwise it would be an "upgrade" only for that hop onwards rather than on all hops, and would therefore mislead the UAS). If a request needs to be rejected because otherwise it would be a misleading "upgrade", the request would be rejected with a 480 (Temporarily Unavailable) response (potentially with a Warning header field with warn-code 381 "SIPS Required"). See Section 5.3 for more details.
この仕様は、プロキシが要求を転送している場合、SIPSリクエスト-RIによって説明されたリソースをSIP URIに「格下げ」することができないことを義務付けています。それ以外の場合は「ダウングレード」になるためにリクエストを拒否する必要がある場合、リクエストは480（一時的に利用できない）応答で拒否されます（Warn-Code 380 "SIPSが許可されていない"を備えた警告ヘッダーで）。同様に、この仕様は、プロキシがリクエストを転送している場合、SIPリクエスト-URIによって記述されたリソースをSIPS URIに「アップグレード」することができないことを義務付けています（そうでなければ、そのホップ以降のみの「アップグレード」になります。すべてのホップではなく、したがってUASを誤解させるでしょう）。それ以外の場合は、誤解を招く「アップグレード」になるため、リクエストを拒否する必要がある場合、リクエストは480（一時的に利用できない）応答で拒否されます（Warn-Code 381 "SIPSが必要」の警告ヘッダーフィールドを使用する可能性があります）。詳細については、セクション5.3を参照してください。
For example, the sip:bob@example.com and sips:bob@example.com AORs refer to the same user "Bob" in the domain "example.com": the first URI is the SIP version, and the second one is the SIPS version. From the point of view of routing, requests to either sip:bob@example.com or sips:bob@example.com are treated the same way. When Bob registers, it therefore does not really matter if he is using a SIP or a SIPS AOR, since they both refer to the same user. At first glance, Section 19.1.4 of [RFC3261] seems to contradict this idea by stating that a SIP and a SIPS URI are never equivalent. Specifically, it says that they are never equivalent for the purpose of comparing bindings in Contact header field URIs in REGISTER requests. The key point is that this statement applies to the Contact header field bindings in a registration: it is the association of the Contact header field with the AOR that will determine whether or not the user is reachable with a SIPS URI.
たとえば、sip：bob@example.comとsips：bob@example.com aorsは、ドメインの同じユーザー「bob」を参照してください "example.com"：最初のuriはsipバージョンで、2番目はsipバージョンです。SIPSバージョン。ルーティングの観点から、sip：bob@example.comまたはsips：bob@example.comへの要求は同じ方法で扱われます。したがって、ボブが登録すると、両方とも同じユーザーを参照するため、SIPまたはSIPS AORを使用しているかどうかは実際には問題ではありません。一見したところ、[RFC3261]のセクション19.1.4は、SIPとSIPS URIが決して同等ではないと述べることにより、このアイデアと矛盾しているようです。具体的には、レジスタリクエストでコンタクトヘッダーフィールドURIのバインディングを比較する目的では、それらが決して同等ではないと述べています。重要なポイントは、このステートメントが登録のコンタクトヘッダーフィールドバインディングに適用されることです。これは、ユーザーがSIPS URIで到達可能かどうかを判断するのは、AORとの接触ヘッダーフィールドの関連です。
Consider this example: if Bob (AOR bob@example.com) registers with a SIPS Contact header field (e.g., sips:bob@bobphone.example.com), the registrar and the location service then know that Bob is reachable at sips:bob@bobphone.example.com and at sip:bob@bobphone.example.com.
この例を考えてみましょう。Bob（aorbob@example.com）がSIPS連絡先ヘッダーフィールド（例：sips：bob@bobphone.example.com）で登録する場合、レジストラとロケーションサービスは、ボブがSIPで到達可能であることを知っています。bob@bobphone.example.comおよびsip：bob@bobphone.example.com
If a request is sent to AOR sips:bob@example.com, Bob's proxy will route it to Bob at Request-URI sips:bob@bobphone.example.com. If a request is sent to AOR sip:bob@example.com, Bob's proxy will route it to Bob at Request-URI sip:bob@bobphone.example.com.
リクエストがaor sipsに送信された場合：bob@example.com、ボブのプロキシは、リクエスト - ウリsips：bob@bobphone.example.comでボブにルーティングします。リクエストがaor sipに送信された場合：bob@example.com、ボブのプロキシは、リクエスト - ウリsip：bob@bobphone.example.comでボブにルーティングします。
If Bob wants to ensure that every request delivered to him always be transported over TLS, Bob can use [RFC5626] when registering.
ボブが彼に配信されたすべての要求が常にTLSを介して輸送されるようにしたい場合、ボブは登録時に[RFC5626]を使用できます。
However, if Bob had registered with a SIP Contact header field instead of a SIPS Contact header field (e.g., sip:bob@bobphone.example.com), then a request to AOR sips:bob@example.com would not be routed to Bob, since there is no SIPS Contact header field for Bob, and "downgrades" from SIPS to SIP are not allowed.
ただし、BobがSIPの連絡先ヘッダーフィールドの代わりにSIP連絡先ヘッダーフィールド（例：sip：bob@bobphone.example.com）に登録していた場合、aor sipsへのリクエスト：bob@example.comはルーティングされません。ボブ、BOBのSIPSコンタクトヘッダーフィールドがないため、SIPSからSIPへの「ダウングレード」は許可されていません。
See Section 6 for illustrative call flows.
説明的なコールフローについては、セクション6を参照してください。
This section describes all the normative requirements defined by this specification.
このセクションでは、この仕様で定義されたすべての規範要件について説明します。
When presented with a SIPS URI, a UAC MUST NOT change it to a SIP URI. For example, if a directory entry includes a SIPS AOR, the UAC is not expected to send requests to that AOR using a SIP Request-URI. Similarly, if a user reads a business card with a SIPS URI, it is not possible to infer a SIP URI. If a 3XX response includes a SIPS Contact header field, the UAC does not replace it with a SIP Request-URI (e.g., by replacing the SIPS scheme with a SIP scheme) when sending a request as a result of the redirection.
SIPS URIが表示された場合、UACはSIP URIに変更してはなりません。たとえば、ディレクトリエントリにSIPS AORが含まれている場合、UACはSIPリクエストURIを使用してそのAORにリクエストを送信することは期待されていません。同様に、ユーザーがSIPS URIで名刺を読む場合、SIP URIを推測することはできません。3XX応答にSIPS連絡先ヘッダーフィールドが含まれている場合、UACはリダイレクトの結果としてリクエストを送信するときに、SIPリクエスト-URI（たとえば、SIPスキームをSIPスキームに置き換えることで）に置き換えません。
As mandated by [RFC3261], Section 8.1.1.8, in a request, "if the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well".
[RFC3261]、セクション8.1.1.8で義務付けられているように、「リクエスト-URIまたはトップルートヘッダーフィールド値がSIPS URIが含まれている場合、コンタクトヘッダーフィールドにはSIPS URIも含まれている必要があります」。
Upon receiving a 416 response or a 480 (Temporarily Unavailable) response with a Warning header with warn-code 380 "SIPS Not Allowed", a UAC MUST NOT re-attempt the request by automatically replacing the SIPS scheme with a SIP scheme as described in [RFC3261], Section 8.1.3.5, as it would be a security vulnerability. If the UAC does re-attempt the call with a SIP URI, the UAC SHOULD get a confirmation from the user to authorize re-initiating the session with a SIP Request-URI instead of a SIPS Request-URI.
Warn-Code 380 "SIPSが許可されていない"を使用して警告ヘッダーを使用して416回の応答または480（一時的に利用できない）応答を受信した場合、UACは、SIPSスキームをSIPスキームに自動的に交換することにより、リクエストを再試行してはなりません。[RFC3261]、セクション8.1.3.5、セキュリティの脆弱性です。UACがSIP URIでコールを再起動した場合、UACはユーザーから確認を取得して、SIPリクエストURIの代わりにSIPリクエスト-URIでセッションを再開始することを許可する必要があります。
When the route set is not empty (e.g., when a service route [RFC3608] is returned by the registrar), it is the responsibility of the UAC to use a Route header field consisting of all SIPS URIs when using a SIPS Request-URI. Specifically, if the route set included any SIP URI, the UAC MUST change the SIP URIs to SIPS URIs simply by changing the scheme from "sip" to "sips" before sending the request. This allows for configuring or discovering one service route with all SIP URIs and allowing sending requests to both SIP and SIPS URIs.
ルートセットが空でない場合（たとえば、レジストラによってサービスルート[RFC3608]が返される場合）、SIPSリクエストURIを使用するときにすべてのSIPS URIで構成されるルートヘッダーフィールドを使用することはUACの責任です。具体的には、ルートセットにSIP URIが含まれている場合、UACは、リクエストを送信する前にスキームを「SIP」から「SIP」に変更するだけで、SIP URIをSIP URISに変更する必要があります。これにより、すべてのSIP URIを使用して1つのサービスルートを構成または検出し、SIPとSIPの両方のURIにリクエストを送信できるようになります。
When the UAC is using a SIP Request-URI, if the route set is not empty and the topmost Route header field entry is a SIPS URI with the lr parameter, the UAC MUST send the request over TLS (using a SIP Request-URI). If the route is not empty and the Route header field entry is a SIPS URI without the lr parameter, the UAC MUST send the request over TLS using a SIPS Request-URI corresponding to the topmost entry in the route set.
UACがSIPリクエストURIを使用している場合、ルートセットが空でなく、最上部のルートヘッダーフィールドエントリがLRパラメーターを備えたSIPS URIの場合、UACはTLSを介してリクエストを送信する必要があります（SIP Request-URIを使用）。ルートが空でなく、ルートヘッダーフィールドエントリがLRパラメーターのないSIPS URIである場合、UACはルートセットの最上位エントリに対応するSIPSリクエスト-URIを使用してTLSを介してリクエストを送信する必要があります。
To emphasize what is already defined in [RFC3261], UAs MUST NOT use the "transport=tls" parameter.
[RFC3261]ですでに定義されているものを強調するには、UASは「Transport = TLS」パラメーターを使用してはなりません。
The UAC registers Contacts header fields to either a SIPS or a SIP AOR.
UACは、ヘッダーフィールドをSIPSまたはSIP AORのいずれかに連絡します。
If a UA wishes to be reachable with a SIPS URI, the UA MUST register with a SIPS Contact header field. Requests addressed to that UA's AOR using either a SIP or SIPS Request-URI will be routed to that UA. This includes UAs that support both SIP and SIPS. This specification does not provide any SIP-based mechanism for a UA to provision its proxy to only forward requests using a SIPS Request-URI. A non-SIP mechanism such as a web interface could be used to provision such a preference. A SIP mechanism for provisioning such a preference is outside the scope of this specification.
UAがSIPS URIで到達可能になりたい場合、UAはSIPS連絡先ヘッダーフィールドに登録する必要があります。SIPまたはSIPのリクエスト-URIを使用してそのUAのAORに宛てられたリクエストは、そのUAにルーティングされます。これには、SIPとSIPの両方をサポートするUASが含まれます。この仕様では、SIPベースのメカニズムは、SIP Request-URIを使用してリクエストのみを転送するためにプロキシをプロキシを提供するためのSIPベースのメカニズムを提供しません。Webインターフェイスなどの非SIPメカニズムを使用して、そのような好みをプロビジョニングできます。このような好みをプロビジョニングするためのSIPメカニズムは、この仕様の範囲外です。
If a UA does not wish to be reached with a SIPS URI, it MUST register with a SIP Contact header field.
UAがSIPS URIで到達したくない場合は、SIP連絡先ヘッダーフィールドに登録する必要があります。
Because registering with a SIPS Contact header field implies a binding of both a SIPS Contact and a corresponding SIP Contact to the AOR, a UA MUST NOT include both the SIPS and the SIP versions of the same Contact header field in a REGISTER request; the UA MUST only use the SIPS version in this case. Similarly, a UA SHOULD NOT register both a SIP Contact header field and a SIPS Contact header field in separate registrations as the SIP Contact header field would be superfluous. If it does, the second registration replaces the first one (e.g., a UA could register first with a SIP Contact header field, meaning it does not support SIPS, and later register with a SIPS Contact header field, meaning it now supports SIPS). Similarly, if a UA registers first with a SIPS Contact header field and later registers with a SIP Contact header field, that SIP Contact header field replaces the SIPS Contact header field.
SIPS連絡先ヘッダーフィールドに登録すると、SIPS接点とAORへの対応するSIP接点の両方の結合があることを意味するため、UAにはレジスタリクエストに同じ連絡先ヘッダーフィールドのSIPバージョンとSIPバージョンの両方を含めてはなりません。この場合、UAはSIPSバージョンのみを使用する必要があります。同様に、UAは、SIPコンタクトヘッダーフィールドが余分なものであるため、SIPコンタクトヘッダーフィールドとSIPの連絡先ヘッダーフィールドの両方を個別の登録で登録しないでください。もしそうなら、2番目の登録は最初の登録に置き換えられます（例えば、UAは最初にSIP連絡先ヘッダーフィールドに登録できます。つまり、SIPをサポートしないことを意味し、後でSIPの連絡先ヘッダーフィールドに登録します。つまり、SIPをサポートします）。同様に、SIPSコンタクトヘッダーフィールドでUAが最初に登録し、後にSIPコンタクトヘッダーフィールドで登録する場合、SIPコンタクトヘッダーフィールドはSIPSコンタクトヘッダーフィールドを置き換えます。
[RFC5626] can be used by a UA if it wants to ensure that no requests are delivered to it without using the TLS connection it used when registering.
[RFC5626]は、登録時に使用したTLS接続を使用せずにリクエストが配信されないようにしたい場合は、UAで使用できます。
If all the Contact header fields in a REGISTER request are SIPS, the UAC MUST use SIPS AORs in the From and To header fields in the REGISTER request. If at least one of the Contact header fields is not SIPS (e.g., sip, mailto, tel, http, https), the UAC MUST use SIP AORs in the From and To header fields in the REGISTER request.
レジスタリクエスト内のすべての連絡先ヘッダーフィールドがSIPSである場合、UACはレジスタリクエストでfromとヘッダーフィールドにsips aorsを使用する必要があります。連絡先ヘッダーフィールドの少なくとも1つがSIP（SIP、MailTo、Tel、HTTP、HTTPSなど）ではない場合、UACはレジスタリクエストでFromとHeaderフィールドにSIP AORを使用する必要があります。
To emphasize what is already defined in [RFC3261], UACs MUST NOT use the "transport=tls" parameter.
[RFC3261]で既に定義されているものを強調するには、UACは「Transport = TLS」パラメーターを使用してはなりません。
If the Request-URI in a request that initiates a dialog is a SIP URI, then the UAC needs to be careful about what to use in the Contact header field (in case Record-Route is not used for this hop). If the Contact header field was a SIPS URI, it would mean that the UAS would only accept mid-dialog requests that are sent over secure transport on each hop. Since the Request-URI in this case is a SIP URI, it is quite possible that the UA sending a request to that URI might not be able to send requests to SIPS URIs. If the top Route header field does not contain a SIPS URI, the UAC MUST use a SIP URI in the Contact header field, even if the request is sent over a secure transport (e.g., the first hop could be re-using a TLS connection to the proxy as would be the case with [RFC5626]).
ダイアログを開始するリクエストのリクエスト-URIがSIP URIである場合、UACはコンタクトヘッダーフィールドで使用するものに注意する必要があります（このホップにレコードルートが使用されない場合）。コンタクトヘッダーフィールドがSIPS URIである場合、UASは各ホップで安全なトランスポートを介して送信されるミッドダイアログリクエストのみを受け入れることを意味します。この場合のリクエスト-URIはSIP URIであるため、URIにリクエストを送信するURIがurisにリクエストを送信できない可能性が非常に高いです。トップルートヘッダーフィールドにSIPS URIが含まれていない場合、UACは安全なトランスポートにリクエストが送信された場合でも、コンタクトヘッダーフィールドでSIP URIを使用する必要があります（例えば、最初のホップはTLS接続の再利用です。[RFC5626]の場合と同様に、プロキシに。
When a target refresh occurs within a dialog (e.g., re-INVITE request, UPDATE request), the UAC MUST include a Contact header field with a SIPS URI if the original request used a SIPS Request-URI.
ダイアログ内でターゲットの更新が発生した場合（例えば、re-invite request、update request）、UACには、元のリクエストがSIPSリクエストURIを使用した場合は、SIPS URIの連絡先ヘッダーフィールドを含める必要があります。
Sessions, dialogs, and transactions can be "derived" from existing ones. A good example of a derived dialog is one that was established as a result of using the REFER method [RFC3515].
セッション、ダイアログ、およびトランザクションは、既存のセッションから「導き出される」ことができます。派生したダイアログの良い例は、参照方法[RFC3515]を使用した結果として確立されたダイアログです。
As a general principle, derived dialogs and transactions cannot result in an effective downgrading of SIPS to SIP, without the explicit authorization of the entities involved.
一般的な原則として、派生したダイアログとトランザクションは、関係するエンティティの明示的な許可なしに、SIPをSIPに効果的に格下げすることはできません。
For example, when a REFER request is used to perform a call transfer, it results in an existing dialog being terminated and another one being created based on the Refer-To URI. If that initial dialog was established using SIPS, then the UAC MUST NOT establish a new one using SIP, unless there is an explicit authorization given by the recipient of the REFER request. This could be a warning provided to the user. Having such a warning could be useful, for example, for a secure directory service application, to warn a user that a request may be routed to a UA that does not support SIPS.
たとえば、紹介リクエストを使用して呼び出し転送を実行すると、既存のダイアログが終了し、URIへの紹介に基づいて作成されます。SIPを使用してその最初のダイアログが確立された場合、referime requentリクエストの受信者によって明示的な承認が与えられない限り、UACはSIPを使用して新しいものを確立してはなりません。これは、ユーザーに提供される警告かもしれません。このような警告を発することは、たとえば、Secure Directory Serviceアプリケーションの場合、SIPSをサポートしないUAにリクエストがルーティングされる可能性があることをユーザーに警告するために役立ちます。
A REFER request can also be used for referring to resources that do not result in dialogs being created. In fact, a REFER request can be used to point to resources that are of a different type than the original one (i.e., not SIP or SIPS). Please see [RFC3515], Section 5.2, for security considerations related to this.
参照要求は、ダイアログが作成されないリソースを参照するためにも使用できます。実際、紹介要求を使用して、元のものとは異なるタイプのリソース（つまり、SIPやSIPではなく）を指すことができます。これに関連するセキュリティ上の考慮事項については、[RFC3515]、セクション5.2を参照してください。
Other examples of derived dialogs and transactions include the use of Third-Party Call Control [RFC3725], the Replaces header field [RFC3891], and the Join header field [RFC3911]. Again, the general principle is that these mechanisms SHOULD NOT result in an effective downgrading of SIPS to SIP, without the proper authorization.
派生したダイアログとトランザクションの他の例には、サードパーティのコールコントロール[RFC3725]、交換ヘッダーフィールド[RFC3891]、および結合ヘッダーフィールド[RFC3911]の使用が含まれます。繰り返しますが、一般的な原則は、これらのメカニズムが、適切な許可なしに、SIPへのSIPの効果的な格下げにつながるべきではないということです。
When a Globally Routable User Agent URI (GRUU) [RFC5627] is assigned to an instance ID/AOR pair, both SIP and SIPS GRUUs will be assigned. When a GRUU is obtained through registration, if the Contact header field in the REGISTER request contains a SIP URI, the SIP version of the GRUU is returned. If the Contact header field in the REGISTER request contains a SIPS URI, the SIPS version of the GRUU is returned.
グローバルにルーティング可能なユーザーエージェントURI（GRUU）[RFC5627]がインスタンスID/AORペアに割り当てられると、SIPとSIPの両方のGruusが割り当てられます。Gruuが登録を通じて取得されると、レジスタリクエストのコンタクトヘッダーフィールドにSIP URIが含まれている場合、GruuのSIPバージョンが返されます。レジスタリクエストの連絡先ヘッダーフィールドにSIPS URIが含まれている場合、GruuのSIPSバージョンが返されます。
If the wrong scheme is received in the GRUU (which would be an error in the registrar), the UAC SHOULD treat it as if the proper scheme was used (i.e., it SHOULD replace the scheme with the proper scheme before using the GRUU).
Gruuで間違ったスキームを受け取った場合（これはレジストラのエラーになります）、UACは適切なスキームが使用されたかのように扱う必要があります（つまり、Gruuを使用する前にスキームを適切なスキームに置き換える必要があります）。
When presented with a SIPS URI, a UAS MUST NOT change it to a SIP URI.
SIPS URIが表示された場合、UASはSIP URIに変更してはなりません。
As mandated by [RFC3261], Section 12.1.1:
[RFC3261]によって義務付けられているように、セクション12.1.1：
If the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header field in the response MUST be a SIPS URI.
ダイアログを開始したリクエストに、リクエスト-URIまたはトップレコードルートヘッダーフィールド値にSIPS URIが含まれていた場合、存在する場合、またはレコードルートヘッダーフィールドがなかった場合はコンタクトヘッダーフィールド、コンタクトヘッダー応答のフィールドは、SIPS URIでなければなりません。
If a UAS does not wish to be reached with a SIPS URI but only with a SIP URI, the UAS MUST respond with a 480 (Temporarily Unavailable) response. The UAS SHOULD include a Warning header with warn-code 380 "SIPS Not Allowed". [RFC3261], Section 8.2.2.1, states that UASs that do not support the SIPS URI scheme at all "SHOULD reject the request with a 416 (Unsupported URI scheme) response".
UASがSIPS URIで到達することを望まないが、SIP URIのみで到達することを望んでいない場合、UASは480（一時的に利用できない）応答で応答する必要があります。UASには、Warn-Code 380 "SIPSが許可されていない"を備えた警告ヘッダーを含める必要があります。[RFC3261]、セクション8.2.2.1は、SIPS URIスキームをまったくサポートしていないUASSが「416（サポートされていないURIスキーム）応答でリクエストを拒否する必要がある」と述べています。
If a UAS does not wish to be contacted with a SIP URI but instead by a SIPS URI, it MUST reject a request to a SIP Request-URI with a 480 (Temporarily Unavailable) response. The UAS SHOULD include a Warning header with warn-code 381 "SIPS Required".
UASがSIP URIと連絡を取ることを望んでいないが、代わりにSIPS URIによって連絡する場合は、480（一時的に利用できない）応答でSIPリクエストURIへのリクエストを拒否する必要があります。UASには、Warn-Code 381「SIPSが必要」を備えた警告ヘッダーを含める必要があります。
It is a matter of local policy for a UAS to accept incoming requests addressed to a URI scheme that does not correspond to what it used for registration. For example, a UA with a policy of "always SIPS" would address the registrar using a SIPS Request-URI over TLS, would register with a SIPS Contact header field, and the UAS would reject requests using the SIP scheme with a 480 (Temporarily Unavailable) response with a Warning header with warn-code 381 "SIPS Required". A UA with a policy of "best-effort SIPS" would address the registrar using a SIPS Request-URI over TLS, would register with a SIPS Contact header field, and the UAS would accept requests addressed to either SIP or SIPS Request-URIs. A UA with a policy of "No SIPS" would address the registrar using a SIP Request-URI, could use TLS or not, would register with a SIP AOR and a SIP Contact header field, and the UAS would accept requests addressed to a SIP Request-URI.
UASが登録に使用したものに対応していないURIスキームに対処された着信要求を受け入れることは、ローカルポリシーの問題です。たとえば、「Always SIPS」のポリシーを持つUAは、TLSを介したSIPSリクエスト-URIを使用してレジストラにアドレス指定し、SIPS連絡先ヘッダーフィールドに登録し、UASは480のSIPスキームを使用してリクエストを拒否します（一時的に利用できません）WARNコード381「SIPSが必要」を備えた警告ヘッダーを使用した応答。「Best-Effort SIPS」のポリシーを備えたUAは、TLSを介したSIPSリクエスト-URIを使用してレジストラに対処し、SIPS連絡先ヘッダーフィールドに登録し、UASはSIPまたはSIPSリクエストURIのいずれかに宛てられたリクエストを受け入れます。「SIPSなし」のポリシーを備えたUAは、SIPリクエスト-URIを使用してレジストラにアドレス指定し、TLSを使用するかどうかにかかわらず、SIP AORとSIPコンタクトヘッダーフィールドに登録し、UASはSIPにアドレス指定されたリクエストを受け入れますRequest-uri。
If a UAS needs to reject a request because the URIs are used inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact header field is a SIP URI), the UAS MUST reject the request with a 400 (Bad Request) response.
URIが一貫して使用されていないためにUASがリクエストを拒否する必要がある場合（たとえば、リクエスト-URIはSIPS URIですが、コンタクトヘッダーフィールドはSIP URIです）、UASは400でリクエストを拒否する必要があります（悪い要求）応答。
When a target refresh occurs within a dialog (e.g., re-INVITE request, UPDATE request), the UAS MUST include a Contact header field with a SIPS URI if the original request used a SIPS Request-URI.
ダイアログ内でターゲットの更新が発生した場合（例えば、re-invite request、update request）、UASには、元のリクエストがSIPSリクエストURIを使用した場合、SIPS URIの連絡先ヘッダーフィールドを含める必要があります。
To emphasize what is already defined in [RFC3261], UASs MUST NOT use the "transport=tls" parameter.
[RFC3261]ですでに定義されているものを強調するには、UASSは「Transport = TLS」パラメーターを使用してはなりません。
The UAC registers Contacts header fields to either a SIPS or a SIP AOR. From a routing perspective, it does not matter which one is used for registration as they identify the same resource. The registrar MUST consider AORs that are identical except for one having the SIP scheme and the other having the SIPS scheme to be equivalent.
UACは、ヘッダーフィールドをSIPSまたはSIP AORのいずれかに連絡します。ルーティングの観点からは、同じリソースを識別するために登録に使用されるものは関係ありません。レジストラは、一方がSIPスキームを持っていることを除いて同一のAORを考慮する必要があり、もう1つはSIPスキームを同等にすることを検討する必要があります。
A registrar MUST accept a binding to a SIPS Contact header field only if all the appropriate URIs are of the SIPS scheme; otherwise, there could be an inadvertent binding of a secure resource (SIPS) to an unsecured one (SIP). This includes the Request-URI and the Contacts and all the Path header fields, but does not include the From and To header fields. If the URIs are not of the proper SIPS scheme, the registrar MUST reject the REGISTER with a 400 (Bad Request).
レジストラは、すべての適切なURIがSIPSスキームの場合にのみ、SIPS連絡先ヘッダーフィールドへのバインディングを受け入れる必要があります。それ以外の場合、安全なリソース（SIP）が無担保されたもの（SIP）に不注意な結合がある可能性があります。これには、リクエスト-URIと連絡先、およびすべてのパスヘッダーフィールドが含まれますが、FromとHeaderフィールドは含まれません。URIが適切なSIPSスキームでない場合、レジストラは400（悪い要求）でレジスタを拒否する必要があります。
A registrar can return a service route [RFC3608] and impose some constraints on whether or not TLS will be mandatory on specific hops. For example, if the topmost entry in the Path header field returned by the registrar is a SIPS URI, the registrar is telling the UAC that TLS is to be used for the first hop, even if the Request-URI is SIP.
レジストラは、サービスルート[RFC3608]を返すことができ、特定のホップでTLSが必須であるかどうかにいくつかの制約を課すことができます。たとえば、レジストラによって返されるパスヘッダーフィールドの最上位エントリがSIPS URIである場合、レジストラはUACに、リクエスト-URIがSIPであっても、TLSが最初のホップに使用されることを伝えています。
If a UA registered with a SIPS Contact header field, the registrar returning a service route [RFC3608] MUST return a service route consisting of SIP URIs if the intent of the registrar is to allow both SIP and SIPS to be used in requests sent by that client. If a UA registers with a SIPS Contact header field, the registrar returning a service route MUST return a service route consisting of SIPS URIs if the intent of the registrar is to allow only SIPS URIs to be used in requests sent by that UA.
SIPS連絡先ヘッダーフィールドに登録されているUAがサービスルート[RFC3608]を返すレジストラは、レジストラの意図がSIPとSIPの両方を使用することを許可する場合、SIP URIで構成されるサービスルートを返す必要があります。クライアント。SIPSコンタクトヘッダーフィールドでUAが登録する場合、レジストラの意図がSIPS URIのみがそのUAから送信されたリクエストで使用できるようにする場合、サービスルートを返すレジストラはSIPS URIで構成されるサービスルートを返す必要があります。
When a GRUU [RFC5627] is assigned to an instance ID/AOR pair through registration, the registrar MUST assign both a SIP GRUU and a SIPS GRUU. If the Contact header field in the REGISTER request contains a SIP URI, the registrar MUST return the SIP version of the GRUU. If the Contact header field in the REGISTER request contains a SIPS URI, the registrar MUST return the SIPS version of the GRUU.
Gruu [RFC5627]が登録を介してインスタンスID/AORペアに割り当てられる場合、レジストラはSIP GruuとSIPSGruuの両方を割り当てる必要があります。レジスタリクエストの連絡先ヘッダーフィールドにSIP URIが含まれている場合、レジストラはGruuのSIPバージョンを返す必要があります。レジスタリクエストの連絡先ヘッダーフィールドにSIPS URIが含まれている場合、レジストラはGruuのSIPSバージョンを返す必要があります。
Proxies MUST NOT use the last-hop exception of [RFC3261] when forwarding or retargeting a request to the last hop. Specifically, when a proxy receives a request with a SIPS Request-URI, the proxy MUST only forward or retarget the request to a SIPS Request-URI. If the target UAS had registered previously using a SIP Contact header field instead of a SIPS Contact header field, the proxy MUST NOT forward the request to the URI indicated in the Contact header field. If the proxy needs to reject the request for that reason, the proxy MUST reject it with a 480 (Temporarily Unavailable) response. In this case, the proxy SHOULD include a Warning header with warn-code 380 "SIPS Not Allowed".
プロキシは、最後のホップにリクエストを転送またはリターゲティングするときに、[RFC3261]のラストホップ例外を使用してはなりません。具体的には、プロキシがSIPSリクエストURIを使用してリクエストを受信した場合、プロキシはSIPSリクエストURIにリクエストを転送またはリターゲットする必要があります。ターゲットUASがSIPコンタクトヘッダーフィールドの代わりにSIPコンタクトヘッダーフィールドを使用して以前に登録した場合、プロキシは、コンタクトヘッダーフィールドに示されたURIにリクエストを転送してはなりません。プロキシがその理由の要求を拒否する必要がある場合、プロキシは480（一時的に利用できない）応答でそれを拒否する必要があります。この場合、プロキシには、Warn-Code 380 "SIPSが許可されていない"を備えた警告ヘッダーを含める必要があります。
Proxies SHOULD transport requests using a SIP URI over TLS when it is possible to set up a TLS connection, or reuse an existing one. [RFC5626], for example, allows for re-using an existing TLS connection. Some proxies could have policies that prohibit sending any request over anything but TLS.
プロキシは、TLS接続をセットアップするか、既存の接続を再利用できる場合、TLSを介したSIP URIを使用してリクエストを輸送する必要があります。たとえば、[RFC5626]では、既存のTLS接続を再利用できます。一部のプロキシには、TLS以外のリクエストを送信することを禁止するポリシーがあります。
When a proxy receives a request with a SIP Request-URI, the proxy MUST NOT forward the request to a SIPS Request-URI. If the target UAS had registered previously using a SIPS Contact header field, and the proxy decides to forward the request, the proxy MUST replace that SIPS scheme with a SIP scheme while leaving the rest of the URI as is, and use the resulting URI as the Request-URI of the forwarded request. The proxy MUST use TLS to forward the request to the UAS. Some proxies could have a policy of not forwarding at all requests using a non-SIPS Request-URI if the UAS had registered using a SIPS Contact header field. If the proxy elects to reject the request because it has such a policy or because it is not capable of establishing a TLS connection, the proxy MAY reject it with a 480 (Temporarily Unavailable) response with a Warning header with warn-code 381 "SIPS Required".
プロキシがSIPリクエストURIでリクエストを受信した場合、プロキシはリクエストをSIPSリクエストURIに転送してはなりません。ターゲットUASがSIPS連絡先ヘッダーフィールドを使用して以前に登録していた場合、プロキシがリクエストを転送することを決定した場合、プロキシはそのSIPスキームをSIPスキームに置き換えなければなりません。転送されたリクエストのリクエスト-uri。プロキシはTLSを使用して、リクエストをUASに転送する必要があります。一部のプロキシには、SIPS連絡先ヘッダーフィールドを使用してUASが登録されていた場合、非SIPSリクエストURIを使用して、すべての要求で転送しないというポリシーを持つことができます。プロキシがそのようなポリシーを備えているため、またはTLS接続を確立できないためにリクエストを拒否することを選択した場合、プロキシは、警告コード381 "SIPSを使用した警告ヘッダーで480（一時的に利用できない）応答でそれを拒否することができます必要"。
If a proxy needs to reject a request because the URIs are used inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact header field is a SIP URI), the proxy SHOULD use response code 400 (Bad Request).
URIが一貫して使用されていないためにプロキシが要求を拒否する必要がある場合（たとえば、リクエスト-URIはSIPS URIですが、コンタクトヘッダーフィールドはSIP URIです）、プロキシは応答コード400（悪い要求）を使用する必要があります。
It is RECOMMENDED that the proxy use the outbound proxy procedures defined in [RFC5626] for supporting UACs that cannot provide a certificate for establishing a TLS connection (i.e., when server-side authentication is used).
プロキシは、TLS接続を確立するための証明書を提供できないUACをサポートするために[RFC5626]で定義されたアウトバウンドプロキシ手順を使用することをお勧めします（つまり、サーバー側の認証が使用される場合）。
When a proxy sends a request using a SIPS Request-URI and receives a 3XX response with a SIP Contact header field, or a 416 response, or a 480 (Temporarily Unavailable) response with a Warning header with warn-code 380 "SIPS Not Allowed" response, the proxy MUST NOT recurse on the response. In this case, the proxy SHOULD forward the best response instead of recursing, in order to allow for the UAC to take the appropriate action.
プロキシがSIPSリクエストURIを使用してリクエストを送信し、SIPコンタクトヘッダーフィールドを使用した3XX応答、416応答、またはワーーンコード380 "SIPを使用した警告ヘッダーを使用した480（一時的に利用できない）応答を受信した場合「応答、プロキシは応答を再開してはなりません。この場合、UACが適切なアクションを実行できるようにするために、プロキシは再帰の代わりに最良の応答を転送する必要があります。
When a proxy sends a request using a SIP Request-URI and receives a 3XX response with a SIPS Contact header field, or a 480 (Temporarily Unavailable) response with a Warning header with warn-code 381 "SIPS Required", the proxy MUST NOT recurse on the response. In this case, the proxy SHOULD forward the best response instead of recursing, in order to allow for the UAC to take the appropriate action.
プロキシがSIPリクエストURIを使用してリクエストを送信し、SIPの連絡先ヘッダーフィールドを使用して3xx応答を受信した場合、またはWarn-Code 381の「SIPが必要」という警告ヘッダーを使用した480（一時的に利用できない）応答を受け取ると、プロキシはプロキシではありません。応答を再審理します。この場合、UACが適切なアクションを実行できるようにするために、プロキシは再帰の代わりに最良の応答を転送する必要があります。
To emphasize what is already defined in [RFC3261], proxies MUST NOT use the "transport=tls" parameter.
[RFC3261]で既に定義されているものを強調するには、プロキシは「Transport = TLS」パラメーターを使用してはなりません。
Using a redirect server with TLS instead of using a proxy has some limitations that have to be taken into account. Since there is no pre-established connection between the proxy and the UAS (such as with [RFC5626]), it is only appropriate for scenarios where inbound connections are allowed. For example, it could be used in a server-to-server environment (redirect server or proxy server) where TLS mutual authentication is used, and where there are no NAT traversal issues. A redirect server would not be able to redirect to an entity that does not have a certificate. A redirect server might not be usable if there is a NAT between the server and the UAS.
プロキシを使用する代わりにTLSを使用してリダイレクトサーバーを使用するには、考慮する必要があるいくつかの制限があります。プロキシとUAS（[RFC5626]など）の間に事前に確立された接続がないため、インバウンド接続が許可されるシナリオにのみ適切です。たとえば、TLS相互認証が使用されている場合、およびNATトラバーサルの問題がない場合、サーバーからサーバーへの環境（リダイレクトサーバーまたはプロキシサーバー）で使用できます。リダイレクトサーバーは、証明書を持っていないエンティティにリダイレクトすることができません。サーバーとUASの間にNATがある場合、リダイレクトサーバーは使用できない場合があります。
When a redirect server receives a request with a SIP Request-URI, the redirect server MAY redirect with a 3XX response to either a SIP or a SIPS Contact header field. If the target UAS had registered previously using a SIPS Contact header field, the redirect server SHOULD return a SIPS Contact header field if it is in an environment where TLS is usable (as described in the previous paragraph). If the target UAS had registered previously using a SIP Contact header field, the redirect server MUST return a SIP Contact header field in a 3XX response if it redirects the request.
Redirect ServerがSIP Request-URIでリクエストを受信すると、Redirect Serverは、SIPまたはSIPの連絡先ヘッダーフィールドに対する3XX応答でリダイレクトできます。ターゲットUASがSIPS連絡先ヘッダーフィールドを使用して以前に登録していた場合、リダイレクトサーバーは、TLSが使用可能な環境にある場合はSIPS連絡先ヘッダーフィールドを返す必要があります（前の段落で説明されています）。ターゲットUASがSIP連絡先ヘッダーフィールドを使用して以前に登録していた場合、リダイレクトサーバーは、リクエストをリダイレクトする場合、3XX応答でSIP連絡先ヘッダーフィールドを返す必要があります。
When a redirect server receives a request with a SIPS Request-URI, the redirect server MAY redirect with a 3XX response to a SIP or a SIPS Contact header field. If the target UAS had registered previously using a SIPS Contact header field, the redirect server SHOULD return a SIPS Contact header field if it is in an environment where TLS is usable. If the target UAS had registered previously using a SIP Contact header field, the redirect server MUST return a SIP Contact header field in a 3XX response if it chooses to redirect; otherwise, the UAS MAY reject the request with a 480 (Temporarily Unavailable) response with a Warning header with warn-code 380 "SIPS Not Allowed". If a redirect server redirects to a UAS that it has no knowledge of (e.g., an AOR in a different domain), the Contact header field could be of any scheme.
Redirect ServerがSIPS Request-URIでリクエストを受信すると、Redirect Serverは、SIPまたはSIPS連絡先ヘッダーフィールドに対する3XX応答でリダイレクトできます。ターゲットUASがSIPS連絡先ヘッダーフィールドを使用して以前に登録していた場合、リダイレクトサーバーは、TLSが使用可能な環境にある場合はSIPS連絡先ヘッダーフィールドを返す必要があります。ターゲットUASがSIP連絡先ヘッダーフィールドを使用して以前に登録していた場合、リダイレクトサーバーは、リダイレクトを選択した場合、3XX応答でSIP連絡先ヘッダーフィールドを返す必要があります。それ以外の場合、UASは、Warn-Code 380「SIPSが許可されていない」を使用した警告ヘッダーを使用して、480（一時的に利用できない）応答でリクエストを拒否する場合があります。リダイレクトサーバーがUASにリダイレクトしている場合（例えば、別のドメイン内のAOR）、コンタクトヘッダーフィールドは任意のスキームの可能性があります。
If a redirect server needs to reject a request because the URIs are used inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact header field is a SIP URI), the redirect server SHOULD use response code 400 (Bad Request).
URIが一貫して使用されていないためにリダイレクトサーバーが要求を拒否する必要がある場合（たとえば、リクエスト-URIはSIPS URIですが、連絡先ヘッダーフィールドはSIP URIです）、リダイレクトサーバーは応答コード400を使用する必要があります（悪い要求）。
To emphasize what is already defined in [RFC3261], redirect servers MUST NOT use the "transport=tls" parameter.
[RFC3261]で既に定義されているものを強調するために、リダイレクトサーバーは「Transport = TLS」パラメーターを使用してはなりません。
The following diagram illustrates the topology used for the examples in this section:
次の図は、このセクションの例に使用されるトポロジーを示しています。
example.com . example.net
.
|-------------| . |------------|
| Registrar/ |__________| Proxy A |
| Auth. Proxy | . | (proxya) |
| (pb) | . |------------|
|-------------| . |
| . |
| . |
|-----------| . |
| Edge | . |
| Proxy B | . |
| (eb) | . |
|-----------| . |
/ | . |
/ | . |
/ | . |
______ | . |
| | _____ . _____
|______| O / \ O . O / \ O
/_______/ /___\ . /___\
.
bob@bobpc bob@bobphone . alice
Topology
トポロジー
In the following examples, Bob has two clients; one is a SIP PC client running on his computer, and the other one is a SIP phone. The PC client does not support SIPS, and consequently only registers with a SIP Contact header field. The SIP phone however does support SIPS and TLS, and consequently registers with a SIPS Contact header field. Both of Bob's devices are going through Edge Proxy B, and consequently, they include a Route header field indicating eb.example.com. Edge Proxy B removes the Route header field corresponding to itself, and adds itself in a Path header field. The registration process call flow is illustrated in Section 6.1.
次の例では、ボブには2つのクライアントがいます。1つはコンピューターで実行されているSIP PCクライアント、もう1つはSIP電話です。PCクライアントはSIPSをサポートせず、その結果、SIPコンタクトヘッダーフィールドのみを登録します。ただし、SIP電話はSIPとTLSをサポートしているため、SIPSコンタクトヘッダーフィールドで登録します。Bobの両方のデバイスはEdge Proxy Bを通過しているため、Eb.example.comを示すルートヘッダーフィールドが含まれています。Edge Proxy Bは、それ自体に対応するルートヘッダーフィールドを削除し、パスヘッダーフィールドに追加します。登録プロセスコールフローは、セクション6.1に示されています。
After registration, there are two Contact bindings associated with Bob's AOR of bob@example.com: sips:bob@bobphone.example.com and sip:bob@bobpc.example.com.
登録後、ボブのbob@example.comのaorに関連付けられた2つの連絡先バインディングがあります：sips：bob@bobphone.example.comおよびsip：bob@bobpc.example.com。
Alice then calls Bob through her own Proxy A. Proxy A locates Bob's domain example.com. In this example, that domain is owned by Bob's Registrar/Authoritative Proxy B. Proxy A removes the Route header field corresponding to itself, and inserts itself in the Record-Route and forwards the request to Registrar/Authoritative Proxy B.
その後、アリスは自分のプロキシAを通してボブに電話します。プロキシAはボブのドメインExample.comを見つけます。この例では、そのドメインはボブのレジストラ/権威あるプロキシBによって所有されています。プロキシAは、それ自体に対応するルートヘッダーフィールドを削除し、レコードルートにそれ自体を挿入し、リクエストをレジストラ/権威あるプロキシBに転送します。
The following subsections illustrate registration and three examples. In the first example (Section 6.2), Alice calls Bob's SIPS AOR. In the second example (Section 6.3), Alice calls Bob's SIP AOR using TCP transport. In the third example (Section 6.4), Alice calls Bob's SIP AOR using TLS transport.
次のサブセクションは、登録と3つの例を示しています。最初の例（セクション6.2）では、アリスはボブのSIPS AORを呼び出します。2番目の例（セクション6.3）では、アリスはTCPトランスポートを使用してボブのSIP AORを呼び出します。3番目の例（セクション6.4）では、アリスはTLSトランスポートを使用してボブのSIP AORを呼び出します。
This flow illustrates the registration process by which Bob's device registers. His PC client (Bob@bobpc) registers with a SIP scheme, and his SIP phone (Bob@phone) registers with a SIPS scheme.
このフローは、ボブのデバイスが登録される登録プロセスを示しています。彼のPCクライアント（BOB@BOBPC）は、SIPスキームで登録し、彼のSIP電話（Bob@Phone）がSIPスキームで登録します。
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B
| | |
| REGISTER F1 | |
|------------------>| REGISTER F2 |
| |-------------->|
| | 200 F3 |
| 200 F4 |<--------------|
|<------------------| |
| | |
| Bob@bobphone | |
| | | |
| |REGISTER F5 | |
| |----------->| REGISTER F6 |
| | |-------------->|
| | | 200 F7 |
| | 200 F8 |<--------------|
| |<-----------| |
| | | |
Bob Registers His Contacts
ボブは彼の連絡先を登録します
Message details
メッセージの詳細
F1 REGISTER Bob's PC Client -> Edge Proxy B
F1レジスタボブのPCクライアント - >エッジプロキシB
REGISTER sip:pb.example.com SIP/2.0
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path, outbound
Route: <sip:eb.example.com;lr>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Content-Length: 0
F2 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
REGISTER sip:pb.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobpc.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
Content-Length: 0
F3 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
F3 200（登録）レジストラ/権威あるプロキシB - >エッジプロキシB
SIP/2.0 200 OK
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Require: outbound
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
Date: Mon, 12 Jun 2006 16:43:12 GMT
Content-Length: 0
F4 200 (REGISTER) Edge Proxy B -> Bob's PC Client
SIP/2.0 200 OK
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds
To: Bob <sip:bob@example.com>;tag=2493K59K9
From: Bob <sip:bob@example.com>;tag=456248
Call-ID: 843817637684230@998sdasdh09
CSeq: 1826 REGISTER
Require: outbound
Supported: path, outbound
Path: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Contact: <sip:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:12 GMT
Content-Length: 0
F5 REGISTER Bob's Phone -> Edge Proxy B
F5ボブの電話を登録 - >エッジプロキシB
REGISTER sips:pb.example.com SIP/2.0
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path, outbound
Route: <sips:eb.example.com;lr>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Content-Length: 0
F6 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B
REGISTER sips:pb.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
Content-Length: 0
F7 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
F7 200（登録）レジストラ/権威あるプロキシB - >エッジプロキシB
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Require: outbound
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:50 GMT
Content-Length: 0
F8 200 (REGISTER) Edge Proxy B -> Bob's Phone
SIP/2.0 200 OK
Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555
To: Bob <sips:bob@example.com>;tag=5150
From: Bob <sips:bob@example.com>;tag=90210
Call-ID: faif9a@qwefnwdclk
CSeq: 12 REGISTER
Require: outbound
Supported: path, outbound
Path: <sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Contact: <sips:bob@bobphone.example.com>
;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>"
;reg-id=1
;expires=3600
Date: Thu, 09 Aug 2007 16:43:50 GMT
Content-Length: 0
Bob's registration has already occurred as per Section 6.1.
ボブの登録は、セクション6.1に従ってすでに発生しています。
In this first example, Alice calls Bob's SIPS AOR (sips:bob@example.com). Registrar/Authoritative Proxy B consults the binding in the registration database, and finds the two Contact header field bindings. Alice had addressed Bob with a SIPS Request-URI (sips:bob@example.com), so Registrar/Authoritative Proxy B determines that the call needs to be routed only to bobphone (which registered using a SIPS Contact header field), and therefore the request is only sent to sips:bob@bobphone.example.com, through Edge Proxy B. Both Registrar/Authoritative Proxy B and Edge Proxy B insert themselves in the Record-Route. Bob answers at sips:bob@bobphone.example.com.
この最初の例では、アリスはボブのSIPS AORを呼び出します（sips：bob@example.com）。レジストラ/権威あるプロキシBは、登録データベースのバインディングに相談し、2つのコンタクトヘッダーフィールドバインディングを見つけます。アリスはBOBにSIPS request-uri（sips：bob@example.com）で扱っていたため、レジストラ/権威あるプロキシBは、コールをボブフォン（SIPS連絡先ヘッダーフィールドを使用して登録）にのみルーティングする必要があると判断したため、リクエストはSIPSにのみ送信されます：bob@bobphone.example.com、Edge Proxy Bを介して、レジストラ/権威あるプロキシBとエッジプロキシBの両方がレコードルートに挿入されます。BobはSIPSで答えます：bob@bobphone.example.com。
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice
| | | | |
| | | | INVITE F9 |
| Bob@bobphone | | INVITE F11 |<-----------|
| | | INVITE F13 |<-----------| 100 F10 |
| | INVITE F15 |<-----------| 100 F12 |----------->|
| |<-----------| 100 F14 |----------->| |
| | 180 F16 |----------->| | |
| |----------->| 180 F17 | | |
| | 200 F20 |----------->| 180 F18 | |
| |----------->| 200 F21 |----------->| 180 F19 |
| | |----------->| 200 F22 |----------->|
| | | |----------->| 200 F23 |
| | | | |----------->|
| | | | | ACK F24 |
| | | | ACK F25 |<-----------|
| | | ACK F26 |<-----------| |
| | ACK F27 |<-----------| | |
| |<-----------| | | |
| | | | | |
Alice Calls Bob's SIPS AOR
アリスはボブのSIPS AORを呼び出します
Message details
メッセージの詳細
F9 INVITE Alice -> Proxy A
f9アリスを招待 - >プロキシa
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F10 100 (INVITE) Proxy A -> Alice
SIP/2.0 100 Trying
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
F11招待プロキシA->レジストラ/権威あるプロキシB
INVITE sips:bob@example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F12 100（招待）レジストラ/権威あるプロキシB->プロキシA
SIP/2.0 100 Trying
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
Record-Route: <sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F14 100（招待）エッジプロキシB - >レジストラ/権威あるプロキシB
SIP/2.0 100 Trying
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F15 INVITE Edge Proxy B -> Bob's phone
INVITE sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
Max-Forwards: 67
To: Bob <sips:bob@example.com>
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F16 180 (INVITE) Bob's Phone -> Edge Proxy B
F16 180（招待）ボブの電話 - >エッジプロキシB
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F18 180 Registrar/Authoritative Proxy B -> Proxy A
F18 180レジストラ/権威あるプロキシB->プロキシA
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F19 180 (INVITE) Proxy A -> Alice
F19 180（招待）プロキシA->アリス
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F20 200 (INVITE) Bob's Phone -> Edge Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F21 200（招待）エッジプロキシB - >レジストラ/権威あるプロキシB
SIP/2.0 200 OK
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F22 200 Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 200 OK
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F23 200 (INVITE) Proxy A -> Alice
F23 200（招待）プロキシA->アリス
SIP/2.0 200 OK
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr>
Contact: <sips:bob@bobphone.example.com>
Content-Length: 0
F24 ACK Alice -> Proxy A
F24 ACK Alice-> Proxy a
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 70
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:proxya.example.net;lr>, <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0
F25 ACK Proxy A -> Registrar/Authoritative Proxy B
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 69
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0
F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
F26 ACKレジストラ/権威あるプロキシB->エッジプロキシB
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 69
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sips:pb.example.com;lr>,
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com;lr;ob>
Content-Length: 0
F27 ACK Proxy B -> Bob's Phone
F27 ACKプロキシB - >ボブの電話
ACK sips:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKkmfdgk
Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2
Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf
Max-Forwards: 68
To: Bob <sips:bob@example.com>;tag=5551212
From: Alice <sips:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 0
Bob's registration has already occurred as per Section 6.1.
ボブの登録は、セクション6.1に従ってすでに発生しています。
In the second example, Alice calls Bob's SIP AOR instead (sip:bob@example.com), and she uses TCP as a transport. Registrar/ Authoritative Proxy B consults the binding in the registration database, and finds the two Contact header field bindings. Alice had addressed Bob with a SIP Request-URI (sip:bob@example.com), so Registrar/Authoritative Proxy B determines that the call needs to be routed both to bobpc (which registered with a SIP Contact header field) and bobphone (which registered with a SIPS Contact header field), and therefore the request is forked to sip:bob@bobpc.example.com and sip:bob@bobphone.example.com, through Edge Proxy B. Note that Registrar/Authoritative Proxy B preserved the SIP scheme of the Request-URI instead of replacing it with the SIPS scheme of the Contact header field that was used for registration. Both Registrar/Authoritative Proxy B and Edge Proxy B insert themselves in the Record-Route. Bob's phone's policy is to accept calls to SIP and SIPS (i.e., "best effort"), so both his PC client and his SIP phone ring simultaneously. Bob answers on his SIP phone, and the forked call leg to the PC client is canceled.
2番目の例では、アリスは代わりにボブのsip aor（sip：bob@example.com）を呼び出し、TCPをトランスポートとして使用しています。レジストラ/権威あるプロキシBは、登録データベースのバインディングに相談し、2つのコンタクトヘッダーフィールドバインディングを見つけます。アリスはBOBにSIP Request-URI（sip：bob@example.com）で演説していたため、レジストラ/権威あるプロキシBは、コールをBOBPC（SIPコンタクトヘッダーフィールドに登録）とボブフォン（SIPS連絡先ヘッダーフィールドに登録されているため、リクエストはsip：bob@bobpc.example.comおよびsip：bob@bobphone.example.com、Edge Proxy Bを使用します。登録に使用されたコンタクトヘッダーフィールドのSIPSスキームに置き換える代わりに、リクエスト-URIのSIPスキーム。レジストラ/権威あるプロキシBとエッジプロキシBの両方が、レコードルートに自分自身を挿入します。ボブの電話のポリシーは、SIPとSIP（つまり、「最善の努力」）への電話を受け入れることです。そのため、彼のPCクライアントとSIP電話の両方が同時にリングします。ボブは彼のSIP電話で答え、PCクライアントへのフォークされたコールレッグがキャンセルされます。
(eb) (pb)
Edge Registrar/
Bob@bobpc Proxy B Auth. Proxy B Proxy A Alice
| | | | |
| | | | INVITE F9 |
| | | INVITE F11 |<-----------|
| | INVITE F13'|<-----------| 100 F10 |
| INVITE F15' |<-----------| 100 F12 |----------->|
|<------------------| 100 F14' |----------->| |
| 180 F16' |----------->| | |
|------------------>| 180 F17' | | |
| |----------->| 180 F18' | |
| Bob@bobphone | |----------->| 180 F19' |
| | | INVITE F13 | |----------->|
| | INVITE F15 |<-----------| | |
| |<-----------| 100 F14 | | |
| | 180 F16 |----------->| | |
| |----------->| 180 F17 | | |
| | 200 F20 |----------->| 180 F18 | |
| |----------->| 200 F21 |----------->| 180 F19 |
| | |----------->| 200 F22 |----------->|
| | | |----------->| 200 F23 |
| | | | |----------->|
| | | | | ACK F24 |
| | | | ACK F25 |<-----------|
| | | ACK F26 |<-----------| |
| | ACK F27 |<-----------| | |
| |<-----------| | | |
| | CANCEL F26'| | |
| CANCEL F27' |<-----------| | |
|<------------------| | | |
| 200 F28' | | | |
|------------------>| 200 F29' | | |
| 487 F30' |----------->| | |
|------------------>| 487 F31' | | |
| |----------->| | |
Alice Calls Bob's SIP AOR
アリスはボブのsip aorを呼び出します
Message details
メッセージの詳細
F9 INVITE Alice -> Proxy A
f9アリスを招待 - >プロキシa
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F10 100 (INVITE) Proxy A -> Alice
F10100（招待）プロキシA->アリス
SIP/2.0 100 Trying
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
F11招待プロキシA->レジストラ/権威あるプロキシB
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route: <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
SIP/2.0 100 Trying
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F13' INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
f13 'レジストラ/権威あるプロキシb->エッジプロキシBを招待する
INVITE sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14' 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F14 '100（招待）エッジプロキシB - >レジストラ/権威あるプロキシB
SIP/2.0 100 Trying
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F15' INVITE Edge Proxy B -> Bob's PC Client
INVITE sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 67
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F16' 180 (INVITE) Bob's PC Client -> Edge Proxy B
F16 '180（招待）ボブのPCクライアント - >エッジプロキシB
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F18' 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F18 '180（招待）レジストラ/権威あるプロキシB->プロキシA
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F19' 180 (INVITE) Proxy A -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=963258
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobpc.example.com>
Content-Length: 0
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
F13招待レジストラ/権威あるプロキシB->エッジプロキシB
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F14 100（招待）エッジプロキシB - >レジストラ/権威あるプロキシB
SIP/2.0 100 Trying
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F15 INVITE Edge Proxy B -> Bob's Phone
INVITE sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:alice@alice-1.example.net>
Content-Type: application/sdp
Content-Length: {as per SDP}
{SDP not shown}
F16 180 (INVITE) Bob's Phone -> Edge Proxy B
F16 180（招待）ボブの電話 - >エッジプロキシB
SIP/2.0 180 Ringing
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F18 180（招待）レジストラ/権威あるプロキシB->プロキシA
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F19 180 (INVITE) Proxy A -> Alice
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F20 200 (INVITE) Bob's Phone -> Edge Proxy B
F20 200（招待）ボブの電話 - >エッジプロキシB
SIP/2.0 200 OK
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
SIP/2.0 200 OK
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F22 200（招待）レジストラ/権威あるプロキシB->プロキシA
SIP/2.0 200 OK
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F23 200 (INVITE) Proxy A -> Alice
SIP/2.0 200 OK
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Record-Route:
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>,
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr>
Contact: <sip:bob@bobphone.example.com>
Content-Length: 0
F24 ACK Alice -> Proxy A
F24 ACK Alice-> Proxy a
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:proxya.example.net;lr>, <sip:pb.example.com;lr>,
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com;lr;ob>
Content-Length: 0
F25 ACK Proxy A -> Registrar/Authoritative Proxy B
F25 ACKプロキシA->レジストラ/権威あるプロキシB
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:pb.example.com;lr>,
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0
F26 ACK Registrar/Authoritative Proxy B -> Edge Proxy B
F26 ACKレジストラ/権威あるプロキシB->エッジプロキシB
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 69
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0
F27 ACK Proxy B -> Bob's Phone
F27 ACKプロキシB - >ボブの電話
ACK sip:bob@bobphone.example.com SIP/2.0
Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.1
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
Max-Forwards: 68
To: Bob <sip:bob@example.com>;tag=5551212
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 ACK
Content-Length: 0
F26' CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B
F26 'レジストラ/権威あるプロキシB->エッジプロキシBをキャンセルする
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Route: <sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;lr;ob>
Content-Length: 0
F27' CANCEL Edge Proxy B -> Bob's PC Client
CANCEL sip:bob@bobpc.example.com SIP/2.0
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Max-Forwards: 69
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0
F28' 200 (CANCEL) Bob's PC Client -> Edge Proxy B
F28 '200（キャンセル）ボブのPCクライアント - >エッジプロキシB
SIP/2.0 200 OK
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0
F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B
F29 '200（キャンセル）エッジプロキシB - >レジストラ/権威あるプロキシB
SIP/2.0 200 OK
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 CANCEL
Content-Length: 0
F30' 487 (INVITE) Bob's PC Client -> Edge Proxy B
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
F31' 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F31 '487（招待）エッジプロキシB - >レジストラ/権威あるプロキシB
SIP/2.0 487 Request Terminated
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2
Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.net>;tag=8675309
Call-ID: lzksjf8723k@sodk6587
CSeq: 1 INVITE
Content-Length: 0
Bob's registration has already occurred as per Section 6.1.
ボブの登録は、セクション6.1に従ってすでに発生しています。
The third example is identical to the second one, except that Alice uses TLS as the transport for her connection to her proxy. Such an arrangement would be common if Alice's UA supported TLS and wanted to use a single connection to the proxy (as would be the case when using [RFC5626]). In the example below, Proxy A is also using TLS as a transport to communicate with Outbound Proxy B, but it is not necessarily the case.
3番目の例は、アリスが彼女のプロキシへの接続のトランスポートとしてTLSを使用していることを除いて、2番目の例と同じです。AliceのUAがTLSをサポートし、プロキシへの単一の接続を使用したい場合（[RFC5626]を使用する場合のように）、このような配置は一般的です。以下の例では、プロキシAはTLSをトランスポートとして使用してアウトバウンドプロキシBと通信していますが、必ずしもそうではありません。
When using a SIP URI in the Request-URI but TLS as a transport for sending the request, the Via field indicates TLS. The Route header field (if present) typically would use a SIP URI (but it could also be a SIPS URI). The Contact header fields and To and From, however would also normally indicate a SIP URI.
リクエスト-URIでSIP URIを使用するが、リクエストを送信するためのトランスポートとしてTLSを使用する場合、VIAフィールドはTLSを示します。ルートヘッダーフィールド（存在する場合）は、通常、SIP URIを使用します（ただし、SIPS URIも可能です）。ただし、コンタクトヘッダーフィールドと出入りは、通常、SIP URIを示します。
The call flow would be exactly as per the second example (Section 6.3). The only difference would be that all the Via header fields would use TLS Via parameters. The URIs would remain SIP URIs and not SIPS URIs.
コールフローは、2番目の例（セクション6.3）に従ってまさにそのままです。唯一の違いは、すべてのVIAヘッダーフィールドがパラメーターを介してTLSを使用することです。ウリスはurisを一杯のままであり、urisを一杯にしません。
SIP [RFC3261] itself introduces some complications with using SIPS, for example, when Record-Route is not used. When a SIPS URI is used in a Contact header field in a dialog-initiating request and Record-Route is not used, that SIPS URI might not be usable by the other end. If the other end does not support SIPS and/or TLS, it will not be able to use it. The last-hop exception is an example of when this can occur. In this case, using Record-Route so that the requests are sent through proxies can help in making it work. Another example is that even in a case where the Contact header field is a SIPS URI, no Record-Route is used, and the far end supports SIPS and TLS, it might still not be possible for the far end to establish a TLS connection with the SIP originating end if the certificate cannot be validated by the far end. This could typically be the case if the originating end was using server-side authentication as described below, or if the originating end is not using a certificate that can be validated.
SIP [RFC3261]自体は、たとえばレコードルートを使用していない場合、SIPを使用することでいくつかの合併症を導入します。SIPS URIがダイアログ開始リクエストでコンタクトヘッダーフィールドで使用され、レコードルートが使用されない場合、SIPS URIは反対側で使用できない場合があります。もう一方の端がSIPやTLSをサポートしていない場合、使用できません。ラストホップの例外は、これがいつ発生するかの例です。この場合、リクエストがプロキシを通じて送信されるようにレコードルートを使用して、それを機能させるのに役立ちます。別の例は、コンタクトヘッダーフィールドがSIPS URIであり、レコードルートが使用されない場合でも、ファーエンドがSIPSとTLSをサポートしている場合でも、ファーエンドがTLS接続を確立することはまだ不可能である可能性があることです。証明書を遠端までに検証できない場合、SIP発信端。これは通常、以下に説明するように、発信端がサーバー側の認証を使用していた場合、または発信元の端が検証できる証明書を使用していない場合に当てはまります。
TLS itself has a significant impact on how SIPS can be used. Server-side authentication (where the server side provides its certificate but the client side does not) is typically used between a SIP end-user device acting as the TLS client side (e.g., a phone or a personal computer) and its SIP server (proxy or registrar) acting as the TLS server side. TLS mutual authentication (where both the client side and the server side provide their respective certificates) is typically used between SIP servers (proxies, registrars), or statically configured devices such as PSTN gateways or media servers. In the mutual authentication model, for two entities to be able to establish a TLS connection, it is required that both sides be able to validate each other's certificates, either by static configuration or by being able to recurse to a valid root certificate. With server-side authentication, only the client side is capable of validating the server side's certificate, as the client side does not provide a certificate. The consequences of all this are that whenever a SIPS URI is used to establish a TLS connection, it is expected to be possible for the entity establishing the connection (the client) to validate the certificate from the server side. For server-side authentication, [RFC5626] is the recommended approach. For mutual authentication, one needs to ensure that the architecture of the network is such that connections are made between entities that have access to each other's certificates. Record-Route [RFC3261] and Path [RFC3327] are very useful in ensuring that previously established TLS connections can be reused. Other mechanisms might also be used in certain circumstances: for example, using root certificates that are widely recognized allows for more easily created TLS connections.
TLS自体は、SIPSの使用方法に大きな影響を与えます。サーバー側の認証（サーバー側が証明書を提供するが、クライアント側が提供しない場合）は、通常、TLSクライアント側（電話またはパーソナルコンピューターなど）とそのSIPサーバーとして機能するSIPエンドユーザーデバイス間で使用されます。プロキシまたはレジストラ）TLSサーバー側として機能します。TLS相互認証（クライアント側とサーバー側の両方がそれぞれの証明書を提供する場合）は、通常、SIPサーバー（プロキシ、レジストラ）、またはPSTNゲートウェイやメディアサーバーなどの静的に構成されたデバイス間で使用されます。相互認証モデルでは、2つのエンティティがTLS接続を確立できるようにするために、静的構成または有効なルート証明書に再開することにより、双方が互いの証明書を検証できることが必要です。サーバー側の認証を使用すると、クライアント側が証明書を提供していないため、クライアント側のみがサーバー側の証明書を検証することができます。このすべての結果は、SIPS URIがTLS接続を確立するために使用されるときはいつでも、エンティティが接続（クライアント）を確立することがサーバー側から証明書を検証することができると予想されることです。サーバー側の認証の場合、[RFC5626]が推奨されるアプローチです。相互認証のために、ネットワークのアーキテクチャが、互いの証明書にアクセスできるエンティティ間で接続が行われるようにする必要があります。Record-route [RFC3261]およびPATH [RFC3327]は、以前に確立されたTLS接続を再利用できるようにするのに非常に役立ちます。他のメカニズムは、特定の状況でも使用される場合があります。たとえば、広く認識されているルート証明書を使用すると、より簡単に作成されたTLS接続が可能になります。
Most of this document can be considered to be security considerations since it applies to the usage of the SIPS URI.
このドキュメントのほとんどは、SIPS URIの使用に適用されるため、セキュリティ上の考慮事項と見なすことができます。
The "last-hop exception" of [RFC3261] introduced significant potential vulnerabilities in SIP, and it has therefore been deprecated by this specification.
[RFC3261]の「ラストホップ例外」は、SIPに重大な潜在的な脆弱性をもたらしたため、この仕様によって非推奨されています。
Section 26.4.4 of [RFC3261] describes the security considerations for the SIPS URI scheme. These security considerations also applies here, as modified by Appendix A.
[RFC3261]のセクション26.4.4では、SIPS URIスキームのセキュリティ上の考慮事項について説明します。これらのセキュリティ上の考慮事項は、付録Aで変更されたように、ここにも適用されます。
This specification registers two new warning codes, namely, 380 "SIPS Not Allowed" and 381 "SIPS Required". The warning codes are defined as follows, and have been included in the Warning Codes (warn-codes) sub-registry of the SIP Parameters registry available from http://www.iana.org.
この仕様は、2つの新しい警告コード、つまり380 "SIPが許可されていない」と381個の「SIPが必要」を登録します。警告コードは次のように定義されており、http://www.iana.orgから入手可能なSIPパラメーターレジストリの警告コード（WARN-CODES）サブレジストリに含まれています。
380 SIPS Not Allowed: The UAS or proxy cannot process the request because the SIPS scheme is not allowed (e.g., because there are currently no registered SIPS contacts).
380 SIPSが許可されていない：SIPSスキームが許可されていないため、UASまたはプロキシはリクエストを処理できません（たとえば、現在登録されているSIPS連絡先がないため）。
381 SIPS Required: The UAS or proxy cannot process the request because the SIPS scheme is required.
381 SIPSが必要：SIPSスキームが必要なため、UASまたはプロキシはリクエストを処理できません。
Reference: RFC 5630
参照：RFC 5630
The note in the Warning Codes sub-registry is as follows:
警告コードのサブレジストリのメモは次のとおりです。
Warning codes provide information supplemental to the status code in SIP response messages.
警告コードは、SIP応答メッセージのステータスコードを補足する情報を提供します。
The author would like to thank Jon Peterson, Cullen Jennings, Jonathan Rosenberg, John Elwell, Paul Kyzivat, Eric Rescorla, Robert Sparks, Rifaat Shekh-Yusef, Peter Reissner, Tina Tsou, Keith Drage, Brian Stucker, Patrick Ma, Lavis Zhou, Joel Halpern, Hisham Karthabil, Dean Willis, Eric Tremblay, Hans Persson, and Ben Campbell for their careful review and input. Many thanks to Rohan Mahy for helping me with the subtleties of [RFC5626].
著者は、ジョン・ピーターソン、カレン・ジェニングス、ジョナサン・ローゼンバーグ、ジョン・エルウェル、ポール・キジバット、エリック・レスカルラ、ロバート・スパークス、リファ・シェク・ユセフ、ピーター・レイスナー、ティナ・ツァウ、キース・ドレイジ、ブライアン・スタッカー、パトリック・マ、ラヴィス・Zhou、ジョエル・ハルパーン、ヒシャム・カーサビル、ディーン・ウィリス、エリック・トレムブレイ、ハンス・パーソン、ベン・キャンベルの慎重なレビューとインプット。[RFC5626]の微妙さを手伝ってくれたRohan Mahyに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5626] Jennings, C., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626] Jennings、C。、「セッション開始プロトコル（SIP）でのクライアント開始接続の管理」、RFC 5626、2009年10月。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[RFC2543] Handley、M.、Schulzrinne、H.、Schooler、E.、およびJ. Rosenberg、「SIP：SESSION INITIATION Protocol」、RFC 2543、1999年3月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327] Willis、D。およびB. Hoeneisen、「Addjacentコンタクトを登録するためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3327、2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照法」、RFC 3515、2003年4月。
[RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003.
[RFC3608] Willis、D。およびB. Hoeneisen、「登録中のサービスルート発見のためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3608、2003年10月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H.、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891] Mahy、R.、Biggs、B。、およびR. Dean、「セッション開始プロトコル（SIP）」は「ヘッダー」、RFC 3891、2004年9月に置き換えられます。
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[RFC3893] Peterson、J。、「セッション開始プロトコル（SIP）認証識別機関（AIB）形式」、RFC 3893、2004年9月。
[RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004.
[RFC3911] Mahy、R。およびD. Petrie、「セッション開始プロトコル（SIP）「Header」に参加、RFC 3911、2004年10月。
[RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)", RFC 4168, October 2005.
[RFC4168] Rosenberg、J.、Schulzrinne、H。、およびG. Camarillo、「Stream Control Transmission Protocol（SCTP）セッション開始プロトコル（SIP）の輸送として」、RFC 4168、2005年10月。
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244] Barnes、M。、「リクエスト履歴情報のセッション開始プロトコル（SIP）の拡張」、RFC 4244、2005年11月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUU) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627] Rosenberg、J。、「セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザーエージェントURIS（GRUU）の取得と使用」、RFC 5627、2009年10月。
In order to support the material in this document, this section makes corrections to RFC 3261.
このドキュメントの資料をサポートするために、このセクションはRFC 3261の修正を行います。
The last sentence of the fifth paragraph of Section 8.1.3.5 is replaced by:
セクション8.1.3.5の5番目の段落の最後の文は次のように置き換えられます。
The client SHOULD retry the request, this time, using a SIP URI unless the original Request-URI used a SIPS scheme, in which case the client MUST NOT retry the request automatically.
クライアントは、元のリクエストURIがSIPSスキームを使用しない限り、SIP URIを使用してリクエストを再試行する必要があります。その場合、クライアントはリクエストを自動的に再試行してはなりません。
The fifth paragraph of Section 10.2.1 is replaced by:
セクション10.2.1の5番目の段落は、次のものに置き換えられます。
If the Address of Record in the To header field of a REGISTER request is a SIPS URI, then the UAC MUST also include only SIPS URIs in any Contact header field value in the requests.
レジスタリクエストのヘッダーフィールドの記録のアドレスがSIPS URIである場合、UACには、リクエストに任意の連絡先ヘッダーフィールド値にSIPS URIのみを含める必要があります。
In Section 16.7 on p. 112 describing Record-Route, the second paragraph is deleted.
pのセクション16.7で112レコードルートを説明すると、2番目の段落が削除されます。
The last paragraph of Section 19.1 is reworded as follows:
セクション19.1の最後の段落は、次のように言い換えられます。
A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used on each hop between the UAC and the resource identified by the target SIPS URI. Any resources described by a SIP URI (...)
SIPS URIは、リソースに安全に接触することを指定します。これは、特に、TLSがUACとターゲットSIPS URIによって識別されるリソースの間の各ホップで使用されることを意味します。sip uri（...）によって説明されているリソース
In the third paragraph of Section 20.43, the words "the session description" in the first sentence are replaced with "SIP". Later in the paragraph, "390" is replaced with "380", and "miscellaneous warnings" is replaced with "miscellaneous SIP-related warnings".
セクション20.43の3番目の段落では、最初の文の「セッションの説明」という言葉が「SIP」に置き換えられます。段落の後半では、「390」は「380」に置き換えられ、「その他の警告」は「その他のSIP関連警告」に置き換えられます。
The second paragraph of Section 26.2.2 is reworded as follows:
セクション26.2.2の2番目の段落は、次のように言い換えられます。
(...) When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the resource identified by the Request-URI, is secured with TLS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address-of-record of the target), SIPS dictates that the entire request path to the target domain be so secured.
（...）リクエストのリクエスト-URIとして使用される場合、SIPSスキームは、要求がリクエスト-URIによって識別されるリソースに到達するまで、リクエストが転送される各ホップがTLSで保護されることを意味します。リクエストのオリジネーターが使用する場合（ターゲットの録音アドレスとしてSIPS URIを使用した場合の場合と同様）、SIPSは、ターゲットドメインへの要求パス全体が非常に確保されることを決定します。
The first paragraph of Section 26.4.4 is replaced by the following:
セクション26.4.4の最初の段落は、以下に置き換えられます。
Actually using TLS on every segment of a request path entails that the terminating UAS is reachable over TLS (by registering with a SIPS URI as a contact address). The SIPS scheme implies transitive trust. Obviously, there is nothing that prevents proxies from cheating. Thus, SIPS cannot guarantee that TLS usage will be truly respected end-to-end on each segment of a request path. Note that since many UAs will not accept incoming TLS connections, even those UAs that do support TLS will be required to maintain persistent TLS connections as described in the TLS limitations section above in order to receive requests over TLS as a UAS.
実際にリクエストパスのすべてのセグメントでTLSを使用するには、終了UASがTLSを介して到達可能であることが必要です（連絡先アドレスとしてSIPS URIに登録することにより）。SIPSスキームは、推移的な信頼を意味します。明らかに、プロキシが不正行為を妨げるものは何もありません。したがって、SIPSは、TLSの使用が要求パスの各セグメントで真にエンドツーエンドで尊重されることを保証することはできません。多くのUASは着信TLS接続を受け入れないため、TLSをサポートするUASでさえ、UASとしてTLSを介したリクエストを受信するために、上記のTLS制限セクションで説明されているように、永続的なTLS接続を維持する必要があります。
The first sentence of the third paragraph of Section 26.4.4 is replaced by the following:
セクション26.4.4の3番目の段落の最初の文は、以下に置き換えられます。
Ensuring that TLS will be used for all of the request segments up to the target UAS is somewhat complex.
TLSがターゲットUASまでのすべての要求セグメントに使用されることを保証することは、やや複雑です。
The fourth paragraph of Section 26.4.4 is deleted.
セクション26.4.4の4番目の段落が削除されます。
The last sentence of the fifth paragraph of Section 26.4.4 is reworded as follows:
セクション26.4.4の第5段落の最後の文は、次のように言い換えられます。
S/MIME or, preferably, [RFC4474] may also be used by the originating UAC to help ensure that the original form of the To header field is carried end-to-end.
S/MIMEまたは、できれば[RFC4474]は、元のヘッダーフィールドの元の形式がエンドツーエンドで運ばれるようにするために、起源のUACによっても使用できます。
In the third paragraph of Section 27.2, the phrase "when the failure of the transaction results from a Session Description Protocol (SDP) (RFC 2327 [1]) problem" is deleted.
セクション27.2の3番目の段落では、「トランザクションの障害がセッション説明プロトコル（SDP）（RFC 2327 [1]）問題から生じるとき」というフレーズが削除されます。
In the fifth paragraph of Section 27.2, "390" is replaced with "380", and "miscellaneous warnings" is replaced with "miscellaneous SIP-related warnings".
セクション27.2の5番目の段落では、「390」が「380」に置き換えられ、「その他の警告」は「その他のSIP関連警告」に置き換えられます。
Author's Address
著者の連絡先
Francois Audet Skype Labs
Francois Audet Skype Labs
EMail: francois.audet@skypelabs.com