On Thu, Jun 14, 2007 at 02:32:56PM +0200, Jerome Borsboom wrote: > > 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? Yes you're quite right. As you correctly note below, normally the client would use the same IP address for both SIP and RTP and therefore the client's first RTP packet would allow both RTP directions to work. > 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? The only scenario where it would break is if you had two servers talking to each other through NAT and both of them use different addresses for RTP. This is indeed a case which the current code does not handle. However, I don't think we should handle it by accepting an RTP packet from any address as we have the information available to do better than that. We should correlate the RTP addresses in the SIP packets and setup a correct expectation once both are received. 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
