Odd network problem with SIP
I have a client using the Spitfire dialler on Win7 to dial via SIP to a carrier called VoxTelecom; I infer they're a virtual carrier because the SIP goes to their Sonus SBC at a single IP, but the media sessions go all over creation. The client has been having completion trouble, and the dialler folks said "crappy circuit; too much jitter and packet loss", tested from the dialler using PingPlotter. I don't think it was jitter, I think it was ping response deviation; PingPlotter doesn't appear to actually test jitter. But to tick the boxes, I had road runner out; they replaced a ubee D2 modem with their New Hawtness Arris D3 modem; no change. All his analog measurements were pristine, he told me. So next step, check the router. Log in to the Fortigate 40D; control panel won't paint properly. This *may* have been an IE10 compatibility mode red-herring, but I temporarily swapped it for a 20C, which I could talk to. Set up the inbound DNATs for udp/5060 SIP and upd/49152-49252 RTP. Ran some calls. They're not seeing my ACK after they send me an SDP. They get the invite, but not the ACK. I send RTP, but they don't bother cause they think the call's not set up yet. Wireshark on the dialler... that ACK packet *has a bad IP header checksum*. Not the earlier packets; just the ACK. Huh? So, assume it's the OS, somehow; reboot. 65 Windows updates and an hour later... Set everything back up, and run more test calls. This time, the Invite has a bad IP header checksum. Look at clock, 6pm EDT. Give up, go home. I'm going to go back to the original router Monday morning, and check the compatibility mode theory, but has anyone ever seen "just certain sent packets show up with a bad IP header checksum, as monitored on-machine"? (I know that the original 40D router might well *have* a problem, and that the checksum thing is orthogonal to the original problem -- since older pcaps show clean setups -- but at least I can confirm I have the NATs configured right.) Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
wireshark can show chksum incorrectly at times. Ujjval K
On Jun 21, 2014, at 9:37 AM, Jay Ashworth <jra at baylink.com> wrote:
I have a client using the Spitfire dialler on Win7 to dial via SIP to a carrier called VoxTelecom; I infer they're a virtual carrier because the SIP goes to their Sonus SBC at a single IP, but the media sessions go all over creation.
The client has been having completion trouble, and the dialler folks said "crappy circuit; too much jitter and packet loss", tested from the dialler using PingPlotter. I don't think it was jitter, I think it was ping response deviation; PingPlotter doesn't appear to actually test jitter.
But to tick the boxes, I had road runner out; they replaced a ubee D2 modem with their New Hawtness Arris D3 modem; no change. All his analog measurements were pristine, he told me.
So next step, check the router. Log in to the Fortigate 40D; control panel won't paint properly. This *may* have been an IE10 compatibility mode red-herring, but I temporarily swapped it for a 20C, which I could talk to.
Set up the inbound DNATs for udp/5060 SIP and upd/49152-49252 RTP.
Ran some calls.
They're not seeing my ACK after they send me an SDP. They get the invite, but not the ACK. I send RTP, but they don't bother cause they think the call's not set up yet.
Wireshark on the dialler... that ACK packet *has a bad IP header checksum*.
Not the earlier packets; just the ACK. Huh?
So, assume it's the OS, somehow; reboot. 65 Windows updates and an hour later...
Set everything back up, and run more test calls. This time, the Invite has a bad IP header checksum. Look at clock, 6pm EDT. Give up, go home.
I'm going to go back to the original router Monday morning, and check the compatibility mode theory, but has anyone ever seen "just certain sent packets show up with a bad IP header checksum, as monitored on-machine"?
(I know that the original 40D router might well *have* a problem, and that the checksum thing is orthogonal to the original problem -- since older pcaps show clean setups -- but at least I can confirm I have the NATs configured right.)
Cheers, -- jra
-- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
True, especially when capturing on the device (versus from a mirror port). Possible MTU size issue? On Jun 21, 2014, at 11:58 AM, Ujjval Karihaloo <ujjval at simplesignal.com> wrote: wireshark can show chksum incorrectly at times. Ujjval K
On Jun 21, 2014, at 9:37 AM, Jay Ashworth <jra at baylink.com> wrote:
I have a client using the Spitfire dialler on Win7 to dial via SIP to a carrier called VoxTelecom; I infer they're a virtual carrier because the SIP goes to their Sonus SBC at a single IP, but the media sessions go all over creation.
The client has been having completion trouble, and the dialler folks said "crappy circuit; too much jitter and packet loss", tested from the dialler using PingPlotter. I don't think it was jitter, I think it was ping response deviation; PingPlotter doesn't appear to actually test jitter.
But to tick the boxes, I had road runner out; they replaced a ubee D2 modem with their New Hawtness Arris D3 modem; no change. All his analog measurements were pristine, he told me.
So next step, check the router. Log in to the Fortigate 40D; control panel won't paint properly. This *may* have been an IE10 compatibility mode red-herring, but I temporarily swapped it for a 20C, which I could talk to.
Set up the inbound DNATs for udp/5060 SIP and upd/49152-49252 RTP.
Ran some calls.
They're not seeing my ACK after they send me an SDP. They get the invite, but not the ACK. I send RTP, but they don't bother cause they think the call's not set up yet.
Wireshark on the dialler... that ACK packet *has a bad IP header checksum*.
Not the earlier packets; just the ACK. Huh?
So, assume it's the OS, somehow; reboot. 65 Windows updates and an hour later...
Set everything back up, and run more test calls. This time, the Invite has a bad IP header checksum. Look at clock, 6pm EDT. Give up, go home.
I'm going to go back to the original router Monday morning, and check the compatibility mode theory, but has anyone ever seen "just certain sent packets show up with a bad IP header checksum, as monitored on-machine"?
(I know that the original 40D router might well *have* a problem, and that the checksum thing is orthogonal to the original problem -- since older pcaps show clean setups -- but at least I can confirm I have the NATs configured right.)
Cheers, -- jra
-- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
+1 -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ujjval Karihaloo Sent: Saturday, June 21, 2014 10:58 AM To: Jay Ashworth Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Odd network problem with SIP wireshark can show chksum incorrectly at times. Ujjval K
On Jun 21, 2014, at 9:37 AM, Jay Ashworth <jra at baylink.com> wrote:
I have a client using the Spitfire dialler on Win7 to dial via SIP to a carrier called VoxTelecom; I infer they're a virtual carrier because the SIP goes to their Sonus SBC at a single IP, but the media sessions go all over creation.
The client has been having completion trouble, and the dialler folks said "crappy circuit; too much jitter and packet loss", tested from the dialler using PingPlotter. I don't think it was jitter, I think it was ping response deviation; PingPlotter doesn't appear to actually test jitter.
But to tick the boxes, I had road runner out; they replaced a ubee D2 modem with their New Hawtness Arris D3 modem; no change. All his analog measurements were pristine, he told me.
So next step, check the router. Log in to the Fortigate 40D; control panel won't paint properly. This *may* have been an IE10 compatibility mode red-herring, but I temporarily swapped it for a 20C, which I could talk to.
Set up the inbound DNATs for udp/5060 SIP and upd/49152-49252 RTP.
Ran some calls.
They're not seeing my ACK after they send me an SDP. They get the invite, but not the ACK. I send RTP, but they don't bother cause they think the call's not set up yet.
Wireshark on the dialler... that ACK packet *has a bad IP header checksum*.
Not the earlier packets; just the ACK. Huh?
So, assume it's the OS, somehow; reboot. 65 Windows updates and an hour later...
Set everything back up, and run more test calls. This time, the Invite has a bad IP header checksum. Look at clock, 6pm EDT. Give up, go home.
I'm going to go back to the original router Monday morning, and check the compatibility mode theory, but has anyone ever seen "just certain sent packets show up with a bad IP header checksum, as monitored on-machine"?
(I know that the original 40D router might well *have* a problem, and that the checksum thing is orthogonal to the original problem -- since older pcaps show clean setups -- but at least I can confirm I have the NATs configured right.)
Cheers, -- jra
-- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Make sure you're fully disabling the ALG on those Fortigates. I got bit by that one time when I discovered (after many emails with support) that there are 2 places you have to shut off the SIP ALG before it's actually disabled, and the documentation only mentioned one of them. Brooks Bridges Firestorm Networks Email: brooks at firestormnetworks.net Voice: +1.8006975891 Fax: +1.8889721835 On 6/21/2014 10:37 AM, Jay Ashworth wrote:
I have a client using the Spitfire dialler on Win7 to dial via SIP to a carrier called VoxTelecom; I infer they're a virtual carrier because the SIP goes to their Sonus SBC at a single IP, but the media sessions go all over creation.
The client has been having completion trouble, and the dialler folks said "crappy circuit; too much jitter and packet loss", tested from the dialler using PingPlotter. I don't think it was jitter, I think it was ping response deviation; PingPlotter doesn't appear to actually test jitter.
But to tick the boxes, I had road runner out; they replaced a ubee D2 modem with their New Hawtness Arris D3 modem; no change. All his analog measurements were pristine, he told me.
So next step, check the router. Log in to the Fortigate 40D; control panel won't paint properly. This *may* have been an IE10 compatibility mode red-herring, but I temporarily swapped it for a 20C, which I could talk to.
Set up the inbound DNATs for udp/5060 SIP and upd/49152-49252 RTP.
Ran some calls.
They're not seeing my ACK after they send me an SDP. They get the invite, but not the ACK. I send RTP, but they don't bother cause they think the call's not set up yet.
Wireshark on the dialler... that ACK packet *has a bad IP header checksum*.
Not the earlier packets; just the ACK. Huh?
So, assume it's the OS, somehow; reboot. 65 Windows updates and an hour later...
Set everything back up, and run more test calls. This time, the Invite has a bad IP header checksum. Look at clock, 6pm EDT. Give up, go home.
I'm going to go back to the original router Monday morning, and check the compatibility mode theory, but has anyone ever seen "just certain sent packets show up with a bad IP header checksum, as monitored on-machine"?
(I know that the original 40D router might well *have* a problem, and that the checksum thing is orthogonal to the original problem -- since older pcaps show clean setups -- but at least I can confirm I have the NATs configured right.)
Cheers, -- jra
We've had to do the same, too. Frank -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Brooks Bridges Sent: Saturday, June 21, 2014 4:10 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Odd network problem with SIP Make sure you're fully disabling the ALG on those Fortigates. I got bit by that one time when I discovered (after many emails with support) that there are 2 places you have to shut off the SIP ALG before it's actually disabled, and the documentation only mentioned one of them. Brooks Bridges Firestorm Networks Email: brooks at firestormnetworks.net Voice: +1.8006975891 Fax: +1.8889721835 On 6/21/2014 10:37 AM, Jay Ashworth wrote:
I have a client using the Spitfire dialler on Win7 to dial via SIP to a carrier called VoxTelecom; I infer they're a virtual carrier because the SIP goes to their Sonus SBC at a single IP, but the media sessions go all over creation.
The client has been having completion trouble, and the dialler folks said "crappy circuit; too much jitter and packet loss", tested from the dialler using PingPlotter. I don't think it was jitter, I think it was ping response deviation; PingPlotter doesn't appear to actually test jitter.
But to tick the boxes, I had road runner out; they replaced a ubee D2 modem with their New Hawtness Arris D3 modem; no change. All his analog measurements were pristine, he told me.
So next step, check the router. Log in to the Fortigate 40D; control panel won't paint properly. This *may* have been an IE10 compatibility mode red-herring, but I temporarily swapped it for a 20C, which I could talk to.
Set up the inbound DNATs for udp/5060 SIP and upd/49152-49252 RTP.
Ran some calls.
They're not seeing my ACK after they send me an SDP. They get the invite, but not the ACK. I send RTP, but they don't bother cause they think the call's not set up yet.
Wireshark on the dialler... that ACK packet *has a bad IP header checksum*.
Not the earlier packets; just the ACK. Huh?
So, assume it's the OS, somehow; reboot. 65 Windows updates and an hour later...
Set everything back up, and run more test calls. This time, the Invite has a bad IP header checksum. Look at clock, 6pm EDT. Give up, go home.
I'm going to go back to the original router Monday morning, and check the compatibility mode theory, but has anyone ever seen "just certain sent packets show up with a bad IP header checksum, as monitored on-machine"?
(I know that the original 40D router might well *have* a problem, and that the checksum thing is orthogonal to the original problem -- since older pcaps show clean setups -- but at least I can confirm I have the NATs configured right.)
Cheers, -- jra
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (5)
-
brooks＠firestormnetworks.net -
frnkblk＠iname.com -
jra＠baylink.com -
peeip989＠gmail.com -
ujjval＠simplesignal.com