On 11/12/13 6:40 PM, Jimmy Hess wrote:
I would suggest capturing packets towards the devices experiencing it, behind the NAT device, using Wireshark ----- I would wonder first if either the NAT/ACL isn't working as designed; or traffic is coming from a SIP ALG / inside the NAT; spoofing the SBC's source IP seems terribly unlikely.
I think it's more likely, there's an unexpected way the Polycom is being contacted, such as a proxy service on a router.
Good idea, but these are typically remote customer sites and any individual phone maybe gets one of these ghost calls per day or two, so implementation is kind of tough.
Then there is that matter of; "Does your NAT device verify the foreign IP address of reverse traffic like a full stateful firewall would, or does it just check the destination port number on an incoming packet, and immediately translate to internal IP based on the destination port number and forward to the internal device?"
In the latter case, the internal device might be contacted on port 5060 from other internet hosts scanning the ephemeral port range; if that 5060 from the internal device has recently been used as a source port from the Polycom contacting the SBC.
That's kind of what I was thinking but we're also seeing it from behind an Adtran IAD with a SIP ACL that permits only our SBCs.
So a full packet capture from the network with the handsets, could give you a better idea, of what you are seeing.
Absolutely agreed. The Polycom XML code mentioned earlier looks promising as well. The curious thing is that this is suddenly happening within the past two days on installations that have been trouble-free for months. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV