Iptables breaks a working VoIP phone?

Corey Edwards tensai at zmonkey.org
Mon Oct 29 08:46:36 MDT 2007


On Mon, 2007-10-29 at 06:31 -0600, Dave Smith wrote:
> Kenneth Burgener wrote:
> > I have dropped packets being logged, and I can see the
> > source/destination IP and port of an occasional packet being lost.  I am
> > not sure the packets I am seeing a from the direct phone call or some
> > sort of "ping" VoIP traffic.  When I put in the rules where it would
> > forward ALL TCP/UDP traffic to the Sipra box, these logs would no longer
> > appear, but the phone calls were still broken.
> >   
> 
> Have you run Wireshark on the phone-side to see what the traffic looks 
> like in both scenarios (1, with the Linksys router, and 2, with the 
> Linux firewall?)

I also recommend running Wireshark. It's an extremely useful tool for
debugging SIP. Like Hans said, you're going to have more success with
targeted troubleshooting than with stabbing in the dark. On your
shorewall you can capture the packets with this command:

        # tcpdump -i any -np -s 1500 -w call-trace.pcap udp

Then make a phone call. You'll get quite a few packets because you'll
get all the RTP as well as the SIP, but that's fine. Speaking of which,
it might be a good time for a quick lesson on how SIP works.

Alice                              Bob
SIP INVITE (one ringy     ----->
  dingy)
                          <-----   180 Ringing (the phone is ringing)
                          <-----   200 OK (the phone was answered)
                                       (SDP: use codec Foo and RTP port
                                       12345 on IP 192.168.0.1)
SIP ACK (SDP: use RTP     ----->
 port 54321 on IP
 172.16.0.1)

At that point, RTP begins to flow between the two IP addresses
specified. This is where NAT becomes a problem. If the endpoints aren't
aware of NAT (which is its design), they will specify their internal
addresses and the return packets will be silently discarded by some
router's egress filters. This is one reason why NAT sucks. You can trick
it using connection tracking and SIP transformations. Or a tool like
STUN to tell the endpoint what its routeable address actually is. Or a
proxy which knows how to filter out the RFC1918 addresses and put in the
correct values.

Corey





More information about the PLUG mailing list