Stuart Henderson wrote:
On 2006/06/13 14:58, Daniel Ouellet wrote:
That's cool! No worry, I guess your subject is way more interesting to many,
or no one is using NAT traversal or have any needs for it.
I don't know much about H.323, but for SIP draft-biggs-sip-nat has some
useful information, care needs to be taken not to break other nat-
traversal mechanisms though (google: SIP ALG break), and there are a
lot of strange UAs around...
Another way for SIP is ser/openser and mediaproxy, but it definitely
needs work to configure, it's nothing like how ftp-proxy/tftp-proxy
work (which seems to be more the sort of thing you're looking for).
Actually I wasn't looking for ftp-proxy type, but really for SIP NAT
traversal. Sorry if I didn't make that clear.
Not going into any details, but in short, and very simplistically as
well, connection are establish out to a phone behind NAT for example
coming from 5060 to port 5060 on the CPE device as SIP defines it and
the reply will be send back to port 5061 oppose to what would be
expected to come back to 5060.
So, the NAT traversal is use to really handle the traffic, but not
looking at the reply to the port use for sending, but to the port+1
instead for SIP communications.
This is a very simplistic description obviously, but I thought it would
be best handle by PF instead of an other proxy, but I may well be wrong.
Trying to keep it simple and I thought that may be a hook inside PF
would accomplish this very well.
Isn't it the case?
I would welcome feedback or idea on this if I am thinking about it the
wrong way.
If best serve by yet an other proxy type of daemon, then may be I could
try to break my teeth on it, but I really thought it was best inside PF.
Thoughts?
