This excerpt is from ECG's training class ECGT2010. In this class, you can ask questions, dialog, and interact with the engineer teaching the class.
SIP Packets can be dropped silently when it is not fragmented because the SIP message is larger. An easy fix in some cases can be to switch to use TCP. We see if often in VoIP with SIP over MPLS. (Read all about SIP and fragmentation problems in another article.)
ALG's often create some problems because they don't fully support the SIP flows. A very standard workaround is to disable the SIP ALG and use a full Session Border Controller (SBC) instead.
You typically should be using the same IP addresses and port numbers for both sending and receiving SIP. For example, on the public interface of your user's NAT device, the SIP may be going from 4.1.2.3 port 49151. You'd therefore expect the other end of the connection to be sending SIP to the device at 4.1.2.3 port 49151. (This course also covers NAT with SIP in expensive detail in another module.)
Retransmissions of SIP are an evidence that something is going wrong -- that SIP messages are being dropped in the path. An occasional SIP retransmission can occur just due to congestion in the network causing a packet to be discarded by a switch or a router. But frequent retransmission points to a more serious problem, like congestion dropping numerous packets, or SIP messages being dropped entirely.
This is a very popular feature which sends very large SIP messages. With SIP over UDP, extensive fragmentation can be required to accommodate the MTU sizes. For example, the SIP message containing the full set of BLF entries might be 40,000 bytes, but the MTU is typically 1500 bytes. That means that a single SIP message could be sliced into 27 fragments using IP fragmentation. If only a single fragment is lost, then the entire message must be retransmitted. (In this course we also go into detail on the SIP signaling for BLF and the different forms used by BroadWorks and Metaswitch.)
If the message is retransmitted often enough, the subscription may be deleted entirely. That would lead to an out-of-sync state where the phone is displaying incorrect information.
To resolve this, we always recommend using SIP over TCP for BLF -- or any other application that sends large payloads in SIP. The SIP standard actually mandates TCP for large messages, but many systems sidestep that requirement and get by OK. BLF really forces this transition.