[Bug 757] New: SIP connection helper not setting RTCP conntrack expectation

bugzilla-daemon at bugzilla.netfilter.org bugzilla-daemon at bugzilla.netfilter.org
Fri Oct 14 07:09:42 CEST 2011


           Summary: SIP connection helper not setting RTCP conntrack
           Product: netfilter/iptables
           Version: linux-2.6.x
          Platform: i386
        OS/Version: Ubuntu
            Status: NEW
          Severity: normal
          Priority: P5
         Component: ip_conntrack
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: falconict at gmail.com
   Estimated Hours: 0.0

Created an attachment (id=368)
 --> (http://bugzilla.netfilter.org/attachment.cgi?id=368)
log and configuration files

I have a strange problem I hope you can help out in.

I'm trying to establish a SIP audio session between a Blink client sitting with
a private IP address on eth0 of a Linux firewall which performs masquerading to
a public IP address ( on eth1 towards the Bonjour SIP service
(I'm using their test call facility).  About 50% of the time, the session is
successful, but the other 50% of the time, all RTP packets from both sides and
the RTCP packets from the calling party (the client) are dropped by the
iptables firewall (logged in syslog).  All SIP packets make it through and the
IP addresses are translated as expected as far as I can tell.

When the session is successful, conntrack -E is able to show the UDP connection
streams being expected from both sides (both RTCP and RTP).  When the session
is unsuccessful, conntrack -E only show the UDP connections from the called

This behavious has been replicated with the iptables packages 1.4.4-2ubuntu2, and 1.4.10-1ubuntu1 and libnetfilter-conntrack packages
0.0.101-1 and 0.9.1-1 under Ubuntu Maverick (10.10), Natty (11.04) and Oneiric
(11.10).  I'm using the nf_conntrack_sip and nf_nat_sip helpers.

It seems to me that the helpers occasionally miss the SIP/SDP packet coming
from the called party proxy containing the called endpoint identifiers (IP and
RTP port), consequently the expectations for the outgoing RTP and RTCP (=RTP+1)
UDP port flows are not set up by libnetfilter, leading to the
RELATED,ESTABLISHED rules not being considered by iptables and a dropping of
both RTCP and RTP port flows.

What's also interesting is that when the call is unsuccessful, conntrack -E
contains the expectation of RTCP and RTP packet flows from the called party,
and yet iptables still drops the incoming RTP packets from the called party
(apart from those of the calling party).

I have attached some log (pcap traces of eth0&1, conntrack and syslog) and
configuration files (iptables), which represent the scenario of 3 successive
SIP call attempts, the first two being unsuccessful and the third being
successful.  I've summarised some salient features below for the 3 sessions:

                                           RTCP ports            RTP ports
eth0         eth1          syslog        calling    called    calling   called
14:09:25-31  14:09:26-31   14:09:25-31   50059      50619     50058     50618
14:09:41-46  14:09:43-46   14:09:41-46   50061      58541     50060     58540
14:09:55-02  14:09:55-02   n.a.          50063      50747     50062     50747

Can you help?

Configure bugmail: http://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.

More information about the netfilter-buglog mailing list