7 Nov
2003
7 Nov
'03
3:01 a.m.
Hi Jiri,
Thanks for that, makes a lot of sence. I did think thats what we were doing so here is my
config file for you to have a look at.
Could you go through it and tell me where I am going wrong?
Thanks much,
Stephen
route{
loose_route();
force_rport();
fix_nated_contact();
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (msg:len >= max_len ) {
sl_send_reply("513", "Message too big");
break;
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
if(method=="REGISTER") {
setflag(1); # remember this is ATA
force_rport();
fix_nated_contact();
log("LOG: In NAT clause\n");
#fix_nated_sdp("3");
};
if (!method=="REGISTER") record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
break;
};
if (uri=~"portal.commverge.co.nz") {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication
if (!www_authorize("portal.commverge.co.nz",
"subscriber")) {
www_challenge("portal.commverge.co.nz", "0");
break;
};
save("location");
break;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
forward(202.180.125.200,5060);
break;
};
# user on-line...forward to his current destination
forward(uri:host,uri:port);
break;
};
if (uri=~"202.180.83.14") {
log("LOG: In Portal clause!\n");
rewritehostport("portal.commverge.co.nz:5060");
log("LOG: Out of Portal clause!\n");
};
if (!lookup("location")) {
forward(202.180.125.200,5060);
break;
};
# user on-line...forward to his current destination
forward(uri:host,uri:port);
break;
}
route[1]
{
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
}
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Friday, 7 November 2003 12:42 p.m.
To: Stephen Miles
Subject: RE: [Serusers] udp error
At 12:15 AM 11/7/2003, Stephen Miles wrote:
Hi Jiri,
SIP support is not turned on on our pix so it is just acting as a nat device, much the
same as a linux box or standard router.
Than you will need RTP relay. Otherwise the media from public internet
to your natted client will be dropped by the nat box. Also, you will
have to configure ser to send replies symmetricaly (as opposed to
address advertised in Via). Use force_rport for that.
What is happening though is that the firewall (pix in
this case, cisco 827 in others) is not forwarding/natting the same port as the original
request. e.i 192.168.18.12 sends sip message to portal on port 5060, firewall gets that
and nats it but uses the next avalible port to send out on so the portal (our sip proxy
running ser) gets the request from firewall:next_avalible_port, not firewall:5060. It
seems that ser doesn't realise this and thats why we get the error, if I set my
softphone (X-Lite) to use the next port the firewall is going to use (from watching logs
etc) is works. Sortphone sends register as 192.168.18.12:65389 and the firewall does the
same firewall:65389 and it works against ser, phone registers and calls can be make.
SIP servers are supposed to reply to port number advertised in
rquest's topmost via header field.
I hope this makes more sence. If not please let me know
as this could be a bit of a show stopper for us using ser and we would very much like to.
Nevertheless, the rtp relay workaround along with SER configured in a nat-friendly
manner should help you out.
-jiri