bugzilla-daemon at bugzilla.netfilter.org
2011-Oct-14 05:09 UTC
[Bug 757] New: SIP connection helper not setting RTCP conntrack expectation
http://bugzilla.netfilter.org/show_bug.cgi?id=757
Summary: SIP connection helper not setting RTCP conntrack
expectation
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 (60.240.200.118) 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
party.
This behavious has been replicated with the iptables packages 1.4.4-2ubuntu2,
1.4.4.4-2ubuntu3 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?
Ivan
--
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.
bugzilla-daemon at bugzilla.netfilter.org
2011-Oct-14 05:11 UTC
[Bug 757] SIP connection helper not setting RTCP & RTP flow expectation
http://bugzilla.netfilter.org/show_bug.cgi?id=757
Ivan <falconict at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|SIP connection helper not |SIP connection helper not
|setting RTCP conntrack |setting RTCP & RTP flow
|expectation |expectation
--
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.
bugzilla-daemon at bugzilla.netfilter.org
2011-Oct-27 05:44 UTC
[Bug 757] SIP connection helper not setting RTCP & RTP flow expectation
http://bugzilla.netfilter.org/show_bug.cgi?id=757 --- Comment #1 from Ivan <falconict at gmail.com> 2011-10-27 07:44:12 --- Please excuse the bump! What's being attempted here is a simple NAT traversal without using any extra capabilities (STUN, ICE or TURN). In my view the use case is simple enough to be able to be handled natively by the existing SIP nat connection helpers, which however seem to be behaving erratically. If there is nothing wrong with the configuration, this might imply something wrong with the conntrack algorithms. Hope someone can help. Ivan -- 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.
bugzilla-daemon at bugzilla.netfilter.org
2011-Nov-07 05:45 UTC
[Bug 757] SIP connection helper not setting RTCP & RTP flow expectation
http://bugzilla.netfilter.org/show_bug.cgi?id=757
Ivan <falconict at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--- Comment #2 from Ivan <falconict at gmail.com> 2011-11-07 06:45:25 ---
I've managed to resolve the issue.
I noticed that whenever the call was successful, the media endpoints had the
same IP address as the SIP signalling endpoints, and whenever the call was not
successful, the endpoints were different. I found that the nf_conntrack_sip
module has a parameter called 'sip_direct_media' that by default only
allows
the signalling and media endpoints to have the same IP address. On specifying
the option to remove this strict requirement, the problem disappeared and calls
became successful.
So the conntrack SIP module is working as designed and there is no bug.
Apologise for the false alarm.
--
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.