Re: nf_conntrack_sip problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Joerg Dorchain wrote:
On Wed, Jul 01, 2009 at 10:56:16PM +0200, Joerg Dorchain wrote:
Aehm, 85.93.219.122 is the address from the SDP payload for the
RTP stream as attached. 85.93.219.114 is is address of where the SIP REGISTER
is sent to.

I will try again with only sip_direct_media=0.

I works, but somewhat ugly.
# conntrack -E expect
180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11080
180 proto=17 src=0.0.0.0 dst=85.93.219.122 sport=0 dport=11081
180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7076
180 proto=17 src=0.0.0.0 dst=212.88.133.153 sport=0 dport=7077

All the places where the ip is 0.0.0.0 or the port is 0 could be
filled more specifically. The necessary information is available
in the same SIP/SDP flow as the used information. Besides the two
RTP stream are unidirectional, so I'd like to have something like
this:
180 proto=17 src=212.88.133.153 dst=85.93.219.122 sport=7076 dport=11080
180 proto=17 src=85.93.219.122 dst=212.88.133.153 sport=11081 dport=7077

It depends on the setup. The remote address is not available at
the time the expectation is created when using early media. As
soon as the SDP payload is sent, one way audio might arrive,
even from multiple source addresses in parallel. So this can't
be made more specific for the generic case. When not using early
media, we could wait for the SDP payload of the remote side, but
I don't think many clients are not doing this.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux