Packet Counts: Twice As High On One Leg?

Home » Asterisk Users » Packet Counts: Twice As High On One Leg?
Asterisk Users 7 Comments

Hi all,

I have two phones that I’ve been comparing (different manufacturers).

To debug call quality issues on one of them, I’ve been using calls from the phone to our main DID, so 3 SIP sessions exist (phone <> asterisk then asterisk <> provider, and the provider<>asterisk for the DID).

The “bad” phone shows roughly twice the number of packets on the phone<>asterisk session as on the other two sessions.

The “good” phone shows roughly equal packet counts on each of the 3
sessions.

I’ve used asterisk server MTUs of 1440 and 1500, but it makes no difference.

Is this double-packet-count a clue, a problem, or a red herring?

The packet counts are shown using “sip show channelstats”.

– Mike

7 thoughts on - Packet Counts: Twice As High On One Leg?

  • Have you checked whether the same codecs, or codecs with the same bandwidth requirements, are used?

    jg

  • Here’s an example of a simple outgoing call. Everything is ulaw. The
    192.x.x.x phone has roughly twice the packet count of the provider session. The “lost” packet count is nonsensical on one session. Sigh.

    – Mike

    steerpike*CLI> sip show channelstats Peer Call ID Duration Recv: Pack Lost ( %)
    Jitter Send: Pack Lost ( %) Jitter
    209.217.98.130 0c15efc03f2 00:01:03 0000003069 0000104829 (97.16%)
    0.0000 0000003040 0000000000 ( 0.00%) 0.0002
    192.168.0.36 qY0p292XeDl 00:01:03 0000006121 0000000000 ( 0.00%)
    0.0000 0000006096 0000000000 ( 0.00%) 0.0001
    2 active SIP channels

    steerpike*CLI> sip show channels Peer User/ANR Call ID Format Hold
    Last Message Expiry Peer
    209.217.98.130 6139419467 0c15efc03f243c7 (ulaw) No
    Tx: ACK 6136866675
    192.168.0.36 mjc_office qY0p292XeDlPcLk (ulaw) No
    Rx: ACK mjc_office

    steerpike*CLI> core show version Asterisk 11.4.0 built by root @ steerpike.avtechpulse.com on a x86_64
    running Linux on 2013-06-19 12:10:47 UTC

  • There’s one thing on my list of things to check, that could be relevant for your problem, too.

    Packet count is one thing, transferred data is another one. If one phone uses smaller UDP
    packages, then the packet count should increase in reciprocally. I have read some comments on the net that smaller packages are preferable because lost packages have less impact on the hearable audio.

    Getting a complete pcap trace with subsequent wireshark analysis is probably a tedious but appropriate way to analyse this. Currently I don’t know what determines the size of the UDP
    packages and whether there are any general ways to control this size.

    jg

  • Aha. I overlooked that some phones had ulaw:10 in sip.conf, instead of the standard ulaw:20. That explains the packet count difference. It seems my call quality issues are coming from something else.

    – Mike