[要約] RFC 4964は、Open Mobile Alliance Push to Talk over CellularのためのSession Initiation ProtocolにおけるP-Answer-Stateヘッダー拡張に関するものです。このRFCの目的は、PTTセッションの状態を示すための新しいヘッダーを定義することです。
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
Open Mobile Allianceのセッション開始プロトコルへのP-Answer-State Header拡張は、携帯電話を介して話をするためのプッシュ
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.
このドキュメントでは、Open Mobile Alliance（OMA）が使用するプライベートセッション開始プロトコル（SIP）ヘッダー（P-Header）について説明します。P-Answer-Stateヘッダーは、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.
Open Mobile Alliance（OMA）（http://www.openmobilealliance.org）は、SIPがさまざまな参加者の半分二重メディアセッションを確立するために使用されるプロトコルであるCellular（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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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 Server」（トークサーバーへのプッシュ）、「未確認の表示」、「未確認の応答」、「確認された表示」、「確認された応答」という用語は、このドキュメントに導入されています。
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- 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.
ここで言及されている「PTTサーバー」は、To Push to Talkサービスのためにネットワークベースの機能を実行するSIPネットワークサーバーです。PTTサーバーは、実行する必要がある機能に基づいて、SIPプロキシ（[2]で定義されている）またはバックトゥバック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端子は、これらの動作モードの両方または1つの両方をサポートできます。ユーザーは、現在の状況と好みに基づいて頻繁に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]は、ネットワーク内のPTTサーバーを使用して、会議フォーカス[10]、リアルタイムトランスポートプロトコル（RTP）翻訳者、またはネットワークポリシーエンダメーションサーバーなどの役割を実行できます。発信者の提供の提供の遅延を最小限に抑えるための最適化の可能性は、PTTサーバーがメディアパケットのバッファリングを実行するために、発信者に早期または「未確認の表示」を提供し、発信者が開始できるようにすることです。呼び出されたPOCターミナルの前に話すことが答えました。SIP UAのイベントパッケージとメカニズムは、バッファリングを有効にするためにPTTサーバーへの現在の回答モードを示すための[11]で定義されています。さらに、特にセッションに複数のドメインが関与している場合、セッションのシグナリングパスに複数のPTTサーバーが関与する可能性があります。また、バッファリングを実行するPTTサーバーは、SIP Inviteリクエストの最終目的地であるSIP UAの現在の回答モードの知識を持つPTTサーバーではない場合があります。[12]で定義されているメカニズムは、SIP UA（またはSIP UAとして機能するPTTサーバーとして機能する）として機能する端子を許可します。特定のモード。ただし、PTTサーバーが、発生するSIPユーザーエージェントクライアント（UAC）に向けて「未確認の表示」を中継するためにメカニズムが必要です。
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に電話をかけるために、Calling UAによって生成されたメディアをバッファリングするPTTサーバー。メディアバーストが通常10〜30秒の順に短いコールの半分二重性の性質のため、追加のエンドツーエンドのレイテンシは許容される可能性があり、これによりユーザーエクスペリエンスが大幅に向上します。ただし、PTTサーバーは、呼び出されたSIP UAが自動回答モードにある可能性が高い場合にのみこれを行うことができます。呼び出された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-Answer-Stateヘッダーフィールドを提案して、「未確認の適応」をサポートしています。新しいSIPヘッダーフィールドは、SIP Inviteリクエストへの応答、またはSIP招待リクエストが送信されるSIPリクエストの結果として送信されたSIP通知リクエストに含まれる応答のSIPFRAGのSIPFRAGにオプションを含めることができます。ヘッダーフィールドは、SIPプロキシまたはバックツーバックUAとして機能するPTTサーバーからの表示を提供して、終了UAが自動的に回答する可能性が高いことを示唆する情報を持っていることを示しています。これにより、SIP Invite Requestの最終目的地から最終的な応答を受信する前に、メディアを送信するために、魅力的なSIP UAに向けて「未確認の表示」を提供します。p-answer-stateヘッダーフィールドの送信者が拡張機能を理解するために受信機に依存しないため、サポートまたは要求のヘッダーは必要ありません。拡張機能が理解されていない場合、ヘッダーフィールドは受信者によって単に無視されます。拡張機能については、以下に説明します。
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-Answer-Stateヘッダーフィールドを使用して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-answer-stateヘッダーフィールドを使用して暫定的な応答を見て、発信者のメディアをバッファリングしたい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）応答を生成すると、PTTサーバーがPTTサーバーを生成したPTTサーバーは、パラメーターを「未確認」でP-Answer-Stateヘッダーフィールドで生成しました。「確認」のパラメーターを備えた状態ヘッダーフィールド。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-Answer-State Headerフィールドの目的は、SIPプロキシまたは連続したUAとして機能するPTTサーバーからの兆候を提供することです。リクエストはおそらく自動的に応答します。したがって、PTTサーバーは、SIP Inviteリクエストの最終目的地から最終的な応答を受信する前に、魅力的なSIP UAを許可する魅力的なSIP UAに「未確認の表示」を提供することができます。暫定的な応答に、値が「未確認」である値を持つp-answer-stateヘッダーフィールドが含まれており、回答が含まれていない場合、受信PTTサーバーは、回答とP-Answer-Stateを含むSIP 200（OK）応答を送信できます。PTTサーバーがメディアバッファリングを実行する意思がある場合、値「未確認」のヘッダーフィールド。値「unconfirmed」の値を持つp-answer-stateヘッダーフィールドを含む応答には、回答も含まれている場合、p-answer-stateヘッダーフィールドを含む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-Answer-Stateヘッダーフィールドは、SIP Inviteリクエストに対する暫定的または最終的な応答またはSIP紹介リクエストの結果として送信されたSIP通知リクエストのSIPFRAGのSIPFragのSIPFRAGのSIP招待リクエストを送信することに含めることができます。値「非不明瞭」を持つP-Answer-Stateヘッダーフィールドが回答を含む暫定的な応答に含まれている場合、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-Answer-Stateヘッダーフィールドとともに回答が含まれている場合、受信PTTサーバーはメディアをバッファリングするか、メディアを転送するかを判断し、ダウンストリーン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-Answer-Stateヘッダーは、応答を送信するノードに、それ自体と発信元のUACの間のシグナリングパスでこの拡張を理解するB2BUAとして機能するPTTサーバーがあるという知識があることの知識を持っている場合にのみ暫定的な応答に含まれます。送信ノードと発信元のUACの間のこのPTTサーバーは、SIP 200（OK）応答またはSIPFrag（[4]で定義されている）のSIPFRAG（[5で定義）のいずれかでのみヘッダーフィールドを渡すだけです（[5で定義されています）]）SIP参照要求の結果として送信されます（[6]で定義されています）。このような状況は、特定のネットワークトポロジでのみ発生します。これが、このヘッダーフィールドの使用が一般的なインターネットに関連しないもう1つの理由です。発信元のUACは、SIP 200（OK）応答またはSIP通知リクエストのSIPFragでP-Answer-Stateヘッダーフィールドのみを受け取ります。
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".
[13]で定義されているメカニズムを使用して、p-answer-stateヘッダーフィールドを含む暫定的な応答は確実に送信できますが、これは必要ありません。これはパフォーマンスの最適化であり、暫定的な応答の影響は、信頼できない（到着しなかった）送られた（到着しなかった）ことは、単にバッファリングが行われないということです。ただし、暫定的な回答が確実に送信され、暫定的な対応が到着しない場合、SIPプラックリクエストの受信時に暫定的な対応送信者がタイムアウトするまでにかかる時間は、暫定的な対応が頃にはそうなる可能性があります。resして、「確認された応答」はすでに受け取られていた可能性があります。回答を含む暫定的な回答が確実に送信される場合、SIP招待リクエストの200（OK）応答は、SIPプラックリクエストを受信する前に送信できません。したがって、暫定的な応答を確実に送信すると、「確認された応答」の送信が遅れる可能性があります。
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サービスには、1つ以上の招待されたPOCサブスクライバーがセッションを受け入れるまで、POCサブスクライバーからのB2BUAスプールメディアとして機能するPTTサーバーが満たすことができる初期セットアップパフォーマンス要件があります。特定の要件は次のとおりです。
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：中間サーバーは、1つ以上の招待されたPOC SIP UASSが招待を受け入れるまで、魅力的な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 UASがSIP招待リクエストを受け入れていなくても、メディアをスプールすることができる中間サーバーは、魅力的なSIP UACからのSIP招待リクエストを受け入れることができますユーザーの介入を必要とせずにリクエスト。
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：メディアをスプールできない、または望まない中間サーバーまたはプロキシ。招待された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：招待状のSIP UACが招待されているSIP UASSがSIP招待状のリクエストを受け入れるまで、魅力的なSIP UACからメディアをスプールすることをいとわない中間サーバーは、魅力的な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招待リクエストを受け入れる可能性が高いという兆候を受け取る必要があります。この場合、招待された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サーバーが別のPTTサーバーまたは招待されたPOC SIP UASの回答モード設定の魅力的なSIP UACを通知するために、多くの代替案が考慮されました。
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.
1つの提案は、SIP 183 Responseと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）応答で理由ヘッダー[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]で定義されているように、返された連絡先ヘッダーで機能タグを使用することでした。これは、別の機能ではなく、セッションの属性であり、さまざまな機能に適用できるため、拒否されました。
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パラメーターの選択は、メディアストリームではなくセッションに適用されるため、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-Answer-Stateヘッダーは、SIPセッションの進捗状況と受け入れの状態に関する追加情報を提供するために選択されました。UACは、その申し出が回答され、受け入れられていると考えていますが、ヘッダーはUACに招待されたPOCサブスクライバーまたは仲介者がSIP招待リクエストを受け入れたかどうかを知らせます。
The P-Answer-State header is applicable in the following circumstances:
P-Answer-Stateヘッダーは、次の状況で適用できます。
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 ネットワークでは、招待されたユーザーが全二重通信で正常であるようにセッションの回答を口頭で認める可能性がないハーフ二重通信に従事するUASがあります。
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]に指定されたSIP招待リクエストに含まれるオファーに応じて送信されたオファーを含まないSIP 18Xまたは2XX応答にP-Answer-Stateヘッダーフィールドを含めることができます。通常、P-Answer-Stateヘッダーフィールドは、SIP 183セッションの進行状況またはSIP 200（OK）応答のいずれかに含まれています。SIPリクエストを受信してSIP招待リクエストを送信するUAには、SIPが作成した暗黙のサブスクリプションの結果として送信されるSIP通知リクエストに含まれる応答のSIPFRAGにP-Answer-Stateヘッダーフィールドを含めることもできます。リクエストを参照してください。
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-answer-stateヘッダーフィールドにパラメーターが「un unsufirmed」を含む場合、UASまたはプロキシは、SIP招待リクエストの最終的な宛先UASがセッションを自動的に受け入れる可能性が高いことを示唆する情報を持っていることを示していますが、これはこれが未確認であり、最終的な宛先UASが最初にユーザーに警告し、セッションを手動で受け入れるか、セッションリクエストを受け入れないことを要求する可能性があります。p-answer-stateヘッダーフィールドにパラメーターが「確認された」パラメーターが含まれている場合、UASまたはプロキシは、宛先UASがセッションを受け入れ、メディアを受信する準備ができていることを示しています。「確認」のパラメーター値には、回答を含むSIP 200（OK）応答の通常のセマンティクスがあり、完全性のために含まれています。「確認」のパラメーター値は、SIP 200（OK）応答またはSIP通知リクエストの本文に含まれる200（OK）のSIPFRAGのみに含まれます。
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-answer-stateヘッダーフィールドを使用して受け取ったSIP 18x応答は、「未確認の応答」として扱われるべきではありません。「確認された」パラメーターを含むp-answer-stateヘッダーフィールドを含むSIP 18x応答は、これが無効な状態であるため、「確認された応答」として扱われてはなりません。
A SIP 200 (OK) response without a P-Answer-State Header field MUST be treated as a "Confirmed Response".
p-answer-stateヘッダーフィールドのない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.
回答を含む「未確認の応答」を受け取るUAC（端末）は、[7]で指定されているようにメディアを送信する場合があります。ただし、メディアが最終受信者によって受信されるという保証はありません。
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]で指定されたメカニズムを使用して、招待されたユーザーが参加したことを判断できます。あるいは、最終的な宛先UASがセッションを受け入れない場合、SIP Byeリクエストを受信したり、メディアを保留にすることもできます。
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に「未確認の応答」を含むSIP通知リクエストを受信するUAC（端末）は、SIPのボディに「未確認の応答」が、オファーが成功したダイアログに関連するリクエストに関連しています。[5]による回答交換は、メディアを送信する場合があります。ただし、元のSIP参照リクエストの紹介ヘッダーに示された最終的な受信者がメディアを受信するという保証はありません。ダイアログは、SIP参照要求が同じダイアログで送信されたため、または[16]で定義されているターゲットダイアログヘッダーにダイアログを特定したターゲットダイアログヘッダーが含まれていたためです。
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.
バックツーバックUAのUAS部分でSIP招待リクエストを受信するPTTサーバーには、オファーを含まないSIP 18xまたは2xx応答、パラメーターを備えたP annswer-Stateヘッダーフィールドに含まれる場合があります。最終的な宛先UAから「確認された応答」をまだ受け取っていない場合、応答に「未確認」であり、SIP Inviteリクエストの最終的な宛先UAがセッションを自動的に受け入れる可能性が高いことを示唆する情報があります。
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 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".
Back-to-Back UAのUAC部分に「Uncrifirmed」を含むP-Answer-Stateヘッダーフィールドを含むSIP招待リクエストに対するSIP 18x応答を受信するPTTサーバーには、P-Answer-Stateヘッダーが含まれる場合があります。SIP 2XX応答のパラメーターを「未確認」のフィールドで、その応答を受け取った結果として、UASのバックツーバックUAの一部が送信します。それ以外の場合は、バックツーバックUAのUAC部分にP-Answer-Stateヘッダーフィールドを含むSIP招待リクエストに対するSIP 18Xまたは2XX応答を受信するPTTサーバーには、P-Answer-Stateヘッダーフィールドが変更されていないことが含まれます。SIP 18xまたは2xxの応答では、その応答を受け取った結果、バックツーバックUAのUASが送信します。バックツーバックUAのUAS部分から送信された応答がSIP 18X応答である場合、応答に含まれるP-Answer-Stateヘッダーフィールドには、「非公式」のパラメーターを含める必要があります。
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部分には、バックツーバックUAのUAC部分が受け取った「未確認の応答」が含まれていない場合でも、送信する「未確認の応答」に回答を含めることができます。答え。
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-Answer-Stateヘッダーフィールドを含むことができます。パラメーターは「確認されました」。このダイアログの一部として以前に「未確認の応答」を連続したUAのUASの一部が以前に「未確認の応答」を送信した場合、バックツーバックUAのUASの一部は、転送された「確認された応答」に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部分に、パラメーター「unspirmed」を備えたp-answer-stateヘッダーフィールドとともに応答の回答が含まれている場合、バックツーバックのUAS部分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.
[6]で指定されているように、SIP参照リクエストを受信してSIP招待状リクエストを別のUAに送信するPTTサーバーの連続したUAのUAS部分は、SIP 200（OK）応答のSIPFRAGを生成する場合がありますパラメーターを備えたP-Answer-Stateヘッダーフィールドを含む、SIP Inviteリクエストへの応答を受信するバックツーバックUAのUAC部分の前に「未確認」を含む。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 Inviteリクエストを送信した場合、UACでP-Answer-Stateヘッダーフィールドを含むSIP 18Xまたは2XX応答を受信した場合バックツーバックUAの一部である場合、バックツーバックUAのUASの一部には、SIP通知リクエストに含まれる応答のSIPFRAGにP-Answer-Stateヘッダーフィールドを含める必要があります。SIPFRAGに含まれるP-Answer-Stateヘッダーフィールドには、元の応答からP-Answer-Stateのパラメーターが含まれていません。このSIP Notifyリクエストは、PTTサーバーの連続したUAのUAS部分が、SIP 18Xまたは2XX応答の受信に基づいて元のSIP参照要求に応答して送信されるというSIP通知リクエストです。SIP通知要求で送信された応答のSIPFRAGがSIP 18X応答である場合、応答のSIPFRAGに含まれるP-ANSWER-STATEヘッダーフィールドには、「未確認」のパラメーターが含まれている必要があります。バックツーバックUAのUAC部分がP-Answer-Stateヘッダーフィールドを含まない「確認された応答」を受け取った場合、その連続したUAのUAS部分にはP-Answer-が含まれる場合があります。SIP参照要求に応じて送信されたSIP通知リクエストに含まれる応答の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:
Back-to-Back UAのUASの一部であるPTTサーバーが、SIP紹介リクエストの結果として以前にSIP通知リクエストを送信した場合：
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-Answer-Stateヘッダーフィールドが含まれています。
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サーバーは、SIP Inviteリクエストに対する「確認された応答」を連続してUAのUAC部分で受信します。
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にパラメーターが「確認された」パラメーターを備えたP-Answer-Stateヘッダーフィールドを含める必要があります。「確認された応答」を受信します。
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招待リクエストによって確立された既存のダイアログに関連している場合、そのバックツーバックUAのUASの一部は、[]で指定されたメディアを受信する準備ができている必要があります。7]。また、連続したUAのUAC部分が最終目的地UAから「確認された応答」を受け取るか、バッファーがいっぱいになるまで受け取るメディアをバッファリングする場合があります。ダイアログは、SIP参照要求が同じダイアログで送信されたため、または[16]で定義されているターゲットダイアログヘッダーにダイアログを特定したターゲットダイアログヘッダーが含まれていたためです。
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-Answer-Stateヘッダーフィールドのセマンティクスを理解する必要はありません。未知のヘッダーの通常の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サーバーには、SIP 18x応答でパラメーターを「未確認」のp-answer-stateヘッダーフィールドを含むことができます。SIP Inviteリクエストの最終的な宛先UAは、セッションを自動的に受け入れる可能性があります。
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-Answer-Stateヘッダーフィールドを追加する場合があります。
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-answer-stateヘッダーの構文は次のように説明されています。
P-Answer-State = "P-Answer-State" HCOLON answer-type
*(SEMI generic-param)
answer-type = "Confirmed" / "Unconfirmed" / token
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]の表2、SIP固有のイベント通知[5]のセクション7.1、SIP情報メソッドの表1および2のセクション7.1を拡張するために必要なP-Answer-Stateヘッダーの追加のテーブルエントリを示します[17]、SIP [13]の暫定応答の信頼性の表1および2、SIP更新方法[18]の表1と2、SIP拡張の表1と2のインスタントメッセージの表1と2、SIPの表1の表1と2方法[6]、およびSIPパブリッシュメソッド[20]の表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-Answer-Stateヘッダーの追加のテーブルエントリ
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オファーを含むリクエストがアリスのターミナルによって送信されるときに、SIPがSDPオファーを含むリクエストを招待するオンデマンドセッションの確立メカニズムを使用します。
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.
この例では、AliceのPTTサーバーは、Callful Sip ProxyとBobのPTTサーバー（Bobの端末の現在の回答設定が自動回答に設定されていることを認識しています）がB2BUAとして機能します。
For simplicity, the invitations by the Conference Focus to the other members of the group are not shown in this example.
簡単にするために、会議による招待状は、グループの他のメンバーへの焦点を示していません。この例には示されていません。
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：オンデマンドセッションを使用した事前に配置されたグループコール
1 INVITE Alice -> Alice's PTT Server
1 Alice-> Aliceの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
(SDP not shown)
（SDPが表示されていません）
2 INVITE Alice's PTT Server -> Conference Focus
2アリスのPTTサーバーを招待する - >会議フォーカス
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
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
(SDP not shown)
（SDPが表示されていません）
The Conference Focus explodes the Conference URI and Invites Bob
カンファレンスフォーカスはカンファレンスURIを爆発させ、ボブを招待します
3 INVITE Conference Focus -> Bob's PTT Server
3カンファレンスフォーカスを招待 - >ボブの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
(SDP not shown)
（SDPが表示されていません）
4 INVITE Bob's PTT Server -> Bob
4ボブのPTTサーバーを招待します - >ボブ
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
(SDP not shown) 5 183 (Session Progress) Bob's PTT Server -> Conference Focus
（SDPが表示されていません）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
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)
7 200 (OK) Alice's PTT Server -> Alice
7 200（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)
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
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
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
(SDP not shown) 11 ACK Bob's PTT Server -> Bob
（SDPが表示されていません）11 ACK BOBの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
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
(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
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の呼び出しを行っています。事前に確立されたセッションは、AliceのPTTサーバーを使用してAliceのPTTサーバーを使用して、SIP Invite SDPオファーアンスワーエクスチェンジを使用して、アリスがコミュニケーションを開始する前にメディアセッションに使用するコーデックやその他のメディアパラメーターを事前に交渉することです。アリスがボブとの通信を開始すると、SIP紹介リクエストが使用され、アリスのPTTサーバーがBOBにSIP Inviteリクエストを送信するよう要求します。この例では、ボブの端末は、事前に確立されたセッションメカニズムを使用していません。
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.
この例では、AliceのPTTサーバーはB2BUAとして機能し、会議フォーカス関数も実行します。Bobの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 Alice-> Aliceの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
(SDP not shown) 2 200 (OK) Alice's PTT Server -> Alice
（SDPが表示されていません）2 200（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
(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
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
4 Alice-> AliceのPTTサーバーを参照してください
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>
5 202 (ACCEPTED) Alice's PTT Server -> Alice
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>
6 INVITE Conference Focus -> Bob's PTT Server
6招待カンファレンスフォーカス - >ボブの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
(SDP not shown)
（SDPが表示されていません）
7 INVITE Bob's PTT Server -> Bob
7ボブのPTTサーバーを招待します - >ボブ
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
(SDP not shown) 8 183 (Session Progress) Bob's PTT Server -> Conference Focus
（SDPが表示されていません）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
9 NOTIFY Alice's PTT Server -> Alice
9 AliceのPTTサーバーに通知 - > Alice
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
SIP/2.0 183 Session Progress
To: "Bob" <sip:bob@example.com>;tag=d28119a
P-Answer-State: Unconfirmed
10 200 (OK) Alice -> Alice's PTT Server
10 200（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 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.
sip/2.0 200 ok via：sip/2.0/udp alicspre-eatablishedsession@alicespttserver.example.org;branch = z9hg4bknashds8 to：<sip：alicesconfermefactoryuri.example.org>; tag = c70ef99 from： "alice" <sip：alice@example.org>; tag = 192830174 Call-ID：A84B4C76E6710 CSEQ：314161アリスと会議の焦点の間のメディアセッションが確立され、会議の焦点はアリスから受け取ったメディアをバッファリングします。
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
(SDP not shown)
（SDPが表示されていません）
12 ACK Bob's PTT Server -> Bob
12 ACK BOBの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
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
(SDP not shown) 14 ACK Conference Focus -> Bob's PTT Server
（SDPが表示されていません）14 ACK Conferenceフォーカス - >ボブの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
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 AliceのPTTサーバーに通知 - > Alice
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
SIP/2.0 200 OK
To: "Bob" <sip:bob@example.com>;tag=d28119a
P-Answer-State: Confirmed
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
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-Answer-Stateヘッダーで返された情報は、特に敏感であるとは見なされません。むしろ、それは本質的に情報に基づいており、この応答の回答の結果として送信されたメディアの配信が保証されていないことを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-Answer-Stateヘッダーがプロキシと中間UASによって使用および追加されるため、エンドツーエンドの保護は適切ではありません。その結果、シグナリングパス上のUASまたは攻撃者の間の「悪意のある」プロキシは、ヘッダーを追加または削除したり、ヘッダー値の内容を変更したりする可能性があります。この攻撃は、Calleeがまだ接触していないという知識を発信者に否定するか、すでに回答したときにCalleeがまだ接触していないことを誤って示します。すでに攻撃に応答したときにカリーがまだ接触していないことを誤って示している攻撃は、発信者がメディアを送信しないことを決定する可能性があることを誤って示しています。。カリーを否定する攻撃は、カリーにまだ接触していないという追加の知識を拒否する攻撃は、これはCalleeが使用せずに回答する前に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.
したがって、プロキシと実装の間のメッセージを保護する必要があります。これは、信号ホップ間で整合性と機密性を提供するトランスポートを使用する必要があります。SIPの輸送層セキュリティ（TLS）[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.
著者は、ジョン・ピーターソン、カレン・ジェニングス、ジェロエン・ヴァン・ベメル、ポール・キジバット、デール・ウォーリー、ディーン・ウィリス、ロハン・マヘイ、クリスチャン・シュミット、マイク・ハンマー、ミゲル・ガルシア・マルティンに感謝します。。著者はまた、この文書のサポートについてOMA POCワーキンググループのメンバーに、特にTom HillerがIETF 62をすすりながらP-Answer-Stateヘッダーの概念を提示してくれたことにも感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[3] OMA, "Push to talk over Cellular - Architecture", OMA-AD-PoC-V1_0_1-20061128-A, November 2006.
[3] OMA、「Cush To To Talk Talk Over Cellular-Architecture」、Oma-Ad-Poc-V1_0_1-20061128-A、2006年11月。
[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, November 2002.
[4] Sparks、R。、「インターネットメディアタイプメッセージ/Sipfrag」、RFC 3420、2002年11月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[5] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[6] Sparks、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[8] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[9] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のフレームワーク」、RFC 4353、2006年2月。
[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] Garcia-Martin、M。、「セリュールオーバーセルラー（POC）サービスをサポートするさまざまな設定のセッション開始プロトコル（SIP）イベントパッケージとデータ形式」、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] Willis、D.、ed。、およびA. Allen、「セッション開始プロトコル（SIP）の回答モードを要求する」、2007年6月、進行中の作業。
[13] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[13] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[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.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）のヘッダーフィールドの理由」、RFC 3326、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] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[16] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006.
[16] Rosenberg、J。、「セッション開始プロトコル（SIP）でのダイアログ識別による承認を要求する」、RFC 4538、2006年6月。
[17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[17] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[18] Rosenberg、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] Campbell、B.、Rosenberg、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] Niemi、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] Mankin、A.、Bradner、S.、Mahy、R.、Willis、D.、Ott、J。、およびB. Rosen、「セッション開始プロトコルの変更プロセス（SIP）」、BCP 67、RFC 3427、12月2002年。
Authors' Addresses
著者のアドレス
Andrew Allen (editor) Research in Motion (RIM) 102 Decker Court, Suite 100 Irving, Texas 75062 USA
Andrew Allen（編集者）Research in Motion（RIM）102 Decker Court、Suite 100 Irving、Texas 75062 USA
EMail: aallen@rim.com
Jan Holm Ericsson Tellusborgsvagen 83-87 Stockholm 12526 Sweden
Jan Holm Ericsson Tellusborgsvagen 83-87 Stockholm 12526 Sweden
EMail: Jan.Holm@ericsson.com
Tom Hallin Motorola 1501 W Shure Drive Arlington Heights, IL 60004 USA
トム・ハリンモトローラ1501 Wシュールドライブアーリントンハイツ、イリノイ州60004 USA
EMail: thallin@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。