4

Eビットが0のときにdtmfサウンドが鳴り、1のときに音が出ないのはなぜですか？（RTPパケットはどちらの方法でもwiresharkに表示されます）

バックグラウンド：

http://www.ietf.org/rfc/rfc2833.txtで概説されているようにRFC2833dtmfイベントを送信して 、Eビットが設定されていない場合に次の動作を取得できます。

たとえば、キー7874556332111111145855885#3が押されると、すべてのイベントが送信され、wiresharkなどのプログラムに表示されますが、音だけが87456321458585#3鳴ります。そのため、最初のキー（別の問題である可能性があります）とイベントの繰り返し（つまり11111）は鳴りません。

上記のリンクされたドキュメントのセクション3.9、図2では、最後のイベントを除くすべてのイベントにEビットが設定されている911の例が示されています。

すべての数値に対して「E」ビットを1に設定すると、イベントが鳴ることはありません。

私はいくつかの考えられる原因を考えましたが、それらが理由であるかどうかはわかりません：

1）図2は、送信された96および97のペイロードタイプを示しています。これらのヘッダーは送信していません。セクション3.8では、コード96と97は、「動的ペイロードタイプ96と97がそれぞれ冗長メカニズムと電話イベントペイロードに割り当てられている」と説明されています。

2）セクション3.5「E：」で、「送信者は、最初の送信ではなく、トーンの最後のパケットを再送信するまで、終了ビットの設定を遅らせることができます」誰かが実際にこれを行う方法を知っていますか？

3）別の出力ストリームもありますが、このストリームの聴取を妨げているのではないかと思います。

4）タイムスタンプ間隔とRTPマーカーもいじっています。

どんな助けでも大歓迎です。関連する領域のwiresharkイベントキャプチャのサンプルを次に示します。

6590 31.159045000 xx.x.x.xxx --.--.---.-- RTP EVENT Payload type=RTP Event, DTMF Pound # (end)
Real-Time Transport Protocol
 Stream setup by SDP (frame 6225)
  Setup frame: 6225
  Setup Method: SDP
 10.. .... = Version: RFC 1889 Version (2)
 ..0. .... = Padding: False
 ...0 .... = Extension: False
 .... 0000 = Contributing source identifiers count: 0
 0... .... = Marker: False
 Payload type: telephone-event (101)
 Sequence number: 0
 Extended sequence number: 65536
 Timestamp: 2000
 Synchronization Source identifier: 0x15f27104 (368210180)
RFC 2833 RTP Event
 Event ID: DTMF Pound # (11)
 1... .... = End of Event: True
 .0.. .... = Reserved: False
 ..00 0000 = Volume: 0
 Event Duration: 1000

注意：ietf.org/rfc/rfc2833.txt仕様で説明されているように、ゼロの音量は取得可能な最大レベルです。

"音量：DTMFディジットおよびトーンとして表現可能なその他のイベントの場合、このフィールドはトーンの電力レベルを示し、符号を落とした後のdBm0で表されます。電力レベルの範囲は0〜-63 dBm0です。有効なDTMFの範囲は0〜 -36 dBm0（受け入れる必要があります）-55 dBm0未満は拒否する必要があります（TR-TSY-000181、ITU-T Q.24A）。したがって、値が大きいほど音量が小さいことを示します。この値はDTMFディジットに対してのみ定義されます。その他の場合イベントの場合、送信者によってゼロに設定され、受信者によって無視されます。」問題は、「イベントの終了」ビットがオンになっている場合です。

4

3 に答える 3

6

2つの理由から、 RFC4733から始めることをお勧めします。

  1. これはRFC2833を廃止します。
  2. 第5章は、DTMFディジットがどのように生成されるかを理解するための優れた情報源です。

DTMFディジットを送信する方法についての私の理解は次のとおりです。

  • 開始パケットが発行されます。Mフラグが設定され、Eフラグがクリアされています。イベントのタイムスタンプが設定されます。
  • 1つ以上の継続パケットが発行されます（ユーザーが数字を押している限り）。彼らは彼らのMとEの旗をクリアしました。開始パケットで定義されたタイムスタンプを使用しますが、シーケンス番号と期間は増分されます（間隔についてはRFCを参照してください）。
  • 終了パケットが送信されます（ユーザーが数字を押すのをやめたとき）。Mフラグがクリアされ、Eフラグが設定されています。

1つのイベントに対して複数のパケットを送信する必要があるのはなぜですか？ネットワークは常に完全であるとは限らず、損失が発生する可能性があるためです。

  • RFCは、次のように述べています（2.5.1.2。「イベントパケットの送信」）。

    堅牢性のために、送信者は「状態」イベントを定期的に再送信する必要があります。

  • そして（2.5.1.4。「最終パケットの再送信」）それ：

    各イベントおよび各セグメントの最終パケットは
    、ソースが更新に使用する間隔で合計3回送信する必要があります。
    これにより、最後のパケットのインスタンスが失われた場合でも、イベントまたはセグメントの期間を正しく認識できるようになります。

あなたの問題に関して：

たとえば、キー7874556332111111145855885＃3を押すと、すべてのイベントが送信され、wiresharkなどのプログラムに表示されますが、87456321458585＃3のみが鳴ります。そのため、最初のキー（別の問題である可能性があります）とイベントの繰り返し（つまり11111）は鳴りません。

WireSharkトレースがないと、何が起こっているのかを判断するのは困難ですが1、連続するイベントの区別がないため、繰り返しの数字は無視されると思います。最初の1桁が認識され、他の桁はイベントの再送信と見なされます。

于 2010-05-11T22:36:57.077 に答える
0

美しさ！どうもありがとうローラン。あなたの推奨事項に基づいて実用的なソリューションを実装しました。（テキストの書式設定を改善するための別の回答として投稿するだけです-賞金を差し上げます）

何が間違っていたかを要約すると：

  1. パケットの冗長性が必要でした。
  2. すべての「E」を 0 に設定すると、繰り返される同じキー イベントが無視されます。
  3. すべての「E」を 1 に設定するということは、イベントの終了を通知したことを意味しますが、実際のイベントではなく、無音です。

要約されたフローの例を次に示します。

Event_ID    M    E    Timestamp      Duration    Sequence_number  
3           1    0    400            400          1
3           0    0    400            800          2
3           0    0    400            1200         3
3           0    0    400            1600         4
3           0    1    400            1600         5
3           0    1    400            1600         6
3           0    1    400            1600         7
7           1    0    800            400          8
7           0    0    800            800          9
7           0    0    800            1200         10
7           0    0    800            1600         11
7           0    1    800            1600         12
7           0    1    800            1600         13
7           0    1    800            1600         14

*注: セクション 5 で提案された rfc4733 の最初の例を見たところ、素晴らしいです! 2833よりずっといい

于 2010-05-12T18:04:50.603 に答える
0

音量が に設定されていることに気付きました0。それが、音が聞こえない理由のように思えますか?

于 2010-05-11T04:37:08.880 に答える