RFC4964 日本語訳
4964 The P-Answer-State Header Extension to the Session InitiationProtocol for the Open Mobile Alliance Push to Talk over Cellular. A.Allen, Ed., J. Holm, T. Hallin. September 2007. (Format: TXT=67505 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Allen, Ed.
Request for Comments: 4964 Research in Motion (RIM)
Category: Informational J. Holm
Ericsson
T. Hallin
Motorola
September 2007
ワーキンググループのA.アレン、エドをネットワークでつないでください。コメントのために以下を要求してください。 4964は動き(縁)カテゴリで研究されます: 情報のJ.のホルムエリクソンT.ハリンモトローラ2007年9月
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.
このドキュメントはPushがOMA PoCアプリケーションに制限される適用性に伴うCellular(PoC)について論議するのにオープンのモバイルAlliance(OMA)によって使用された個人的なSession Initiationプロトコル(SIP)ヘッダー(P-ヘッダー)について説明します。 P答え州のヘッダーは、PoCアプリケーションに特定の受話器の回答モードを示すのに使用されます。
Allen, et al. Informational [Page 1] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[1ページ]のRFC4964P答え州のヘッダー2007年9月
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
1. 序論…3 2. 総合的な適用性…3 3. 用語…3 4. 拡大のためのバックグラウンド…4 5. 概要…5 6. P答え州のヘッダー…6 6.1. 要件…8 6.2. 考えられた代替手段…8 6.3. P答え州のヘッダーのための適用性証明…9 6.4. P答え州のヘッダーの使用法…10 6.4.1. UA(端末)の手順…11 6.4.2. UA(PTTサーバ)の手順…11 6.4.3. Proxyサーバにおける手順…14 7. 正式な構文…14 7.1. P答え州のヘッダー構文…14 7.2. 新しいヘッダーのテーブル…14 8. 例の用法セッションは流れます…15 8.1. 根回しされたグループは、使用の要求次第のセッションを召集します…15 8.2. 1-1 呼び出し使用はセッションをあらかじめ確立しました…21 9. セキュリティ問題…28 10. IANA問題…28 10.1. ヘッダーフィールドの登録…28 11. 承認…29 12. 参照…29 12.1. 標準の参照…29 12.2. 有益な参照…30
Allen, et al. Informational [Page 2] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[2ページ]のRFC4964P答え州のヘッダー2007年9月
1. Introduction
1. 序論
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.
オープンのモバイルAlliance(OMA)( http://www.openmobilealliance.org )は、SIPが異なった関係者の向こう側に半二重メディアセッションを証明するのに使用されるプロトコルであるところでOver Cellular(PoC)サービスについて話すためにPushを指定しています。 このドキュメントは、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サービスは同時に1SIP UAsにセッションを証明するためには(PoC端末)の、そして、通常、ボタンを押している開始しているユーザによって開始されたSIP Userエージェント(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サービスを支持して非常に厳しい要件の収集を定義しました。 満足できる経験をユーザに提供するために、初期のセッション設立(ユーザがボタンを押す時から彼らが指示に話させる時間までの)を最小にしなければなりません。
2. Overall Applicability
2. 総合的な適用性
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拡張子はネットワーク形態に関する仮定と遷移的な信頼の存在を確実にします。 一般に、これらの仮定は全体でインターネットのNOT APPLICABLEです。 ここで指定されたメカニズムは、Pushがどれが汎用ソリューションは全く見つけられなかったか、そして、不十分な運用経験が一般解が必要であるかどうか理解するためにどこで入手できたか、そして、または、より一般的なソリューションがどこでまだ熟していないかにCellularについて論議するようにオープンのモバイルAllianceによって指定された要件を満たすように設計されました。 この拡大に関してされた仮定に関するその他の詳細に関しては、セクション6.3で適用性証明を参照してください。
3. Terminology
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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-
ここに言及される「PTTサーバ」はPushがサービスについて話すようにネットワークベースの機能を実行するSIPネットワークサーバです。 PTT ServerがSIP Proxyとして機能できる、([2])か後部では、定義されます。
Allen, et al. Informational [Page 3] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[3ページ]のRFC4964P答え州のヘッダー2007年9月
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 Pushにかかわる1PTT Serversがあることができます。
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).
「確認された応答」は、「確認された指示」を含むSIP200(OK)応答であり、答え(Session記述プロトコル(SDP)答えなどの)を含むSIP200(OK)応答の普通の意味論を持っています。
4. Background for the Extension
4. 拡大のためのバックグラウンド
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端末を構成する能力を提供するスピーカーフォーン、そして/または、ヘッドホンとソフトウェアを受け取るようにそのようなハードウェアが能力であるとサポートするかもしれません。 この運転モードはAutomatic Answerモードとして知られています。 あるいはまた、ユーザは、最初に、ユーザを警告して、ユーザが手動でメディアの前にセッション招待に応じるのが必要であるPoC端末が受け入れられるのを構成できます。 この運転モードはManual Answerモードとして知られています。 PoC端末は両方かこれらの運転モードの1つだけをサポートするかもしれません。 ユーザは頻繁に彼らの現在の事情と好みに基づくPoC端末のAnswer Mode(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
OMA PoC Architecture3は会議焦点10、リアルタイムのトランスポート・プロトコル(RTP)翻訳者、またはネットワーク方針実施サーバのような役割を実行できるネットワークの中でPTT Serversを利用します; または、話すために指示への訪問者の提供の遅れを最小にする可能な最適化がPTTサーバが提供するためにメディア向けの資料セットのバッファリングを実行することである、早さ、「未確認の指示」は、訪問者が呼ぶことのPoC端末が答えた前に話し始めるのを訪問者に支持して、許容します。 イベントパッケージとSIP UAがバッファリングを可能にするために現在のアンサーモードをPTT Serverに示すメカニズムは定義されます。
Allen, et al. Informational [Page 4] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[4ページ]のRFC4964P答え州のヘッダー2007年9月
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).
[11]で。 特に複数のドメインがセッションにかかわるとき、さらに、1PTT Serverがセッションのためにシグナリング経路にかかわることができました。 また、バッファリングを実行するPTT ServerはSIP INVITE要求のための最終的な目的地であるSIP UAの現在のアンサーモードに関する知識があるPTT Serverでないかもしれません。 メカニズムは特定のモードで答えるために最終的な目的地のSIP UserエージェントServer(UAS)に優先を示すためにSIP UA(またはSIP UAとして機能するPTT Serverとして)として作用する端末を許容する[12]で定義されます。 しかしながら、PTT Serverが起因しているSIP UserエージェントClient(UAC)に向かった応答における「未確認の指示」をリレーするのにメカニズムが必要です。
5. Overview
5. 概要
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.
この拡大の目的はネットワークが経験について話すために、より速いプッシュを提供するのを可能にする最適化をサポートすることです、呼ばれたUAの前でSIP200(OK)に応答を供給するとする中間的SIPユーザエージェント(PTT Server)、および答えるとき再生のために呼んでいるUAによって呼ばれたUAに作られたメディアをバッファリングするPTT Serverを通して。 呼び出しの半二重本質のために、終わりから終わりへの追加潜在を許容できます、そして、これはユーザー・エクスペリエンスをかなり改良します。(そこでは、メディア炸裂が通常、10-30秒の注文で短いです)。 しかしながら、呼ばれたSIP UAがAutomatic Answerモードであるという高い確率があるとき、PTT Serverだけがこれができます。 呼ばれたUAの近くのPTT Serversには、呼ばれたUAの回答モードに関する最新の知識がありそうです、そして、セルラー・ネットワークの制限された帯域幅本質のため、彼らは上流へ呼ばれたUAが自動的に生成しているSIP200(OK)に応答を提供できるより速くモードに答える呼ばれたSIP UAのもののしるしを通過できます。
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 INVITE要求への応答、または送られるようSIP INVITE要求に要求するSIP REFER要求の結果、送られたSIP NOTIFY要求に応答を含むsipfragに任意に新しいSIPヘッダーフィールドを含むことができます。 ヘッダーフィールドは、SIPプロキシとして務めるPTT Serverか背中合わせのUAからのそれには終わっているUAがおそらく自動的に答えると暗示する情報があるという指示を提供するのに使用されます。 これは、SIP INVITE要求の最終的な目的地から最終的な応答を受ける前にメディアを伝えるために「未確認の指示」を誘っているSIP UAに向かって供給して戻します。 P答え州のヘッダーフィールドの送付者が拡大を理解するために受信機によらないので、どんなSupportedもRequireヘッダーも必要ではありません。 拡大が理解されていないなら、ヘッダーフィールドは受取人によって単に無視されます。 拡大は以下で説明されます。
Allen, et al. Informational [Page 5] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[5ページ]のRFC4964P答え州のヘッダー2007年9月
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 Serverが、SIP INVITE要求を転送して、呼ばれたUAがAutomatic Answerモードでありそうであるのを知っているとき、それは、彼らが訪問者のメディアをバッファリングできると上流のPTT Serversに合図するために「未確認」のパラメタがあるP答え州のヘッダーフィールドでSIPが183の暫定的な応答であると生成します。
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 Serverは、それを吸収して、訪問者のSIP UAのために適切な答えでSIP200(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が、SIP200(OK)が応答であると生成すると、パラメタが「未確認」の状態でP答え州のヘッダーフィールドで暫定的な応答を生成したPTT Serverが「確認されること」のパラメタでSIP200(OK)応答にP答え州のヘッダーフィールドを加えます。 SIP200(OK)応答は訪問者のメディアをバッファリングしているPTT Serverによって吸収されます、SIP200(OK)が応答であると既に生成したとき。 そして、バッファリングPTT Serverはバッファリングされたメディアを展開し始めます。
6. The P-Answer-State Header
6. P答え州のヘッダー
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 Serverか背中合わせのUAからのそれにはUAが要求のRequest-URIで特定した終わりにおそらく自動的に答えると暗示する情報があるという指示を提供することです。 したがって、それは、PTT ServerがSIP INVITE要求の最終的な目的地から最終的な応答を受ける前にメディアを伝えるのを可能にする誘っているSIP UAに向かって「未確認の指示」を供給して戻すのを可能にします。 暫定的な応答が値が「未確認」のP答え州のヘッダーフィールドを含んでいて、PTT Serverが、メディアバッファリングを実行しても構わないと思っていて、答えは含んでいないなら、値が「未確認」の状態で受信PTT Serverが答えを含むSIP200(OK)応答とP答え州のヘッダーフィールドを送ることができます。 また、また、値が「未確認」のP答え州のヘッダーフィールドを含む応答が答えを含んでいるなら、応答におけるP答え州のヘッダーフィールドと答えを含んでいたPTT Serverは、それが決勝が「指示を確認する」までメディアをバッファリングするのが受け取られていることを望んでいるのを示しています。
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
SIP INVITE要求への暫定的であるか最終的な応答かSIP INVITE要求を送るというSIP REFER要求の結果、送られたSIP NOTIFY要求のsipfragにP答え州のヘッダーフィールドを含むことができます。 値が「未確認」のP答え州のヘッダーフィールドが答えを含む暫定的な応答に含まれているなら、PTT Serverはどこで上流へ他のPTTにServersをバッファリングして、意志をするかに関する決定を前進の上流のaに任せています。
Allen, et al. Informational [Page 6] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[6ページ]のRFC4964P答え州のヘッダー2007年9月
"Confirmed indication" in a SIP 200 (OK) response when the final response is received from the destination UA.
目的地UAから最終的な応答を受けるとき、SIP200(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.
注意Itによる意図しないで、そんなに複数のPTT Serversが順次バッファリングを実行するということです。 PTT Serverが暫定的な応答で「未確認」の値でP状態に答えているヘッダーフィールドに伴う答えを含んでいるなら、受信PTT Serverは、それが、メディアをバッファリングするか、メディアを転送して、または「未確認の指示」を送ったdownstrean PTT Serverがメディアをバッファリングするのを許容するかを決定できます。 PTT Serverがメディアをバッファリングするなら、最終的な「確認された指示」が受け取られているまでそうして、したがって、複数のPTTでServersをバッファリングするシリーズが行われないことを意図します。
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.
応答を送るノードがそれ自体と起因しているUACの間のシグナリング経路でこの拡大を理解しているB2BUAとして機能するPTT Serverがあるという知識を持っていると、P答え州のヘッダーは暫定的な応答に含まれているだけです。 要求はSIP REFERの結果、定義されるように[5])で発信していました。送付ノードと起因しているUACの間のこのPTT ServerがSIP200(OK)応答かsipfragでヘッダーフィールドを伝えるだけである、(SIP NOTIFY要求の[4])で定義される、(([6])で定義されるように。 そのような状況は特定のネットワークtopologiesで起こるだけです。(topologiesはこのヘッダーフィールドの使用が一般的なインターネットに関連していない別の理由です)。 起因しているUACはSIP200(OK)応答かSIP NOTIFY要求のsipfragでP答え州のヘッダーフィールドを受けるだけでしょう。
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要求が受信されている前にSIP INVITE要求のための200(OK)応答を送ることができません。 したがって、送付の暫定的な応答は潜在的に「確認された応答」の発信を確かに遅らせるかもしれません。
Allen, et al. Informational [Page 7] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[7ページ]のRFC4964P答え州のヘッダー2007年9月
6.1. Requirements
6.1. 要件
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加入者がセッションを受け入れるまで誘っているPoC加入者からのメディアをスプールするB2BUAとして機能するPTT Serverが満たすことができる初期のセットアップ性能必要条件があります。 決められた一定の要求は以下の通りです。
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 INVITE要求を受け入れないでも、スプールメディアのできる中間的サーバは誘っているSIP UACからSIP 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 UASsが誘っているSIP UACにメディアをスプールしているというSHOULDが示すSIP INVITE要求を受け入れるまで誘っているSIP UACからのメディアをスプールしても構わないと思っている中間的サーバ。
6.2. Alternatives Considered
6.2. 考えられた代替手段
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 Serverは、おそらく必要なユーザ介入なしでSIP INVITE要求を受け入れるのに招待されたSIP UAが指示後部ですが、受信する必要があります。 この場合、招待されたSIP UACが要請を受け入れそうであるというヒントを持っているPTT ServerはSIP183(セッションProgress)応答かSIP200(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 Serverが招待されたPoC SIP UASのアンサーモード設定について別のPTT Serverか誘っている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つの提案はSIP183応答とSIP200(OK)応答におけるユニークな理由句を作成することでした。 これは、理由句が人間の読者のために通常意図するので拒絶されて、特別な構文的、そして、意味的な意味のためにサーバによって分析されることを意味しませんでした。
Allen, et al. Informational [Page 8] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[8ページ]のRFC4964P答え州のヘッダー2007年9月
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.
別の提案はSIP183応答とSIP200(OK)応答にReasonヘッダー[14]を使用することでした。 Reasonヘッダーの意図している使用に矛盾しているでしょう、したがって、これが拒絶されて、用法は、これらの応答コードのために定義されないで、新しいプロトコル識別子を作成して、登録するのを必要としたでしょう。
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は、申し出が答えられて、受け入れられたのを見ますが、ヘッダーは、招待されたPoC加入者かまさしく仲介者がSIP INVITE要求を受け入れたかどうかをUACに知らせます。
6.3. Applicability Statement for the P-Answer-State Header
6.3. P答え州のヘッダーのための適用性証明
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 半二重コミュニケーションに従事している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サーバは、誘っているユーザがメディアを送る時間を短縮するためにメディアのバッファリングを提供できます。
Allen, et al. Informational [Page 9] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[9ページ]のRFC4964P答え州のヘッダー2007年9月
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.
さらに、問題にはあるセキュリティは、信じられるネットワークのために考えられるだけであり、ホップごとの遷移的な信頼があるセキュリティー対策を使用します。 一般的なインターネットのこのメカニズムの使用法の安全保障問題は評価されていません。
6.4. Usage of the P-Answer-State Header
6.4. P答え州のヘッダーの使用法
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 INVITE要求に含まれた申し出に対応して送られた申し出を含まないどんなSIP 18xや2xx応答でもP答え州のヘッダーフィールドを入れるかもしれません。 通常、P答え州のヘッダーフィールドはSIP183Session ProgressかSIP200(OK)応答のどちらかに含まれています。 また、SIP INVITE要求を送るというSIP REFER要求を受け取るUAは、それがSIP REFER要求で作成された暗黙の購読の結果、送るSIP NOTIFY要求に応答のsipfragのP答え州のヘッダーフィールドを含んでいるのを含むかもしれません。
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 INVITEのためのUASが要求する最終的な目的地が自動的にセッションを受け入れそうですが、これが未確認であり、最終的な目的地UASが最初に、ユーザを警告して、セッションの手動の承認を必要とするか、またはセッション要求を受け入れないのが、可能であると暗示する情報があるのを示しています。 P答え州のヘッダーフィールドが「確認される」というパラメタを含むとき、UASかプロキシが、目的地UASがセッションを受け入れたのを示していて、メディアを受け取る準備ができています。 「確認されること」のパラメタ値は、答えを含むSIP200(OK)応答の普通の意味論を持っていて、完全性のために含まれています。 「確認されること」のパラメタ値はSIP200(OK)応答かSIP NOTIFY要求のボディーに含まれた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答え州のヘッダーのない容認されたSIP 18x応答は「未確認の応答」として扱われた状態でSHOULD NOTをさばきます。 これが無効の状態であるので、「確認される」というパラメタを含むP答え州のヘッダーフィールドを含むSIP 18x応答を「確認された応答」として扱ってはいけません。
A SIP 200 (OK) response without a P-Answer-State Header field MUST be treated as a "Confirmed Response".
P答え州のHeader分野のないSIP200(OK)応答を「確認された応答」として扱わなければなりません。
Allen, et al. Informational [Page 10] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[10ページ]のRFC4964P答え州のヘッダー2007年9月
6.4.1. Procedures at the UA (Terminal)
6.4.1. UAの手順(端末)
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]で指定されたメカニズムは、招待されたユーザが加わったことを決定するのに使用されるかもしれません。 あるいはまた、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 REFER要求に対応して[5]によると、うまくいっている申し出答え交換があった対話に関連するSIP NOTIFY要求のボディーにsipfragに「未確認の応答」を含むSIP NOTIFY要求を受け取るUAC(端末)はメディアを送るかもしれません。 しかしながら、メディアがそれが示された最終的な受取人によって受け取られるという保証が全くない、Refer、-、ヘッダー、オリジナルのSIP REFER要求で。 同じ対話でSIP REFER要求を送ったか、またはSIP REFER要求が[16]で定義されるようにTarget-対話ヘッダーを含んだのでそれが対話を特定したので、対話を関係づけることができました。
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答え州の手順が全くありません。
6.4.2. Procedures at the UA (PTT Server)
6.4.2. UAの手順(PTTサーバ)
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から「確認された応答」をまだ受けていないなら、背中合わせのUA MAYのUAS部分でのSIP INVITE要求を受け取るPTT Serverは申し出を含まないどんなSIP 18xや2xx応答にも応答で「未確認」のパラメタがあるP答え州のヘッダーフィールドを含んでいます、そして、それには、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
パラメタが「未確認」の状態で背中合わせのUA MAYのUAC部分でP答え州のヘッダーフィールドを含むSIP INVITE要求へのSIP 18x応答を受けるPTT ServerはSIPで「未確認」のパラメタがあるP答え州のヘッダーフィールドを含んでいます。
Allen, et al. Informational [Page 11] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[11ページ]のRFC4964P答え州のヘッダー2007年9月
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".
その応答を受けることの結果、UASが離れさせる背中合わせのUAの2xx応答は発信します。 さもなければ、背中合わせのUA SHOULDのUAC部分におけるP答え州のヘッダーフィールドを含むSIP 18xを受けるPTT ServerかSIP INVITE要求への2xx応答がSIP 18xで変更されていないP答え州のヘッダーフィールドかその応答を受けることの結果、背中合わせのUAのUAS部分が送る2xx応答を含んでいます。 背中合わせの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.
背中合わせのUAのUAC部分によって受け取られた「未確認の応答」が答えを含まなかったとしても、PTT Serverの背中合わせのUAのUAS部分はそれが送る「未確認の応答」における答えを含むかもしれません。
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 Serverが背中合わせのUAのUAC部分での「確認された応答」を受けるなら、背中合わせのUA MAYのUAS部分は進められた応答にパラメタが「確認されている」P答え州のヘッダーフィールドを含んでいます。 背中合わせのUAの一部が以前にこの対話の一部、背中合わせのUA SHOULDのUAS部分として「未確認の応答」を送ったUASが進められた「確認された応答」にパラメタが「確認されている」P答え州のヘッダーフィールドを含んでいるなら。
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 Serverの背中合わせのUAのUAS部分がP答え州のヘッダーフィールドに伴う応答における答えを含んでいるなら、背中合わせのUAのUAS部分は、[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 INVITE要求を別のUAに送るというSIP REFER要求を受け取るPTT Serverの背中合わせのUAのUAS部分はそれに暗示する情報があるならSIP INVITE要求への応答を受ける背中合わせの自動的に受け入れそうなSIP INVITEのための最終的な目的地UAがセッションを要求するUAのUAC部分の前でP答え州のヘッダーフィールドを含むSIP200(OK)応答のsipfragを発生させるかもしれません。
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,
PTT Serverの背中合わせのUAのUAC部分が背中合わせのUAのUAC部分でSIP REFER Requestを受けることの結果、SIP INVITE要求を送って、P答え州のヘッダーフィールドを含むSIP 18xか2xx応答を受けるなら、後部へのUA SHOULDのUAS部分はSIP NOTIFY要求に含まれた応答のsipfragにP答え州のヘッダーフィールドを含んでいます。 sipfragに含まれているP答え州のヘッダーフィールド
Allen, et al. Informational [Page 12] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[12ページ]のRFC4964P答え州のヘッダー2007年9月
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.
変更されていなかった状態でオリジナルの応答からのP答え状態からのパラメタを含んでいます。 このSIP NOTIFY要求はPTT Serverの背中合わせのUAのUAS部分がSIP 18xか2xx応答を受けるのに基づくオリジナルのSIP REFER要求に対応して発信するというSIP NOTIFY要求です。 応答のsipfragが、SIP NOTIFY要求がSIP 18x応答であることを送ったなら、応答のsipfragにP答え州のヘッダーフィールドを含んでいると、「未確認」のパラメタは含まなければなりません。 背中合わせのUAのUAC部分がP答え州のヘッダーフィールドを含まない「確認された応答」を受けるなら、背中合わせのUA MAYのUAS部分はパラメタがSIP REFER要求に対応して送られたSIP NOTIFY要求に含まれた応答のsipfragで「確認されている」P答え州のヘッダーフィールドを含んでいます。
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:
以前に背中合わせのUAのUAS部分であるPTT ServerがSIP REFERの結果、SIP 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 Serverは次に、後部への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 Server SHOULDは、「確認された応答」を受けることの結果、後部から逆UAのUAS部分が発信するというその後のSIP NOTIFY要求にパラメタが応答のsipfragで「確認されている」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 REFER要求がうまくいっている申し出答え交換があったSIP INVITE要求で確立された既存の対話に関連されるなら、背中合わせのUaのUAS部分は[7]で指定されているとしてメディアを受け取る準備ができているに違いありません。 また、背中合わせのUAのUAC部分が最終的な目的地UAから「確認された応答」を受けるか、またはバッファが完全になるまで、それは受け取るどんなメディアもバッファリングするかもしれません。 同じ対話でSIP REFER要求を送ったか、またはSIP REFER要求が[16]で定義されるようにTarget-対話ヘッダーを含んだのでそれが対話を特定したので、対話を関係づけることができました。
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.
「確認された応答」がリリースするなら「確認された応答」とSHOULDを受けない可能性がセッションをリリースするので、バッファがあふれる前に、準備されていて、メディアSHOULDをバッファリングするPTT Serverは受信しませんでした。
Allen, et al. Informational [Page 13] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[13ページ]のRFC4964P答え州のヘッダー2007年9月
6.4.3. Procedures at the Proxy Server
6.4.3. Proxyサーバにおける手順
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 Serverはそれが溯源するSIP 18x応答で「未確認」のパラメタがあるP答え州のヘッダーフィールドを含むかもしれません。([2])による対応することの方法で、それに情報があるなら、それは、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 ServerはP答え州のヘッダーフィールドを加えるかもしれません。
7. Formal Syntax
7. 正式な構文
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から引き継がれて、ここで繰り返されません。 Implementersは、このドキュメントを理解するのにSIP[2]と[8]の記法とコンテンツによく知られる必要があります。
7.1. P-Answer-State Header Syntax
7.1. P答え州のヘッダー構文
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答え状態」HCOLON答えタイプ*(SEMIジェネリック-param)答えP答え状態=タイプは「確認された」か「未確認」の/象徴と等しいです。
7.2. Table of the New Header
7.2. 新しいヘッダーのテーブル
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]でTable2を広げるのが必要であるP答え州のヘッダー、SIPの特定のイベント通知[5]のセクション7.1、SIP INFO方法[17]によるTables1と2、SIP[13]の暫定的な応答のReliabilityのTables1と2、SIP UPDATE方法[18]によるTables1と2、Instant Messaging[19]のためのSIP拡張子でのTables1と2、SIP REFER方法[6]によるTable1、およびSIP PUBLISH方法[20]によるTable2に追加テーブル項目を供給します:
Allen, et al. Informational [Page 14] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[14ページ]のRFC4964P答え州のヘッダー2007年9月
Header field where proxy ACK BYE CAN INV OPT REG SUB
_______________________________________________________________
P-Answer-State 18x,2xx ar - - - o - - -
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG SUB_______________________________________________________________ P答え州の18x、2xx ar--、--、--o----、-
Header field NOT PRA INF UPD MSG REF PUB
_______________________________________________________________
P-Answer-State R - - - - - - -
ヘッダーフィールドNOT PRA INF UPD MSG REF PUB_______________________________________________________________ P答え州のR--、--、--、--、--、--、-
Table 1: Additional Table Entries for the P-Answer-State Header
テーブル1: P答え州のヘッダーのための追加テーブル項目
8. Example Usage Session Flows
8. 例の用法セッション流れ
For simplicity, some details such as intermediate proxies and SIP 100 Trying responses are not shown in the following example flows.
簡単さにおいて、中間的プロキシやSIP100Trying応答などのいくつかの詳細は以下の例の流れで示されません。
8.1. Pre-Arranged Group Call Using On-Demand Session
8.1. 要求次第のセッションを使用する根回しされたグループ呼び出し
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を使用することでアリスが根回しされたグループが電話をさせるのを示します。 セッション開始はアリスが彼女の押して話しボタンを押すときSDP申し出を含むSIP 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 ServerはServer(ボブの端末の現在のAnswer Mode設定がAuto Answerに設定されるのを意識している)がB2BUAとして機能させるCall Stateful SIP ProxyとボブのPTTを活動させます。
For simplicity, the invitations by the Conference Focus to the other members of the group are not shown in this example.
簡単さにおいて、グループの他のメンバーへのコンファレンスFocusによる招待状はこの例に示されません。
Allen, et al. Informational [Page 15] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[15ページ]のRFC4964P答え州のヘッダー2007年9月
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======>|
| | | | |
| | | | |
アリスのアリスのConferenceボブのボブの端末のPTTサーバ焦点PTTサーバ端末| | | | | |--(1)招待-->|、|、|、|、| |--(2)招待-->|、|、|、|、| |--(3)招待>|、|、|、|、| |--(4)招待-->|、|、| | <--(5)183----| | | | <、-、--(6)200----| | | | <、-、--(7)200----| | | | |----(8)ACK--->|、|、|、|、| |---(9)ACK---->|、|、|、|、|、|、|、| |=====早めのメディアセッション====>|、|、|、|、| メディア| | | | バッファリング| | | | | | <、-、--(10)200---| | | | |---(11)ACK--->|、|、| | <--(12)200---| | | | |--(13)ACK--->|、|、|、|、|、|、|、|、| |========メディアセッション======>|、|、|、|、|、|、|、|、|、|、|
Figure 1: Pre-Arranged Group Call Using On-Demand Session
図1: 要求次第のセッションを使用する根回しされたグループ呼び出し
1 INVITE Alice -> Alice's PTT Server
1 アリス・->アリスの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
INVITE一口: FriendsOfAlice@example.org SIP/2.0Via: 一口/2.0/UDP pc33.example.org; ブランチは前方へz9hG4bKnashds8マックスと等しいです: 70 To: <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、From: 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 接触を招いてください: <一口: alice@pc33.example.org 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 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
INVITE一口: FriendsOfAlice@example.org SIP/2.0Via: 一口/2.0/UDP AlicesPTTServer.example.org; ブランチは以下を通ってz9hG4bK77ef4c2312983.1と等しいです。 一口/2.0/UDP pc33.example.org; ブランチ=z9hG4bKnashds8
Allen, et al. Informational [Page 16] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[16ページ]のRFC4964P答え州のヘッダー2007年9月
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
記録的なルート: <一口: 前方へAlicesPTTServer.example.org>マックス: 69 To: <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、From: 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 接触を招いてください: <一口: alice@pc33.example.org 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 142
(SDP not shown)
(見せられなかったSDP)
The Conference Focus explodes the Conference URI and Invites Bob
コンファレンスFocusはコンファレンスURIとInvitesボブを爆発させます。
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
INVITE一口: bob@example.com SIP/2.0Via: 一口/2.0/UDP AlicesConferenceFocus.example.org; ブランチは前方へz9hG4bK4721d8マックスと等しいです: 70 To: 「ボブ」<一口: bob@example.com 、gt;、From: <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、; タグは2178309898呼び出しIDと等しいです: e60a4c784b6716 CSeq: 301166605 接触を招いてください: <一口: AlicesConferenceFocus.example.org>コンテントタイプ: sdp Contentアプリケーション/長さ: 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
INVITE一口: bob@example.com SIP/2.0Via: 一口/2.0/UDP BobsPTTServer.example.com; ブランチは前方へz9hG4bKa27bc93マックスと等しいです: 70 To: 「ボブ」<一口: bob@example.com 、gt;、From: <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、; タグは781299330呼び出しIDと等しいです: 6eb4c66a847710 CSeq: 478209 接触を招いてください: <一口: BobsPTTServer.example.com>コンテントタイプ: sdp Contentアプリケーション/長さ: 142
(SDP not shown)
(見せられなかったSDP)
Allen, et al. Informational [Page 17] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[17ページ]のRFC4964P答え州のヘッダー2007年9月
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
以下を通って一口/2.0 183セッション進歩 一口/2.0/UDP AlicesConferenceFocus.example.org; ブランチ=z9hG4bK4721d8To: 「ボブ」<一口: bob@example.com 、gt;、;=a6c85cf From:にタグ付けをしてください <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、; タグは2178309898呼び出しIDと等しいです: e60a4c784b6716 Contact: <一口: BobsPTTServer.example.com>CSeq: 301166605 P答え状態を招待してください: 未確認のコンテンツの長さ: 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)
以下を通って一口/2.0 200OK 一口/2.0/UDP AlicesPTTServer.example.org; ブランチは以下を通ってz9hG4bK77ef4c2312983.1と等しいです。 一口/2.0/UDP pc33.example.org; ブランチはz9hG4bKnashds8の記録的なルートと等しいです: <一口: AlicesPTTServer.example.org>To: <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、;=c70ef99From:にタグ付けをしてください 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 接触を招いてください: <一口: AlicesConferenceFocus.example.org>P答え州: 未確認のコンテントタイプ: sdp Contentアプリケーション/長さ: 131 (見せられなかったSDP)
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
以下を通って一口/2.0 200OK 一口/2.0/UDP pc33.example.org; ブランチはz9hG4bKnashds8の記録的なルートと等しいです: <一口: AlicesPTTServer.example.org>To: <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、;=c70ef99From:にタグ付けをしてください 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 接触を招いてください: <一口: AlicesConferenceFocus.example.org>P答え州: 未確認のコンテントタイプ: sdp Contentアプリケーション/長さ: 131
Allen, et al. Informational [Page 18] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[18ページ]のRFC4964P答え州のヘッダー2007年9月
(SDP not shown)
(見せられなかった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はちびちび飲みます: 以下を通ってAlicesConferenceFocus.example.org一口/2.0 一口/2.0/UDP pc33.example.org; ブランチ=z9hG4bKnashds9は以下を発送します。 <一口: 前方へAlicesPTTServer.example.org>マックス: 70 To: <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、;=c70ef99From:にタグ付けをしてください 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出し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はちびちび飲みます: 以下を通ってAlicesConferenceFocus.example.org一口/2.0 一口/2.0/UDP AlicesPTTServer.example.org; ブランチは以下を通ってz9hG4bK77ef4c2312983.1と等しいです。 一口/2.0/UDP pc33.example.org; ブランチは前方へz9hG4bKnashds9マックスと等しいです: 69 To: <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、;=c70ef99From:にタグ付けをしてください 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出し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.
アリスとコンファレンスFocusとの早めの半二重メディアセッションは現在確立されます、そして、コンファレンスFocusはそれがアリスから受け取るメディアをバッファリングします。
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
以下を通って一口/2.0 200OK 一口/2.0/UDP BobsPTTServer.example.com; ブランチ=z9hG4bKa27bc93To: 「ボブ」<一口: bob@example.com 、gt;、;=d28119a From:にタグ付けをしてください <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、; タグは781299330呼び出しIDと等しいです: 6eb4c66a847710 CSeq: 478209 接触を招いてください: <一口: bob@192.0.2.4 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 131
(SDP not shown)
(見せられなかったSDP)
Allen, et al. Informational [Page 19] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[19ページ]のRFC4964P答え州のヘッダー2007年9月
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一口: bob@192.0.2.4 SIP/2.0Via: 一口/2.0/UDP BobsPTTServer.example.com; ブランチは前方へz9hG4bKa27bc93マックスと等しいです: 70 To: 「ボブ」<一口: bob@example.com 、gt;、;=d28119a From:にタグ付けをしてください <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、; タグは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
以下を通って一口/2.0 200OK 一口/2.0/UDP AlicesConferenceFocus.example.org; ブランチ=z9hG4bK4721d8To: 「ボブ」<一口: bob@example.com 、gt;、;=a6670811From:にタグ付けをしてください <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、; タグは2178309898呼び出しIDと等しいです: e60a4c784b6716 Contact: <一口: BobsPTTServer.example.com>CSeq: 301166605 P答え状態を招待してください: 確認されたコンテントタイプ: sdp Contentアプリケーション/長さ: 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はちびちび飲みます: 以下を通ってBobsPTTServer.example.com一口/2.0 一口/2.0/UDP AlicesConferenceFocus.example.org; ブランチは前方へz9hG4bK4721d8マックスと等しいです: 70 To: 「ボブ」<一口: bob@example.com 、gt;、;=a6670811From:にタグ付けをしてください <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、; タグは2178309898呼び出し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.
アリスとボブとのメディアセッションは現在確立されます、そして、コンファレンスFocusはバッファリングされたメディアをボブに転送します。
Allen, et al. Informational [Page 20] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[20ページ]のRFC4964P答え州のヘッダー2007年9月
8.2. 1-1 Call Using Pre-Established Session
8.2. 1-1 呼び出し使用はセッションをあらかじめ確立しました。
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をCallにするのをボブにプレ確立したセッションを使用することで示します。 プレ確立したセッションは対話がメディアセッションにコミュニケーションを開始するアリスの前で使用されるためにコーデックと他のメディアパラメタをあらかじめ交渉するアリスのPTT Server使用によるSIP INVITE SDP申し出の確立した答え交換であるところです。 アリスがボブにコミュニケーションを開始するとき、SIP REFER要求は、SIP INVITE要求をボブに送るようアリスのPTT Serverに要求するのに使用されます。 この例では、ボブの端末はプレ確立したセッションメカニズムを使用しません。
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 ServerはB2BUAとして機能して、また、コンファレンスFocus機能を実行します。 ボブのPTT Server(ボブの端末の現在のAnswer Mode設定がAuto Answerに設定されるのを意識している)はB2BUAとして機能します。
Allen, et al. Informational [Page 21] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[21ページ]のRFC4964P答え州のヘッダー2007年9月
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---------->| | |
| | | |
アリスのアリスのボブのボブの端末のPTTサーバ/PTTサーバ端末コンファレンス焦点| | | | |-----(1)招待------->|、|、| | <、-、-、-、--(2)200-----------| | | |-------(3)ACK--------->|、|、|、|、|、|、|、|、|、|、|、|、|、|、| |----(4)参照してください。---------->|、|、| | <、-、-、-、--(5)202-----------| | | | |----(6)招待---->|、|、|、| |--(7)招待---->|、|、|、|、|、| | <、-、-、--(8)183-------| | | <、-、--(9)通知してください。----------| | | |-----(10)200---------->|、|、|、|、|、|、| |=早めのメディアセッション=>|、|、|、| メディア| | | バッファリング| | | | | <、-、--(11)200-----| | | |---(12)ACK----->|、| | <、-、-、--(13)200------| | | |-----(14)ACK----->|、|、| |===========メディアセッション==========>|、|、|、|、| | <、-、--(15)通知してください。---------| | | |-----(16)200---------->|、|、|、|、|、|、|
Figure 2: 1-1 Call Using Pre-Established Session
図2: 1-1 呼び出し使用はセッションをあらかじめ確立しました。
1 INVITE Alice -> Alice's PTT Server
1 アリス・->アリスの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
一口を招待してください: 以下を通ってAlicesConferenceFactoryURI.example.org一口/2.0 一口/2.0/UDP pc33.example.org; ブランチは前方へz9hG4bKnashds8マックスと等しいです: 70 To: <一口: AlicesConferenceFactoryURI.example.org>From: 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 接触を招いてください: <一口: alice@pc33.example.org 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 142
(SDP not shown)
(見せられなかったSDP)
Allen, et al. Informational [Page 22] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[22ページ]のRFC4964P答え州のヘッダー2007年9月
2 200 (OK) Alice's PTT Server -> Alice
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
以下を通って一口/2.0 200OK 一口/2.0/UDP pc33.example.org; ブランチ=z9hG4bKnashds8To: <一口: AlicesConferenceFactoryURI.example.org>; =c70ef99From:にタグ付けをしてください。 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 接触を招いてください: <一口: AlicesPre-establishedSession@AlicesPTTServer.example.org>コンテントタイプ: sdp Contentアプリケーション/長さ: 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一口: AlicesPre-establishedSession@AlicesPTTServer.example.org SIP/2.0Via: 一口/2.0/UDP pc33.example.org; ブランチは前方へz9hG4bKnashds9マックスと等しいです: 70 To: <一口: AlicesConferenceFactoryURI.example.org>; =c70ef99From:にタグ付けをしてください。 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314159 ACKコンテンツの長さ: 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 Serverと共にPreが確立したSessionを設立しました。すべてのメディアパラメタがコミュニケーション時に使用のためにあらかじめ交渉されます。
Alice initiates a communication to Bob.
アリスはボブにコミュニケーションを開始します。
4 REFER Alice -> Alice's PTT Server
4はアリス・->アリスの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>
REFER一口: AlicesPre-establishedSession@AlicesPTTServer.example.org SIP/2.0Via: 一口/2.0/UDP pc33.example.org; ブランチは前方へz9hG4bKnashds8マックスと等しいです: 70 To: <一口: AlicesConferenceFactoryURI.example.org>; =c70ef99From:にタグ付けをしてください。 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314160はTo:を参照する状態で参照されます。 「ボブ」<一口: bob@example.com 、gt;、接触: <一口: alice@pc33.example.org 、gt。
Allen, et al. Informational [Page 23] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[23ページ]のRFC4964P答え州のヘッダー2007年9月
5 202 (ACCEPTED) Alice's PTT Server -> Alice
5 202(受け入れる)アリスの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>
一口/2.0 202は以下を通って受け入れました。 一口/2.0/UDP pc33.example.org; ブランチ=z9hG4bKnashds8To: <一口: AlicesConferenceFactoryURI.example.org>; =c70ef99From:にタグ付けをしてください。 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314160 接触を参照してください: <一口: 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
INVITE一口: bob@example.com SIP/2.0Via: 一口/2.0/UDP AlicesConferenceFocus.example.org; ブランチは前方へz9hG4bk4721d8マックスと等しいです: 70 To: 「ボブ」<一口: bob@example.com 、gt;、From: 「アリス」<一口: Alice@example.org 、gt;、; 参照されていた状態で=2178309898にタグ付けをしてください: <一口: Alice@example.org 、gt;、呼び出しID: e60a4c784b6716 CSeq: 301166605 接触を招いてください: <一口: AlicesConferenceFocus.example.org>コンテントタイプ: sdp Contentアプリケーション/長さ: 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
INVITE一口: bob@example.com SIP/2.0Via: 一口/2.0/UDP BobsPTTServer.example.com; ブランチは前方へz9hG4bKa27bc93マックスと等しいです: 70 To: 「ボブ」<一口: bob@example.com 、gt;、From: 「アリス」<一口: Alice@example.org 、gt;、; 参照されていた状態で=781299330にタグ付けをしてください: <一口: Alice@example.org 、gt;、呼び出しID: 6eb4c66a847710 CSeq: 478209 接触を招いてください: <一口: BobsPTTServer.example.com>コンテントタイプ: sdp Contentアプリケーション/長さ: 142
(SDP not shown)
(見せられなかったSDP)
Allen, et al. Informational [Page 24] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[24ページ]のRFC4964P答え州のヘッダー2007年9月
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
以下を通って一口/2.0 183セッション進歩 一口/2.0/UDP AlicesConferenceFocus.example.org; ブランチ=z9hG4bK4721d8To: 「ボブ」<一口: bob@example.com 、gt;、;=a6c85cf From:にタグ付けをしてください 「アリス」<一口: Alice@example.org 、gt;、; タグは2178309898呼び出しIDと等しいです: e60a4c784b6716 Contact: <一口: BobsPTTServer.example.com>CSeq: 301166605 P答え状態を招待してください: 未確認のコンテンツの長さ: 0
9 NOTIFY Alice's PTT Server -> Alice
9はアリスのPTTのサーバ->アリスに通知します。
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一口: alice@pc33.example.org SIP/2.0Via: 一口/2.0/UDP AlicesPre-establishedSession@AlicesPTTServer.example.org; ブランチは前方へz9hG4bKnashds8マックスと等しいです: 70 To: <一口: AlicesConferenceFactoryURI.example.org>; =c70ef99From:にタグ付けをしてください。 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314161 接触に通知してください: <一口: AlicesPre-establishedSession@AlicesPTTServer.example.org 、gt;、出来事: Subscription-状態を参照してください: 能動態; =60コンテントタイプを吐き出します: メッセージ/sipfrag; バージョンは2.0のContent-長さと等しいです: 99
SIP/2.0 183 Session Progress To: "Bob" <sip:bob@example.com>;tag=d28119a P-Answer-State: Unconfirmed
一口/2.0 183セッション進歩To: 「ボブ」<一口: bob@example.com 、gt;、; =d28119a P-答え状態にタグ付けをしてください: 未確認
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
以下を通って一口/2.0 200OK 一口/2.0/UDP AlicesPre-establishedSession@AlicesPTTServer.example.org; ブランチ=z9hG4bKnashds8To: <一口: AlicesConferenceFactoryURI.example.org>; =c70ef99From:にタグ付けをしてください。 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314161に通知します。
Allen, et al. Informational [Page 25] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[25ページ]のRFC4964P答え州のヘッダー2007年9月
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.
アリスとコンファレンスFocusとの早めの半二重メディアセッションは現在確立されます、そして、コンファレンスFocusはそれがアリスから受け取るメディアをバッファリングします。
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
以下を通って一口/2.0 200OK 一口/2.0/UDP BobsPTTServer.example.com; ブランチ=z9hG4bK927bc93To: 「ボブ」<一口: bob@example.com 、gt;、;=d28119a From:にタグ付けをしてください <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、; タグは781299330呼び出しIDと等しいです: 6eb4c66a847710 CSeq: 478209 接触を招いてください: <一口: bob@192.0.2.4 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 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一口: bob@192.0.2.4 SIP/2.0Via: 一口/2.0/UDP BobsPTTServer.example.com; ブランチは前方へz9hG4bK927bc93マックスと等しいです: 70 To: 「ボブ」<一口: bob@example.com 、gt;、;=d28119a From:にタグ付けをしてください 「アリス」<一口: Alice@example.org 、gt;、; タグは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
以下を通って一口/2.0 200OK 一口/2.0/UDP AlicesConferenceFocus.example.org; ブランチ=z9hG4bK4721d8To: 「ボブ」<一口: bob@example.com 、gt;、;=a6670811From:にタグ付けをしてください <一口: 「アリスの友人」 FriendsOfAlice@example.org 、gt;、; タグは2178309898呼び出しIDと等しいです: e60a4c784b6716 Contact: <一口: BobsPTTServer.example.com>CSeq: 301166605 P答え状態を招待してください: 確認されたコンテントタイプ: sdp Contentアプリケーション/長さ: 131
(SDP not shown)
(見せられなかったSDP)
Allen, et al. Informational [Page 26] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[26ページ]のRFC4964P答え州のヘッダー2007年9月
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はちびちび飲みます: 以下を通ってBobsPTTServer.example.com一口/2.0 一口/2.0/UDP AlicesConferenceFocus.example.org; ブランチは前方へz9hG4bK4721d8マックスと等しいです: 70 To: 「ボブ」<一口: bob@example.com 、gt;、;=a6670811From:にタグ付けをしてください 「アリス」<一口: Alice@example.org 、gt;、; タグは1928301774呼び出し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.
アリスとボブとのメディアセッションは現在確立されます、そして、コンファレンスFocusはバッファリングされたメディアをボブに転送します。
15 NOTIFY Alice's PTT Server -> Alice
15はアリスのPTTのサーバ->アリスに通知します。
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一口: alice@pc33.example.org SIP/2.0Via: 一口/2.0/UDP AlicesPre-establishedSession@AlicesPTTServer.example.org; ブランチは前方へz9hG4bKnashds8マックスと等しいです: 70 To: <一口: AlicesConferenceFactoryURI.example.org>; =c70ef99From:にタグ付けをしてください。 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314162 接触に通知してください: <一口: AlicesPre-establishedSession@AlicesPTTServer.example.org>出来事: Subscription-状態を参照してください: 能動態; =60コンテントタイプを吐き出します: メッセージ/sipfrag; バージョンは2.0のContent-長さと等しいです: 83
SIP/2.0 200 OK To: "Bob" <sip:bob@example.com>;tag=d28119a P-Answer-State: Confirmed
一口/2.0 200OK To: 「ボブ」<一口: bob@example.com 、gt;、; =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
以下を通って一口/2.0 200OK 一口/2.0/UDP AlicesPre-establishedSession@AlicesPTTServer.example.org; ブランチ=z9hG4bKnashds8To: <一口: AlicesConferenceFactoryURI.example.org>; =c70ef99From:にタグ付けをしてください。 「アリス」<一口: alice@example.org 、gt;、; タグは1928301774呼び出しIDと等しいです: a84b4c76e66710 CSeq: 314162に通知します。
Allen, et al. Informational [Page 27] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[27ページ]のRFC4964P答え州のヘッダー2007年9月
9. Security Considerations
9. セキュリティ問題
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答え州のヘッダーがプロキシと中間的UAsによって使用されて、加えられるので、終わりから終わりへの保護は適切ではありません。 その結果、UAsの間の「悪意がある」プロキシかシグナリング経路の攻撃者が、加えるか、ヘッダーを取り除くか、またはヘッダー価値のコンテンツを変更できました。 この攻撃は、訪問される人がまだ連絡されていないという知識を訪問者に対して否定するか、または彼らが既に答えたとき、訪問される人がまだ連絡されていないのを間違って示します。 彼らが既に攻撃に答えたとき、訪問される人がまだ連絡されていないのを間違って示す攻撃は訪問される人にほんとうは答えましたが、それらのメディアが仲介者によって格納されるのをさせたがっていないのでメディアを伝えないと決める訪問者をもたらすかもしれません。 訪問される人がまだ連絡されていないという追加知識を訪問される人に対して否定する攻撃は訪問される人にこの拡張子の使用なしで答える前に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.
したがって、プロキシの間のメッセージを保護するのが必要であり、実現SHOULDは保全を提供して、シグナリングの間を秘密に跳ぶ輸送を使用します。 この保護を提供するのにSIPで合図しながら基づくTransport Layer Security(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.
問題にはあるセキュリティは、信じられるネットワークのために考えられるだけであり、他動な信用と共にホップごとのセキュリティー対策を使用します。 一般的なインターネットのこのメカニズムの使用法の安全保障問題は評価されていません。
10. IANA Considerations
10. IANA問題
10.1. Registration of Header Fields
10.1. ヘッダーフィールドの登録
This document defines a private SIP extension header field (beginning with the prefix "P-" ) based on the registration procedures defined in RFC 3427 [21].
このドキュメントはRFC3427[21]で定義された登録手順に基づく個人的なSIP拡大ヘッダーフィールド(接頭語「P」で、始まる)を定義します。
The following row has been added to the "Header Fields" section of the SIP parameter registry:
SIPパラメタ登録の「ヘッダーフィールド」セクションに以下の列を追加してあります:
Allen, et al. Informational [Page 28] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[28ページ]のRFC4964P答え州のヘッダー2007年9月
+----------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+----------------+--------------+-----------+
| P-Answer-State | | [RFC4964] |
+----------------+--------------+-----------+
+----------------+--------------+-----------+ | ヘッダー名| コンパクト形| 参照| +----------------+--------------+-----------+ | P答え状態| | [RFC4964]| +----------------+--------------+-----------+
11. Acknowledgements
11. 承認
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.
作者はこの仕事の進行に貢献した彼らのコメントについてジョン・ピーターソン、Cullenジョニングス、ジョロエンバンBemmel、ポールKyzivat、デール・ウォーリー、ディーン・ウィリス、Rohan Mahay、クリスチャンのシュミット、マイク・ハマー、およびミゲル・ガルシア-マーチンに感謝したがっています。 また、作者は彼らのこのドキュメントのサポートのためのOMA POC作業部会のメンバーとIETF62にP答え州のヘッダーの概念をSIPPINGに提示するための特にトム・ヒラーに感謝したがっています。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[3] OMA, "Push to talk over Cellular - Architecture",
OMA-AD-PoC-V1_0_1-20061128-A, November 2006.
[3] OMA、「Cellularの上で押して話してください--構造」、OMA-西暦PoC-V1_0_1-20061128A、11月2006
[4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420,
November 2002.
R.、「インターネットメディアTypeメッセージ/sipfrag」、RFC3420 2002年11月の[4]スパーク。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[6] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、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、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[8] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[8] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[9] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[9] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
Allen, et al. Informational [Page 29] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[29ページ]のRFC4964P答え州のヘッダー2007年9月
12.2. Informative References
12.2. 有益な参照
[10] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
2006年2月の[10] ローゼンバーグ、J.、「セッション開始プロトコル(一口)がある会議のための枠組み」RFC4353。
[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.、「セッション開始はセル(PoC)サービスの上のプッシュから話のサポートで(一口)イベントパッケージとデータの形式について各種設定方法に議定書の中で述べます」、RFC4354、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月)で働いています。
[13] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[13] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、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.、オラン、D.、およびG.キャマリロ、「セッション開始プロトコル(一口)のための理由ヘッダーフィールド」、RFC3326(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、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[16] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)", RFC
4538, June 2006.
[16] ローゼンバーグ、J.、「セッション開始プロトコル(一口)における対話識別による要求認可」、RFC4538、2006年6月。
[17] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[17] ドノヴァン、S.、「一口インフォメーション方法」、RFC2976、2000年10月。
[18] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[18] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、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、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。
[20] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[20]Niemi、A.、「イベント州政府出版物のためのセッション開始プロトコル(一口)拡大」、RFC3903、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.ローゼンは「セッション開始プロトコル(一口)のために過程を変えます」、BCP67、RFC3427、2002年12月。
Allen, et al. Informational [Page 30] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[30ページ]のRFC4964P答え州のヘッダー2007年9月
Authors' Addresses
作者のアドレス
Andrew Allen (editor) Research in Motion (RIM) 102 Decker Court, Suite 100 Irving, Texas 75062 USA
動き(縁どっている)102デッカー法廷、スイートのアンドリューアレン(エディタ)Research、100、アービング、テキサス75062米国
EMail: aallen@rim.com
メール: aallen@rim.com
Jan Holm Ericsson Tellusborgsvagen 83-87 Stockholm 12526 Sweden
ジャンホルムエリクソンTellusborgsvagen83-87ストックホルム12526スウェーデン
EMail: Jan.Holm@ericsson.com
メール: Jan.Holm@ericsson.com
Tom Hallin Motorola 1501 W Shure Drive Arlington Heights, IL 60004 USA
トム・ハリン・モトローラ1501Wシュアー・Drive IL60004アーリントンハイツ(米国)
EMail: thallin@motorola.com
メール: thallin@motorola.com
Allen, et al. Informational [Page 31] RFC 4964 The P-Answer-State Header September 2007
アレン、他 情報[31ページ]のRFC4964P答え州のヘッダー2007年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Allen, et al. Informational [Page 32]
アレン、他 情報[32ページ]
一覧
スポンサーリンク
