SIP call, can't send RTP on bound UDP port after sending ICMP packet
Hi
We have a strange issue with a SIP call where if we receive even a single RTP packet whilst the port is closed before we have sent a keepalive packet to open the pinhole, any packets subsequently sent come from src port 1042. The far end isn't expecting that so it results in no audio.
However if we managed to send the keepalive before receiving RTP from the far end everything works fine and we have audio. We receive an RTP packet destined for port 30322 but we the port isn't open so an ICMP packet is returned. However when we then try to send the keepalive it comes from port 1042 rather than 30322. This is after the second 200OK on the second leg of the call. Anyone know why this is happening. We can send a Wireshark trace if required, we would have uploaded but the system isn't allowing.
Thanks
You have to post the capture file on cloudshark.org or any plain file sharing service and edit the question with a login-free link to it.
But Wireshark rarely tells you why something has happened on a protocol level - in most cases it "only" tells you exactly what has happened. Normally only the log from the application can answer the "why" question.
So without knowing the structure of your network between the actual source of the RTP and the point where you observe this behaviour it is hard to say whether the RTP source or some firewall/SBC equipment is responsible for the behaviour, which is the first step of the analysis. Only after identifying the responsible box you can switch trace mode on it and analyse the traces after the test call.
SIP helpers (application layer gateways) on non-SBC firewalls are often a PITA as they contain bugs which ...(more)