Yes, this is a known issue,
but the solution depends
on how you optimize you rtp handling (active media). The INVITE from
your GW
will not be NATed and as the INVITE is loose route, no
lookup("location") is done to see if the dst UA is NATed.
However, this is what the nat=yes flag is supposed to be used for, to
mark the
dialog as NATed. Thus, the Route set from your GW should contain
nat=yes and
this will cause the right flag to be set for the INVITE.
Doing it in the onreply route should not work, because you need to make
sure
that both the INVITE from the GW and the OK from the UA are handled as
rtp
proxy forked. I'm not sure why it works, maybe you force rtp proxy for
too many
calls? (calls to the GW from NATed UAs except symmetric NATs can go
without rtp
proxy).
g-)
Natambu Obleton wrote:
After
a crap load of tracing and putting log(“I am here\n”) all over the
config file I think I may of gotten it working?
I started
with the gettingstarted
gw-pstn.cfg file and made this change…
I edited my
onreply route[1] to
setflag(6)..
onreply_route[1]
{
log("******************************ONREPLY ROUTE[1]\n");
Added:
if (!search("^Contact:[ ]*\*") &&
client_nat_test("7")) {
Added:
log("******************************ONREPLY ROUTE[1]
set_flag\n");
Added:
setflag(6);
Added:
}
if ((isflagset(6) || isflagset(7)) &&
(status=~"(180)|(183)|2[0-9][0-9]")) {
log("******************************ONREPLY ROUTE[1]
flag_set\n");
if (!search("^Content-Length:[ ]*0")) {
use_media_proxy();
log("******************************ONREPLY ROUTE[1]
use_media_proxy\n");
};
};
if (client_nat_test("1")) {
log("******************************ONREPLY ROUTE[1]
fix_nated_contact\n");
fix_nated_contact();
};
}
Ok. I have SER working
with mediaproxy and it
rewrites the requests to goto the Mediaproxy server as it should, but
after a
call has been up for a bit.. it gets another invite from my PSTN
gateway and
when this invite comes through it doesn’t rewrite the media addresses
why?
My config:
http://laplata.fasttrackcomm.net/ser_cfg.txthttp://laplata.fasttrackcomm.net/ser_cfg.txt
My transaction log:
http://laplata.fasttrackcomm.net/translog.txt
About ¾’s of the way down
you will see where
206.123.213.84 sends another invite for the call and SER doesn’t change
the media information on it. Thanks for your help.
Natambu Obleton
Network Engineer
FastTrack Communications
nobleton@fasttrackcomm.net
(970) 247-3366 office
(970) 247-2426 fax
_______________________________________________
Serusers mailing list
Serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers