Some or all VoIP (SIP) invites are being dropped due to "242 Packet dropped - failed processing"

03/26/2020 1,056 People found this article helpful 491,383 Views

Description

After upgrading to 5.8 firmware or higher from 5.6 (or 5.7), or after replacing a Gen4 on SonicOS 4.x or Gen 5 device on 5.6 or lower firmware with a Gen6 device, VOIP invites can only be made from some locations.

Example: Cell phones can still call in to phones behind the firewall, but soft-phones or hard-phones using VOIP within the organization cannot call one another.

In this example, the PBX is hosted upstream.
This drop code number may change in future versions higher than 5.8.1.14, but the reason for dropping packet will stay the same in the drop code matrix.

The following steps delineate how to find the invite packet in the capture, illustrate why this traffic is dropped, and provide the resolution.

Resolution

Step 1: Opening this capture in Wireshark will allow you to find your VOIP call

Step 2: Analysis of the call flow reveals that the invites are sent, but there are no responses. Selecting the invite packet will highlight the packet number in Wireshark
Step 3: Selecting this line in the Graph Analysis directs us to packet 771

Reason: In this example, review of the capture shows us that 770 is a UDP fragment of packet 771. 772 and 773 also correspond to a fragmented UDP packet that was sent to the SonicWall from a remote location at a packet size larger than 1514 bytes on the wire, and therefore had to be fragmented.

Although some routers might pass this traffic, the SonicWall is a security appliance, and will drop this traffic. This is reflected in the HTML export of the capture, or when viewed before export directly on the firewall.
Fragmented UDP traffic, especially SIP traffic, is a clear violation of RFC protocol, which SonicOS Enhanced firmware 5.8 and above very strictly adhere to in these circumstances. RFC 3261 is the RFC standard for SIP traffic, and states the following:

18.1.1 Sending Requests  The client side of the transport layer is responsible for sending the request and receiving responses. The user of the transport layer passes the client transport the request, an IP address, port, transport, and possibly TTL for multicast destinations.  If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP.

To read more, see http://www.ietf.org/rfc/rfc3261.txt

SonicOS enhanced firmware 5.6, which is no longer supported, was less RFC compliant on this, but 5.8 has enhanced security by becoming more strict. RFC 4693 goes into additional detail regarding security concerns of unnecessary packet fragmentation.

How to Test:

When a call comes in that is less than the MTU and does not need fragmentation, (for instance: from a Cell phone rather than from the VOIP phone within the organization) the invite is forwarded to the phone on its registered socket as expected.

Removal of unnecessary information on the originating devices or SIP servers will bring the SIP invite packet to a smaller size, and therefore within the size of the MTU path, allowing the packet through. In this case, the X-nt-alter-id value can be removed, and bring the packet to a size lower than the MTU path.

Another method of working around this while fitting into RFC compliance as cited above would be to use SIP over TCP instead of SIP over UDP if fragmentation is required. Many vendors do not use this, however, as UDP audio or video streams do not need to rely on verification that a packet arrived, whereas TCP does.

Not Finding Your Answers?

ASK THE COMMUNITY

Was This Article Helpful?

YES NO

Some or all VoIP (SIP) invites are being dropped due to "242 Packet dropped - failed processing"

Description

Resolution

Related Articles

Categories

Not Finding Your Answers?

Was This Article Helpful?

Article Helpful Form

Article Not Helpful Form

Follow Us

Subscribe to newsletter

Stay In Touch