Network Working Group A. Allen, Ed.
Request for Comments: 4964 Research in Motion (RIM)
Category: Informational J. Holm
Ericsson
T. Hallin
Motorola
September 2007
The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular
P-回答ステートヘッダー拡張セッション開始プロトコルに対する細胞上でトークするオープン・モバイル・アライアンスプッシュのために
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document describes a private Session Initiation Protocol (SIP) header (P-header) used by the Open Mobile Alliance (OMA) for Push to talk over Cellular (PoC) along with its applicability, which is limited to the OMA PoC application. The P-Answer-State header is used for indicating the answering mode of the handset, which is particular to the PoC application.
この文書は、OMA PoCアプリケーションに制限され、その適用性と共にセルラ（POC）上にプッシュツートークオープン・モバイル・アライアンス（OMA）によって使用されるプライベートセッション開始プロトコル（SIP）ヘッダ（P-ヘッダ）を記述する。 P-回答ステートヘッダは、PoCアプリケーションに特有のハンドセットの応答モードを示すために使用されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Overall Applicability ...........................................3
3. Terminology .....................................................3
4. Background for the Extension ....................................4
5. Overview ........................................................5
6. The P-Answer-State Header .......................................6
6.1. Requirements ...............................................8
6.2. Alternatives Considered ....................................8
6.3. Applicability Statement for the P-Answer-State Header ......9
6.4. Usage of the P-Answer-State Header ........................10
6.4.1. Procedures at the UA (Terminal) ....................11
6.4.2. Procedures at the UA (PTT Server) ..................11
6.4.3. Procedures at the Proxy Server .....................14
7. Formal Syntax ..................................................14
7.1. P-Answer-State Header Syntax ..............................14
7.2. Table of the New Header ...................................14
8. Example Usage Session Flows ....................................15
8.1. Pre-Arranged Group Call Using On-Demand Session ...........15
8.2. 1-1 Call Using Pre-Established Session ....................21
9. Security Considerations ........................................28
10. IANA Considerations ...........................................28
10.1. Registration of Header Fields ............................28
11. Acknowledgements ..............................................29
12. References ....................................................29
12.1. Normative References .....................................29
12.2. Informative References ...................................30
The Open Mobile Alliance (OMA) (http://www.openmobilealliance.org) is specifying the Push to talk Over Cellular (PoC) service where SIP is the protocol used to establish half-duplex media sessions across different participants. This document describes a private extension to address specific requirements of the PoC service and may not be applicable to the general Internet.
オープン・モバイル・アライアンス（OMA）（http://www.openmobilealliance.org）は、SIPプロトコルが異なる参加者の間で半二重メディアセッションを確立するために使用される携帯電話（POC）サービスをオーバープッシュツートークを指定しています。この文書では、PoCサービスの特定の要件に対処するために、民間の拡張について説明し、一般的なインターネットには適用できない場合があります。
The PoC service allows a SIP User Agent (UA) (PoC terminal) to establish a session to one or more SIP UAs simultaneously, usually initiated by the initiating user pushing a button.
PoCサービスは、SIPユーザエージェント（UA）（PoC端末）を同時に、通常のボタンを押して開始するユーザーによって開始された1つの以上のSIP UAはにセッションを確立することができます。
OMA has defined a collection of very stringent requirements in support of the PoC service. In order to provide the user with a satisfactory experience, the initial session establishment (from the time the user presses the button to the time they get an indication to speak) must be minimized.
OMAは、PoCサービスのサポートに非常に厳しい要件の集合を定義しています。十分な経験を持つユーザーを提供するために、最初のセッション確立最小限に抑えなければならない（時間からは、利用者は、彼らが話すように表示を取得する時にボタンを押します）。
The SIP extension specified in this document makes certain assumptions regarding network topology and the existence of transitive trust. These assumptions are generally NOT APPLICABLE in the Internet as a whole. The mechanism specified here was designed to satisfy the requirements specified by the Open Mobile Alliance for Push to talk over Cellular for which either no general-purpose solution was found, where insufficient operational experience was available to understand if a general solution is needed, or where a more general solution is not yet mature. For more details about the assumptions made about this extension, consult the applicability statement in section 6.3.
この文書で指定されたSIPの拡張機能は、ネットワークトポロジと推移的な信頼の有無について一定の仮定を行います。これらの仮定は、全体として、インターネットで一般的に適用されていません。ここで指定されたメカニズムは、一般的な解決策が必要な場合には不十分運用経験を理解するために利用した全く汎用ソリューションのいずれかが、見つからなかったために携帯電話を介して話をするプッシュオープン・モバイル・アライアンスによって指定された要件を満たすように設計された、またはどこましたより一般的な解決策はまだ成熟していないです。この拡張についての仮定の詳細については、セクション6.3の適用に関する声明を参照してください。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。
The terms "PTT Server" (Push to talk Server), "Unconfirmed Indication", "Unconfirmed Response", "Confirmed Indication", and "Confirmed Response" are introduced in this document.
用語「PTTサーバ」（サーバプッシュツートーク）、「未確認表示」、「未確認応答」、「確認表示」、および「確認応答」は、本文書で紹介されています。
A "PTT Server" as referred to here is a SIP network server that performs the network-based functions for the Push to talk service. The PTT Server can act as a SIP Proxy (as defined in [2]) or a back-
「PTTサーバ」ここでいうサービスをプッシュツートークのためのネットワーク・ベースの機能を実行SIPネットワークサーバです。 PTTサーバは、SIPプロキシ（[2]で定義されるように）、またはバックとして作用することができます
to-back UA (B2BUA) (as defined in [2]) based on the functions it needs to perform. There can be one or more PTT Servers involved in a SIP Push to talk session.
UA（B2BUA）逆に、それは実行する必要がある機能に基づいて、（[2]で定義されるように）。セッションの話をするSIPプッシュに関与する1台の以上のPTTサーバが存在する場合があります。
An "Unconfirmed Indication" as referred to here is an indication that the final target UA for the request has yet to be contacted and an intermediate SIP node is indicating that it has information that hints that the request is likely to be answered by the target UA.
ここでいう「未確認表示」が要求の最終目標UAはまだ接触しなければならないことを示すものであると中間SIPノードは、要求がターゲットUAによって応答する可能性があることをヒント情報を有することを示して。
An "Unconfirmed Response" is a SIP 18x or 2xx response containing an "Unconfirmed Indication".
「未確認応答」は「未確認指示」を含むSIP 18Xまたは2XX応答です。
A "Confirmed Indication" as referred to here is an indication that the target UA has accepted the session invitation and is ready to receive media.
ここでいう「確認表示」とは、標的UAは、セッション招待を受け入れ、メディアを受信する準備ができていることを示すものです。
A "Confirmed Response" is a SIP 200 (OK) response containing a "Confirmed Indication" and has the usual semantics of a SIP 200 (OK) response containing an answer (such as a Session Description Protocol (SDP) answer).
「確認応答」は「確認指示」を含むSIP 200（OK）応答であり、（例えば、セッション記述プロトコル（SDP）答えとして）回答を含むSIP 200（OK）応答の通常の意味を有します。
The PoC terminal could support such hardware capabilities as a speakerphone and/or headset and software that provide the capability for the user to configure the PoC terminal to accept the session invitations immediately and play out the media as soon as it is received without requiring the intervention of the called user. This mode of operation is known as Automatic Answer mode. The user can alternatively configure the PoC terminal to first alert the user and require the user to manually accept the session invitation before media is accepted. This mode of operation is known as Manual Answer mode. The PoC terminal could support both or only one of these modes of operation. The user can change the Answer Mode (AM) configuration of the PoC terminal frequently based on their current circumstances and preference (perhaps because the user is busy, or in a public area where she cannot use a speakerphone, etc.).
PoC端末はただちにセッションの招待を受け入れ、介入を必要とせずに、すぐにそれが受信されるように、メディアを再生するためにPoC端末を設定するには、ユーザのための機能を提供スピーカーフォンおよび/またはヘッドセットやソフトウェアなどのハードウェアの機能をサポートすることができましたユーザーの。この動作モードは自動応答モードとして知られています。ユーザは、代わりに最初のユーザーに警告し、メディアが受け入れられる前に、手動でセッション招待を受諾することをユーザに要求するPoC端末を構成することができます。この動作モードはマニュアル応答モードとして知られています。 PoC端末は、これらの動作モードの両方または一方のみをサポートすることができました。 PoC端末の応答モード（AM）の構成を変更することができ、ユーザが頻繁に彼らの現在の状況や好みに基づいて（ユーザがビジー、または彼女はスピーカーフォン、等を使用することができないパブリック領域にある恐らくため）。
The OMA PoC Architecture [3] utilizes PTT Servers within the network that can perform such roles as a conference focus [10], a real-time transport protocol (RTP) translator, or a network policy enforcement server. A possible optimization to minimize the delay in the providing of the caller with an indication to speak is for the PTT server to perform buffering of media packets in order to provide an early or "Unconfirmed Indication" back to the caller and allow the caller to start speaking before the called PoC terminal has answered. An event package and mechanisms for a SIP UA to indicate its current answer mode to a PTT Server in order to enable buffering are defined in [11]. In addition, particularly when multiple domains are involved in the session, more than one PTT Server could be involved in the signaling path for the session. Also, the PTT Server that performs the buffering might not be the PTT Server that has knowledge of the current answer mode of the SIP UA that is the final destination for the SIP INVITE request. A mechanism is defined in [12] that allows a terminal that acts as a SIP UA (or as a PTT Server that acts as a SIP UA) to indicate a preference to the final destination SIP User Agent Server (UAS) to answer in a particular mode. However, a mechanism is required for a PTT Server to relay the "Unconfirmed Indication" in a response back towards the originating SIP User Agent Client (UAC).
OMAのPoCアーキテクチャ[3]会議フォーカス[10]、リアルタイムトランスポートプロトコル（RTP）翻訳、またはネットワークポリシー強制サーバなどの役割を実行することができ、ネットワーク内のPTTサーバを利用します。 PTTサーバは、呼び出し元に、早期または「未確認表示」を提供するために、メディアパケットのバッファリングを行い、呼び出し元が開始できるようにするために話をする指示と共に、発信者の提供の遅延を最小限に抑えることができる最適化があります呼ばれるPoC端末の前に言えば答えました。バッファリングを可能にするために、PTTサーバへの現在の応答モードを示すために、SIP UAのイベントパッケージ及びメカニズムは[11]で定義されています。加えて、複数のドメインがセッションに関与している場合は特に、複数のPTTサーバは、セッションのシグナリング経路に関与し得ます。また、バッファリングを行い、PTTサーバは、SIP INVITEリクエストをため、最終的な宛先であるSIP UAの現在の応答モードの知識を持っているPTTサーバではないかもしれません。機構はAに答えるために、最終的な宛先SIPユーザエージェントサーバ（UAS）への好みを示すために、SIP UAとして（またはSIP UAとして動作するPTTサーバとして）作用する端子を可能にする[12]で定義されています特定のモード。しかし、メカニズムは、バック元のSIPユーザエージェントクライアント（UAC）への応答で「未確認表示」を中継するためにPTTサーバーに必要です。
The purpose of this extension is to support an optimization that makes it possible for the network to provide a faster push to talk experience, through an intermediate SIP user agent (PTT Server) providing a SIP 200 (OK) response before the called UA does, and a PTT Server buffering the media generated by the calling UA for replay to the called UA when it answers. Because of the half-duplex nature of the call, where media bursts are short typically in the order of 10-30 seconds, the additional end-to-end latency can be tolerated, and this considerably improves the user experience. However, the PTT Server only can do this when there is a high probability that the called SIP UA is in Automatic Answer mode. It is likely that PTT Servers near the called UA have up-to-date knowledge of the answering mode of the called UA, and due to the restricted bandwidth nature of the cellular network, they can pass upstream an indication of the called SIP UA's answering mode faster than the called UA can deliver an automatically generated SIP 200 (OK) response.
この拡張の目的は、ネットワークが中間SIPユーザエージェント（PTTサーバ）と呼ばれるUAが行う前に、SIP 200（OK）応答を提供を通じて、経験を話すより速くプッシュを提供することが可能となり、最適化をサポートすることです、そして、PTTサーバは、それが応答したときに呼び出されるUAにリプレイを呼びかけUAによって生成されたメディアをバッファリングします。メディアバーストは10〜30秒の順に、追加的なエンド・ツー・エンドの遅延が許容されることができる一般的に短く、これはかなりのユーザーエクスペリエンスを向上させ、コールの半二重的性質のため。呼ばれるSIP UAは、自動応答モードである確率が高いときしかし、PTTサーバは、これを行うことができます。呼ばれるUAの近くにPTTサーバーと呼ばれるUAの応答モードの最新の知識を持っている、とによるセルラーネットワークの帯域幅制限付き性質のために、彼らはと呼ばれるSIP UAの応答の表示を上流に渡すことができる可能性があります呼び出さUAより速いモードが自動的に生成されたSIP 200（OK）応答を送達することができます。
This document proposes a new SIP header field, the P-Answer-State header field to support an "Unconfirmed Indication". The new SIP header field can be optionally included in a response to a SIP INVITE request, or in a sipfrag of a response included in a SIP NOTIFY request sent as a result of a SIP REFER request that requests a SIP INVITE request to be sent. The header field is used to provide an indication from a PTT Server acting as a SIP proxy or back-to-back UA that it has information that hints that the terminating UA will likely answer automatically. This provides an "Unconfirmed Indication" back towards the inviting SIP UA to transmit media prior to receiving a final response from the final destination of the SIP INVITE request. No Supported or Require headers are needed because the sender of the P-Answer-State header field does not depend on the receiver to understand the extension. If the extension is not understood, the header field is simply ignored by the recipient. The extension is described below.
この文書では、「未確認表示」をサポートする新しいSIPヘッダフィールド、P-回答ステートヘッダフィールドを提案しています。新しいSIPヘッダフィールドは、必要に応じてSIPに応じて含めることができるINVITE要求、または応答のsipfragに送信されるSIP INVITEリクエストを要求するSIP REFER要求の結果として送信されるNOTIFYリクエストをSIPに含まれます。ヘッダフィールドは、それが終了するUAは、おそらく自動的に応答することがヒント情報を持っていることをUAにSIPプロキシとして動作するPTTサーバからの指示を提供するか、バック・ツー・バックするために使用されます。これは、従来INVITE要求をSIPの最終的な目的地から最終的な応答を受信するメディアを送信するためのバック招待するSIP UAに向かって「未確認表示」を提供します。 P-回答ステートヘッダフィールドの送信者が拡張を理解するために受信機に依存しないため、ノーサポートされているか、必要とヘッダが必要とされています。拡張が理解されていない場合、ヘッダフィールドは、単に受信者によって無視されます。拡張子は以下の通りです。
Thus, when a PTT Server forwards a SIP INVITE request and knows that the called UA is likely to be in Automatic Answer mode, it also generates a SIP 183 provisional response with a P-Answer-State header field with a parameter of "Unconfirmed" to signal to upstream PTT Servers that they can buffer the caller's media.
従って、PTTサーバが転送SIPのINVITEリクエストと呼ばれるUAが自動応答モードにある可能性が高いことを知っている場合、それはまた、「未確認」のパラメータを使用してP-回答ステートヘッダフィールドとSIP 183暫定応答を生成します彼らは、呼び出し元のメディアをバッファリングすることができPTTサーバーを上流へ信号を出力します。
A PTT Server that wishes to buffer the caller's media, upon seeing the provisional response with a P-Answer-State header field with a parameter of "Unconfirmed", absorbs it and generates a SIP 200 (OK) response for the caller's SIP UA with an appropriate answer.
「未確認」のパラメータを使用してP-回答ステートヘッダフィールドとの暫定的な応答を見る際に、発信者のメディアをバッファリングしたいPTTサーバは、それを吸収して呼び出し元のSIP UAのためのSIP 200（OK）レスポンスを生成します適切な答え。
When the called UA generates a SIP 200 (OK) response, the PTT Server that generated the provisional response with a P-Answer-State header field with a parameter "Unconfirmed" adds to the SIP 200 (OK) response a P-Answer-State header field with a parameter of "Confirmed". The SIP 200 (OK) response is absorbed by the PTT Server that is buffering the caller's media, as it has already generated a SIP 200 (OK) response. The buffering PTT Server then starts playing out the buffered media.
UAと呼ばれるが、SIP 200（OK）応答を生成する場合、パラメータ「未確認」とP-回答ステートヘッダフィールドと暫定応答を生成したPTTサーバは、SIP 200（OK）応答をP-Answer-に追加します「確認済み」のパラメータを持つ状態のヘッダフィールド。 SIP 200（OK）応答は、それがすでにSIP 200（OK）応答を生成しているように、呼び出し側のメディアをバッファリングされたPTTサーバに吸収されます。バッファリングPTTサーバは、緩衝媒体の再生を開始します。
The purpose of the P-Answer-State header field is to provide an indication from a PTT Server acting as a SIP proxy or back-to-back UA that it has information that hints that the terminating UA identified in the Request-URI of the request will likely answer automatically. Thus, it enables the PTT Server to provide an "Unconfirmed Indication" back towards the inviting SIP UA permitting it to transmit media prior to receiving a final response from the final destination of the SIP INVITE request. If a provisional response contains the P-Answer-State header field with the value "Unconfirmed" and does not contain an answer, then a receiving PTT Server can send a SIP 200 (OK) response containing an answer and a P-Answer-State header field with the value "Unconfirmed" if the PTT Server is willing to perform media buffering. If the response containing the P-Answer-State header field with the value "Unconfirmed" also contains an answer, the PTT Server that included the P-Answer-State header field and answer in the response is also indicating that it is willing to buffer the media until a final "Confirmed Indication" is received.
P-回答ステートヘッダフィールドの目的は、SIPプロキシとして動作するPTTサーバからの指示を提供するか、バック・ツー・バックUAが終了UAがRequest-URIの中で同定されたことをヒント情報を持っていることですリクエストは、おそらく自動的にお答えします。従って、PTTサーバは、INVITE要求をSIPの最終的な目的地から最終的な応答を受信する前にメディアを送信することを可能にする「未確認指示」バック招待SIP UAに向かって提供することができます。暫定的な応答は、値「未確認」とP-回答ステートヘッダフィールドを含み、答えが含まれていない場合、その後、受信PTTサーバは、回答とP-回答ステートを含むSIP 200（OK）応答を送信することができますPTTサーバは、メディアバッファリングを実行する意思がある場合、値「未確認」のヘッダフィールド。値「未確認」とP-回答ステートヘッダフィールドを含む応答はまた、答えが含まれている場合は、応答してP-回答ステートヘッダフィールドと答えが含まPTTサーバはまた、バッファリングする意思があることを示しています最後の「確認表示」までのメディアが受信されます。
The P-Answer-State header field can be included in a provisional or final response to a SIP INVITE request or in the sipfrag of a SIP NOTIFY request sent as a result of a SIP REFER request to send a SIP INVITE request. If the P-Answer-State header field with value "Unconfirmed" is included in a provisional response that contains an answer, the PTT Server is leaving the decision of where to do buffering to other PTT Servers upstream and will forward upstream a
P-回答ステートヘッダフィールドは、SIP INVITE要求を送信する要求を、SIP INVITEに仮または最終応答またはSIPリクエストをREFERの結果として送信されたSIP NOTIFY要求のsipfragに含めることができます。値が「未確認」とP-回答ステートヘッダフィールドは、解答が含まれている暫定応答に含まれている場合は、PTTサーバは、上流他のPTTサーバへのバッファリングを行う場所の決定を残しているし、上流に転送します
"Confirmed indication" in a SIP 200 (OK) response when the final response is received from the destination UA.
最終応答が宛先UAから受信されるSIP 200（OK）応答の「確認表示」。
NOTE It is not intended that multiple PTT Servers perform buffering serially. If a PTT Server includes an answer along with P-Answer-State header field with the value "Unconfirmed" in a provisional response, then a receiving PTT Server can determine whether it buffers the media or forwards the media and allows the downstrean PTT Server that sent the "Unconfirmed Indication" to buffer the media. It is intended that if a PTT Server buffers media, it does so until a final "Confirmed Indication" is received, and therefore serial buffering by multiple PTT Servers does not take place.
複数のPTTサーバは、シリアルバッファリングを行うことを意図するものではないことに注意してください。 PTTサーバは、暫定的な応答の値「未確認」とP-回答ステートヘッダフィールドと共に答えが含まれている場合、受信したPTTサーバは、メディアをバッファまたはメディアを転送し、downstrean PTTサーバーを許可するかどうかを決定することができますメディアをバッファリングするための「未確認表示」を送りました。 PTTサーバがメディアをバッファする場合、最終的な「確認指示」を受信するまで、それがそうすることを意図しているので、複数のPTTサーバによってシリアルバッファリングは行われません。
The P-Answer-State header is only included in a provisional response when the node that sends the response has knowledge that there is a PTT Server acting as a B2BUA that understands this extension in the signaling path between itself and the originating UAC. This PTT Server between the sending node and the originating UAC will only pass the header field on in either a SIP 200 (OK) response or in the sipfrag (as defined in [4]) of a SIP NOTIFY request (as defined in [5]) sent as a result of a SIP REFER request (as defined in [6]). Such a situation only occurs with specific network topologies, which is another reason why use of this header field is not relevant to the general Internet. The originating UAC will only receive the P-Answer-state header field in a SIP 200 (OK) response or in the sipfrag of a SIP NOTIFY request.
P-回答ステートヘッダのみ応答を送信するノードは、それ自体と発信UACとの間のシグナリング経路におけるこの拡張を理解B2BUAとして動作するPTTサーバがあるという知識を有している暫定的な応答に含まれています。送信ノードと発信UACとの間のこのPTTサーバは、[5で定義されたSIPの（NOTIFYリクエストを（[4]で定義されるように）のいずれかSIP 200（OK）応答してオンまたはsipfragのヘッダフィールドを通過しますで定義されている]）（SIPの結果として、REFERリクエストを送信された[6]）。このような状況は、唯一、このヘッダフィールドの使用は一般的なインターネットに関連していないもう一つの理由である、特定のネットワークトポロジで発生します。発信UACは、SIP 200（OK）応答のPアンサー状態ヘッダーフィールドを受信またはSIPのsipfragに要求を通知します。
Provisional responses containing the P-Answer-State header field can be sent reliably using the mechanism defined in [13], but this is not required. This is a performance optimization, and the impact of a provisional response sent unreliably (failing to arrive) is simply that buffering does not take place. However, if the provisional responses are sent reliably and the provisional response fails to arrive, the time taken for the provisional response sender to time out on the receipt of a SIP PRACK request is likely to be such that, by the time the provisional response has been resent, the "Confirmed Response" could have already been received. When provisional responses that contain an answer are sent reliably, the 200 (OK) response for the SIP INVITE request cannot be sent before the SIP PRACK request is received. Therefore, sending provisional responses reliably could potentially delay the sending of the "Confirmed Response".
P-回答ステートヘッダフィールドを含む暫定応答が[13]で定義されたメカニズムを使用して確実に送信することができるが、これは必須ではありません。これは、パフォーマンスの最適化で、（到着に失敗）不確かに送られた暫定応答の影響は、バッファリングが行われないということだけです。暫定応答が確実に送信され、暫定応答が到着しなかった場合は、SIP PRACK要求の受信時にタイムアウトに暫定応答の送信者にかかる時間は、時間によって暫定応答があり、なるようになる可能性があります再送して、「確認応答」は、既に受信されている可能性があります。答えを含む暫定応答が確実に送信されると、SIP PRACK要求を受信する前に、INVITE要求をSIP 200（OK）応答を送信することができません。そのため、確実に暫定応答を送信することは、潜在的に「確認応答」の送信を遅らせることができます。
The OMA PoC service has initial setup performance requirements that can be met by a PTT Server acting as a B2BUA spooling media from the inviting PoC subscriber until one or more invited PoC subscribers have accepted the session. The specific requirements are:
OMA PoCサービスは、一つ以上の招待のPoC加入者まで、PTTサーバは、招待のPoC加入者からB2BUAスプールメディアとして作用することによって満たすことができる初期セットアップ性能要件は、セッションを受け入れたしました。具体的な要件は次のとおりです。
REQ-1: An intermediate server MAY spool media from the inviting SIP UA until one or more invited PoC SIP UASs has accepted the invitation.
REQ-1：中間サーバ一つ以上のPoC SIPのUASが招待を受け入れた招待するまで招待SIP UAからメディアをスプールするかもしれません。
REQ-2: An intermediate server that is capable of spooling media MAY accept a SIP INVITE request from an inviting SIP UAC even if no invited SIP UAS has accepted the SIP INVITE request if it has a hint that the invited SIP UAS is likely to accept the request without requiring user intervention.
REQ-2：何の招待SIP UASはそれが招待SIP UASが受け入れる可能性が高いことをヒントを持っている場合、SIP INVITE要求を受け入れなかった場合でも、SIPは、招待SIP UACからのINVITEリクエストを受け入れるかもしれメディアをスプールすることができ、中間サーバユーザーの介入を必要とせずに要求。
REQ-3: An intermediate server or proxy that is incapable of spooling media or does not wish to, but has a hint that the invited SIP UAS is likely to automatically accept the session invitation, MUST be able to indicate back to another intermediate server that can spool media that it has some hint that the invited UAS is likely to automatically accept the session invitation.
REQ-3：スプールメディアが不可能であるかを希望しませんが、招待SIP UASは自動的にセッション招待を受諾する可能性があるというヒントを持っている中間サーバまたはプロキシは、他の中間サーバに戻って示すことができなければならないことそれは招待UASが自動的にセッション招待を受諾する可能性があることを、いくつかのヒントを持っているメディアをスプールすることができます。
REQ-4: An intermediate server that is willing to spool media from the inviting SIP UAC until one or more invited SIP UASs have accepted the SIP INVITE request SHOULD indicate that it is spooling media to the inviting SIP UAC.
REQ-4：1以上の招待SIPのUASまで招待SIP UACからメディアをスプールしていく所存です中間サーバ、SIP INVITE要求を受け入れているが、それは魅力的なSIPのUACにメディアをスプールしていることを示す必要があります。
In order to meet REQ-3, a PTT Server needs to receive an indication back that the invited SIP UA is likely to accept the SIP INVITE request without requiring user intervention. In this case, the PTT Server that has a hint that the invited SIP UAC is likely to accept the request can include an answer state indication in the SIP 183 (Session Progress) response or SIP 200 (OK) response.
REQ-3を満たすために、PTTサーバは、招待SIP UAは、SIPは、ユーザーの介入を必要とせずに、INVITE要求を受け取りやすいバックという指示を受信する必要があります。この場合、招待SIP UACが要求を受け入れる可能性があるというヒントを持っているPTTサーバは、SIP 183（セッションの進捗状況）応答またはSIP 200（OK）応答で答え状態表示を含めることができます。
A number of alternatives were considered for the PTT Server to inform another PTT Server or the inviting SIP UAC of the invited PoC SIP UAS's answer mode settings.
選択肢の数は、他のPTTサーバや魅力的なSIP招待のPoC SIP UASの応答モード設定のUACを通知するPTTサーバー用に考えられました。
One proposal was to create a unique reason-phrase in the SIP 183 response and SIP 200 (OK) response. This was rejected because the reason phrases are normally intended for human readers and not meant to be parsed by servers for special syntactic and semantic meaning.
一つの提案は、SIP 183応答およびSIP 200（OK）応答にユニークな理由フレーズを作成することでした。理由句は、通常、人間の読者を対象としており、特別な構文と意味の意味については、サーバによって解析されたことを意味するものではないので、これが拒否されました。
Another proposal was to use a Reason header [14] in the SIP 183 response and SIP 200 (OK) response. This was rejected because this would be inconsistent with the intended use of the Reason header and its usage is not defined for these response codes and would have required creating and registering a new protocol identifier.
別の提案は、SIP 183応答およびSIP 200（OK）応答でReasonヘッダ[14]を使用することでした。これは、ヘッダとその使用は、これらの応答コードのために定義されておらず、新たなプロトコル識別子を作成し、登録する必要だろう理由の用途と矛盾することになるため、これは拒否されました。
Another proposal was to use a feature-tag in the returned Contact header as defined in [15]. This was rejected because it was not a different feature, but is an attribute of the session and can be applied to many different features.
別の提案は[15]で定義されるように返さContactヘッダに特徴タグを使用することでした。これは、さまざまな機能がありませんでしたので拒否が、セッションの属性であり、多くの異なる特徴に適用することができました。
Another proposal was to use a new SDP attribute. The choice of an SDP parameter was rejected because the answer state applies to the session and not to a media stream.
別の提案は、新しいSDP属性を使用することでした。答状態はメディアストリームへのセッションに適用されていないので、SDPパラメータの選択が拒否されました。
The P-Answer-State header was chosen to give additional information about the state of the SIP session progress and acceptance. Even though the UAC sees that its offer has been answered and accepted, the header lets the UAC know whether the invited PoC subscriber or just an intermediary has accepted the SIP INVITE request.
P-回答ステート・ヘッダは、SIPセッションの進行状況と受け入れの状態に関する追加情報を与えるように選択しました。 UACは、そのオファーが答えて受理されたことを見ているにもかかわらず、ヘッダは、UACは、招待のPoC加入者または単に仲介がSIP INVITEリクエストを受け入れているかどうかを知ることができます。
The P-Answer-State header is applicable in the following circumstances:
P-回答ステートヘッダは、次の状況に適用可能です。
o In networks where there are UAs that engage in half-duplex communication where there is not the possibility for the invited user to verbally acknowledge the answering of the session as is normal in full-duplex communication;
O全二重通信に正常であるように口頭でセッションの応答を確認するために招待されたユーザーの可能性がない半二重通信に従事するのUAが存在するネットワークにおいて、
o Where the invited UA can automatically accept the session without user intervention;
O招待UAは自動的にユーザーの介入なしでセッションを受け入れることができますどこに。
o The network also contains intermediate network SIP servers that are trusted;
Oネットワークも信頼されている中間ネットワークのSIPサーバが含まれています。
o The intermediate network SIP servers have knowledge of the current answer mode setting of the terminating UAS; and,
中間ネットワークoをSIPサーバは、終端UASの現在の応答モード設定の知識を持っています。そして、
o The intermediate network SIP servers have knowledge of the media types and codecs likely to be accepted by the terminating UAS; and,
中間ネットワークoをSIPサーバは終了UASに受け入れられる可能性が高いメディアタイプとコーデックの知識を持っています。そして、
o The intermediate network SIP servers can provide buffering of the media in order to reduce the time for the inviting user to send media.
oを中間ネットワークのSIPサーバは、メディアを送信するために魅力的なユーザーのための時間を短縮するために、メディアのバッファリングを提供することができます。
o The intermediate network SIP servers assume knowledge of the network topology and the existence of similar intermediate network SIP servers in the signaling path.
中間ネットワークoをSIPサーバは、ネットワークトポロジの知識とシグナリングパスに類似の中間ネットワークSIPサーバーの存在を前提としています。
Such configurations are generally not applicable to the Internet as a whole where such trust relationships do not exist.
このような構成は、一般的に、このような信頼関係が存在しない、インターネット全体には適用されません。
In addition, security issues have only been considered for networks that are trusted and use hop-by-hop security mechanisms with transitive trust. Security issues with usage of this mechanism in the general Internet have not been evaluated.
また、セキュリティ上の問題は、信頼できると推移的な信頼とホップバイホップのセキュリティ・メカニズムを使用しているネットワークのために考えられてきました。一般的なインターネットでのこのメカニズムの利用とセキュリティの問題が評価されていません。
A UAS, B2BUA, or proxy MAY include a P-Answer-State header field in any SIP 18x or 2xx response that does not contain an offer, sent in response to an offer contained in a SIP INVITE request as specified in [7]. Typically, the P-Answer-State header field is included in either a SIP 183 Session Progress or a SIP 200 (OK) response. A UA that receives a SIP REFER request to send a SIP INVITE request MAY also include a P-Answer-State header field in the sipfrag of a response included in a SIP NOTIFY request it sends as a result of the implicit subscription created by the SIP REFER request.
UAS、B2BUA又はプロキシは、[7]で指定されるようにINVITE要求をSIPに含まれるオファーに応答して送信されたオファーを含まない任意のSIP 18Xまたは2XX応答してP-回答ステートヘッダフィールドを含んでいてもよいです。典型的には、P-回答ステートヘッダフィールドは、SIP 183のセッションプログレス又はSIP 200（OK）応答のいずれかに含まれています。 SIPは、SIP INVITE要求を送信する要求をREFER受信UAはまた、SIPに含まれる応答のsipfragにP-回答ステートヘッダフィールドを含んでいてもよいことはSIPにより作成された暗黙的加入の結果として送信要求NOTIFY要求を参照してください。
When the P-Answer-State header field contains the parameter "Unconfirmed", the UAS or proxy is indicating that it has information that hints that the final destination UAS for the SIP INVITE request is likely to automatically accept the session, but that this is unconfirmed and it is possible that the final destination UAS will first alert the user and require manual acceptance of the session or not accept the session request. When the P-Answer-State header field contains the parameter "Confirmed", the UAS or proxy is indicating that the destination UAS has accepted the session and is ready to receive media. The parameter value of "Confirmed" has the usual semantics of a SIP 200 (OK) response containing an answer and is included for completeness. A parameter value of "Confirmed" is only included in a SIP 200 (OK) response or in the sipfrag of a 200 (OK) contained in the body of a SIP NOTIFY request.
P-回答ステートヘッダフィールドは、パラメータ「未確認」が含まれている場合、UASまたはプロキシは、SIPのための最終的な宛先UAS要求が自動的にセッションを受け入れやすいINVITEことヒント情報を有することを示しているが、これはあること未確認と最終目的地UASは最初にユーザーに警告し、セッションを手動で承認を必要とするか、またはセッション要求を受け入れないだろうということが可能です。 P-回答ステートヘッダフィールドが「確認」パラメータを含む場合、UASまたはプロキシは、宛先UASがセッションを受け入れ、メディアを受信する準備ができたことを示しています。 「確認済み」のパラメータ値は、答えを含むSIP 200（OK）応答の通常の意味を持ち、完全を期すために含まれています。 「確認」のパラメータ値のみSIP 200（OK）応答または200のsipfragに含まれている（OK）NOTIFYリクエストをSIPのボディに含まれます。
A received SIP 18x response without a P-Answer-State header field SHOULD NOT be treated as an "Unconfirmed Response". A SIP 18x response containing a P-Answer-State header field containing the parameter "Confirmed" MUST NOT be treated as a "Confirmed Response" because this is an invalid condition.
P-回答ステートヘッダフィールドなしで受信されたSIP 18X応答「は未確認応答」として扱われるべきではありません。これは無効な状態であるため、「確認応答」として扱われてはいけません「確認」パラメータを含むP-回答ステートヘッダフィールドを含むSIP 18X応答。
A SIP 200 (OK) response without a P-Answer-State Header field MUST be treated as a "Confirmed Response".
P-回答ステートヘッダフィールドのないSIP 200（OK）応答は「確認応答」として扱わなければなりません。
A UAC (terminal) that receives an "Unconfirmed Response" containing an answer MAY send media as specified in [7]; however, there is no guarantee that the media will be received by the final recipient.
[7]で指定されたメディアを送信することができる答えを含む「未確認応答」を受信するUAC（端子）しかし、メディアは、最終的な受信者によって受信される保証はありません。
How a UAC confirms whether or not the media was received by the final destination when it has received a SIP 2xx response containing an "Unconfirmed Indication" is application specific and outside of the scope of this document. If the application is a conference then the mechanism specified in [7] could be used to determine that the invited user joined. Alternatively, a SIP BYE request could be received or the media could be placed on hold if the final destination UAS does not accept the session.
UACは、それが「未確認指示」を含むSIPの2xx応答を受信したときにメディアが最終的な宛先によって受信されたか否かを確認する方法を、この文書の範囲の特定と外部アプリケーションがあります。アプリケーションが会議である場合、[7]に指定されたメカニズムは、招待されたユーザーが参加することを決定するために使用することができます。あるいは、SIP BYE要求を受信することができ、または、最終的な宛先UASがセッションを受け入れない場合はメディアが保留にすることができます。
A UAC (terminal) that receives, in response to a SIP REFER request, a SIP NOTIFY request containing an "Unconfirmed Response" in a sipfrag in the body of the SIP NOTIFY request related to a dialog for which there has been a successful offer-answer exchange according to [5] MAY send media. However, there is no guarantee that the media will be received by the final recipient that was indicated in the Refer-To header in the original SIP REFER request. The dialog could be related either because the SIP REFER request was sent on the same dialog or because the SIP REFER request contained a Target-Dialog header, as defined in [16], that identified the dialog.
SIPは、SIPの体内のsipfragの「未確認応答」を含む要求をNOTIFY、REFERリクエストをSIPに応答して、受信したUAC（端末）が成功したオファーがされたダイアログに関連する要求をNOTIFY [5]によると答え交換がメディアを送信することができます。しかし、メディアが参照、元のSIPヘッダREFER要求に示された最終的な受信者によって受信される保証はありません。ダイアログが関連することができるいずれかのSIP要求が同じダイアログ上で送信またはSIPを参照するためのダイアログを同定している、[16]で定義されるように要求は、ターゲット対話ヘッダを含んでいたためREFER。
A UAC (terminal) that receives an "Unconfirmed Response" that does not contain an answer MAY buffer media until it receives another "Unconfirmed Response" containing an answer or a "Confirmed Response".
それが答えたり、「確認応答」を含む別の「未確認応答」を受信するまでメディアをバッファリングすることができる答えが含まれていない「未確認応答」を受信UAC（ターミナル）。
There are no P-Answer-State procedures for a terminal acting in the UAS role.
UASの役割で行動し、端末にはP-回答ステート手順はありません。
A PTT Server that receives a SIP INVITE request at the UAS part of its back-to-back UA MAY include, in any SIP 18x or 2xx response that does not contain an offer, a P-Answer-State header field with the parameter "Unconfirmed" in the response if it has not yet received a "Confirmed Response" from the final destination UA, and it has information that hints that the final destination UA for the SIP INVITE request is likely to automatically accept the session.
SIPは、そのバックツーバックUAのUAS部にINVITEリクエストを受信するPTTサーバは、「パラメータと、オファーが含まれていない任意のSIP 18Xまたは2XX応答して、P-回答ステートヘッダフィールドを含んでいてもよいです最終目的地UAからの確認応答 『「それはまだ受け取っていない場合に応じて』、そして、それはSIPのための最終的な目的地UAは、リクエストが自動的にセッションを受け取りやすいINVITEというヒント情報を持っている未確認。
A PTT Server that receives a SIP 18x response to a SIP INVITE request containing a P-Answer-State header field with the parameter "Unconfirmed" at the UAC part of its back-to-back UA MAY include the P-Answer-State header field with the parameter "Unconfirmed" in a SIP
SIPにSIP 18X応答を受信したPTTサーバは、バックツーバックUAのUAC部にパラメータ「未確認」とP-回答ステートヘッダーフィールドを含む要求はP-回答ステートヘッダを含むかもしれINVITE SIPにおけるパラメータ「未確認」とのフィールド
2xx response that the UAS part of its back-to-back UA sends as a result of receiving that response. Otherwise, a PTT Server that receives a SIP 18x or 2xx response to a SIP INVITE request containing a P-Answer-State header field at the UAC part of its back-to-back UA SHOULD include the P-Answer-State header field unmodified in the SIP 18x or 2xx response that the UAS part of its back-to-back UA sends as a result of receiving that response. If the response sent by the UAS part of its back-to-back UA is a SIP 18x response, then the P-Answer-State header field included in the response MUST contain a parameter of "Unconfirmed".
その背中合わせのUAのUAS部分がその応答を受信した結果として送信することを2XX応答。そうでなければ、その背中合わせのUAのUAC部にP-回答ステートヘッダーフィールドを含むINVITE要求をSIPにSIP 18Xまたは2XX応答を受信したPTTサーバーは、非修飾P-回答ステートヘッダフィールドを含むべきですSIP 18Xまたは2XX応答してその背中合わせのUAのUASの一部は、その応答を受信した結果として送信します。その背中合わせのUAのUAS部によって送信された応答がSIP 18X応答である場合には、P-回答ステートヘッダフィールドは「未確認」のパラメータを含まなければなりません応答に含まれます。
The UAS part of the back-to-back UA of a PTT Server MAY include an answer in the "Unconfirmed Response" it sends even if the "Unconfirmed Response" received by the UAC part of the back-to-back UA did not contain an answer.
PTTサーバのバックツーバックUAのUASの一部は、「未確認応答」バックツーバックのUAC部で受信した「未確認応答は」UA含まれていなかった場合でも、それは送信中に答えを含んでもよい（MAY）答え。
If a PTT Server receives a "Confirmed Response" at the UAC part of its back-to-back UA, then the UAS part of its back-to-back UA MAY include in the forwarded response a P-Answer-State header field with the parameter "Confirmed". If the UAS part of its back-to-back UA previously sent an "Unconfirmed Response" as part of this dialog, the UAS part of its back-to-back UA SHOULD include in the forwarded "Confirmed Response" a P-Answer-State header field with the parameter "Confirmed".
PTTサーバは、そのバックツーバックUAのUAC部に「確認応答」を受信した場合、そのバックツーバックUAのUAS部分が有する転送応答してP-回答ステートヘッダフィールドを含んでいてもよいですパラメータは、「確認しました」。そのバックツーバックUAのUASの一部は、以前にこのダイアログの一環として、「未確認応答」を送信した場合、そのバックツーバックのUASの一部は、UAは、P-Answer-転送「確認応答」に含めるべきです「確認」パラメータを使用している状態のヘッダフィールド。
If the UAS part of the back-to-back UA of a PTT Server includes an answer in a response along with a P-Answer-State header field with the parameter "Unconfirmed", then the UAS part of its back-to-back UA needs to be ready to receive media as specified in [7]. Also, it MAY buffer any media it receives until it receives a "Confirmed Response" from the final destination UA or until its buffer is full.
PTTサーバのバックツーバックUAのUAS部は、パラメータのバック・ツー・バックの「未確認」、次いでUAS部分とP-回答ステートヘッダフィールドと共に応答における答えが含まれている場合UAは、[7]で指定されたメディアを受信する準備ができている必要があります。また、それが最終目的地UAからか、そのバッファがいっぱいになるまで、「確認応答」を受信するまで、それが受信する任意のメディアをバッファリングすることができます。
A UAS part of the back-to-back UA of a PTT Server that receives a SIP REFER request to send a SIP INVITE request to another UA, as specified in [6], MAY generate a sipfrag of a SIP 200 (OK) response containing a P-Answer-State header field with the parameter "Unconfirmed" prior to the UAC part of its back-to-back UA receiving a response to the SIP INVITE request, if it has information that hints that the final destination UA for the SIP INVITE request is likely to automatically accept the session.
SIPは、で指定されるように、別のUAにSIP INVITE要求を送信する要求をREFER受信PTTサーバーのバックツーバックUAのUAS部[6]、SIP 200（OK）応答のsipfragを生成MAYそれがヒント情報を持っている場合、SIP INVITE要求に対する応答を受信し、そのバックツーバックUAのUAC部に先立っパラメータ「未確認」とP-回答ステートヘッダフィールドを含むそのための最終的な宛先UA SIP INVITE要求すると、自動的にセッションを受け入れる可能性があります。
If the UAC part of a back-to-back UA of a PTT Server sent a SIP INVITE request as a result of receiving a SIP REFER Request, receives a SIP 18x or 2xx response containing a P-Answer-State header field at the UAC part of its back-to-back UA, then the UAS part of its back-to-back UA SHOULD include the P-Answer-State header field in the sipfrag of the response contained in a SIP NOTIFY request. The P-Answer-State header field that is contained in the sipfrag, contains the parameters from the P-Answer-State from the original response unmodified. This SIP NOTIFY request is the SIP NOTIFY request that the UAS part of the back-to-back UA of the PTT Server sends in response to the original SIP REFER request based upon receiving the SIP 18x or 2xx response. If the sipfrag of the response sent in the SIP NOTIFY request is a SIP 18x response, then the P-Answer-State header field included in the sipfrag of the response MUST contain a parameter of "Unconfirmed". If the UAC part of its back-to-back UA receives a "Confirmed Response" that does not contain a P-Answer-State header field, then the UAS part of its back-to-back UA MAY include a P-Answer-State header field with the parameter "Confirmed" in the sipfrag of the response contained in a SIP NOTIFY request sent in response to the SIP REFER request.
PTTサーバのバックツーバックUAのUAC部はSIPを送信した場合、SIP要求をREFER受信した結果としてINVITEリクエストを、UACにP-回答ステートヘッダフィールドを含むSIP 18Xまたは2XX応答を受信しますその背中合わせのUA、その背中合わせのUAの次にUAS部分の一部は、SIP NOTIFYリクエストに含まれる応答のsipfragにP-回答ステートヘッダフィールドを含むべきです。 sipfragに含まれるP-回答ステートヘッダフィールドは、修飾されていない元の応答のP-回答ステートからパラメータを含んでいます。このSIP NOTIFYリクエストは、SIPはPTTサーバのバックツーバックUAのUAS部分がSIP 18Xまたは2XX応答を受信に基づいて、元のSIP REFER要求に応じて送信要求をNOTIFYあります。 SIPに送信された応答のsipfrag要求がSIP 18X応答であるNOTIFY場合、P-回答ステートヘッダフィールドは、応答のsipfragに含まれる「未確認」のパラメータを含まなければなりません。そのバックツーバックUAのUACの一部は、P-回答ステートヘッダフィールドが含まれていない「確認応答」を受信した場合、そのバックツーバックUAのUASの一部は、P-Answer-を含んでもよい（MAY）パラメータと状態ヘッダーフィールドSIPに応答して送信されるSIP NOTIFY要求に含まれる応答のsipfragの「確認済み」リクエスト参照。
In the case where a PTT Server that's UAS part of its back-to-back UA previously sent a SIP NOTIFY request as a result of the SIP REFER request:
UAS PTTサーバの場合には、その背中合わせのUAの一部は、以前にSIP要求をSIP REFERの結果としてNOTIFYリクエストを送信しました：
1) the SIP NOTIFY request contains a P-Answer-State header field with the parameter "Unconfirmed" in the sipfrag of a response, and
1）SIP NOTIFYリクエストは、応答のsipfragに「未確認」パラメータを使用してP-回答ステートヘッダフィールドを含む、および
2) the PTT Server subsequently receives at the UAC part of its back-to-back UA a "Confirmed Response" to the SIP INVITE request.
2）PTTサーバは、その後、バックツーバックUAのUACの一部でSIPに「確認応答」INVITEリクエストを受け取ります。
Such a PTT Server SHOULD include a P-Answer-State header field with the parameter "Confirmed" in the sipfrag of the response included in the subsequent SIP NOTIFY request that the UAS part of its back-to-back UA sends as a result of receiving the "Confirmed Response".
そのようなPTTサーバは、後続のSIPに含まれる応答のsipfragにその背中合わせのUAのUAS部分が結果として送信するNOTIFYリクエストを「確認済み」パラメータを使用してP-回答ステートヘッダフィールドを含むべきです「確認応答」を受信します。
If the SIP REFER request is related to an existing dialog established by a SIP INVITE request for which there has been a successful offer-answer exchange, the UAS part of its back-to-back UA MUST be ready to receive media as specified in [7]. Also, it MAY buffer any media it receives until the UAC part of its back-to-back UA receives a "Confirmed Response" from the final destination UA or until its buffer is full. The dialog could be related either because the SIP REFER request was sent on the same dialog or because the SIP REFER request contained a Target-Dialog header, as defined in [16], that identified the dialog.
SIPは、要求が成功したオファーアンサー交換がされたSIP INVITE要求によって確立された既存のダイアログに関連して参照する場合に指定されているように、そのバックツーバックのUASの一部は、UAは、[メディアを受信する準備ができなければならない（MUST） 7]。また、それはバックツーバックUAのUAC部分が最終的な宛先UAから、またはそのバッファがいっぱいになるまで、「確認応答」を受信するまで、受信したメディアをバッファリングすることができます。ダイアログが関連することができるいずれかのSIP要求が同じダイアログ上で送信またはSIPを参照するためのダイアログを同定している、[16]で定義されるように要求は、ターゲット対話ヘッダを含んでいたためREFER。
A PTT Server that buffers media SHOULD be prepared for the possibility of not receiving a "Confirmed Response" and SHOULD release the session if a "Confirmed Response" is not received before the buffer overflows.
メディアをバッファPTTサーバは「確認応答」を受信しない可能性のために準備されるべきであると、「確認応答は、」バッファオーバーフローの前に受信されない場合は、セッションを解放する必要があります。
SIP proxy servers do not need to understand the semantics of the P-Answer-State header field. As part of the regular SIP rules for unknown headers, a proxy will forward unknown headers.
SIPプロキシサーバは、P-回答ステートヘッダフィールドの意味を理解する必要はありません。未知のヘッダの定期的なSIPルールの一環として、プロキシは、未知のヘッダを転送します。
A PTT Server that acts as a proxy MAY include a P-Answer-State header field with the parameter "Unconfirmed" in a SIP 18x response that it originates (in a manner compliant with [2]) if it has information that hints that the final destination UA for the SIP INVITE request is likely to automatically accept the session.
プロキシとして機能PTTサーバは、それがヒント情報を有する場合、それは（を[2]に準拠した方法で）発信ことSIP 18X応答して、パラメータ「未確認」とP-回答ステートヘッダフィールドを含んでいてもよいですUAは、SIPのためのINVITEリクエストを最終目的地は、自動的にセッションを受け入れる可能性があります。
A PTT Server that acts as a proxy MAY add a P-Answer-State header field with the parameter "Confirmed" to a "Confirmed Response".
プロキシとして機能PTTサーバは「確認応答」を「確認済み」パラメータでP-回答ステートヘッダーフィールドを追加するかもしれません。
The mechanisms specified in this document is described in both prose and an augmented Backus-Naur Form (BNF) defined in [8]. Further, several BNF definitions are inherited from SIP and are not repeated here. Implementers need to be familiar with the notation and contents of SIP [2] and [8] to understand this document.
本書で指定されたメカニズムは、散文と[8]で定義された拡張バッカスナウア記法（BNF）の両方に記載されています。さらに、いくつかのBNFの定義は、SIPから継承されており、ここでは繰り返しません。実装は、SIPの表記と内容に精通している必要がある[2]、[8]この文書を理解します。
The syntax of the P-Answer-State header is described as follows:
次のようにP-応答ステート・ヘッダの構文を説明します。
P-Answer-State = "P-Answer-State" HCOLON answer-type *(SEMI generic-param) answer-type = "Confirmed" / "Unconfirmed" / token
P-回答ステート= "P-回答ステート" HCOLONの解答型*（SEMIジェネリック-のparam）答型= "確認" / "未確認" /トークン
Table 1 provides the additional table entries for the P-Answer-State header needed to extend Table 2 in SIP [2], section 7.1 of the SIP-specific event notification [5], Tables 1 and 2 in the SIP INFO method [17], Tables 1 and 2 in Reliability of provisional responses in SIP [13], Tables 1 and 2 in the SIP UPDATE method [18], Tables 1 and 2 in the SIP extension for Instant Messaging [19], Table 1 in the SIP REFER method [6], and Table 2 in the SIP PUBLISH method [20]:
表1は、SIPの表2を拡張するために必要なP-回答ステートヘッダーの追加のテーブルエントリを提供する[2]、SIP INFO方式でSIP固有のイベント通知[5]、表1及び表2のセクション7.1 [17 ]、インスタントメッセージングのためのSIP拡張における表1およびSIPにおける暫定応答の信頼性が2 [13]、表1および表2のSIP UPDATEメソッドに[18]、表1及び2 [19]、SIP表1方法[20] PUBLISH SIP方法、[6]、および表2を参照してください。
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Answer-State 18x,2xx ar - - - o - - -
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Answer-State R - - - - - - -
Table 1: Additional Table Entries for the P-Answer-State Header
表1：P-回答ステートヘッダーのための追加のテーブルエントリ
For simplicity, some details such as intermediate proxies and SIP 100 Trying responses are not shown in the following example flows.
簡単にするために、このような中間プロキシ及びSIP 100試行応答などのいくつかの詳細は、以下の例のフローには示されていません。
The following flow shows Alice making a pre-arranged group call using a Conference URI which has Bob on the member list. The session initiation uses the on-demand session establishment mechanism where a SIP INVITE request containing an SDP offer is sent by Alice's terminal when Alice pushes her push to talk button.
以下のフローは、アリスがメンバーリストにボブを有する会議URIを使用して事前配置グループ通話を行うことを示しています。セッション開始は、アリスがボタンを話をする彼女のプッシュを押すとSIPがアリスの端末によって送信されたSDPのオファーを含むINVITEリクエストをオンデマンドセッション確立メカニズムを使用しています。
In this example, Alice's PTT Server acts a Call Stateful SIP Proxy and Bob's PTT Server (which is aware that the current Answer Mode setting of Bob's terminal is set to Auto Answer) acts as a B2BUA.
この例では、アリスのPTTサーバは、コールステートフルSIPプロキシとして作用し、（ボブの端末の現在の応答モード設定が自動応答に設定されていることを認識している）ボブのPTTサーバは、B2BUAとして機能します。
For simplicity, the invitations by the Conference Focus to the other members of the group are not shown in this example.
簡単にするために、グループの他のメンバーに会議Focus社の招待状は、この例には示されていません。
Alice's Alice's Conference Bob's Bob's
Terminal PTT Server Focus PTT Server Terminal
| | | | |
|--(1)INVITE-->| | | |
| |--(2)INVITE-->| | |
| | |--(3)INVITE->| |
| | | |--(4)INVITE-->|
| | |<--(5)183----| |
| |<---(6)200----| | |
|<---(7)200----| | | |
|----(8)ACK--->| | | |
| |---(9)ACK---->| | |
| | | | |
|=====Early Media Session====>| | |
| | MEDIA | |
| | BUFFERING | |
| | | |<---(10)200---|
| | | |---(11)ACK--->|
| | |<--(12)200---| |
| | |--(13)ACK--->| |
| | | | |
| | |========Media Session======>|
| | | | |
| | | | |
Figure 1: Pre-Arranged Group Call Using On-Demand Session
図1：On-Demandセッションを使用して事前に決められたグループコール
1 INVITE Alice -> Alice's PTT Server
1アリスのINVITE - >アリスのPTTサーバ
INVITE sip:FriendsOfAlice@example.org SIP/2.0 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 Max-Forwards: 70 To: "Alice's Friends" <sip:FriendsOfAlice@example.org> From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.example.org> Content-Type: application/sdp Content-Length: 142
SIPのINVITE：FriendsOfAlice@example.org SIP / 2.0経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds8マックス・フォワード：70： "アリスさんの友達" <一口：FriendsOfAlice@example.org>から： "アリス」<一口：alice@example.org>;タグ= 1928301774のCall-ID：a84b4c76e66710のCSeq：<SIP：alice@pc33.example.org>のContent-Type：アプリケーション/ SDPのContent-Length：142 314159連絡先を招待します
(SDP not shown)
（SDP図示せず）
2 INVITE Alice's PTT Server -> Conference Focus
2アリスのPTTサーバをINVITE - >会議フォーカス
INVITE sip:FriendsOfAlice@example.org SIP/2.0 Via: SIP/2.0/UDP AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8
SIPのINVITE：FriendsOfAlice@example.org SIP / 2.0経由：SIP / 2.0 / UDP AlicesPTTServer.example.org;ブランチ= z9hG4bK77ef4c2312983.1経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds8
Record-Route: <sip:AlicesPTTServer.example.org> Max-Forwards: 69 To: "Alice's Friends" <sip:FriendsOfAlice@example.org> From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.example.org> Content-Type: application/sdp Content-Length: 142
レコードルート：<SIP：AlicesPTTServer.example.org>マックス・フォワード：69： "アリスさんの友達" <一口：FriendsOfAlice@example.org>から： "アリス" <一口：alice@example.org>;タグ= 1928301774コールID：a84b4c76e66710のCSeq：<SIP：alice@pc33.example.org>のContent-Type：アプリケーション/ SDPのContent-Length：142 314159連絡先を招待
(SDP not shown)
（SDP図示せず）
The Conference Focus explodes the Conference URI and Invites Bob
会議の焦点は、会議のURIを爆発し、ボブを招待します
3 INVITE Conference Focus -> Bob's PTT Server
3会議フォーカスをINVITE - >ボブのPTTサーバ
INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 Max-Forwards: 70 To: "Bob" <sip:bob@example.com> From: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=2178309898 Call-ID: e60a4c784b6716 CSeq: 301166605 INVITE Contact: <sip:AlicesConferenceFocus.example.org> Content-Type: application/sdp Content-Length: 142
ブランチ= z9hG4bK4721d8マックス・転送し、SIP / 2.0 / UDP AlicesConferenceFocus.example.org：70： "ボブ" <一口：bob@example.com>から：「アリスのbob@example.comは、SIP / 2.0経由：SIPのINVITEフレンズ」<一口：FriendsOfAlice@example.org>;タグ= 2178309898のCall-ID：e60a4c784b6716ののCSeq：<SIP：AlicesConferenceFocus.example.org>のContent-Type：アプリケーション/ SDPのContent-Length：142 301166605連絡先を招待
(SDP not shown)
（SDP図示せず）
4 INVITE Bob's PTT Server -> Bob
>ボブ - 4ボブのPTTサーバをINVITE
INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bKa27bc93 Max-Forwards: 70 To: "Bob" <sip:bob@example.com> From: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=781299330 Call-ID: 6eb4c66a847710 CSeq: 478209 INVITE Contact: <sip:BobsPTTServer.example.com> Content-Type: application/sdp Content-Length: 142
〜70：： "ボブ" <一口：bob@example.com>から：「アリス;：bob@example.com SIP / 2.0経由：ブランチ= z9hG4bKa27bc93マックス・フォワードSIP / 2.0 / UDP BobsPTTServer.example.com SIPのINVITEフレンズ」<一口：FriendsOfAlice@example.org>;タグ= 781299330コールID：6eb4c66a847710のCSeq：478209する連絡先を招待：<SIP：BobsPTTServer.example.com>のContent-Type：アプリケーション/ SDPコンテンツの長さ：142
(SDP not shown)
（SDP図示せず）
5 183 (Session Progress) Bob's PTT Server -> Conference Focus
5 183（セッションの進捗状況）ボブのPTTサーバ - >会議フォーカス
SIP/2.0 183 Session Progress Via: SIP/2.0/UDP AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 To: "Bob" <sip:bob@example.com>;tag=a6c85cf From: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=2178309898 Call-ID: e60a4c784b6716 Contact: <sip:BobsPTTServer.example.com> CSeq: 301166605 INVITE P-Answer-State: Unconfirmed Content-Length: 0
SIP / 2.0 183セッションプログレス経由：SIP / 2.0 / UDP AlicesConferenceFocus.example.org;への分岐= z9hG4bK4721d8： "ボブ" <一口：bob@example.com>;からタグ= a6c85cf： "アリスさんの友達" <一口：FriendsOfAlice @ example.org>;タグ= 2178309898のCall-ID：e60a4c784b6716連絡先：<SIP：BobsPTTServer.example.com>のCSeq：301166605は、P-回答ステートをINVITE：未確認のContent-Length：0
6 200 (OK) Conference Focus -> Alice's PTT Server
6 200（OK）の会議フォーカス - >アリスのPTTサーバ
SIP/2.0 200 OK Via: SIP/2.0/UDP AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 Record-Route: <sip:AlicesPTTServer.example.org> To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:AlicesConferenceFocus.example.org> P-Answer-State: Unconfirmed Content-Type: application/sdp Content-Length: 131 (SDP not shown)
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP AlicesPTTServer.example.org;ブランチ= z9hG4bK77ef4c2312983.1経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds8録音-ルート：<SIP：AlicesPTTServer.example。 ORG>へ： "アリスさんの友達" <一口：FriendsOfAlice@example.org>;からタグ= c70ef99： "アリス" <一口：alice@example.org>; = 1928301774のCall-IDタグ：のCSeq a84b4c76e66710：314159は、連絡先をINVITE： <SIP：AlicesConferenceFocus.example.org> P-回答ステート：未確認コンテンツタイプ：アプリケーション/ SDPのContent-Length：131（SDP図示せず）
7 200 (OK) Alice's PTT Server -> Alice
7200（OK）アリスのPTTサーバ - >アリス
SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 Record-Route: <sip:AlicesPTTServer.example.org> To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:AlicesConferenceFocus.example.org> P-Answer-State: Unconfirmed Content-Type: application/sdp Content-Length: 131 (SDP not shown)
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds8録音-ルート：<SIP：AlicesPTTServer.example.org>へ： "アリスさんの友達" <一口：FriendsOfAlice@example.org>。 "アリス" <一口：alice@example.org>;タグ= 1928301774のCall-ID：からタグ= c70ef99 a84b4c76e66710のCSeq：<SIP：AlicesConferenceFocus.example.org> P-回答ステート：314159連絡先をINVITE未確認のContentタイプ：アプリケーション/ SDPのContent-Length：131（SDP図示せず）
8 ACK Alice -> Alice's PTT Server
8 ACKアリス - >アリスのPTTサーバ
ACK sip:AlicesConferenceFocus.example.org SIP/2.0 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9 Route: <sip:AlicesPTTServer.example.org> Max-Forwards: 70 To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0
ACKのSIP：AlicesConferenceFocus.example.org SIP / 2.0経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds9ルート：<SIP：AlicesPTTServer.example.org>マックス・フォワード：70： "アリスさんの友達" < SIP：FriendsOfAlice@example.org>;タグ= c70ef99から： "アリス" <一口：alice@example.org>;タグ= 1928301774のCall-ID：a84b4c76e66710のCSeq：314159 ACKのコンテンツの長さ：0
9 ACK Alice's PTT Server -> Conference Focus
9 ACKアリスのPTTサーバ - >会議フォーカス
ACK sip:AlicesConferenceFocus.example.org SIP/2.0 Via: SIP/2.0/UDP AlicesPTTServer.example.org;branch=z9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9 Max-Forwards: 69 To: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0
ACKのSIP：AlicesConferenceFocus.example.org SIP / 2.0経由：SIP / 2.0 / UDP AlicesPTTServer.example.org;ブランチ= z9hG4bK77ef4c2312983.1経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds9マックス・フォワード：69 "アリスさんの友達" <一口：FriendsOfAlice@example.org>;からタグ= c70ef99：への "アリス" <一口：alice@example.org>;タグ= 1928301774のCall-ID：a84b4c76e66710のCSeq：314159 ACKのコンテンツの長さ： 0
The early half-duplex media session between Alice and the Conference Focus is now established, and the Conference Focus buffers the media it receives from Alice.
アリスとの会議の焦点の間の早期半二重メディアセッションは現在確立され、会議の焦点は、それがアリスから受け取ったメディアをバッファします。
10 200 (OK) Bob -> Bob's PTT Server
10 200（OK）ボブ - >ボブのPTTサーバ
SIP/2.0 200 OK Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bKa27bc93 To: "Bob" <sip:bob@example.com>;tag=d28119a From: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=781299330 Call-ID: 6eb4c66a847710 CSeq: 478209 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP BobsPTTServer.example.com;ブランチ= z9hG4bKa27bc93へ： "ボブ" <一口：bob@example.com>;からタグ= d28119a： "アリスさんの友達" <一口：FriendsOfAlice @ example.org>;タグ= 781299330コールID：6eb4c66a847710のCSeq：478209連絡先をINVITE：<SIP：bob@192.0.2.4>のContent-Type：アプリケーション/ SDPコンテンツの長さ：131
(SDP not shown)
（SDP図示せず）
11 ACK Bob's PTT Server -> Bob
11 ACKボブのPTTサーバ - >ボブ
ACK sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bKa27bc93 Max-Forwards: 70 To: "Bob" <sip:bob@example.com>;tag=d28119a From: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=781299330 Call-ID: 6eb4c66a847710 CSeq: 478209 ACK Content-Length: 0
ACK SIP：bob@192.0.2.4のSIP / 2.0経由：SIP / 2.0 / UDP BobsPTTServer.example.com;ブランチ= z9hG4bKa27bc93マックス・フォワード：70： "ボブ" <一口：bob@example.com>;タグ= d28119a From： "アリスさんの友達" <一口：FriendsOfAlice@example.org>;タグ= 781299330コールID：6eb4c66a847710のCSeq：478209 ACKのコンテンツの長さ：0
12 200 (OK) Bob's PTT Server -> Conference Focus
12 200（OK）ボブのPTTサーバ - >会議フォーカス
SIP/2.0 200 OK Via: SIP/2.0/UDP AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 To: "Bob" <sip:bob@example.com>;tag=a6670811 From: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=2178309898 Call-ID: e60a4c784b6716 Contact: <sip:BobsPTTServer.example.com> CSeq: 301166605 INVITE P-Answer-State: Confirmed Content-Type: application/sdp Content-Length: 131
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP AlicesConferenceFocus.example.org;への分岐= z9hG4bK4721d8： "ボブ"：; <一口bob@example.com>からタグ= a6670811： "アリスさんの友達" <一口：FriendsOfAlice @ example.org>;タグは= 2178309898のCall-ID：e60a4c784b6716連絡先：<SIP：BobsPTTServer.example.com>のCSeq：301166605は、P-回答ステートをINVITE：確認のContent-Type：アプリケーション/ SDPコンテンツの長さ：131
(SDP not shown)
（SDP図示せず）
13 ACK Conference Focus -> Bob's PTT Server
13点のACK会議フォーカス - >ボブのPTTサーバ
ACK sip:BobsPTTServer.example.com SIP/2.0 Via: SIP/2.0/UDP AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 Max-Forwards: 70 To: "Bob" <sip:bob@example.com>;tag=a6670811 From: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=2178309898 Call-ID: e60a4c784b6716 CSeq: 301166605 ACK Content-Length: 0
ACKのSIP：BobsPTTServer.example.com SIP / 2.0経由：SIP / 2.0 / UDP AlicesConferenceFocus.example.org;ブランチ= z9hG4bK4721d8マックス・フォワード：70： "ボブ" <一口：bob@example.com>;タグ= a6670811 From： "アリスさんの友達" <一口：FriendsOfAlice@example.org>;タグ= 2178309898のCall-ID：e60a4c784b6716ののCSeq：301166605 ACKのコンテンツの長さ：0
The media session between Alice and Bob is now established and the Conference Focus forwards the buffered media to Bob.
アリスとボブの間でメディアセッションは、現在確立され、会議の焦点はボブに緩衝媒体を転送しています。
The following flow shows Alice making a 1-1 Call to Bob using a pre-established session. A pre-established session is where a dialog is established with Alice's PTT Server using a SIP INVITE SDP offer-answer exchange to pre-negotiate the codecs and other media parameters to be used for media sessions ahead of Alice initiating a communication. When Alice initiates a communication to Bob, a SIP REFER request is used to request Alice's PTT Server to send a SIP INVITE request to Bob. In this example, Bob's terminal does not use the pre-established session mechanism.
以下のフローは、アリスが事前に確立されたセッションを使用してボブに1-1コールを作る示しています。事前に確立されたセッションは、ダイアログは、SIPを使用してAliceのPTTサーバで確立されている場合の事前交渉のコーデックと通信を開始する先行アリスのメディアセッションに使用される他のメディアパラメータにSDPオファーアンサー交換をINVITE。アリスはボブへの通信を開始すると、SIP REFER要求は、ボブへINVITEリクエストをSIPを送信するためにアリスのPTTサーバを要求するために使用されます。この例では、ボブの端末は、事前に確立されたセッションのメカニズムを使用していません。
In this example, Alice's PTT Server acts as a B2BUA and also performs the Conference Focus function. Bob's PTT Server (which is aware that the current Answer Mode setting of Bob's terminal is set to Auto Answer) acts as a B2BUA.
この例では、アリスのPTTサーバは、B2BUAとして機能し、また、会議フォーカス機能を実行します。 （ボブの端末の現在の応答モード設定が自動応答に設定されていることを認識している）ボブのPTTサーバは、B2BUAとして機能します。
Alice's Alice's Bob's Bob's
Terminal PTT Server / PTT Server Terminal
Conference Focus
| | | |
|-----(1)INVITE-- ----->| | |
|<-----(2)200-----------| | |
|-------(3)ACK--------->| | |
| | | |
| | | |
| | | |
|----(4)REFER---------->| | |
|<-----(5)202-----------| | |
| |----(6)INVITE---->| |
| | |--(7)INVITE---->|
| | | |
| |<----(8)183-------| |
|<---(9)NOTIFY----------| | |
|-----(10)200---------->| | |
| | | |
|=Early Media Session==>| | |
| MEDIA | |
| BUFFERING | |
| | |<---(11)200-----|
| | |---(12)ACK----->|
| |<----(13)200------| |
| |-----(14)ACK----->| |
| |===========Media Session==========>|
| | | |
|<---(15)NOTIFY---------| | |
|-----(16)200---------->| | |
| | | |
Figure 2: 1-1 Call Using Pre-Established Session
図2：事前に確立されたセッションを使用して1-1コール
1 INVITE Alice -> Alice's PTT Server
1アリスのINVITE - >アリスのPTTサーバ
INVITE sip:AlicesConferenceFactoryURI.example.org SIP/2.0 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 Max-Forwards: 70 To: <sip:AlicesConferenceFactoryURI.example.org> From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.example.org> Content-Type: application/sdp Content-Length: 142
SIPのINVITE：AlicesConferenceFactoryURI.example.org SIP / 2.0経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds8マックス・フォワード：70：<SIP：AlicesConferenceFactoryURI.example.org>から： "アリス" <一口：alice@example.org>;タグ= 1928301774のCall-ID：a84b4c76e66710のCSeq：314159 INVITE連絡先：<SIP：alice@pc33.example.org>のContent-Type：アプリケーション/ SDPコンテンツの長さ：142
(SDP not shown)
（SDP図示せず）
2 200 (OK) Alice's PTT Server -> Alice
2200（OK）アリスのPTTサーバ - >アリス
SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:AlicesPre-establishedSession@ AlicesPTTServer.example.org> Content-Type: application/sdp Content-Length: 131
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds8へ：<SIP：AlicesConferenceFactoryURI.example.org>;タグ= c70ef99から： "アリス" <一口：alice@example.org> ;タグ= 1928301774のCall-ID：a84b4c76e66710のCSeq：314159は、連絡先をINVITE：<SIP：AlicesPre-establishedSession @ AlicesPTTServer.example.org>のContent-Type：アプリケーション/ SDPコンテンツの長さ：131
(SDP not shown)
（SDP図示せず）
3 ACK Alice -> Alice's PTT Server
3 ACKアリス - >アリスのPTTサーバ
ACK sip:AlicesPre-establishedSession@AlicesPTTServer.example.org SIP/2.0 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds9 Max-Forwards: 70 To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0
ACKのSIP：AlicesPre-establishedSession@AlicesPTTServer.example.org SIP / 2.0経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds9マックス・フォワード：70：<SIP：AlicesConferenceFactoryURI.example.org>;タグ= a84b4c76e66710のCSeq：314159 ACKのコンテンツ長：0;： "アリス" タグ= 1928301774のCall-ID <SIP：alice@example.org>からc70ef99
Alice's terminal has established a Pre-established Session with Alice's PTT Server. All the media parameters are pre-negotiated for use at communication time.
アリスの端末は、アリスのPTTサーバとの事前セッションを確立しています。すべてのメディアパラメータは、通信時に使用するため事前に交渉しています。
Alice initiates a communication to Bob.
アリスはボブへの通信を開始します。
4 REFER Alice -> Alice's PTT Server
>アリスのPTTサーバ - 4アリスをREFER
REFER sip:AlicesPre-establishedSession@AlicesPTTServer.example.org SIP/2.0 Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 Max-Forwards: 70 To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 REFER Refer-To: "Bob" <sip:bob@example.com> Contact: <sip:alice@pc33.example.org>
SIP REFER：AlicesPre-establishedSession@AlicesPTTServer.example.orgをSIP / 2.0経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds8マックス・フォワード：70：<SIP：AlicesConferenceFactoryURI.example.org>;タグ= "アリス" <一口：alice@example.org>;タグ= 1928301774のCall-ID：からc70ef99 a84b4c76e66710のCSeq： "ボブ" <一口：bob@example.com>連絡先：<SIP：アリス314160はREFER-TOを参照してください。 @ pc33.example.org>
5 202 (ACCEPTED) Alice's PTT Server -> Alice
5 202（ACCEPTED）アリスのPTTサーバ - >アリス
SIP/2.0 202 ACCEPTED Via: SIP/2.0/UDP pc33.example.org;branch=z9hG4bKnashds8 To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314160 REFER Contact: <sip:AlicesPre-establishedSession@ AlicesPTTServer.example.org>
SIP / 2.0 202 ACCEPTED経由：SIP / 2.0 / UDP pc33.example.org;ブランチ= z9hG4bKnashds8へ：<SIP：AlicesConferenceFactoryURI.example.org>;からタグ= c70ef99： "アリス" <一口：alice@example.org> ; = 1928301774のCall-IDタグ：a84b4c76e66710のCSeq：314160連絡先を参照してください。<SIP：AlicesPre-establishedSession @ AlicesPTTServer.example.org>
6 INVITE Conference Focus -> Bob's PTT Server
6会議フォーカスをINVITE - >ボブのPTTサーバ
INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP AlicesConferenceFocus.example.org;branch=z9hG4bk4721d8 Max-Forwards: 70 To: "Bob" <sip:bob@example.com> From: "Alice" <sip:Alice@example.org>;tag=2178309898 Referred-By: <sip:Alice@example.org> Call-ID: e60a4c784b6716 CSeq: 301166605 INVITE Contact: <sip:AlicesConferenceFocus.example.org> Content-Type: application/sdp Content-Length: 142
INVITE SIP：bob@example.com SIP / 2.0経由：SIP / 2.0 / UDP AlicesConferenceFocus.example.org;ブランチ= z9hG4bk4721d8マックス・フォワード：70： "ボブ" <一口：bob@example.com>から：「アリス「<一口：Alice@example.org>;タグ= 2178309898呼ばバイ：<SIP：Alice@example.org>コールID：e60a4c784b6716のCSeq：301166605連絡先をINVITE：<SIP：AlicesConferenceFocus.example.org>のContent-Type ：アプリケーション/ SDPコンテンツの長さ：142
(SDP not shown)
（SDP図示せず）
7 INVITE Bob's PTT Server -> Bob
>ボブ - 7ボブのPTTサーバをINVITE
INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bKa27bc93 Max-Forwards: 70 To: "Bob" <sip:bob@example.com> From: "Alice" <sip:Alice@example.org>;tag=781299330 Referred-By: <sip:Alice@example.org> Call-ID: 6eb4c66a847710 CSeq: 478209 INVITE Contact: <sip:BobsPTTServer.example.com> Content-Type: application/sdp Content-Length: 142
SIP INVITE：bob@example.comをSIP / 2.0経由：SIP / 2.0 / UDP BobsPTTServer.example.com;ブランチ= z9hG4bKa27bc93マックス・フォワード：70： "ボブ" <一口：bob@example.com>から：「アリス「<一口：Alice@example.org>;タグ= 781299330-によって参照：<SIP：Alice@example.org>コール-IDを：6eb4c66a847710のCSeq：478209を接触INVITE：<SIP：BobsPTTServer.example.com>のContent-Type ：アプリケーション/ SDPコンテンツの長さ：142
(SDP not shown)
（SDP図示せず）
8 183 (Session Progress) Bob's PTT Server -> Conference Focus
8 183（セッションの進捗状況）ボブのPTTサーバ - >会議フォーカス
SIP/2.0 183 Session Progress Via: SIP/2.0/UDP AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 To: "Bob" <sip:bob@example.com>;tag=a6c85cf From: "Alice" <sip:Alice@example.org>;tag=2178309898 Call-ID: e60a4c784b6716 Contact: <sip:BobsPTTServer.example.com> CSeq: 301166605 INVITE P-Answer-State: Unconfirmed Content-Length: 0
SIP / 2.0 183セッションプログレス経由：SIP / 2.0 / UDP AlicesConferenceFocus.example.org;への分岐= z9hG4bK4721d8： "ボブ" <一口：bob@example.com>;からタグ= a6c85cf： "アリス" <一口：アリス@ example.org>;タグ= 2178309898のCall-ID：e60a4c784b6716連絡先：<SIP：BobsPTTServer.example.com>のCSeq：301166605は、P-回答ステートをINVITE：未確認のContent-Length：0
9 NOTIFY Alice's PTT Server -> Alice
>アリス - 9アリスのPTTサーバをNOTIFY
NOTIFY sip:alice@pc33.example.org SIP/2.0 Via: SIP/2.0/UDP AlicesPre-establishedSession@AlicesPTTServer.example.org; branch=z9hG4bKnashds8 Max-Forwards: 70 To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314161 NOTIFY Contact: <sip:AlicesPre-establishedSession@AlicesPTTServer.example.org> Event: refer Subscription-State: Active;Expires=60 Content-Type: message/sipfrag;version=2.0 Content-Length: 99
一口にNOTIFY：SIP / 2.0を介してalice@pc33.example.org：SIP / 2.0 / UDP AlicesPre-establishedSession@AlicesPTTServer.example.org。ブランチ= z9hG4bKnashds8マックス・フォワード：70：<SIP：AlicesConferenceFactoryURI.example.org>;からタグ= c70ef99：;：a84b4c76e66710のCSeq：314161はNOTIFY： "アリス" タグ= 1928301774のCall-ID <一口alice@example.org>連絡先：<SIP：AlicesPre-establishedSession@AlicesPTTServer.example.org>イベント：サブスクリプションのステートを参照してください：99：;：;バージョン= 2.0のContent-Lengthのメッセージ/ sipfragアクティブは= 60 Content-Typeの有効期限
SIP/2.0 183 Session Progress To: "Bob" <sip:bob@example.com>;tag=d28119a P-Answer-State: Unconfirmed
SIP / 2.0 183セッション進行する： "ボブ" <SIP：bob@example.com>;タグ= d28119a P-回答ステート：未確認
10 200 (OK) Alice -> Alice's PTT Server
10200（OK）アリス - >アリスのPTTサーバ
SIP/2.0 200 OK Via: SIP/2.0/UDP AlicesPre-establishedSession@AlicesPTTServer.example.org; branch=z9hG4bKnashds8 To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314161 NOTIFY
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP AlicesPre-establishedSession@AlicesPTTServer.example.org。ブランチ= z9hG4bKnashds8へ：<SIP：AlicesConferenceFactoryURI.example.org>;からタグ= c70ef99：;：a84b4c76e66710のCSeq：314161はNOTIFY： "アリス" タグ= 1928301774のCall-ID <一口alice@example.org>
The early half-duplex media session between Alice and the Conference Focus is now established and the Conference Focus buffers the media it receives from Alice.
アリスとの会議の焦点の間の早期半二重メディアセッションは、現在確立され、会議の焦点は、それがアリスから受け取ったメディアをバッファリングしています。
11 200 (OK) Bob -> Bob's PTT Server
11 200（OK）ボブ - >ボブのPTTサーバ
SIP/2.0 200 OK Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bK927bc93 To: "Bob" <sip:bob@example.com>;tag=d28119a From: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=781299330 Call-ID: 6eb4c66a847710 CSeq: 478209 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP BobsPTTServer.example.com;ブランチ= z9hG4bK927bc93へ： "ボブ" <一口：bob@example.com>;からタグ= d28119a： "アリスさんの友達" <一口：FriendsOfAlice @ example.org>;タグ= 781299330コールID：6eb4c66a847710のCSeq：478209連絡先をINVITE：<SIP：bob@192.0.2.4>のContent-Type：アプリケーション/ SDPコンテンツの長さ：131
(SDP not shown)
（SDP図示せず）
12 ACK Bob's PTT Server -> Bob
12 ACKボブのPTTサーバ - >ボブ
ACK sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP BobsPTTServer.example.com;branch=z9hG4bK927bc93 Max-Forwards: 70 To: "Bob" <sip:bob@example.com>;tag=d28119a From: "Alice" <sip:Alice@example.org>;tag=781299330 Call-ID: 6eb4c66a847710 CSeq: 478209 ACK Content-Length: 0
ACK SIP：bob@192.0.2.4のSIP / 2.0経由：SIP / 2.0 / UDP BobsPTTServer.example.com;ブランチ= z9hG4bK927bc93マックス・フォワード：70： "ボブ" <一口：bob@example.com>;タグ= d28119a From： "アリス" <一口：Alice@example.org>;タグ= 781299330コールID：6eb4c66a847710のCSeq：478209 ACKのコンテンツの長さ：0
F13 200 (OK) Bob's PTT Server -> Conference Focus
F13 200（OK）ボブのPTTサーバ - >会議フォーカス
SIP/2.0 200 OK Via: SIP/2.0/UDP AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 To: "Bob" <sip:bob@example.com>;tag=a6670811 From: "Alice's Friends" <sip:FriendsOfAlice@example.org>;tag=2178309898 Call-ID: e60a4c784b6716 Contact: <sip:BobsPTTServer.example.com> CSeq: 301166605 INVITE P-Answer-State: Confirmed Content-Type: application/sdp Content-Length: 131
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP AlicesConferenceFocus.example.org;への分岐= z9hG4bK4721d8： "ボブ"：; <一口bob@example.com>からタグ= a6670811： "アリスさんの友達" <一口：FriendsOfAlice @ example.org>;タグは= 2178309898のCall-ID：e60a4c784b6716連絡先：<SIP：BobsPTTServer.example.com>のCSeq：301166605は、P-回答ステートをINVITE：確認のContent-Type：アプリケーション/ SDPコンテンツの長さ：131
(SDP not shown)
（SDP図示せず）
14 ACK Conference Focus -> Bob's PTT Server
14点のACK会議フォーカス - >ボブのPTTサーバ
ACK sip:BobsPTTServer.example.com SIP/2.0 Via: SIP/2.0/UDP AlicesConferenceFocus.example.org;branch=z9hG4bK4721d8 Max-Forwards: 70 To: "Bob" <sip:bob@example.com>;tag=a6670811 From: "Alice" <sip:Alice@example.org>;tag=1928301774 Call-ID: e60a4c784b6716 CSeq: 301166605 ACK Content-Length: 0
ACKのSIP：BobsPTTServer.example.com SIP / 2.0経由：SIP / 2.0 / UDP AlicesConferenceFocus.example.org;ブランチ= z9hG4bK4721d8マックス・フォワード：70： "ボブ" <一口：bob@example.com>;タグ= a6670811 From： "アリス" <一口：Alice@example.org>;タグ= 1928301774のCall-ID：e60a4c784b6716のCSeq：301166605 ACKのコンテンツの長さ：0
The media session between Alice and Bob is now established and the Conference Focus forwards the buffered media to Bob.
アリスとボブの間でメディアセッションは、現在確立され、会議の焦点はボブに緩衝媒体を転送しています。
15 NOTIFY Alice's PTT Server -> Alice
>アリス - 15アリスのPTTサーバをNOTIFY
NOTIFY sip:alice@pc33.example.org SIP/2.0 Via: SIP/2.0/UDP AlicesPre-establishedSession@AlicesPTTServer.example.org; branch=z9hG4bKnashds8 Max-Forwards: 70 To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314162 NOTIFY Contact: <sip:AlicesPre-establishedSession@ AlicesPTTServer.example.org> Event: refer Subscription-State: Active;Expires=60 Content-Type: message/sipfrag;version=2.0 Content-Length: 83
一口にNOTIFY：SIP / 2.0を介してalice@pc33.example.org：SIP / 2.0 / UDP AlicesPre-establishedSession@AlicesPTTServer.example.org。ブランチ= z9hG4bKnashds8マックス・フォワード：70：<SIP：AlicesConferenceFactoryURI.example.org>;からタグ= c70ef99：;：a84b4c76e66710のCSeq：314162はNOTIFY： "アリス" タグ= 1928301774のCall-ID <一口alice@example.org>連絡先：<SIP：AlicesPre-establishedSession @ AlicesPTTServer.example.org>イベント：サブスクリプションのステートを参照してください：アクティブ; = 60 Content-Typeの有効期限：メッセージ/ sipfragを、バージョン= 2.0のContent-Length：83
SIP/2.0 200 OK To: "Bob" <sip:bob@example.com>;tag=d28119a P-Answer-State: Confirmed
SIP / 2.0 200 OK "ボブ" <SIP：bob@example.com>;タグ= d28119aのP-回答ステート：確認
16 200 (OK) Alice -> Alice's PTTServer
16 200（OK）アリス - >アリスのPTTServer
SIP/2.0 200 OK Via: SIP/2.0/UDP AlicesPre-establishedSession@AlicesPTTServer.example.org; branch=z9hG4bKnashds8 To: <sip:AlicesConferenceFactoryURI.example.org>;tag=c70ef99 From: "Alice" <sip:alice@example.org>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314162 NOTIFY
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP AlicesPre-establishedSession@AlicesPTTServer.example.org。ブランチ= z9hG4bKnashds8へ：<SIP：AlicesConferenceFactoryURI.example.org>;からタグ= c70ef99：;：a84b4c76e66710のCSeq：314162はNOTIFY： "アリス" タグ= 1928301774のCall-ID <一口alice@example.org>
The information returned in the P-Answer-State header is not viewed as particularly sensitive. Rather, it is informational in nature, providing an indication to the UAC that delivery of any media sent as a result of an answer in this response is not guaranteed. An eavesdropper cannot gain any useful information by obtaining the contents of this header.
P-回答ステートヘッダに返される情報は特に敏感として見ていません。むしろ、それは、この応答に答えた結果として送信されたすべてのメディアの配信が保証されていないことをUACへの指示を提供する、自然の中での情報です。盗聴者は、このヘッダの内容を取得することによって、任意の有用な情報を得ることができません。
End-to-end protection is not appropriate because the P-Answer-State header is used and added by proxies and intermediate UAs. As a result, a "malicious" proxy between the UAs or attackers on the signaling path could add or remove the header or modify the contents of the header value. This attack either denies the caller the knowledge that the callee has yet to be contacted or falsely indicates that the callee has yet to be contacted when they have already answered. The attack that falsely indicates that the callee has yet to be contacted when they have already answered attack could result in the caller deciding not to transmit media because they do not wish to have their media stored by an intermediary even though in reality the callee has answered. The attack that denies the callee the additional knowledge that the callee has yet to be contacted does not appear to be a significant concern since this is the same as the situation when a B2BUA sends a 200 (OK) before the callee has answered without the use of this extension.
P-回答ステートヘッダがプロキシと中間のUAによって使用され、追加されるため、エンドツーエンドの保護は適切ではありません。結果として、シグナル伝達経路上のUA又は攻撃者との間の「悪意のある」プロキシが追加または削除ヘッダまたはヘッダ値の内容を修正することができます。この攻撃は、呼び出し元呼び出し先がまだ連絡する必要があるか、虚偽の呼び出し先が彼らはすでに答えていたときに連絡をまだ持っていることを示している知識を否定するのどちらか。誤って呼び出し先が彼らのメディアが実際に呼び出し先が応答したにもかかわらず、仲介によって格納したくないので、彼らはすでに攻撃がメディアを送信しない決定、呼び出し元が生じる可能性が答えていたときに連絡をまだ持っていることを示している攻撃。これは、B2BUAは、200（OK）を送信し、状況と同じであるため、呼び出し先が使用せずに答えた前に、呼び出し先が接触するまだ持っていることの追加の知識は重要な問題ではないようで呼び出し先を拒否攻撃この拡張機能の。
It is therefore necessary to protect the messages between proxies and implementation SHOULD use a transport that provides integrity and confidentially between the signaling hops. The Transport Layer Security (TLS) [9] based signaling in SIP can be used to provide this protection.
整合性を提供し、内密のシグナリングホップ間の輸送を使用すべきプロキシと実装の間のメッセージを保護する必要があります。トランスポート層セキュリティ（TLS）SIPで[9]ベースのシグナリングは、この保護を提供するために使用することができます。
Security issues have only been considered for networks that are trusted and use hop-by-hop security mechanisms with transitive trust. Security issues with usage of this mechanism in the general Internet have not been evaluated.
セキュリティの問題は、信頼できると推移的な信頼とホップバイホップのセキュリティ・メカニズムを使用しているネットワークのために考えられてきました。一般的なインターネットでのこのメカニズムの利用とセキュリティの問題が評価されていません。
This document defines a private SIP extension header field (beginning with the prefix "P-" ) based on the registration procedures defined in RFC 3427 [21].
この文書は、RFC 3427 [21]で定義された登録手順に基づいて、プライベートSIP拡張ヘッダフィールド（接頭辞「P-」で始まる）を定義します。
The following row has been added to the "Header Fields" section of the SIP parameter registry:
次の行は、SIPパラメータレジストリの「ヘッダフィールド」セクションに追加されました。
+----------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+----------------+--------------+-----------+
| P-Answer-State | | [RFC4964] |
+----------------+--------------+-----------+
The authors would like to thank Jon Peterson, Cullen Jennings, Jeroen van Bemmel, Paul Kyzivat, Dale Worley, Dean Willis, Rohan Mahay, Christian Schmidt, Mike Hammer, and Miguel Garcia-Martin for their comments that contributed to the progression of this work. The authors would also like to thank the OMA POC Working Group members for their support of this document and, in particular, Tom Hiller for presenting the concept of the P-Answer-State header to SIPPING at IETF 62.
著者は、この作業の進行に貢献した彼らのコメントのためにジョン・ピーターソン、カレン・ジェニングス、イェルーンバンBemmel、ポールKyzivat、デイル・ウォーリー、ディーンウィリス、ロハンMahay、クリスチャン・シュミット、マイク・ハマー、とミゲル・ガルシア・マーティンに感謝したいと思います。著者らはまた、IETF 62でSIPPINGにP-回答ステートヘッダーの概念を提示するため、このドキュメントの彼らのサポートのためにOMA POC作業部会のメンバーに感謝したいと、特に、トム・ヒラーでしょう。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] OMA, "Push to talk over Cellular - Architecture", OMA-AD-PoC-V1_0_1-20061128-A, November 2006.
[3] OMA、 "携帯電話を介して話をするプッシュ - アーキテクチャ"、OMA-AD-のPoC-V1_0_1-20061128-A、2006年11月に。
[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[4]、R.、 "インターネットメディアタイプのメッセージ/ sipfrag"、RFC 3420、2002年11月スパークス。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[6] R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月、火花。
[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[7]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[8] "構文仕様のための増大しているBNF：ABNF" クロッカー、D.、エド、およびP. Overell、。、RFC 4234、2005年10月に。
[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[9]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[10] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[10]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
[11] Garcia-Martin, M., "A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-to-Talk over Cellular (PoC) Service", RFC 4354, January 2006.
[11]ガルシア・マーチン、M.、「Aセッション開始プロトコル（SIP）イベントパッケージとプッシュ・ツー・トークセルラー（POC）サービスオーバーのサポートにおける各種設定のためのデータ形式」、RFC 4354、2006年1月。
[12] Willis, D., Ed., and A. Allen, "Requesting Answering Modes for the Session Initiation Protocol (SIP)", Work in Progress, June 2007.
[12]ウィリス、D.、エド。、およびA.アレン、進歩、2007年6月に仕事 "セッション開始プロトコル（SIP）のための要求応答モード"。
[13] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
、RFC 3262、2002年6月[13]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[14] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December 2002.
[14] Schulzrinneと、H.、オラン、D.、およびG.カマリロ、RFC 3326 "セッション開始プロトコル（SIP）理由ヘッダーフィールド" 2002年12月。
[15] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[15]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェント能力を示します"。
[16] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
、RFC 4538、2006年6月[16]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）におけるダイアログ識別介して要求承認"。
[17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[17]ドノバン、S.、 "SIP INFOメソッド"、RFC 2976、2000年10月。
[18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[18]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[19] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[19]キャンベル、B.、ローゼンバーグ、J.、Schulzrinneと、H.、のHuitema、C.、およびD. Gurle、 "インスタントメッセージングのためのセッション開始プロトコル（SIP）拡張子"、RFC 3428、2002年12月。
[20] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[20]ニエミ、A.、 "イベント状態の出版のためのセッション開始プロトコル（SIP）の拡張"、RFC 3903、2004年10月。
[21] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[21]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。
Authors' Addresses
著者のアドレス
Andrew Allen (editor) Research in Motion (RIM) 102 Decker Court, Suite 100 Irving, Texas 75062 USA
アンドリュー・アレン（エディタ）は、Research In Motion（RIM）102デッカー裁判所、スイート100アーヴィング、テキサス75062 USA
EMail: aallen@rim.com
メールアドレス：aallen@rim.com
Jan Holm Ericsson Tellusborgsvagen 83-87 Stockholm 12526 Sweden
ヤン・ホルムエリクソンTellusborgsvagen 83-87ストックホルム12526スウェーデン
EMail: Jan.Holm@ericsson.com
メールアドレス：Jan.Holm@ericsson.com
Tom Hallin Motorola 1501 W Shure Drive Arlington Heights, IL 60004 USA
トム・アリンモトローラ1501 Wシュアードライブアーリントンハイツ、IL 60004 USA
EMail: thallin@motorola.com
メールアドレス：thallin@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。