Yes, I have tried your patch yesterday evening. The SIP-control connection
was OK as I could get my phone ringing, but got no audio in both
directions. I did not have time to get a network trace yet, but I remember
that when I wrote up the patch I use some months ago, the wrongly expected
connection was a problem I ran into.
Forgive me if I'm wrong, but doesn't the line below, which is in the
set_expected_rtp function, expect an RTP-connection which originates from
ct->tuplehash[!dir].tuple.src.u3 which is the IP-address of the SIP
control connection server in the case that the client sends a SIP packet
to the server?
nf_conntrack_expect_init(exp, family,
&ct->tuplehash[!dir].tuple.src.u3, addr,
IPPROTO_UDP, NULL, &port);
I am not an expert in the netfilter code, but is it possible that your
client starts to send an RTP-stream to the server and hence generates a
conntrack entry that enables the server to send an RTP-stream back to
the client?
Regards,
Jerome
On Thu, 14 Jun 2007, Herbert Xu wrote:
On Thu, Jun 14, 2007 at 11:28:05AM +0200, Jerome Borsboom wrote:
Your patch indeed resolves part of the issue, but it is not complete. The
problem is that set_expected_rtp in the file
net/netfilter/nf_conntrack_sip.c assumes that the source IP-address of the
expected RTP audio connection is the same as the source address of the SIP
control connection. This is not necessarily the case and prevents RTP
connections from getting through the NAT box as the expected connection
does not match the attempted connection.
Did you actually try my patch? It certainly does not assume this.
In fact all my SIP servers use different addresses for the audio
connection and they work just fine with the client behind SNAT.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
