前回は両方向のRTPの流れをWireSharkを使って調べてみました。この方法で、VoIP GWから20ms間隔でRTPが流れていることは確認できましたが、X-Liteから送られたRTPをVoIP GWがちゃんと受信できているかどうかまではわかりません。そこで、VoIP GW側のRTP送受信タスクで、パケット数をカウントしてみました。およそ5分間の通話状態でのカウントは次のようになりました。
毎秒50パケットですから5分間では15000パケットになるはずです。outpacketはほぼ期待どおりの数字です。しかし、inpacketがoutpacketに比べてずいぶんと少ないようです。「ひょっとして、VoIP GWが受信パケットを取りこぼしているのではないだろうか?」と思いました。受信タスク自体は読み捨てているだけで何の処理もしていないので負荷は小さいはずですが、ドライバやTINETのレベルで取りこぼしが発生する可能性もあります。
RTPでは各パケットにシーケンス番号が付いていますので、これが非連続になれば取りこぼしがあったことがわかります。それを確認してみたのが、上記表示の "bad seq" の値です。シーケンス番号が非連続のパケットを受信する度にインクリメントされるのですが、結果はゼロ。つまり、とりこぼしはなかったことになります。
そうすると、残る可能性はX-Liteのパケット送信間隔が長いために、結果として送信パケット数が少なくなったことになります。上記の数字はいつも開発に使っているLet's NoteでX-Liteを走らせた場合の数字なのですが、デスクトップのマシンでもX-Liteを走らせてみました。結果は、次のとおり。inpacketとoutpacketの値がほぼ同じとなりました。
どうやら、Let's NoteでX-Liteを走らせた場合にはパケット送信数がホントに少なかったようです。デスクトップもLet's Noteも OSとしてはWindows XPを使っています。Let's Note上では時間がゆっくりと流れているんでしょうかねぇ。in と outで380パケットも差があるということは、時間にしておよそ7.6秒に相当します。5分(300秒)間で7.6秒もずれてきてしまうとは驚きです。
毎秒50パケットですから5分間では15000パケットになるはずです。outpacketはほぼ期待どおりの数字です。しかし、inpacketがoutpacketに比べてずいぶんと少ないようです。「ひょっとして、VoIP GWが受信パケットを取りこぼしているのではないだろうか?」と思いました。受信タスク自体は読み捨てているだけで何の処理もしていないので負荷は小さいはずですが、ドライバやTINETのレベルで取りこぼしが発生する可能性もあります。
RTPでは各パケットにシーケンス番号が付いていますので、これが非連続になれば取りこぼしがあったことがわかります。それを確認してみたのが、上記表示の "bad seq" の値です。シーケンス番号が非連続のパケットを受信する度にインクリメントされるのですが、結果はゼロ。つまり、とりこぼしはなかったことになります。
そうすると、残る可能性はX-Liteのパケット送信間隔が長いために、結果として送信パケット数が少なくなったことになります。上記の数字はいつも開発に使っているLet's NoteでX-Liteを走らせた場合の数字なのですが、デスクトップのマシンでもX-Liteを走らせてみました。結果は、次のとおり。inpacketとoutpacketの値がほぼ同じとなりました。
どうやら、Let's NoteでX-Liteを走らせた場合にはパケット送信数がホントに少なかったようです。デスクトップもLet's Noteも OSとしてはWindows XPを使っています。Let's Note上では時間がゆっくりと流れているんでしょうかねぇ。in と outで380パケットも差があるということは、時間にしておよそ7.6秒に相当します。5分(300秒)間で7.6秒もずれてきてしまうとは驚きです。