events - エンドビットのRFC4733イベントデュラトン

Question

RFC 4733を読む際に、イベント期間が最後の3つのeビットで増加してはならないかどうかが明確に述べられていません。イベントの重要な情報は、mビット、タイムスタンプ、およびeビットのようです。イベント期間が最後の3つのeビットで増加する場合、3つのeビットのそれぞれを個別のイベントと見なし、トーンを3倍にすることは理にかなっていますか？または、受信した最初のeビットをイベントの終わりとし、最後の2ビットを破棄する必要がありますか？3ビットで増加するイベント期間を示すwiresharkキャプチャがあり、これを理解するのに疲れています。

Answer 1

イベントの最終パケットが3 回送信される可能性がある場合、期間フィールドは単調に増加するはずです。したがって、コメントの説明では、それぞれに E ビットが設定され、期間が 720、800、および 880 の 3 つのパケットが表示されます。これは、パケットの期間フィールドがイベントを示しているため、パケットが 80 ミリ秒間隔で送信されることを示しています。このパラメータで示されている限り、これまで持続してきました。」

ただし、これはまだ単一のイベントであるため、イベントのプレイアウトは、受信した最初のパケットの間続く必要があります。

たとえば、3 つのパケットが到着していることがわかりますが、最初のパケット (持続時間 720) が到着しなかった場合、2 番目のパケット (持続時間 800) が表示され、トーンを 800 ミリ秒再生する必要があります。

そうは言っても、送信者は、あなたが見ているものではなく、同じ期間で終了パケットを送信することを期待しています. これは、送信側のバグである可能性があります。(送信は期間の増加を引き起こす必要がありますが、これは再送信です。)

Answer 2

送信者は明らかに RFC を破っています。

1. イベントが終了したときに「E」ビットを設定する必要があります
2. イベントの期間に応じて期間が増加します

期間がまだ増加している場合、明らかにイベントは終了していませんが、E ビットが設定されている場合、イベントは終了しています - つまり、矛盾

一方（2.5.2.2から）

1. レシーバーがイベントの終了を受信すると、トーンの再生を停止する必要があります。
2. プレイアウトが停止したら、レシーバーはトーンを再開すべきではありません。
3. 受信者は、保持された履歴と、現在のパケットのタイムスタンプとイベント コードに基づいて、それが既に再生されて経過したイベントに対応すると判断する場合があります。その場合、イベントのさらなるレポートは無視する必要があります

つまり、タイムスタンプからイベントがすでに再生されており、この場合はイベントを繰り返すべきではないことがわかります。