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）におけるSIPS URIスキームの使用
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................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スキームのとTransport Layer Security（TLS）[RFC5246]の使用量はSIP [RFC3261]でunderspecifiedされており、実装のための混乱の原因となっています。
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スキームの使用に関するガイドラインを提供します。それはまた、（[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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がプロキシを認証するために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サーバーの役割を引き受けます。 UACとUASはそれが送信または要求を受信しているかに応じて、SIPに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.
第二の重要な制限は、相互認証証明書を交換するために両側を必要とすることです。これは、ユーザーの幅広い人口のための証明書インフラストラクチャを設定するのが困難で、SIP UAのために、特に、多くの環境では非現実的であることが証明されています。
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はそれで識別されるリソースに送信されたリクエストがTLS上で、各SIPホップ上で送信されることを意味しているため、URIは「ベストエフォートTLS」には適していませんSIPS：彼らは「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.
1は、SIPのために、「ベストエフォートTLS」を使用したい場合は、1だけ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接続を開き、（等Contactヘッダーフィールド、経路、リクエストURI、へ、から）、SIPメッセージ内のすべてのヘッダフィールドの代わりに、SIPS URIの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.
それらはTLS接続を開くことができる場合同様、プロキシはルートセットがSIP URIの代わりにSIPS URIを用いた場合でも、TLSを使用して要求を転送することができます。プロキシは、TLSトランスポートを使用する場合でも、SIP URIを使用して、Record-Routeヘッダフィールドを挿入することができます。 [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.
一部のユーザーエージェント、サーバーのリダイレクト、およびプロキシは独立してSIPSが使用されているかどうかにかかわらず、すべての接続でTLSを強制するローカルポリシーを持っているかもしれません。
3.1.4. Usage of the transport=tls URI Parameter and the TLS Via Parameter
3.1.4. 輸送の使用方法= TLS URIパラメータおよびTLS経由のパラメータ
[RFC3261], Section 26.2.2 deprecated the "transport=tls" URI transport parameter in SIPS or SIP URIs:
[RFC3261]、セクション26.2.2はSIPS又はSIP URIの中に「輸送= TLS」URIトランスポートパラメータを非推奨しました。
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スキームでなお、トランスポートは、TLSとは無関係であり、したがって「すする：alice@atlanta.com;輸送= TCP」および「一口：alice@atlanta.com;輸送= SCTP」（両方とも有効である。なお、もののUDP）はSIPSのための有効なトランスポートではありません。 「輸送= 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に留まる必要があるため、「TLS」パラメータは、[RFC3261]、セクション25にABNFから排除されていません。輸送= TLSパラメータは、だけ、[RFC2543]と[RFC3261]の間でインターネットドラフトの一部では、RFCで定義されていません。
This specification does not make use of the transport=tls parameter.
この仕様は、トランスポート= 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に単一のホップにTLSの使用を指示するための代替メカニズムの回復は、この仕様の範囲外です。
For Via header fields, the following transport protocols are defined in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS-SCTP".
"UDP"、 "TCP"、 "TLS"、 "SCTP"、および[RFC4168]に： "TLS-SCTP" Viaヘッダー・フィールドは、次のトランスポート・プロトコルは、[RFC3261]で定義されています。
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のRequest-URIの存在は必ずしも要求が各ホップで安全に送信されたことを示すものではありません。 SIPSは、要求のエンドツーエンドを確保するために全体の要求パスのために使用されたのであればどのようにUASが知っているのですか？効果的に、UASは確実に知ることができません。ただし、[RFC3261]は、セクション26.4.4は、UASはセキュリティを検証するために、いくつかのチェックを行うことができますどのように推奨しています。また、履歴-Infoヘッダフィールド[RFC4244]はSIPとSIPSからリターゲットを検出するために検査することができます。それは実際に、それはなかったが、要求が、各ホップで確実に送達されたという印象で要求の受信を残すことができるので、プロキシによってSIPからSIPSに再標的化することは問題です。
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.
プロキシは、SIPまたはSIPS URIに要求のルーティングについて、独自のポリシーを持つことができます。例えば、いくつかの環境では、いくつかのプロキシにのみルーティングするように構成することができるURIをSIPS。いくつかのプロキシは不適合を検出し、安全でない要求を拒否するように設定することができます。 Contactヘッダーフィールドからは、およびViaヘッダフィールドSIPSを強制するために、実施例では、プロキシは、Request-URIを、パス、録音・ルートを調べることができます。
[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
[RFC3261]、セクション26.4.4は、S / MIMEはまた、Toヘッダーフィールドの元の形は、エンドツーエンドを実施することを確実にするために発信UACで使用することができることを説明します。具体的には[RFC3261]、セクション26.4.4に記載されていないが、これは、およびのような「トンネル」の重要なヘッダフィールド（に使用されること[RFC3893]を暗示することを意味します
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).
暗号化され、SIPメッセージ内の情報を複製し、UASは、これらの重要なヘッダフィールドの内容を検証することができ、S / MIME本体を締結中）から。このアプローチは確かに合法的であるが、好ましいアプローチは、[RFC4474]で定義されたSIPアイデンティティ機構を使用することです。 SIPアイデンティティは、とりわけ、含む署名されたアイデンティティダイジェストを作成し、レコードのアドレス（Fromヘッダフィールドから）送信者（AOR）と元のターゲットのAOR（からは、フィールドヘッダします）。
[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:
-URIを要求するためにに関してセクション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スキームは、要求がRequest-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.
Bの@のBのURI：のは、SIPSの意味を説明するために、古典的なSIPの台形を見てみましょう。代わりに、example.comとexample.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
ラストホップ例外とSIPの台形
According to [RFC3261], if a@A is sending a request to sips:b@B, the following applies:
@ AはSIPSに要求送信された場合、[RFC3261]によれば、A：Bの@ Bは、以下が適用されます。
o TLS is required between UA a@A and Proxy A
O TLSは、UAの@ AとプロキシAとの間に必要とされます
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.
TLSは、@ AとプロキシA UAとの間には必須ではなく、プロキシBとUAのB @ Bの間である理由の一つは、疑問に思うことができます。主な理由は、[RFC3261]を[RFC5626]の前に書かれたということです。その時、それが唯一のプロキシBが提供する証明書を持っているでしょうし、UA bがないため、多くの実用的な展開で、プロキシBは、UA bのTLS接続を確立することはできないかもしれないと認識されました。 UA bはTLSサーバになりますので、着信TLS接続を受け入れることができないだろう。その結果は、その[RFC3261]である - それは着信要求のためにTLSをサポートする必要がないかもしれないが、対応UASのB、それにもかかわらず、それはUACの役割を取るよう、発信要求に対してTLSをサポートする必要があります。多くの人が誤って信じて何に反して、ラストホップ例外がTLSをサポートしていませんUASに対処するためにSIPS URIを使用可能にするために作成されていない：最終ホップ例外がオーバー輸送することがないように着信要求を可能にするための試みでした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.
さらに、ダイアログ内のSIPSを使用して問題を考えます。 @ AはSIPSのRequest-URIを用いたB @ Bに要求を送信した場合、次に、[RFC3261]、セクション8.1.1.8によれば、 "Contactヘッダーフィールドは、同様にSIPS URIを含まなければなりません"。これは、B @ Bは、ダイアログ（例えば、BYEまたは再INVITE）以内に新しい要求を送信すると、SIPS URIを使用する必要がありますことを意味します。何も録音・ルートエントリが存在しない場合は、最後のレコード・ルートエントリはSIPS URIで構成されている場合、または、これは、B @ Bが最初の場所でSIPSを理解することが期待されていることを意味し、また、TLSをサポートするために必要です。最後のレコード・ルートエントリはしかし、SIP URIであれば、bがTLSを使用せずに要求を送信することができるだろう（ただし、bが、まだメッセージを解析するときSIPSスキームを扱うことができることになります）。いずれの場合においても、Bに対するB @ Bからの要求にRequest-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
ラストホップ例外なくSIP台形
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（または偶数フィールドをヘッダに）を持っていたので、したがって、それを推測することは適切ではありません。いくつかは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
要求が実際には各ホップにTLS上で配信されること、絶対保証するものではありません（要求URIで使用する場合）場合は、インターネットなどのグローバルなオープンな環境で有用SIPSされている理由のいくつかは、求めていますか？理由だけではなく、SIPとTLSトランスポートを使用してから、いずれかが異なるSIPSされますか？違いは、AにSIPS URIを使用していることです
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.
Request-URIが、あなたがネットワークに指示している場合は、各ホップの上にTLSを使用すると、それは要求を拒否することができない場合は、あなたではなく、要求がTLSなしで配信要求を持っているよりも失敗するだろうことを意味します。ただ、SIP要求URIの代わりに、SIPSのでTLSを使用して、Request-URIが「ベストエフォート型」のサービスを意味しますリクエストはなく、各ホップで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の使用を強制的にプロキシ要求と要求するオプションタグを持っていないですか？その答えは、それが唯一のRequest-URIにSIPSを使用して機能的に同等になることです。 SIPS URIは、しかし、他の多くのヘッダーフィールドで使用することができます：連絡先に登録、連絡先のダイアログ作成リクエストなどもできるURIをSIPS、呼ば-ことで、-TOを参照してくださいするにはからのルート、録音・ルート、パス、中人間が使用可能なフォーマット（例えば、名刺、ユーザインタフェース）で使用することができます。 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は、ターゲットによって指定されたSIPリソースがURIは、要求のターゲットドメインを担当するプロキシにのみとは対照的に、UACと遠隔UAS（の間の各ホップにTLSを使用して、確実に接触するSIPSことを意味することを指定します-uri）。これは、SIPS URIは、SIPネットワーク外、例えば、公衆交換電話網（PSTN）のような他のネットワークへの「マッピング」とUASリソースを識別するとき何が起こるかを指定するには、この文書の範囲外です。
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 URIを（例えば、SIP：alice@example.comとSIPS：alice@example.com）同じリソースを指します。この要件は、「SIP URIによって記載された任意のリソースは、確実にそのリソースと通信することが所望される場合だけ、スキームを変更することにより、SIPS URIに 『アップグレード』することができる」と述べている[RFC3261]、セクション19.1において暗黙的です。これは、プロキシがクライアントまたは別のプロキシへの安全な接続を確立できない場合、SIPS URIは必ずしも、特に、到達可能になることを意味するものではありません。これは、いずれかの要求を転送するとき、プロキシが任意に（5.3節を参照）SIPS URIにSIP URIを「アップグレード」ということを示唆していません。むしろ、それはリソースがSIPでアドレス指定可能であるとき、それはまた、SIPSとアドレス指定可能であることを意味します。
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 Contactヘッダーフィールドに登録されたUAの場合を考えます。 UACは、後SIPリクエストURIを使用して要求に対処している場合、セクション6.3および6.4でのメッセージF13で示されるように、要求を転送するプロキシは、UASのSIPリクエストURI宛。プロキシは、SIPリクエストURIとしないのRequest-URIが登録に使用されるSIPを使用してUAに要求を転送します。プロキシは、Request-URIとして、この新しいURIを使用して、次いでそのままURIの残りの部分を残しながら、SIP方式との結合登録Contactヘッダフィールドに使用し、SIPSスキームを置き換えることによってこれを行います。プロキシはこれを行うため、その代わりにSIPS要求-URIを使用しなかった場合、応答は、（例えば、INVITEに対する200）は、SIPS Contactヘッダーフィールドを含める必要があります。そのSIPSのContactヘッダーフィールドは、（そのUAがSIPSをサポートしていなかった場合は不可能である）ACKを含む任意の半ば対話要求にSIPSのContactヘッダーフィールドを使用するために、他のUAを強制します。
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のRequest-URIによって記述リソーススキームを変更することによって、または非セキュアリンクを介して関連する要求を送信することによってSIP URIに「格下げ」されないことを本明細書の義務。それ以外の場合は、「ダウングレード」になるので、要求を拒否する必要がある場合、要求は（潜在的に警告コード380との警告ヘッダーと「不可SIPS」）480（一時的に利用できない）応答で拒否されるだろう。同様に、プロキシは、要求を転送しているときに、リソースがRequest-URIスキームを変更することにより、SIPS URIに「アップグレード」することができないSIPによって記載され、本明細書の義務は、（そうでなければ、それは以降のホップだけのために「アップグレード」することになりますむしろ、すべてのホップよりも、そのためUASを欺くでしょう）。それ以外の場合は、「アップグレード」誤解を招くことになるので、要求を拒否する必要がある場合、要求は480（一時的に利用できない）応答で拒否されるだろう（警告コード381と、潜在的Warningヘッダーフィールドを持つ「必須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とすする：bob@example.comのAORは、ドメイン内の同じユーザ「ボブ」、「example.com」を参照してください最初のURIは、SIPバージョンであり、2つ目でありますSIPSバージョン。ルーティングの観点から、SIPのいずれかへの要求：bob@example.comまたはSIPS：bob@example.comは同じように扱われます。ボブが登録すると、彼はSIPまたはSIPS AORを使用している場合、それらの両方が同じユーザーを参照しているので、それゆえ実際に、重要ではありません。一見すると、[RFC3261]のセクション19.1.4は、SIPとSIPS URIは等価では決してありませんことを示すことによって、この考えと矛盾するようです。具体的には、それは彼らがREGISTER要求のContactヘッダーフィールドのURIでバインディングを比較する目的のために等価では決してありませんことを言います。それは、ユーザーがSIPS URIで到達可能であるかどうかを決定しますAORとContactヘッダーフィールドの関連付けです：キーポイントは、この文は、登録にContactヘッダーフィールドのバインディングに適用されるということです。
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.
この例を考える：ボブは（AOR bob@example.com）SIPSコンタクトヘッダフィールドに登録している場合（例えば、すする：bob@bobphone.example.com）、レジストラ及びロケーションサービスは、次にボブはSIPSに到達可能であることを知っています。 bob@bobphone.example.comと一口で：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に送られるリクエストはすする場合：要求URIでボブにbob@example.com、ボブのプロキシをルーティングそれはすする：bob@bobphone.example.com。要求がAOR一口に送信された場合：bob@bobphone.example.com：bob@example.com、ボブのプロキシは、Request-URI一口でボブへのルートをでしょう。
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.
ボブは（例えば、SIP：bob@bobphone.example.com）の代わりにSIPS ContactヘッダーフィールドのSIPコンタクトヘッダフィールドに登録されていた場合は、その後、AORへの要求では、SIP：bob@example.comはにルーティングされません何SIPSのContactヘッダーボブのためのフィールド、およびSIPにSIPSから「ダウングレード」がないので、ボブ、許可されていません。
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 Contactヘッダーフィールドが含まれている場合、リダイレクトの結果として要求を送信するとき、UACは、SIPリクエストURI（例えば、SIP方式とSIPSスキームを交換することにより）に置き換えません。
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またはトップRouteヘッダーフィールド値がSIPS URIを含む場合、Contactヘッダーフィールドは、同様に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.
416応答または警告コード380「許可されていないSIPを」と警告ヘッダ480（一時的に利用できない）応答を受信すると、UACが自動的に記載されているようにSIP方式とSIPSスキームを置き換えることによって、要求を再試行してはいけませんそれはセキュリティ上の脆弱性であるように、[RFC3261]、セクション8.1.3.5、。 UACは、SIP URIとのコールを再試行しない場合、UACは、SIP要求URIの代わりに、SIPSリクエスト-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.
SIPSのRequest-URIを使用する場合、ルートセットが空でない場合（サービス経路[RFC3608]はレジストラによって返された場合、例えば、）、それが全てで構成されるRouteヘッダーフィールドを使用するUACの責任であることはURIをSIPS。ルートセットは、任意のSIP URIが含まれている場合、具体的に、UACは、単純に要求を送信する前に、「SIPS」に「SIP」のスキームを変更することにより、SIPS URIにSIP URIを変更する必要があります。これは、構成または発見すべてのSIP URIを持つ1つのサービスルートをとSIPとSIPS 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はルートセットが空でないと、最上位のルートヘッダフィールドエントリはLRパラメータでSIPS URIである場合、SIPのRequest-URIを使用している場合、UACはTLSオーバー要求（SIPリクエスト-URIを使用して）を送信しなければなりません。経路が空でないとRouteヘッダーフィールドエントリはLRパラメータなしSIPS URIである場合、UACはルートセット内の一番上のエントリに対応するSIPSのRequest-URIを使用してTLSを介して要求を送信しなければなりません。
To emphasize what is already defined in [RFC3261], UAs MUST NOT use the "transport=tls" parameter.
すでに[RFC3261]で定義されているものを強調するために、UAは、「トランスポート= 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 Contactヘッダーフィールドに登録する必要があります。リクエストは、SIPまたは要求URIは、そのUAにルーティングされますSIPSのいずれかを使用して、そのUAのAOR宛。これは、SIPとSIPSの両方をサポートするUAが含まれています。この仕様は、前方SIPSのRequest-URIを使用して要求に提供し、そのプロキシをUAのための任意のSIPベースのメカニズムを提供していません。ウェブインタフェースなどの非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
SIPS Contactヘッダーフィールドに登録するSIPS接触及びAORに対応するSIPの接触の両方の結合を意味するので、UAは、SIPSとREGISTERリクエストにおいて同じContactヘッダフィールドのSIPバージョンの両方を含めることはできません。 UAは、この場合にのみSIPSのバージョンを使用する必要があります。同様に、UAは、SIPコンタクトヘッダフィールドのように別の登録にSIPコンタクトヘッダフィールドとSIPS Contactヘッダーフィールドの両方を登録しない余分であろう。その場合は、第2の登録は、最初のもの（例えば、UAは、それがSIPをサポートしていない意味、SIPコンタクトヘッダフィールドを有する第1の登録ができ、以降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.
Contactヘッダーフィールドは、それを意味することは、今）SIPSをサポートしています。 UAは、SIPS Contactヘッダーフィールドで最初の登録以降SIPコンタクトヘッダフィールドに登録した場合、同様に、そのSIPコンタクトヘッダフィールドはSIPS Contactヘッダーフィールドを置き換えます。
[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.
それは何の要求が登録時に、それが使用TLS接続を使用せずに、それに配信されていないことを保証したい場合は、[RFC5626]は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.
REGISTERリクエストのすべてのContactヘッダーフィールドはSIPSしている場合、UACがからにSIPSのAORを使用しなければならないし、REGISTERリクエストのフィールドをヘッダーにします。 Contactヘッダフィールドの少なくとも一方がSIPS（例えば、SIP、MAILTO、TEL、HTTP、HTTPS）でない場合、UACからでSIPのAORを使用しなければならなくて、REGISTERリクエストのフィールドをヘッダーします。
To emphasize what is already defined in [RFC3261], UACs MUST NOT use the "transport=tls" parameter.
すでに[RFC3261]で定義されているものを強調するために、求めるUACは、「トランスポート= 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]).
ダイアログを開始し、要求でのRequest-URIは、SIP URIがある場合、UACは（このホップのために使用されていない場合のレコード・ルートに）Contactヘッダーフィールドに使用するかについて注意する必要があります。 ContactヘッダーフィールドはSIPS URIだった場合、それはUASのみが各ホップで安全なトランスポートを介して送信され、ダイアログ中の要求を受け入れることを意味します。要求URIこのケースでは、SIP URIであるので、UAはそのURIにリクエストを送ることがSIPS URIにリクエストを送信することができない場合がありますことを、かなり可能です。トップRouteヘッダーフィールドはSIPS URIが含まれていない場合、UACは、リクエストが（例えば、最初のホップを再使用することができTLS接続をセキュアなトランスポート経由で送信されても、ContactヘッダーフィールドにSIP URIを使用しなければなりません[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.
ターゲットリフレッシュ（例えば、再INVITE要求、UPDATE要求）ダイアログ内で発生した場合、元の要求がSIPS要求-URIを使用した場合、UACはSIPS URIでContactヘッダーフィールドを含まなければなりません。
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].
セッション、ダイアログ、および取引は、既存のものに「由来」することができます。誘導されたダイアログの良い例は、REFERメソッド[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にSIPSの効果的な格下げにつながることができません。
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.
REFERリクエストがコール転送を実行するために使用されている場合たとえば、それが終了している既存のダイアログと参照してください-へのURIに基づいて作成されている別のものになります。その最初のダイアログがSIPSを使用して確立された場合は、REFERリクエストの受信者によって与えられた明示的な承認がある場合を除き、その後、UACは、SIPを使用して、新しいものを確立してはなりません。これは、ユーザーに提供する警告である可能性があります。そのような警告を持つことは、リクエストが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.
REFER要求は、ダイアログが作成さにはなりませんリソースを参照するために使用することができます。実際には、REFER要求は、元の（すなわち、SIPまたはSIPSない）とは異なるタイプであるリソースを指すために使用することができます。これに関連したセキュリティ上の考慮事項については、[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にSIPSの効果的な格下げになってはならないということです。
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とSIPS GRUUs両方が割り当てられます。 GRUUは、登録を介して取得されたときにREGISTER要求のContactヘッダフィールドは、SIP URIを含む場合、GRUUのSIPバージョンが返されます。 REGISTER要求のContactヘッダーフィールドは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またはトップRecord-Routeヘッダーフィールド値にSIPS URIを含ま開始した要求、またはContactヘッダーフィールドにはRecord-Routeヘッダーフィールドがなかった場合場合は、連絡先のヘッダー応答内のフィールドは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は、警告コード380を「許可されていませんSIPS」と警告ヘッダを含めるべきです。 [RFC3261]、セクション8.2.2.1は、全くSIPS URIスキームをサポートしていないのUASが「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は、警告コード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スキーム宛の着信要求を受け入れることは、ローカルポリシーの問題です。例えば、一時的に（UAは、「常にSIPS」のポリシーとSIPSコンタクトヘッダフィールドに登録することになる、TLS上SIPS要求-URIを使用してレジストラに対処するだろう、とUAS 480とSIP方式を使用して要求を拒否する警告コード381と警告ヘッダと利用不可能）応答「は必須SIPS」。方針にUA、TLS上のSIPSリクエスト-URIを使用してレジストラに取り組むだろうSIPS Contactヘッダーフィールドに登録するだろう、とUASはリクエストがSIPまたはSIPS要求-URIのいずれかに宛て受け入れるだろう「ベストエフォートは、SIPS」。 「いいえSIPS」の方針にUA要求がSIP宛受け入れるだろうSIP AORとSIP Contactヘッダーフィールド、およびUASに登録するだろう、TLSを使用するか、できなかった、SIPリクエスト-URIを使用してレジストラに対処しますリクエスト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がリクエストを拒否する必要がある場合、UASは400（不正な要求）で要求を拒絶しなければなりません（例えば、Request-URIがSIPS URIですが、Contactヘッダーフィールドは、SIP URIです）応答。
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.
ターゲットリフレッシュ（例えば、再INVITE要求、UPDATE要求）ダイアログ内で発生した場合、元の要求がSIPS要求-URIを使用した場合、UASは、SIPS URIとContactヘッダーフィールドを含まなければなりません。
To emphasize what is already defined in [RFC3261], UASs MUST NOT use the "transport=tls" parameter.
すでに[RFC3261]で定義されているものを強調するために、のUASは、「トランスポート= 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のいずれかにコンタクトヘッダフィールドを登録します。ルーティングの観点から、彼らが同じリソースを識別として登録するために使用されるかは重要ではありません。レジストラは、1つのSIP方式を有し、他の等価であるとSIPSスキームを有する以外は同一であるのAORを考慮しなければなりません。
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 Contactヘッダーフィールドに結合受け入れなければなりません。そうでない場合は、セキュリティで保護されていない一方（SIP）にセキュアリソース（SIPS）の結合不注意があってもよいです。これは、Request-URIと連絡先と、すべてのパスヘッダフィールドを含むが、から含まれていないとフィールドをヘッダーにします。 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である場合、例えば、レジストラは、Request-URIがSIPであっても、TLSは、最初のホップのために使用されることをUACを語っています。
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.
UAは、SIPS Contactヘッダーフィールドに登録されている場合は登録の目的は、両方のSIPを許可することであり、それによって送信された要求で使用するSIPS場合、サービスルート[RFC3608]を返すレジストラは、SIPのURIからなるサービスルートを返さなければなりませんクライアント。 UAは、SIPS Contactヘッダーフィールドに登録する場合、サービスルートを返すレジストラは、登録の目的のみそのUAによって送信されたリクエストに使用されるURIをSIPS許可する場合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とSIPS GRUUの両方を割り当てる必要があります。 REGISTER要求のContactヘッダーフィールドがSIP URIが含まれている場合、レジストラはGRUUのSIPバージョンを返さなければなりません。 REGISTER要求のContactヘッダーフィールドは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
最後のホップに要求を転送するか、再標的化するときプロキシは[RFC3261]の最後のホップ例外を使用してはいけません。具体的には、プロキシはSIPSのRequest-URI、プロキシに要求を受信したとき
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".
のみ転送する必要がありますまたはSIPSのRequest-URIに要求を再ターゲット。ターゲットUASは、以前代わりSIPS ContactヘッダフィールドのSIPコンタクトヘッダフィールドを使用して登録した場合、プロキシは、URIにリクエストを転送してはいけませんContactヘッダフィールドで示さ。プロキシがその理由で要求を拒否する必要がある場合、プロキシは480（一時的に利用できない）応答でそれを拒絶しなければなりません。この場合、プロキシは、警告コード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のRequest-URIに要求を転送してはなりません。ターゲットUASはSIPS Contactヘッダーフィールドを使用して、以前に登録されていた、とプロキシが要求を転送することを決定し、プロキシがあるとして、URIの残りの部分を残しながら、SIP方式にスキームをSIPSその交換し、結果として得られるURIを使用する必要がある場合リクエスト-URI転送された要求の。プロキシは、UASに要求を転送するためにTLSを使用しなければなりません。いくつかのプロキシはUASがSIPSのContactヘッダーフィールドを使用して登録した場合は非SIPSのRequest-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は一貫性のない使用されているので、プロキシは、要求を拒否する必要がある場合、プロキシは応答コード400（悪いRequest）を使用する必要があり（例えば、Request-URIがSIPS URIであるが、Contactヘッダフィールドは、SIP URIです）。
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のRequest-URIを使用して要求を送信し、SIPコンタクトヘッダフィールドと3XX応答、または416応答、または警告コード380を有する警告ヘッダ「480（一時的に利用できない）応答を受信すると許可されていないSIPS 「応答、プロキシは応答に再帰てはなりません。この場合、プロキシは、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を使用して要求を送信し、SIPSのContactヘッダーフィールドと3XX応答、または警告コード381「必須SIPS」を有する警告ヘッダ480（一時的に利用できない）応答を受信すると、プロキシはNOT MUST応答に再帰。この場合、プロキシは、UACが適切な行動を取ることを可能にするために、代わりに再帰の最適な応答を転送する必要があります。
To emphasize what is already defined in [RFC3261], proxies MUST NOT use the "transport=tls" parameter.
すでに[RFC3261]で定義されているものを強調するために、プロキシは、「トランスポート= 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とリダイレクトサーバーを使用することを考慮しなければならないいくつかの制限があります。プロキシと（例えば、[RFC5626]のように）UASとの間に予め確立された接続が存在しないので、着信接続が許可されているシナリオにのみ適切です。例えば、それはサーバー間の環境で使用することができ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.
リダイレクトサーバは、SIPリクエストURIで要求を受信すると、リダイレクトサーバは、SIPまたはSIPS Contactヘッダーフィールドのいずれかに3xx応答でリダイレクトすることができます。ターゲットUASは、以前SIPS Contactヘッダーフィールドを使用して登録した場合は、TLSが使用可能な環境であれば、リダイレクトサーバは、（前の段落で説明したように）SIPS Contactヘッダーフィールドを返すべきです。ターゲット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.
リダイレクトサーバーはSIPSのRequest-URIを持つリクエストを受信すると、リダイレクトサーバは、SIPまたはSIPSのContactヘッダーフィールドに3xx応答でリダイレクトすることができます。ターゲットUASが以前SIPS Contactヘッダーフィールドを使用して登録した場合、それはTLSが使用可能な環境であれば、リダイレクトサーバーはSIPS Contactヘッダーフィールドを返すべきです。ターゲットUASは、SIPコンタクトヘッダフィールドを使用して、以前に登録した場合は、リダイレクトすることを選択した場合、リダイレクトサーバは、3XX応答してSIPコンタクトヘッダフィールドを返さなければなりません。そうでなければ、UASは、警告コード380を「不可SIPS」と警告ヘッダ480（一時的に利用できない）応答で要求を拒絶するかもしれません。リダイレクトサーバーは、それが（例えば、異なるドメイン内のAOR）の知識を持たないUASにリダイレクトする場合、Contactヘッダーフィールドは、任意の方式のものであってもよいです。
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は一貫性のない使用されているため、リダイレクトサーバは、要求を拒否する必要がある場合（例えば、Request-URIがSIPS URIであるが、Contactヘッダフィールドは、SIP URIである）、リダイレクトサーバは、応答コード400（不正な要求）を使用してください。
To emphasize what is already defined in [RFC3261], redirect servers MUST NOT use the "transport=tls" parameter.
すでに[RFC3261]で定義されているものを強調するために、サーバは「輸送= 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つのクライアントを持っています。一つは自分のコンピュータ上で実行されているSIP PCクライアントであり、他の一つはSIPフォンです。 PCクライアントは、SIPSをサポートし、その結果のみのSIP Contactヘッダーフィールドに登録しません。 SIP電話機は、しかしながら、支持SIPSとTLSを行い、その結果、SIPS Contactヘッダーフィールドに登録します。ボブの装置の双方は、エッジプロキシBを通過され、その結果、それらはeb.example.comを示すRouteヘッダフィールドを含みます。エッジプロキシBは、自身に対応するRouteヘッダフィールドを削除し、パスヘッダフィールドに自分自身を追加します。登録プロセスのコールフローは、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@bobphone.example.comとSIP：bob@bobpc.example.com登録後、bob@example.comのBobのAORに関連する2つのコンタクトバインディングがあります。
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は、自身に対応するRouteヘッダフィールドを削除し、レコードルート自体を挿入し、レジストラ/権威プロキシ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を呼び出します。第二の例（6.3）において、アリスは、TCPトランスポートを使用してボブのSIP AORを呼び出します。第三の例（セクション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クライアント（ボブの@ bobpc）は、SIP方式に登録し、彼のSIPフォン（携帯電話@ボブ）はSIPSスキームに登録されます。
(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 REGISTERボブの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
pb.example.com SIP / 2.0経由：SIP / 2.0 / TCP bobpc.example.com:5060;branch=z9hG4bKnashdsマックス・フォワード：70：ボブ<SIP：bob@example.com>から：ボブ<一口を登録SIP：bob@example.com>;タグは= 456248コールID：843817637684230 998sdasdh09 @のCSeq：1826 REGISTERサポート：パス、アウトバウンドルート：<SIP：eb.example.com; LR>連絡先：<SIP：ボブの@ 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
F2 REGISTERエッジプロキシB - >レジストラ/権威プロキシ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
一口に登録：pb.example.com SIP / 2.0経由：SIP / 2.0 / TCP eb.example.com:5060;branch=z9hG4bK87asdks7経由：SIP / 2.0 / TCP bobpc.example.com:5060;branch=z9hG4bKnashdsマックス転送し：<：bob@example.com一口>から：ボブ：69にボブ<一口：bob@example.com>;タグ= 456248コールID：843817637684230 998sdasdh09 @のCSeq：1826 REGISTERサポート：パス、アウトバウンドパス：<SIP ：laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com; LR; OB>連絡先：<SIP：bob@bobpc.example.com>; + sip.instance = "<壷：UUID：0C67446E-F1A1-11D9-94D3- 000A95A0E128>」; REG-ID = 1のContent-Length：0
F3 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
F3 200（REGISTER）登録/権威プロキシ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
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP eb.example.com:5060;branch=z9hG4bK87asdks7経由：ボブ<SIP：ボブ@例にSIP / 2.0 / TCPのbobpc.example.com:5060;branch=z9hG4bKnashds .COM>;タグ= 2493K59K9から：ボブ<SIP：bob@example.com>;タグ= 456248コールID：843817637684230のCSeq 998sdasdh09 @：REGISTER 1826必要：アウトバウンドサポート：パス、アウトバウンドパス：<SIP：laksdyjanseg237 + fsdf +uy623hytIJ8@eb.example.com; LR; OB>連絡先：<SIP：bob@bobphone.example.com>; + sip.instance = "<壷：UUID：0C67446E-F1A1-11D9-94D3-000A95A0E128>"; ; REG-ID = 1 = 3600日有効期限が切れる：月を、2006年6月12日午前16時43分12秒GMTのコンテンツの長さ：0
F4 200 (REGISTER) Edge Proxy B -> Bob's PC Client
F4 200（REGISTER）エッジ・プロキシB - >ボブのPCクライアント
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
SIP / 2.0 200 OK経由：SIP / 2.0 / TCPのbobpc.example.com:5060;branch=z9hG4bKnashdsへ：ボブ<SIP：bob@example.com>;からタグ= 2493K59K9：ボブ<SIP：bob@example.com >;タグ= 456248コールID：843817637684230 998sdasdh09 @のCSeq：1826 REGISTER要求：アウトバウンドサポート：パス、アウトバウンドパス：<SIP：laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com; LR; OB>連絡先：<SIP： bob@bobphone.example.com>; + sip.instance = "<壷：UUID：0C67446E-F1A1-11D9-94D3-000A95A0E128>"; REG-ID = 1; = 3600日を期限が切れる：木、2007年8月9日16： 43:12 GMTのコンテンツの長さ：0
F5 REGISTER Bob's Phone -> Edge Proxy B
F5 REGISTERボブの電話 - >エッジ・プロキシ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
REGISTERでは、SIP：pb.example.com SIP / 2.0経由：SIP / 2.0 / TLS bobphone.example.com:5061;branch=z9hG4bK9555マックス・フォワード：70：ボブ<一口：bob@example.com>から：ボブ<一口：bob@example.com>;タグ= 90210コールID：faif9a @ qwefnwdclkのCSeq：12 REGISTERサポート：パス、アウトバウンドルート：<一口：eb.example.com; LR>連絡先：<一口：ボブの@ 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
F6 REGISTERエッジ・プロキシB - >レジストラ/権威プロキシ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
REGISTERでは、SIP：pb.example.com SIP / 2.0経由：SIP / 2.0 / TLS eb.example.com:5061;branch=z9hG4bK876354経由：SIP / 2.0 / TLS bobphone.example.com:5061;branch=z9hG4bK9555マックス前方に：69：ボブ<一口：bob@example.com>から：ボブ<一口：bob@example.com>;タグ= 90210コールID：faif9a @ qwefnwdclkのCSeq：12 REGISTERサポート：パス、アウトバウンドパス：<一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>連絡先：<一口：bob@bobphone.example.com>; + sip.instance = "<壷：UUID：6F85D4E3-E8AA- 46AA-B768-BF39D5912143>」; REG-ID = 1のContent-Length：0
F7 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B
F7 200（REGISTER）登録/権威プロキシ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
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS eb.example.com:5061;branch=z9hG4bK876354経由：SIP / 2.0 / TLS bobphone.example.com:5061;branch=z9hG4bK9555へ：ボブ<一口：ボブ@例.COM>;からタグ= 5150：ボブ<一口：bob@example.com>;タグは= 90210のCall-ID：faif9a @ qwefnwdclkのCSeq：12レジスタが必要：アウトバウンドのサポート：パス、往路：<一口：psodkfsj + 34 +kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>連絡先：<一口：bob@bobphone.example.com>; + sip.instance = "<壷：UUID：6F85D4E3-E8AA-46AA-B768- BF39D5912143>」; REG-ID = 1; = 3600日を期限が切れる：木、2007年8月9日午前16時43分50秒GMTのコンテンツの長さ：0
F8 200 (REGISTER) Edge Proxy B -> Bob's Phone
F8 200（REGISTER）エッジ・プロキシB - >ボブの電話
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
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS bobphone.example.com:5061;branch=z9hG4bK9555へ：ボブ<一口：bob@example.com>;タグ= 5150投稿者：ボブ<一口：bob@example.com >;タグ= 90210コールID：faif9a @ qwefnwdclkのCSeq：12 REGISTER要求：アウトバウンドのサポート：パス、アウトバウンドパス：<一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.comを、LR、OB>お問い合わせ<一口：bob@bobphone.example.com>; + sip.instance = "<URN：UUID：6F85D4E3-E8AA-46AA-B768-BF39D5912143>"; REG-ID = 1; = 3600日の有効期限：木、09 2007年8月夜四時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（：bob@example.comをすする）を呼び出します。レジストラ/権威プロキシBは、登録データベースにバインディングを参照し、2つのContactヘッダーフィールド・バインディングを見つけます。レジストラ/権威プロキシBは、コールが（SIPSコンタクトヘッダフィールドを使用して登録する）のみbobphoneにルーティングする必要があり、従ってことを決定するように、アリスは、SIPSのリクエストURI（bob@example.com SIPS）でボブに対処していましたレコードルートに自身を挿入するエッジプロキシBの両方レジストラ/権威プロキシB及びエッジプロキシBを介して、bob@bobphone.example.com：要求のみ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
>プロキシA - F9は、アリスのINVITE
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}
bob@example.com SIP / 2.0経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKproutマックス・フォワード：70：ボブ<一口：bob@example.com>から一口をINVITE：アリス<一口：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeqは：ルートを1 INVITE：<一口を：proxya.example.net; LR>連絡先：<一口：alice@alice-1.example .NET>コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：{SDPの通り} {SDPは示されていません}
F10 100 (INVITE) Proxy A -> Alice
F10 100（INVITE）プロキシA - >アリス
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
：アリス<一口：alice@example.net> SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKproutへ：：：ボブ<bob@example.com一口>経由を試してSIP / 2.0 100;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1は、コンテンツの長さをINVITE：0
F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
F11 INVITEプロキシ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}
一口にINVITE：bob@example.com SIP / 2.0経由：SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKpouet経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKproutマックス-Forwards：69：ボブ<一口：bob@example.com>から：アリス<一口：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：レコード・ルートを1 INVITE：<一口に： proxya.example.net; LR>連絡先：<一口：alice@alice-1.example.net>コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：{SDPは示されていない} {SDPに従って}
F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F12 100（INVITE）登録/権威プロキシ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
SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKpouet経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKproutへ：ボブ<一口：ボブ経由をしようとSIP / 2.0 100 @ example.com>から：アリス<一口：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：コンテンツ長を1 INVITE：0
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
F13 INVITEレジストラ/権威プロキシB - >エッジ・プロキシ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}
一口にINVITE：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TLS pb.example.com:5061;branch=z9hG4bKbalouba経由：SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKpouet経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKprout最大フォワード：68：から<bob@example.com一口>：アリスはボブ<一口：alice@example.net>;タグ= 8675309コールID：lzksjf8723k @ sodk6587のCSeq：ルートを1 INVITE：<一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@edge.example.com; LR; OB>レコード・ルート：<一口：pb.example.com ; LR>、<一口：proxya.example.net; LR>連絡先：<一口：alice@alice-1.example.net>コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：{SDPは示されていない{SDP当たりとして} }
F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F14 100（INVITE）エッジプロキシ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
SIP / 2.0 / TLS pb.example.com:5061;branch=z9hG4bKbalouba経由：SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKpouet経由：SIP / 2.0 / TLS alice-経由を試してSIP / 2.0 100 1.example.net:5061;branch=z9hG4bKproutへ：ボブ<一口：bob@example.com>から：アリス<一口：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1 INVITEコンテンツの長さ：0
F15 INVITE Edge Proxy B -> Bob's phone
F15 INVITEエッジ・プロキシB - >ボブの携帯電話
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}
一口にINVITE：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TLS eb.example.com:5061;branch=z9hG4bKbiba経由：SIP / 2.0 / TLS pb.example.com:5061;branch=z9hG4bKbalouba経由：SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKpouet経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKproutマックス・フォワード：67：ボブ<一口：ボブ@ example.com>から：アリス<一口：alice@example.net>; = 8675309のCall-IDタグ：lzksjf8723k @ sodk6587のCSeq：1レコードルートをINVITE <一口：psodkfsj + 34 + kklsL + uJH-Xm816k09Kk @ EB。 example.com; LR; OB>、<一口：pb.example.com; LR>、<一口：proxya.example.net; LR>連絡先：<一口：alice@alice-1.example.net>のContent-Type ：アプリケーション/ SDPコンテンツ長：{SDPに従って} {SDP示されていません}
F16 180 (INVITE) Bob's Phone -> Edge Proxy B
F16 180ボブの電話番号を（INVITE） - >エッジ・プロキシ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
SIP / 2.0 180リンギングの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：をボブ<一口：bob@example.com>;からタグ= 5551212：アリス<SIPS ：alice@example.net>;タグは= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：レコード・ルートを1 INVITE：<一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>、 <一口：pb.example.com; LR>、<一口：proxya.example.net; LR>連絡先：<一口：bob@bobphone.example.com>のContent-Length：0
F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F17 180（INVITE）エッジプロキシB - >レジストラ/権威プロキシ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
SIP / 2.0 180リンギングの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へ：ボブ<一口：bob@example.com>;：アリスからタグ= 5551212 <一口：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587 CSeq：<一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>、<一口：pb.example.com; LR>レコードルートINVITE 1、<一口：proxya.exampleを.NET; LR>連絡先：<一口：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
SIP / 2.0 180リンギング経由：SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKpouet経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKproutへ：ボブ<一口：ボブ@ example.com>;からタグ= 5551212：アリス<一口：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeqは：レコードルートをINVITE 1 <一口：psodkfsj + 34 + kklsL + uJH -Xm816k09Kk@eb.example.com; LR; OB>、<一口：pb.example.com; LR>、<一口：proxya.example.net; LR>連絡先：<一口：bob@bobphone.example.com>コンテンツの長さ：0
F19 180 (INVITE) Proxy A -> Alice
F19 180（INVITE）プロキシ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
SIP / 2.0 180リンギングのVia：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKprout：をボブ<一口：bob@example.com>;からタグ= 5551212：アリス<一口：例@アリス.NET>;タグは= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：レコードルートをINVITE 1 <一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>、<一口：PB .example.comと、LR>、<一口：proxya.example.net; LR>連絡先：<一口：bob@bobphone.example.com>のContent-Length：0
F20 200 (INVITE) Bob's Phone -> Edge Proxy B
F20 200ボブの電話番号を（INVITE） - >エッジ・プロキシ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
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS eb.example.com:5061;branch=z9hG4bKbiba経由：SIP / 2.0 / TLS pb.example.com:5061;branch=z9hG4bKbalouba経由：SIP / 2.0 / TLSのproxya。 example.net:5061;branch=z9hG4bKpouetのVia：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKprout：をボブ<一口：bob@example.com>;からタグ= 5551212：アリス<SIPS ：alice@example.net>;タグは= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：レコード・ルートを1 INVITE：<一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>、 <一口：pb.example.com; LR>、<一口：proxya.example.net; LR>連絡先：<一口：bob@bobphone.example.com>のContent-Length：0
F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F21 200（INVITE）エッジプロキシ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
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS pb.example.com:5061;branch=z9hG4bKbalouba経由：SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKpouet経由：SIP / 2.0 / TLS alice- 1.example.net:5061;branch=z9hG4bKproutへ：ボブ<一口：bob@example.com>;：アリスからタグ= 5551212 <一口：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587 CSeq：<一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>、<一口：pb.example.com; LR>レコードルートINVITE 1、<一口：proxya.exampleを.NET; LR>連絡先：<一口：bob@bobphone.example.com>のContent-Length：0
F22 200 Registrar/Authoritative Proxy B -> Proxy A
F22 200レジストラ/権威プロキシB - >プロキシ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
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKpouet経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKproutへ：ボブ<一口：ボブ@ example.com>;からタグ= 5551212：アリス<一口：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeqは：レコードルートをINVITE 1 <一口：psodkfsj + 34 + kklsL + uJH -Xm816k09Kk@eb.example.com; LR; OB>、<一口：pb.example.com; LR>、<一口：proxya.example.net; LR>連絡先：<一口：bob@bobphone.example.com>コンテンツの長さ：0
F23 200 (INVITE) Proxy A -> Alice
F23 200（INVITE）プロキシ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
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKprout：をボブ<一口：bob@example.com>;からタグ= 5551212：アリス<一口：例@アリス.NET>;タグは= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：レコードルートをINVITE 1 <一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>、<一口：PB .example.comと、LR>、<一口：proxya.example.net; LR>連絡先：<一口：bob@bobphone.example.com>のContent-Length：0
F24 ACK Alice -> Proxy A
F24 ACKアリス - >プロキシ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
ACKをすする：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKksdjfマックス・フォワード：70：ボブ<一口：bob@example.com> ;からタグ= 5551212：アリス<一口：alice@example.net>; = 8675309のCall-IDタグ：;：PB lzksjf8723k @ sodk6587のCSeq：1 ACKルート：<一口LR proxya.example.net>、<一口。 example.com; LR>、<一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@pb.example.com; LR; OB>のContent-Length：0
F25 ACK Proxy A -> Registrar/Authoritative Proxy B
F25 ACKプロキシA - >レジストラ/権威プロキシ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
ACKでは、SIP：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKplo7hy経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch= z9hG4bKksdjfマックス・フォワード：69：ボブ<一口：bob@example.com>;からタグ= 5551212：アリス<一口：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1 ACKルート<一口：pb.example.com; LR>、<一口：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
ACKをすする：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TLS pb.example.com:5061;branch=z9hG4bK8msdu2経由：SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKplo7hy経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKksdjf最大フォワード：69：ボブ<一口：bob@example.com>;からタグ= 5551212：アリス<一口例：@アリス。ネット>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1 ACKルート：<一口：pb.example.com; LR>、<一口：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
ACKをすする：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TLS eb.example.com:5061;branch=z9hG4bKkmfdgk経由：SIP / 2.0 / TLS pb.example.com:5061;branch=z9hG4bK8msdu2経由：SIP / 2.0 / TLS proxya.example.net:5061;branch=z9hG4bKplo7hy経由：SIP / 2.0 / TLS alice-1.example.net:5061;branch=z9hG4bKksdjfマックス・フォワード：68：ボブ<一口：ボブ@ example.com>;からタグ= 5551212：アリス<一口：alice@example.net>;タグは= 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番目の例では、アリスは（一口：bob@example.com）の代わりにBobのSIP AORを呼び出し、彼女はトランスポートとしてTCPを使用しています。レジストラ/権威プロキシBは、登録データベースにバインディングを参照し、2つのContactヘッダーフィールド・バインディングを見つけます。アリスは、SIPリクエストURI（SIP：bob@example.com）でボブに対処していたので、レジストラ/権威プロキシBは、コールが（（SIPコンタクトヘッダフィールドに登録されている）とbobphone両方がbobpcにルーティングする必要があると判断しますある）SIPS Contactヘッダーフィールドに登録され、したがって、要求は、SIPに二股さ：bob@bobpc.example.comとSIP：bob@bobphone.example.com、エッジプロキシB.注を通してレジストラ/権威プロキシBが保持することをリクエストURIのSIP方式の代わりに登録するために使用したContactヘッダーフィールドのSIPS方式でそれを置き換えます。レジストラ/権威プロキシB及びエッジプロキシBの両方は、レコードルートに自身を挿入します。ボブの携帯電話の政策は同時にSIPとSIPSへの呼び出し（すなわち、「ベストエフォート」）を受け入れるので、彼の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
>プロキシA - F9は、アリスのINVITE
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}
bob@example.com SIP / 2.0経由：SIPのINVITE SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutマックス・フォワード：70：ボブ<SIP：bob@example.com>から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1ルートをINVITE：<SIP：proxya.example.net; LR>連絡先：<SIP：alice@alice-1.example .NET>コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：{SDPの通り} {SDPは示されていません}
F10 100 (INVITE) Proxy A -> Alice
F10 100（INVITE）プロキシ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
SIP / 2.0 100試みる経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：bob@example.com>から：アリス<SIP：alice@example.net>。タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1は、コンテンツの長さをINVITE：0
F11 INVITE Proxy A -> Registrar/Authoritative Proxy B
F11 INVITEプロキシ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}
SIPのINVITE：bob@example.com SIP / 2.0経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutマックス-Forwards：69：から：<bob@example.com一口>：アリス<SIP：alice@example.net>ボブ;タグは= 8675309コールID：lzksjf8723k @ sodk6587のCSeq：1レコード-ルートをINVITE：<SIP： proxya.example.net; LR>連絡先：<SIP：alice@alice-1.example.net>コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：{SDPは示されていない} {SDPに従って}
F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F12 100（INVITE）登録/権威プロキシB - >プロキシ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
SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：ボブ経由をしようとSIP / 2.0 100 @ example.com>から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：0：コンテンツ長をINVITE 1
F13' INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
F13' レジストラ/権威プロキシBをINVITE - >エッジ・プロキシ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}
SIPのINVITE：bob@bobpc.example.com SIP / 2.0経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.2経由：SIP / 2.0 / TCPのproxya.example.net:5060;branch= z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutマックス・フォワード：68：ボブ<SIP：bob@example.com>から：アリス<SIP：alice@example.net> ;タグは= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：<SIP：laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com; LR; OB>ルートINVITE 1レコードルート<SIP：pb.example.com; LRを>、<SIP：proxya.example.net; LR>連絡先：<SIP：alice@alice-1.example.net>コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：{SDPに従って} {SDP示されていません}
F14' 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F14' 100（INVITE）エッジプロキシ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
SIP / 2.0を介してをしよう100：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.2経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCPボブさんへalice-1.example.net:5060;branch=z9hG4bKprout <一口：bob@example.com>から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq： 1コンテンツの長さをINVITE：0
F15' INVITE Edge Proxy B -> Bob's PC Client
F15' エッジ・プロキシB INVITE - >ボブのPCクライアントを
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}
SIP INVITE：bob@bobpc.example.comをSIP / 2.0経由：SIP / 2.0 / TCP eb.example.com:5060;branch=z9hG4bKbiba経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba。 2ビア：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutマックス・フォワード：67：ボブ<SIP： bob@example.com>から：アリス<SIP：alice@example.net>; = 8675309のCall-IDタグ：lzksjf8723k @ sodk6587のCSeq：1は、録音-ルートをINVITE：<SIP：laksdyjanseg237+fsdf+uy623hytIJ8@eb.example。 COM; LR; OB>、<SIP：pb.example.com; LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：alice@alice-1.example.net>のContent-Type：アプリケーション/ SDPのContent-Length：{SDPの通り} {SDPは示されていません}
F16' 180 (INVITE) Bob's PC Client -> Edge Proxy B
F16' 180（INVITE）ボブの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
SIP / 2.0 180リンギング経由：SIP / 2.0 / TCP eb.example.com:5060;branch=z9hG4bKbiba経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.2経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：bob@example.com>;タグ= 963258投稿者：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeqは：レコードルートをINVITE 1：<SIP：laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.comを、LR、OB>、<SIP ：pb.example.com; LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：bob@bobpc.example.com>のContent-Length：0
F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F17' 180（INVITE）エッジプロキシB - >レジストラ/権威プロキシ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
SIP / 2.0 180リンギング経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.2経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：bob@example.com>;からタグ= 963258：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587ののCSeq：レコード・ルートINVITE 1：<一口：laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.comを、LR、OB>、<SIP：pb.example.com; LR>、<SIP：proxya.example.net ; LR>連絡先：<SIP：bob@bobpc.example.com>のContent-Length：0
F18' 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F18' 180（INVITE）登録/権威プロキシ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
SIP / 2.0 180リンギング経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：ボブ@ example.com>;からタグ= 963258：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1レコードルートをINVITE <SIP：laksdyjanseg237 + fsdf + uy623hytIJ8 @ EB .example.comと、LR; OB>、<SIP：pb.example.com; LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：bob@bobpc.example.com>のContent-Length： 0
F19' 180 (INVITE) Proxy A -> Alice
F19' 180（INVITE）プロキシA - >アリス
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
SIP / 2.0 180リンギングのVia：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKprout：をボブ<SIP：bob@example.com>;タグ= 963258から：アリス<SIP：アリス例@ .NET>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：レコードルートをINVITE 1：<SIP：laksdyjanseg237+fsdf+uy623hytIJ8@eb.example.com; LR; OB>、<SIP：pb.example.com ; LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：bob@bobpc.example.com>のContent-Length：0
F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B
F13 INVITEレジストラ/権威プロキシ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}
SIPのINVITE：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.1経由：SIP / 2.0 / TCPのproxya.example.net:5060;branch= z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutマックス・フォワード：68：ボブ<SIP：bob@example.com>から：アリス<SIP：alice@example.net> ;タグは= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：<SIP：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>レコードルート：ルートINVITE、1 <SIP：pb.exampleを.COM; LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：alice@alice-1.example.net>コンテンツタイプ：アプリケーション/ sdpのコンテンツ長：{SDPの通り} {SDP図示されていません}
F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F14 100（INVITE）エッジプロキシ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
SIP / 2.0を介してをしよう100：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.1経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCPボブさんへalice-1.example.net:5060;branch=z9hG4bKprout <一口：bob@example.com>から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq： 1コンテンツの長さをINVITE：0
F15 INVITE Edge Proxy B -> Bob's Phone
F15 INVITEエッジ・プロキシB - >ボブの電話
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}
INVITE SIP：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TLS eb.example.com:5061;branch=z9hG4bKtroubaba経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba。 1ビア：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutマックス・フォワード：68：ボブ<SIP： bob@example.com>から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：レコードルートをINVITE 1：<SIP：psodkfsj + 34 + kklsL + uJH-Xm816k09Kkを@ eb.example.com; LR; OB>、<SIP：pb.example.com; LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：alice@alice-1.example.net>コンテンツ-Type：アプリケーション/ SDPコンテンツ長：{SDPは示されていない} {SDPに従って}
F16 180 (INVITE) Bob's Phone -> Edge Proxy B
F16 180ボブの電話番号を（INVITE） - >エッジ・プロキシ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
SIP / 2.0 180リンギング経由：SIP / 2.0 / TLS eb.example.com:5061;branch=z9hG4bKtroubaba経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.1経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：bob@example.com>;タグ= 5551212投稿者：アリス<一口：alice@example.net>;タグは= 8675309コールID：lzksjf8723k @ sodk6587のCSeq：1レコード-ルートをINVITE：<SIP：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB >、<SIP：pb.example.com; LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：bob@bobphone.example.com>のContent-Length：0
F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F17 180（INVITE）エッジプロキシB - >レジストラ/権威プロキシ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
SIP / 2.0 180リンギング経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.1経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：bob@example.com>;からタグ= 5551212：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587ののCSeq：レコード・ルートを1 INVITE：<一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.comを、LR、OB>、<SIP：pb.example.com; LR>、<SIP：proxya .example.net; LR>連絡先：<SIP：bob@bobphone.example.com>のContent-Length：0
F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F18 180（INVITE）登録/権威プロキシ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
SIP / 2.0 180リンギング経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：ボブ@ example.com>;タグ= 5551212から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：INVITE 1レコードルート<SIP：psodkfsj + 34 + kklsL + uJH -Xm816k09Kk@eb.example.com; LR; OB>、<SIP：pb.example.com; LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：bob@bobphone.example.com>コンテンツの長さ：0
F19 180 (INVITE) Proxy A -> Alice
F19 180（INVITE）プロキシA - >アリス
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
SIP / 2.0 180リンギングのVia：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKprout：をボブ<SIP：bob@example.com>;タグ= 5551212から：アリス<SIP：アリス例@ .NET>;タグは= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：レコードルートをINVITE 1：<SIP：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>、<SIP：PB .example.comと、LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：bob@bobphone.example.com>のContent-Length：0
F20 200 (INVITE) Bob's Phone -> Edge Proxy B
F20 200ボブの電話番号を（INVITE） - >エッジ・プロキシ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
SIP / 2.0 200 OK経由：SIP / 2.0 / TLS eb.example.com:5061;branch=z9hG4bKtroubaba経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.1経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：bob@example.com>;タグ= 5551212投稿者：アリス<一口：alice@example.net>;タグは= 8675309コールID：lzksjf8723k @ sodk6587のCSeq：1レコード-ルートをINVITE：<SIP：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB >、<SIP：pb.example.com; LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：bob@bobphone.example.com>のContent-Length：0
F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F21 200（INVITE）エッジプロキシB - >レジストラ/権威プロキシ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
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.1経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：bob@example.com>;からタグ= 5551212：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587ののCSeq：レコード・ルートを1 INVITE：<一口：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.comを、LR、OB>、<SIP：pb.example.com; LR>、<SIP：proxya .example.net; LR>連絡先：<SIP：bob@bobphone.example.com>のContent-Length：0
F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A
F22 200（INVITE）登録/権威プロキシ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
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：ボブ@ example.com>;タグ= 5551212から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：INVITE 1レコードルート<SIP：psodkfsj + 34 + kklsL + uJH -Xm816k09Kk@eb.example.com; LR; OB>、<SIP：pb.example.com; LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：bob@bobphone.example.com>コンテンツの長さ：0
F23 200 (INVITE) Proxy A -> Alice
F23 200（INVITE）プロキシA - >アリス
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
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ：;：アリス<一口例：@アリス<一口bob@example.com>からタグ= 5551212 .NET>;タグは= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：レコードルートをINVITE 1：<SIP：psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com; LR; OB>、<SIP：PB .example.comと、LR>、<SIP：proxya.example.net; LR>連絡先：<SIP：bob@bobphone.example.com>のContent-Length：0
F24 ACK Alice -> Proxy A
F24 ACKアリス - >プロキシ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
ACKのSIP：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutマックス・フォワード：70：ボブ<SIP：bob@example.com> ;タグ= 5551212から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1 ACKルート：<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
ACKのSIP：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCPのalice-1.example.net:5060;branch= z9hG4bKproutマックス・フォワード：69：ボブ<SIP：bob@example.com>;タグ= 5551212から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1 ACKルート：<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
ACKのSIP：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.1経由：SIP / 2.0 / TCPのproxya.example.net:5060;branch= z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutマックス・フォワード：69：ボブ<SIP：bob@example.com>;タグ= 5551212から：アリス<SIP：アリス@ example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1 ACKルート：<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
ACKのSIP：bob@bobphone.example.com SIP / 2.0経由：SIP / 2.0 / TLS eb.example.com:5061;branch=z9hG4bKtroubaba経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba。 1ビア：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutマックス・フォワード：68：ボブ<SIP： bob@example.com>;タグ= 5551212から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1個のACKのコンテンツの長さ：0
F26' CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B
F26' レジストラ/権威プロキシB CANCEL - >エッジ・プロキシ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
SIP CANCEL：bob@bobpc.example.comをSIP / 2.0経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.2マックス・フォワード：70：ボブ<SIP：bob@example.com>投稿者：アリス<SIP：alice@example.net>;タグは= 8675309コールID：lzksjf8723k @ sodk6587のCSeq：<SIP：1ルートCANCEL psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.comを、LR; OB>のContent-Length：0
F27' CANCEL Edge Proxy B -> Bob's PC Client
F27' エッジ・プロキシB CANCEL - >ボブのPCクライアントを
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
SIP CANCEL：bob@bobpc.example.comをSIP / 2.0経由：SIP / 2.0 / TCP eb.example.com:5060;branch=z9hG4bKtroubaba経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba。 2マックス・フォワード：69：から：アリス：ボブ<bob@example.com一口> <一口：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1のContent-LengthをCANCEL：0
F28' 200 (CANCEL) Bob's PC Client -> Edge Proxy B
F28' 200（CANCEL）ボブの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
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP eb.example.com:5060;branch=z9hG4bKtroubaba経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.2へ：ボブ<SIP：ボブ@ example.com>から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1のContent-LengthをCANCEL：0
F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B
F29' 200（CANCEL）エッジプロキシ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
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.2へ：ボブ<SIP：bob@example.com>から：アリス<SIP：alice@example.net>。タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：1のContent-LengthをCANCEL：0
F30' 487 (INVITE) Bob's PC Client -> Edge Proxy B
F30' 487（INVITE）ボブのPCクライアント - >エッジ・プロキシ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
SIP / 2.0 487要求によって終端：SIP / 2.0 / TCP eb.example.com:5060;branch=z9hG4bKtroubaba経由：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.2経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：bob@example.com>から：アリス<SIP： alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq：コンテンツ長をINVITE 1：0
F31' 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B
F31' 487（INVITE）エッジ・プロキシ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
SIP / 2.0 487要求によって終端：SIP / 2.0 / TCP pb.example.com:5060;branch=z9hG4bKbalouba.2経由：SIP / 2.0 / TCP proxya.example.net:5060;branch=z9hG4bKpouet経由：SIP / 2.0 / TCP alice-1.example.net:5060;branch=z9hG4bKproutへ：ボブ<SIP：bob@example.com>から：アリス<SIP：alice@example.net>;タグ= 8675309のCall-ID：lzksjf8723k @ sodk6587のCSeq ：1のContent-LengthをINVITE：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.
第三の例では、アリスは彼女のプロキシへの彼女の接続のためのトランスポートとしてTLSを使用することを除いて、第二のものと同じです。アリスのUAがTLSをサポートし、（[RFC5626]を使用する場合場合のように）プロキシへの単一の接続を使用したい場合、このような構成は一般的であろう。以下の例では、プロキシAはまた、アウトバウンドプロキシBと通信するトランスポートとしてTLSを使用しているが、それは必ずしもそうではありません。
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.
リクエストを送信するためのトランスポートとしてのRequest-URIが、TLSでSIP URIを使用する場合は、Viaフィールドには、TLSを示しています。 Routeヘッダーフィールド（存在する場合）は、典型的には、SIP URIを使用する（それはまた、SIPS URIであってもよいです）。 Contactヘッダーフィールドとし、より、しかしまた、通常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.
コールフローは、正確に第二の例（セクション6.3）の通りであろう。唯一の違いは、すべてのViaヘッダーフィールドは、TLS経由のパラメータを使用することになります。 URIは、SIP URIを維持し、URIをSIPSないでしょう。
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をダイアログ開始要求のContactヘッダフィールドに使用され、レコードルートが使用されていない場合、それはURIがもう一方の端で使用可能ではないかもしれないSIPS。もう一方の端は、SIPSおよび/またはTLSをサポートしていない場合、それを使用することはできません。最終ホップの例外は、これが発生する可能性があります場合の例です。この場合、要求はプロキシを経由して送信されるように、レコード・ルートを使用すると、それが動作することに役立ちます。別の例でもContactヘッダーフィールドは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ゲートウェイまたはメディアサーバーとして静的に設定されたデバイスとの間で使用されています。相互認証モデルでは、TLS接続を確立することができるようにする2つのエンティティのためには、双方が静的な構成によって、または有効なルート証明書に再帰することができることのいずれかによって、互いの証明書を検証できることが必要です。サーバー側の認証では、クライアント側だけでは、クライアント側が証明書を提供しないように、サーバー側の証明書を検証することが可能です。このすべての結果は、SIPS URIは、TLS接続を確立するために使用されるときはいつでも、接続（クライアント）、サーバー側からの証明書を検証するための確立エンティティのことができると期待されていることです。サーバ側認証用に、[RFC5626]は推奨されるアプローチです。相互認証のために、一つはネットワークのアーキテクチャは、接続が互いの証明書へのアクセス権を持っているエンティティ間で行われるようなものであることを確認する必要があります。レコードルート[RFC3261]とパス[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が「許可されていませんSIPS」と381「必須SIPS」を登録します。警告コードは、次のように定義され、（ - コードを警告する）http://www.iana.orgから入手可能なSIPパラメータレジストリのサブレジストリ警告コードに含まれています。
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が許可されていない：UASまたはSIPSスキームが許可されていないので、プロキシが要求を処理できない（例えば、現在、登録さ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].
著者は、ジョン・ピーターソン、カレン・ジェニングス、ジョナサン・ローゼンバーグ、ジョンエルウェル、ポールKyzivat、エリックレスコラ、ロバート・スパークス、Rifaat Shekh・ユセフ、ピーターReissner、ティナツオウ、キース糖剤、ブライアンStucker、パトリック馬、ラヴィス周に感謝したいと思いますその慎重に検討し、入力のためのジョエル・ハルパーン、ヒシャムKarthabil、ディーンウィリス、エリック・トレンブレイ、ハンスPerssonの、そしてベン・キャンベル。 [RFC5626]の機微で私を助けるためローハンマーイに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ジェニングス、C.、RFC 5626、2009年10月 "セッション開始プロトコル（SIP）におけるクライアント開始された接続の管理"。
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[RFC2543]ハンドレー、M.、Schulzrinneと、H.、学生はE.、およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、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]ウィリス、D.とB. Hoeneisen、 "セッション開始プロトコル非隣接コンタクトを登録するための（SIP）拡張ヘッダーフィールド"、RFC 3327、2002年12月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]スパークス、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]ウィリス、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]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[RFC3891]マーイ、R.、ビッグス、B.、およびR.ディーン、 "セッション開始プロトコル（SIP） "は、" ヘッダ" を置き換えRFC 3891、2004年9月。
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[RFC3893]ピーターソン、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]マーイ、R.とD.ペトリー、 "セッション開始プロトコル（SIP）は、 "" ヘッダ"、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.
、RFC 4168、2005年10月 "セッション開始プロトコル（SIP）のためのトランスポートとしてストリーム制御伝送プロトコル（SCTP）" [RFC4168]ローゼンバーグ、J.、Schulzrinneと、H.、およびG.カマリロ、。
[RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005.
[RFC4244]バーンズ、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]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、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]ローゼンバーグ、J.、RFC 5627、2009年10月 "セッション開始プロトコル（SIP）でグローバルにルーティング可能なユーザエージェントのURI（GRUU）の取得と使用" を参照してください。
Appendix A. Bug Fixes for
付録A.バグ修正
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の第五段落の最後の文が置き換えられます：
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.
クライアントは、元のRequest-URIは、クライアントが自動的に要求を再試行してはいけません、その場合、SIPSスキームを使用しない限り、SIP URIを使用して、この時間は要求を再試行すべきです。
The fifth paragraph of Section 10.2.1 is replaced by:
10.2.1項の第五段落が置き換えられます：
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.
REGISTERリクエストのToヘッダーフィールドにおけるレコードのアドレスがSIPS URIの場合、UACはまた、要求だけで任意のContactヘッダーフィールド値にSIPS URIを含まなければなりません。
In Section 16.7 on p. 112 describing Record-Route, the second paragraph is deleted.
P上のセクション16.7で。レコードルートを記述112は、第二段落を削除します。
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とターゲットURIをSIPSで識別されるリソース間の各ホップで使用されることを、特に意味します。 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の第三段落では、最初の文の単語「セッション記述」は、「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.
要求のRequest-URIとして使用する場合（...）、SIPSスキームは、要求はTLSで保護されたRequest-URIによって識別されるリソースに到達するまで各ホップは、その上の要求が、転送されることを意味します。要求（これらはアドレス・オブ・レコードターゲットとして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の使用が真に要求パスの各セグメント上のエンド・ツー・エンドを尊重されることを保証することができません。多くのUA以来、着信TLS接続を受け付けないことに注意してください、TLSをサポートしていないものも含めUAは、UASとしてTLSを超える要求を受信するために、上記のTLS制限の項で説明したように持続的なTLS接続を維持する必要があります。
The first sentence of the third paragraph of Section 26.4.4 is replaced by the following:
セクション26.4.4の第三段落の最初の文は次のように置き換えます。
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の第四段落が削除されます。
The last sentence of the fifth paragraph of Section 26.4.4 is reworded as follows:
次のようにセクション26.4.4の第五の段落の最後の文を言い換えています：
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.
好ましくは、[RFC4474]もToヘッダーフィールドの元の形は、エンドツーエンドを担持していることを保証するために発信UACによって使用されてもよいS / MIMEまたは、。
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の第三段落に、「トランザクションの失敗はセッション記述プロトコル（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の第五節では、「390」を「380」に置き換えられ、「その他の警告は」「その他のSIP関連の警告」に置き換えられています。
Author's Address
著者のアドレス
Francois Audet Skype Labs
フランソワ・ヤフー研究所のいずれか
EMail: francois.audet@skypelabs.com
メールアドレス：francois.audet@skypelabs.com