21 Feb
2005
21 Feb
'05
5:51 p.m.
If you have the latest cvs version, you can use "19" (add test=16). It may
make a difference if you have configured your UA with stun. If not, "3"
should be good.
Use some sort of stun client implementation to test your nat.
http://sourceforge.net/project/showfiles.php?group_id=47735&package_id=…
rtpproxy is rather silent. :-( You should do a tcpdump port control_port to
see if any traffic is going.
Also, you can do netstat -nlp to see if any udp ports are allocated once you
believe a call is proxied.
g-)
Aisling O'Driscoll wrote:
Hi Greger,
I only use nat_uac_test("3") as that is what is given in most
examples on the mailing list. Is there any way that i can test if I
am behind symmetric nat? I have rtpproxy running with ser but not
sure if my below ser.cfg script invokes it correctly. Do you know
where I could find the rtpproxy debug log?
Thanks again,
Aisling.
---- Original Message ----
From: greger(a)teigre.com
To: ashling.odriscoll(a)cit.ie, serusers(a)lists.iptel.org
Subject: Re: [Serusers] SER SDP Port Problem??
Date: Mon, 21 Feb 2005 12:11:15 +0100
Aisling,
The port is in the m= line. You use nat_uac_test("3"). Any particular
reason
for not using all tests?
Please note that sdp rewriting does not work if the UA is behind a
symmetric
NAT and you are calling in. You must then via an RTP proxy like
mediaproxy
or rtpproxy.
g-)
Aisling O'Driscoll wrote:
-------------------Legal
Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended
only for the person to whom it is addressed. Its contents may be
protected by legal and/or professional privilege. Should it be
received by you in error please contact the sender at the above
quoted email address. Any unauthorised form of reproduction of this
message is strictly prohibited. The Institute does not guarantee the
security of any information electronically transmitted and is not
liable if the information contained in this communication is not a
proper and complete record of the message as transmitted by the
sender nor for any delay in its receipt. Hi,
I understand the basic problem behind one way audio is that the
client behind nat has a private address in the sdp information,
therefore the voice cannot be delivered to this private address. It
is necessary to rewrite this sdp info with the nat public address.
However I have done this in my ser.cfg and I still have one way
voice.
I have included some of relevant ethereal messages on SER and my
ser.cfg below. The messages show that the rtp information has been
changed. Does anyone think the problem is because there is no port
information in the "c" and "o" fields in the sdp?? If so how can I
make sure the port is included?
Many Thanks,
Aisling.
Ethereal messages:
call between private client with public nat address 63.218.54.71
and
a public client with address 157.190.183.80. The
SER address is
157.190.183.70.
REGISTER sip:157.190.183.70 SIP/2.0
VIA: SIP/2.0/UDP 63.218.54.71:11987;rport;branch=z9h.....
FROM: whoever <sip:2008@157.190.183.70>;tag=455....
TO: whoever <sip:2008@157.190.183.70>
CONTACT: "whoever" <sip:2008@63.218.54.71:11987>
Call-Id: ....
CSeq: 22227 REGISTER
Expires; 1800
User Agent: X-Lite release 1103m
Content-Length: 0
SIP/2.0 200 OK
VIA: SIP/2.0/UDP 63.218.54.71:11987;rport;branch=z9h.....
FROM: whoever <sip:2008@157.190.183.70>;tag=455....
TO: whoever <sip:2008@157.190.183.70>
CONTACT: "whoever" <sip:2008@63.218.54.71:11987>;q=0.00
expires=1800
Call-Id: ....
CSeq: 22227 REGISTER
Expires; 1800
User Agent: X-Lite release 1103m
Content-Length: 0
The public client (157.190.183.80 also registers)
Then the private client invites the public client to a voice
conversation:
INVITE sip:2001@157.190.183.70 SIP/2.0
VIA: SIP/2.0/UDP 63.218.54.71:11987;rport;branch=z9h.....
FROM: whoever <sip:2008@157.190.183.70>;tag=455....
TO: whoever <sip:2001@157.190.183.70>
CONTACT: "whoever" <sip:2008@63.218.54.71:11987>
Call-Id: ....
CSeq: 19929 INVITE
Expires; 1800
User Agent: X-Lite release 1103m
Content-Type=application/sdp
Content-Length: 290
Session description Protocol
Owner/Creator of the Session (o): 2008 245812 272828 IN IP4
63.218.54.71
Connection information (c): IN IP4 63.218.54.71
A 100 Trying is sent back from SER to the private client (i.e.
caller)
The INVITE is forwarded from SER to public client (callee) as show
below:
INVITE sip:2001@157.190.183.70 SIP/2.0
VIA: SIP/2.0/UDP 157.190.183.70;branch=....
VIA: SIP/2.0/UDP 63.218.54.71:11987;branch=z9h.....
FROM: whoever <sip:2008@157.190.183.70>;tag=455....
TO: whoever <sip:2001@157.190.183.70>
CONTACT: "whoever" <sip:2008@63.218.54.71:11987>
Call-Id: ....
CSeq: 19929 INVITE
Expires; 1800
User Agent: X-Lite release 1103m
Content-Type=application/sdp
Content-Length: 290
Session description Protocol
Owner/Creator of the Session (o): 2008 245812 272828 IN IP4
63.218.54.71
Connection information (c): IN IP4 63.218.54.71
157.190.183.80 157.190.183.70 SIP 100 Trying
157.190.183.80 157.190.183.70 SIP 180 Ringing
157.190.183.70 63.218.54.71 SIP 180 Ringing
157.190.183.80 157.190.183.70 SIP/SDP Status: 200OK
SIP/2.0 200 OK
Via: SIP/2.0/UDP 157.190.183.70;branch=....
Via: SIP/2.0/UDP 63.218.54.71:11987;rport=11987;branch=.....
From: whoever<sip:2008@157.190.183.70>;tag=...
To: <sip:2001@157.190.183.70>;tag=....
CSeq: 19929 INVITE
User Agent: Grandtsream BT100 1.0.5.18
Contact: <sip:2001@157.190.183.80>
Session description protocol
(c) IN IP4 157.190.183.80
#
# $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $
#
# simple quick-start config script
#
# ----------- global configuration parameters
------------------------
#debug=3 # debug level (cmd line: -dddddddddd)
#fork=yes
#log_stderror=no # (cmd line: -E)
/* Uncomment these lines to enter debugging mode
debug=7
fork=no
log_stderror=yes
*/
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
#port=5060
#children=4
fifo="/tmp/ser_fifo"
alias="157.190.183.70:5060"
# ------------------ module loading
----------------------------------
# Uncomment this if you want to use SQL database
loadmodule "/usr/lib/ser/modules/mysql.so"
loadmodule "/usr/lib/ser/modules/sl.so"
loadmodule "/usr/lib/ser/modules/tm.so"
loadmodule "/usr/lib/ser/modules/rr.so"
loadmodule "/usr/lib/ser/modules/maxfwd.so"
loadmodule "/usr/lib/ser/modules/usrloc.so"
loadmodule "/usr/lib/ser/modules/registrar.so"
loadmodule "/usr/lib/ser/modules/textops.so"
loadmodule "/usr/lib/ser/modules/nathelper.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
loadmodule "/usr/lib/ser/modules/auth.so"
loadmodule "/usr/lib/ser/modules/auth_db.so"
# ----------------- setting module-specific parameters
---------------
# -- usrloc params --
#modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
modparam("usrloc", "db_mode", 2)
# -- auth params --
# Uncomment if you are using auth module
#
#modparam("auth_db", "calculate_ha1", yes)
#
# If you set "calculate_ha1" parameter to yes (which true in this
config),
# uncomment also the following parameter)
#
#modparam("auth_db", "password_column", "password")
# -- rr params --
# add value to ;lr param to make some broken UAs happy
#NB Had to up this value from 1 to 11 because reinvites were
bombarding called phone
modparam("rr", "enable_full_lr", 11)
#!! Nathelper
modparam("registrar", "nat_flag", 6)
modparam("nathelper", "natping_interval", 30) #Ping interval 30 s
modparam("nathelper", "ping_nated_only", 1) #Ping only clients
behind NAT
modparam("tm", "fr_inv_timer", 80)
# ------------------------- request routing logic
-------------------
# main routing logic
route{
# 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;
};
#########################added for cit client behind nat
09/02/05#######################
if (nat_uac_test("3")){
if (method == "REGISTER" || ! search("^Record-Route:")){
log("Log: Someone trying to register from private IP,rewriting\n");
fix_nated_contact(); #Rewrite contact with source IP
if (method == "INVITE"){
fix_nated_sdp("1"); #Add direction=active to SDP
};
force_rport(); # Add rport parameter to topmost Via
setflag(6); # Mark as Nated
};
};
#####################################################################
###################
# 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") record_route();
# loose-route processing
if (loose_route()) {
#commented 11/02/05
#t_relay();
route(1);
break;
};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
log(1,"into loop");
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication
# if (!www_authorize("157.190.183.70", "subscriber")) {
# www_challenge("157.190.183.70", "0");
# break;
# };
save("location");
break;
};
lookup("aliases");
if (!uri==myself) {
append_hf("P-hint: outbound alias\r\n");
route(1);
break;
};
if (method=="INVITE"){
log(1,"in invite loop");
#break; #no 100 trying
t_on_failure("1");
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
#sl_send_reply("404", "Not Found");
route(2);
break;
};
};
# forward to current uri now; use stateful forwarding; that
# works reliably even if we forward from TCP to UDP
#commented 11/02/05#######################
if (!t_relay()) {
sl_reply_error();
};
}
######################################entered
11/02/05############################################################
route[1]
{
#!!Nathelper
if(uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)" &&
!search("^Route:")){
sl_send_reply("479", "We don't forward to private IP
addresses");
break;
};
t_on_reply("1");
if(!t_relay()){
sl_reply_error();
};
}
######################################entered
11/02/05############################################################
#!! Nathelper
onreply_route[1]{
if(isflagset(6) && status =~ "(183)|2[0-9][0-9]"){
fix_nated_contact();
force_rtp_proxy();
} else if (nat_uac_test("1")){
fix_nated_contact();
};
}
#####################################################################
#
###########################################
# ------------- handling of unavailable user ------------------
route[2] {
# non-Voip -- just send "off-line"
if (!(method == "INVITE" || method == "ACK" || method ==
"CANCEL")) {
sl_send_reply("404", "Not Found");
break;
};
# forward to voicemail now
rewritehostport("157.190.183.70:5062");
t_relay_to_udp("157.190.183.70", "5062");
}
# if forwarding downstream did not succeed, try voicemail running
# at 157.190.183.70:5062
failure_route[1] {
revert_uri();
rewritehostport("157.190.183.70:5062");
append_branch();
t_relay_to_udp("157.190.183.70", "5062");
}
-------------------Legal
Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended
only for the person to whom it is addressed. Its contents may be
protected by legal and/or professional privilege. Should it be
received by you in error please contact the sender at the above
quoted email address. Any unauthorised form of reproduction of this
message is strictly prohibited. The Institute does not guarantee
the
security of any information electronically
transmitted and is not
liable if the information contained in this communication is not a
proper and complete record of the message as transmitted by the
sender nor for any delay in its receipt.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
-------------------Legal
Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended
only for the person to whom it is addressed. Its contents may be
protected by legal and/or professional privilege. Should it be
received by you in error please contact the sender at the above
quoted email address. Any unauthorised form of reproduction of this
message is strictly prohibited. The Institute does not guarantee the
security of any information electronically transmitted and is not
liable if the information contained in this communication is not a
proper and complete record of the message as transmitted by the
sender nor for any delay in its receipt.