I'm having an issue with my carrier regarding dropped packets. The packet type is a very specific SIP/SDF packet, specifically an "INVITE" message from an IP PBX to a remote IP phone. The PBX sends these invites reliably (proven by Wireshark, thank you Wireshark!) but do not arrive reliably. The remote IP phone "sometimes" receives these packets, and when it does, reliably replies to the PBX. Both ends have Wireshark running simultaneously, so we can see (and prove) what transpires. Once the call is initiated the PBX periodically sends an "INVITE" every 90 seconds, if/when the IP phone does not respond (because it never received the package) the PBX drops the call (which was working perfectly) and the phone reboots. Both sides are using Century Link VDSL with ActionTec c1000a modems. I know we're getting the packets TO the modem, but the carrier can't/won't monitor on the packet level to tell us IF the packets are leaving the modem, further they refuse to help us locate the source of said "dropped packets". Is there a way to place a trace between the carrier and the modem they provide to monitor the ACTUAL DSL circuit and traffic? If the modem is indeed passing the traffic (I suspect it is) then the carrier/internet is to blame. Yes, I realize packets are lost while transversing the public internet. HELP! asked 21 Jan '13, 11:16  daddio211 showing 5 of 6 show 1 more comments |
One Answer:
Unfortunately no, as the DSL signal is an analog signal that transports the digital signal through modulation. There is special equipment to analyze the DSL signal, but you won't be able to recover the digital signal with that method.
O.K. if you capture in front of the modem (TAP, hub, mirror port on the switch), and you see the packets, you have the best proof you can generate that the packet reaches the equipment of the provider. If those packets do not reach the other side (also directly after the DSL) modem, it's the responsibility of the provider analyze the problem. If they are unable to analyze it, it's probably the wrong provider for you and you should consider to switch to another provider.
One more reason to "blame" the provider ;-)
Recommendation: You can create such a packet with a packet generator (e.g. Ostinato) and iterate through an increasing TTL (from 1 to n), then send the packet to the remote destination. As soon as you get a "destination unreachable" or a similar ICMP message, you know how far the packet got, without beeing dropped somewhere. If you don't get an answer for a certain TTL and that packet does not reach the other side, you (most certainly) know what device dropped the packet. To get the IP address of that device, please run a traceroute to the destination and compare the hops with your TTL tests. Regards answered 22 Jan '13, 23:33  Kurt Knochner ♦ edited 22 Jan '13, 23:54 Kurt, thank you very much for chiming in. I'll look into Ostinato and see what we can find with a traceroute. The carrier repeatedly claims "We can't do anything on the packet level" but the way you put it makes a lot more sense. The carrier is being paid for the transport, the info should arrive!... At least semi-reliably. I'll report back with more findings. (23 Jan '13, 08:05) daddio211
at least for its own network infrastructure. They can't do much if the packet leaves their network, but even then they could tell you: Look dear customer, we hand over the packet to another carrier, but we don't know what they are doing. If they are unable to deliver that tiny piece of information, they should not call themselves a carrier (23 Jan '13, 10:59) Kurt Knochner ♦ |
If the modem has som sort of firewall it is possible that the "pin hole" is closed after a fixed period if no further packets are sent on this IP/port combination. Is it possible to set the session supervission time shorter as a test(shorter time between re-INVITES) or use STUN.
Anders, thank you for your reply and suggestion!
I had the VoIP functioning (WITH this problem) using the carrier provided modem (NAT enabled to PBX) & had the problem above. Customer had a Sonicwall TZ 205 that needed to go in, so their security contractor installed it but gave us access.
The trouble exists in both situations: 1. Carrier provided modem set for NAT 2. Carrier provided modem in bridged mode, PPPoE/NAT/routing performed by Sonicwall TZ 205.
A quick Google doesn't indicate if the TZ 205 supports STUN or not. I suspect it would, maybe Sonicwall calls it a different name?
Okay, I did a little research on STUN. Regardless of the firewall this MAY be an option in the future. I'm thinking hardware VPN may be a better (and more controlable) solution.
I've now replaced the ActionTec modem (that was in bridged mode) with a Zyxel modem. Same issue. I don't believe the modem is the issue at this point, that the trouble is the carrier themselves.
If the call always break after 90s and the voice quality up to then is OK random packet drops shouldn't be the issue. You could analyse the RTP stream for drops to get an idea of the over all quality regarding drops.
Anders, thank you again. My choice of words "dropped packets" is not an entirely accurate assessment. What I attempted to define is that it is a VERY PARTICULAR type of packet that is being dropped. TDP, UDP and SIP packets are about as close to perfect as you could expect. The VERY PARTICULAR packet type that is being interrupted is SIP/SDP also known as an "invite" packet.