Remote Office - One-way Audio - Wireshark Cap Bad Checksum

Discussion in '3CX Phone System - General' started by eihli, Aug 2, 2011.

Thread Status:
Not open for further replies.
  1. eihli

    Joined:
    Jan 3, 2011
    Messages:
    16
    Likes Received:
    0
    We've been having a problem with one-way audio at a remote office.

    Here is a brief recap:
    * Intermittent one-way audio for external extensions. Things will work fine for a few hours, then several calls will have one-way audio. The caller can hear the office, but the office can't hear the caller.
    * Happens on multiple phones (both SPA 942).
    * Happens both using the 3CX Tunnel and using static port forwarding.
    * The PBX records audio both ways, even when the external extension can't hear the caller.

    I think I just found something that is relevant but I'm not sure what to do with it.

    A Wireshark capture shows all packets coming in to the phone system from the remote location ok, but packets going from the phone system to the remote location all have bad checksums in their headers.

    I've attached a screenshot of the capture.

    What does this mean and how is it fixed?

    Thanks,
     

    Attached Files:

  2. eihli

    Joined:
    Jan 3, 2011
    Messages:
    16
    Likes Received:
    0
    Re: Remote Office - One-way Audio - Wireshark Cap Bad Checks

    Bah never mind I think that Wireshark info is irrelevant:
    http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html

    7.8.2. Checksum offloading

    The checksum calculation might be done by the network driver, protocol driver or even in hardware.

    For example: The Ethernet transmitting hardware calculates the Ethernet CRC32 checksum and the receiving hardware validates this checksum. If the received checksum is wrong Wireshark won't even see the packet, as the Ethernet hardware internally throws away the packet.

    Higher level checksums are "traditionally" calculated by the protocol implementation and the completed packet is then handed over to the hardware.

    Recent network hardware can perform advanced features such as IP checksum calculation, also known as checksum offloading. The network driver won't calculate the checksum itself but will simply hand over an empty (zero or garbage filled) checksum field to the hardware.

    Note!
    Checksum offloading often causes confusion as the network packets to be transmitted are handed over to Wireshark before the checksums are actually calculated. Wireshark gets these "empty" checksums and displays them as invalid, even though the packets will contain valid checksums when they leave the network hardware later.



    ... Back to square one.
     
  3. nbailey

    nbailey Member

    Joined:
    Jan 31, 2011
    Messages:
    359
    Likes Received:
    0
    Re: Remote Office - One-way Audio - Wireshark Cap Bad Checks

    you are correct, ignore those errors. one way audio are issues with incorrect firewall settings and port forwarding.

    info on remote extensions: http://www.3cx.com/blog/voip-howto/remote-extensions/

    but to be honest you would be better off setting up the SIP proxy manager as it resolves these issues.

    http://www.3cx.com/blog/releases/sip-proxy-manager/

    this is the best option.

    Thanks,
    Nate
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. eihli

    Joined:
    Jan 3, 2011
    Messages:
    16
    Likes Received:
    0
    Re: Remote Office - One-way Audio - Wireshark Cap Bad Checks

    If it was a firewall setting or port forwarding, the problem would be continual, right? The fact that it is intermittent confuses me.

    And I mentioned in my OP that we have tried using the SIP proxy manager and experience the same problem.
     
  5. joshrose26

    Joined:
    Jul 18, 2011
    Messages:
    7
    Likes Received:
    0
    Re: Remote Office - One-way Audio - Wireshark Cap Bad Checks

    Just a shot in the dark, but is it possible that your RTP port forward range isn't wide enough to accomodate all of the calls that may be happening at that time of day.

    Just installed our first system and ran into this issue myself. I think default is 9000-X two UDP ports per concurrent call.

    The other question, is there any other high traffic functions that are occuring at those times of day. I.E. a barracuda backup appliance that has high priority QOS sucking up your upload pipe.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.