M D wrote:
I have an
OpenSER 1.1 box on a public IP running a config taken
more-or-less verbatim from the
iptel.org <http://iptel.org> getting
started examples. I have a UA behind a PIX which is translating port
5060 on the phone to port 8907 on the firewall. OpenSER is ignoring this
and sending replies to INVITEs to port 5060 on the firewall.
If it's likely to make any difference, the
PATed IP and the IP of the
OpenSER box are on the same network.
On 08/08/06, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Use force_rport()
http://openser.org/dokuwiki/doku.php?id=openser_v1.1.0_core_cookbook#force_…
Thanks Klaus. The config already had several mentions of force_rport()
but it none before or during the INVITE handler. I've added it like
so:
route {
...
force_rport();
# -----------------------------------------------------------------
# Call Type Processing Section
# -----------------------------------------------------------------
if (uri!=myself) {
route(4);
route(1);
return;
};
if (method=="ACK") {
route(1);
return;
} else if (method=="CANCEL") {
route(1);
return;
} else if (method=="INVITE") {
route(3);
return;
} else if (method=="REGISTER") {
route(2);
return;
};
...
}
Does that seem reasonable? It's going to force_rport() for every call,
NATed, PATed or not. Perhaps I should add a block to deal with NAT
traversal prior to routing the call according to message, something
like:
route {
...
if (nat_uac_test("19")) {
setflag(6);
force_rport();
fix_nated_contact();
};
# -----------------------------------------------------------------
# Call Type Processing Section
# -----------------------------------------------------------------
if (uri!=myself) {
route(4);
route(1);
return;
};
if (method=="ACK") {
route(1);
return;
} else if (method=="CANCEL") {
route(1);
return;
} else if (method=="INVITE") {
route(3);
return;
} else if (method=="REGISTER") {
route(2);
return;
};
}
Thanks for any help,
Mark