Hi All.
I'm using -dev16 and I'm trying to solve a problem where re-INVITES don't always get handled
correctly because of ports being changed from the original INVITE.
Does anyone know if there is something special I need to do for nathelper/rtpproxy to play nice
with re-INVITE messages? Right now I sometimes loose one or both of my RTP channels after a
re-INVITE is received.
Also, are there any docs on the rtpproxy command line arguments? I see these are valid, but I'm
not sure what they are for: vf2Rl:6:s:t:r:p
Regards,
Paul
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
Hi All.
I'm using dev12 with nathelper and rtpproxy. I'm interfacing with a company that uses Sonus
equipment to terminate to the PSTN. This company is telling me that SER is not performing to
RFC3261 because ACK messages are not including any "Route:" headers as stated in section 12.1.2.
Following is an email I recieved from their network engineers. Attached is also a partial
conversation between my SER proxy and their Sonus box. The actual problem is that Sonus
disconnects the call after a few seconds because of this ACK routing issue.
+++++++++START OF EMAIL FROM THE GUYS USING SONUS++++++++++++++
No, this is definitely not a Sonus issue.
The response sent from the Sonus to the SER contains the correct set of Record-Route (every hop
that the original INVITE has traversed). When the SER sends back the ACK, the SER if it acts as a
UAC, then must include this set of Record-Route as Route in the message per RFC3261 section
12.1.2.
I believe you will have problem with this if you interface the SER with any SIP proxy. I assume
that it works with Broadvox because you are connected directly to their gateway and no other proxy
is in between. If you were to connect directly with the Sonus, then it would work.
The problem should be fixed on your end. You just need to look into the code where it generates
the ACK and follow RFC3261 section 12.1.2 on how to build and send it.
+++++++++END OF EMAIL FROM THE GUYS USING SONUS++++++++++++++
Here is the actual problem from a real SER/Sonus dialog.
We have a "200 OK" and two ACKs - The first ACK is good and the second ACK is bad because it
should have a "Route:" header referring to the Sonus box.
NOTE: If I have STUN enabled on my SIP phone then SER works 100% fine. If STUN is not used on the
SIP phone then the second ACK is messed up as shown here. So the ACK from SER to Sonus is
incorrect. A working (corrected ACK) is at the very bottom of this message.
These are the bogus IP addresses shown in the dialog:
100.99.99.99.99 is my SER proxy
100.10.10.10 is the public side of my firewall
216.50.50.50 is the ip of the Sonus box
U 2004/11/18 14:13:08.419098 100.99.99.99:5060 -> 100.10.10.10:5060
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKa70081ccdd52daf0.
To: <sip:14075551212@sip.mycompany.com;user=phone>;tag=069c9797.
From: "Paul (1002)" <sip:9990010001@sip.mycompany.com;user=phone>;tag=92691bb29380c100.
Call-ID: e37c04be3e50ea72(a)192.168.0.83.
CSeq: 21752 INVITE.
Contact: sip:4075551212@216.50.50.50:5060.
Record-Route: <sip:216.50.50.50:5060;lr>.
Record-Route: <sip:100.99.99.99;ftag=92691bb29380c100;lr=on>.
Accept: multipart/mixed, application/sdp, application/isup, application/dtmf,
application/dtmf-relay.
Allow: OPTIONS, INVITE, CANCEL, ACK, BYE, PRACK, INFO.
Supported: timer.
Content-Disposition: session;handling=required.
Content-Type: application/sdp.
Session-Expires: 240;refresher=uas.
Content-Length: 244.
.
v=0.
o=Sonus_UAC 18748 26881 IN IP4 216.229.118.76.
s=SIP Media Capabilities.
c=IN IP4 100.99.99.99.
t=0 0.
m=audio 35552 RTP/AVP 18 101.
a=rtpmap:18 G729/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=sendrecv.
a=nortpproxy:yes.
#
U 2004/11/18 14:13:08.428394 100.10.10.10:5060 -> 100.99.99.99:5060
ACK sip:4075551212@216.50.50.50:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.168.0.83;branch=z9hG4bKf4bb608e498ec61d.
Route: <sip:100.99.99.99;ftag=92691bb29380c100;lr=on>.
Route: <sip:216.50.50.50:5060;lr>.
From: "Paul (1002)" <sip:9990010001@sip.mycompany.com;user=phone>;tag=92691bb29380c100.
To: <sip:14075551212@sip.mycompany.com;user=phone>;tag=069c9797.
Contact: <sip:9990010001@192.168.0.83;user=phone>.
Call-ID: e37c04be3e50ea72(a)192.168.0.83.
CSeq: 21752 ACK.
User-Agent: Grandstream BT100 1.0.5.16.
Max-Forwards: 70.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
.
#
U 2004/11/18 14:13:08.429879 100.99.99.99:5060 -> 216.50.50.50:5060
ACK sip:216.50.50.50:5060;lr SIP/2.0.
Via: SIP/2.0/UDP 100.99.99.99;branch=z9hG4bK2b35.552edb80cbf475b9be9ae3f9db23f960.0.
Via: SIP/2.0/UDP 192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKf4bb608e498ec61d.
From: "Paul (1002)" <sip:9990010001@sip.mycompany.com;user=phone>;tag=92691bb29380c100.
To: <sip:14075551212@sip.mycompany.com;user=phone>;tag=069c9797.
Contact: <sip:9990010001@100.10.10.10:5060;user=phone>.
Call-ID: e37c04be3e50ea72(a)192.168.0.83.
CSeq: 21752 ACK.
User-Agent: Grandstream BT100 1.0.5.16.
Max-Forwards: 16.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
.
+++++++++++++++The Second ACK Should Look Like This+++++++++++++++++++++++
U 2004/11/18 14:13:08.429879 100.99.99.99:5060 -> 216.50.50.50:5060
ACK sip:216.50.50.50:5060;lr SIP/2.0.
Via: SIP/2.0/UDP 100.99.99.99;branch=z9hG4bK2b35.552edb80cbf475b9be9ae3f9db23f960.0.
Via: SIP/2.0/UDP 192.168.0.83;rport=5060;received=100.10.10.10;branch=z9hG4bKf4bb608e498ec61d.
Route: <sip:216.50.50.50:5060;lr>.
From: "Paul (1002)" <sip:9990010001@sip.mycompany.com;user=phone>;tag=92691bb29380c100.
To: <sip:14075551212@sip.mycompany.com;user=phone>;tag=069c9797.
Contact: <sip:9990010001@100.10.10.10:5060;user=phone>.
Call-ID: e37c04be3e50ea72(a)192.168.0.83.
CSeq: 21752 ACK.
User-Agent: Grandstream BT100 1.0.5.16.
Max-Forwards: 16.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
Regards,
Paul
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
Hi all,
Since SER does not provide DNS SRV failover capability, how do you
perform failover for your PSTN gateways?
I currently think about some sort of load balancing with exec_dset()
which looks up a gateway in a mysql db and give it 10 tries to find a
gateway (SER is running on my.domain:5060)
route
{
if (!mf_process_maxfwd_header("10"))
{
sl_send_reply("483", "Too many hops");
break;
}
<snip>
exec_dset("/my/sipgw-balancing-script"); # returns a random GW
t_on_failure("1");
t_relay();
<snip>
}
failure_route[1]
{
if(t_check_status("503")
{
rewritehostport("my.domain:5060"); # peform loop
append_branch();
t_relay();
}
}
Is this good practice? Any other ideas/optimizations?
Cheers,
Andy
Dear sirs:
I�ve been wondering if there is a way to disconnect a session already
stablished with the SER, i mean, if i want to stablish a policy regarding
a limit of time per call (i.e. 3 minutes per session) or if i use a third
party gateway and i don�t have any control of it in a pre-paid dial-plan
scenario.
Thanks in advance for any information or comments regarding this
particular issue.
Andr�s Parra L.
Ipsofactum Ltd.
andresparra(a)ipsofactum.com
www.ipsofactum.com
---------------------------------
Do you Yahoo!?
Discover all that�s new in My Yahoo!
Hi All,
Any idea whether SER works fine with multiple IPs on a
single server. (We have got 2 NICs).
Appreciate your inputs/suggestions.
Thanks & regards,
Suvendu.
________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony
hi guys,
I am seeing this error in my log file: ERROR: t_should_relay: status
rewrite by UAS: stored: 408, received: 487
Did any of you experienced this before?
Here is my ser.cfg in case you need it:
thanks
I also replaced IP addresses for $gateway, $voicemail, and $sip_proxy
# ----------- 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"
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database
loadmodule "/usr/lib/ser/modules/mysql.so"
loadmodule "/usr/lib/ser/modules/textops.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/group.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
modparam("rr", "enable_full_lr", 1)
modparam("group", "db_url", "mysql://ser:heslo@localhost/ser")
# time to give up on ringing -- global timer, applies to
# all transactions
modparam("tm", "fr_inv_timer", 15)
# ------------------------- request routing logic -------------------
# main routing logic
route {
if (!mf_process_maxfwd_header("10")) {
log("LOG: Too many hops\n");
sl_send_reply("483", "Alas Too Many Hops");
break;
};
if (!(method=="REGISTER")) record_route();
if (loose_route()) {
t_relay();
break;
};
if (!uri==myself) {
t_relay();
break;
} else {
if (method == "REGISTER") {
#if (!save("location")) {
# sl_reply_error();
#};
# Uncomment this if you want to use digest
authentication
if (!www_authorize("sip_proxy", "subscriber")) {
www_challenge("sip_proxy", "0");
break;
};
save("location");
break;
};
};
# Destination PSTN or H323?
if( uri=~"^sip:9[0-9]*@sip_proxy" )
{
route(1);
break;
};
if( uri=~"^sip:\*74@sip_proxy" )
{
route(2);
break;
};
# does the user wish redirection on no availability? (i.e., is
he
# in the voicemail group?) -- determine it now and store it in
# flag 4, before we rewrite the flag using UsrLoc
#if (is_user_in("Request-URI", "voicemail")) {
# setflag(4);
#};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
# handle user which was not found
route(4);
break;
};
# if user is on-line and is in voicemail group, enable
redirection
if (method == "INVITE" ) {
t_on_failure("1");
};
t_relay();
}
# ------------ Send it to our PSTN ----------------------
route[1] {
# Route to PSTN Gateways(s)
if (uri=~"^sip:9[0-9]*@sip_proxy") { ## This assumes
that th
e caller is
log("Forwarding to PSTN\n"); ## registered
in our re
alm
strip(1);
#t_relay_to_udp( "gateway", "5060" );
rewritehostport("gateway:5060");
forward(uri:host, uri:port);
break;
};
}
route[2] {
if (uri=~"^sip:\*74@sip_proxy") { ## This assumes that
the c
aller is
log("Picking up a Call on PSTN\n"); ##
registered in
our realm
#t_relay_to_udp( "gateway", "5060" );
rewritehostport("gateway:5060");
forward(uri:host, uri:port);
break;
};
}
# ------------- handling of unavailable user ------------------
route[4] {
# non-Voip -- just send "off-line"
if (!(method == "INVITE" || method == "ACK" || method ==
"CANCEL")) {
sl_send_reply("404", "Not Found");
break;
};
# not voicemail subscriber
#if (!isflagset(4)) {
# sl_send_reply("404", "Not Found and no voicemail turned
on");
# break;
#};
# forward to voicemail now
rewritehostport("voicemail:5090");
t_relay_to_udp("voicemail", "5090");
#t_relay_to_tcp ("voicemail","5090");
}
# if forwarding downstream did not succeed, try voicemail running
# at voicemail:5090
failure_route[1] {
revert_uri();
rewritehostport("voicemail:5090");
append_branch();
t_relay_to_udp("voicemail", "5090");
#t_relay_to_tcp ("voicemail","5090");
}
I don't know if i should submit any trace routes and stuff like that.
The system works fine, just i am not sure where i am getting this from.
thank in advance for the help.
Srbo Cvetkovic | CityNet, Inc.
srbo(a)city-net.com | Pittsburgh, PA
voice: 412.481.5406 | fax: 412.431.1315
I am experiencing an issue with Cisco ATA186's behind NAT where when they place a call, they can not hear the called party until they speak. Since the voice cut through does eventually happen once you speak, I believe it may just be a small code issue with my ser.cfg file. This is important to me because the application I am implementing has customers using the ATA to call into an IVR platform. The problem is that they never hear the IVR until they say something. Any suggestions would be greatly appreciate. I am attaching my ser.cfg file which has been modified from an earlier version of SER. My problem may just be that I am using an antiquated config file. I am not trying to do anything crazy of special with this, so if you know of a simple working ser.cfg file that can handle registrations from behind NAT, that would be very helpful.
Any help would be greatly appreciated.
Thanks,
Brian
# simple quick-start config script
#
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no # (cmd line: -E)
listen=6.9.1.75
listen=127.0.0.1
port=5060
children=16
check_via=yes # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
fifo="/tmp/ser_fifo"
# syn_branch - Shall the server use stateful synonym branches? It is
# faster but not reboot-safe. Default is yes.
syn_branch=yes
memlog=3
# hostname matching an alias will satisfy the condition uri==myself".
alias=ari.com
alias=6.9.1.75
alias=6.9.1.16
# sip_warning - Should replies include extensive warnings? By default
# yes, it is good for trouble-shooting.
sip_warning=yes
# server_signature - Should locally-generated messages include server's
# signature? By default yes, it is good for trouble-shooting.
server_signature=yes
# reply_to_via - A hint to reply modules whether they should send reply
# to IP advertised in Via. Turned off by default, which means that
# replies are sent to IP address from which requests came.
reply_to_via=no
# mhomed -- enable calculation of outbound interface; useful on
# multihomed servers.
mhomed=0
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database
loadmodule "/usr/local/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/tm.so"
loadmodule "/usr/local/lib/ser/modules/rr.so"
loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
loadmodule "/usr/local/lib/ser/modules/usrloc.so"
loadmodule "/usr/local/lib/ser/modules/registrar.so"
loadmodule "/usr/local/lib/ser/modules/acc.so"
loadmodule "/usr/local/lib/ser/modules/textops.so"
loadmodule "/usr/local/lib/ser/modules/uri.so"
loadmodule "/usr/local/lib/ser/modules/group.so"
loadmodule "/usr/local/lib/ser/modules/msilo.so"
loadmodule "/usr/local/lib/ser/modules/enum.so"
loadmodule "/usr/local/lib/ser/modules/nathelper.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
loadmodule "/usr/local/lib/ser/modules/auth.so"
loadmodule "/usr/local/lib/ser/modules/auth_db.so"
# ----------------- setting module-specific parameters ---------------
modparam("usrloc|group|msilo|uri", "db_url","mysql://ser:heslo@localhost/ser")
# -- 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
modparam("rr", "enable_full_lr", 1)
# -- tm params --
modparam("tm", "fr_timer", 20 )
modparam("tm", "fr_inv_timer", 90 )
modparam("tm", "wt_timer", 20 )
# -- msilo params
modparam("msilo", "registrar", "sip:registrar@ari.com")
# -- enum params --
#
modparam("enum", "domain_suffix", "e164.arpa.")
# -- nathelper params --
#
modparam("registrar", "nat_flag", 1)
modparam("nathelper", "natping_interval", 30) # Ping interval 30 s
#modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT
# -- acc params --
# that is the flag for which we will account -- don't forget to
#modparam("acc", "db_flag", 1 )
#modparam("acc", "db_missed_flag", 3 )
# ------------------------- request routing logic -------------------
# main routing logic
route {
/* ********* ROUTINE CHECKS ********************************** */
# filter too old messages
if (!mf_process_maxfwd_header("10")) {
log(1, "LOG: Too many hops\n");
sl_send_reply("483","Alas Too Many Hops");
break;
};
if ( msg:len >= max_len ) {
sl_send_reply("513", "Wow -- Message too large");
break;
};
if (search("^(Contact|m): .*(a)(192\.168\.|10\.|172\.16)")) {
log(1, "src address different than via header->NAT detected\n");
log(1, "force_rport and fix_nated_contact and setflag(5)\n");
#try NAT traversal, works only if the client is symmetrical
force_rport();
fix_nated_contact();
append_hf("P-hint: fixed NAT contact for request\r\n");
# flag 5 indicates that incoming request is from NATed client
setflag(5);
};
/* ********* RR ********************************** */
# to be safe, record route everything; UAs may use different
# transport protocols and need to have SER in path
record_route();
setflag(1);
# if route forces us to forward to some explicit destination,
# do so; check however first that a cheater didn't preload
# a gateway destination to bypass PSTN ACLs
if (loose_route()) {
log(1, "Loose Route\n");
if ((uri=~"sip:[+0-9]+@6\.9\.1\.16")) {
# it is gateway -- proceed to ACLs
route(3);
break;
};
# route HF determined next hop; forward there
append_hf("P-hint: rr-enforced\r\n");
t_relay();
break;
};
/* ********* check for requests targeted out of our domain... *******
*/
# sign of our domain: there is '@' (username) or : (nothing) in
# front of our domain name ; ('.' is not there -- we handle all
# xxx.iptel.org as outbound hosts);if none of these cases matches,
# proceed with processing of outbound requests in route[2]
if (!(uri==myself)) {
log(1, "Not myself\n");
route(2);
break;
};
/* ************ requests for our domain ********** */
/* now, the request is for sure for our domain */
# registers always MUST be authenticated to
# avoid stealing incoming calls
if (method=="REGISTER") {
# Make sure that user's dont register infinite loops
if (search("^(Contact|m): .*(a)(ari\.com|6\.9\.1\.75)")) {
log(1, "LOG: alert: someone trying to set aor==contact\n
");
sl_send_reply("476", "No Server Address in Contacts Allo
wed" );
break;
};
if (search("^(Contact|m): .*6\.9\.1\.16")) {
log(1, "LOG: alert: protected contacts\n");
sl_send_reply("476", "No Server Address in Contacts Allo
wed" );
break;
};
if (!www_authorize("ari.com" /* realm */,"subscriber" /* table n
ame */ )) {
# challenge if none or invalid credentials
www_challenge( "ari.com" /* realm */,"0" /* no qop -- s
ome phones can't deal with it */);
break;
};
# prohibit attempts to grab someone else's To address
# using valid credentials;
if (!check_to()) {
log(1, "LOG: To Cheating attempt\n");
sl_send_reply("403", "That is ugly -- use To=id in REGIS
TERs");
break;
};
if (isflagset(5)) {
#register from nated client, save nat_flag=6
#in location table
setflag(6);
};
# it is an authenticated request, update Contact database now
if (!(save("location"))) {
sl_reply_error();
};
m_dump();
break;
};
# NAT Traversal Code
if ((isflagset(5)) || (isflagset(6))) {
log(1, "at least one of the participants is NATed->record_route\
n");
record_route();
log(1, " -->setting up reply processing ->onreply_route[1]")
;
t_on_reply("1");
if (method=="INVITE") {
log(1, " INVITE request-->force_rtp_proxy, set NATED
-INVITE flag(7)");
force_rtp_proxy();
append_hf("P-hint: request forced to rtp proxy\r\n");
setflag(7);
};
};
# native SIP destinations are handled using our USRLOC DB
if (lookup("location")) {
log(1, "Native SIP destination detected\n");
append_hf("P-hint: USRLOC\r\n");
if (!t_relay()) {
sl_reply_error();
break;
};
};
# now check if it's about PSTN destinations through our gateway;
if (uri=~"sip:\+?[0-9][0-9]*@.*") {
log(1, "PSTN destination to be used\n");
route(3);
break;
};
# # check whether some inventive user has uploaded gateway
# # contacts to UsrLoc to bypass our authorization logic
# if (uri=~"sip:[+0-9]+@6\.9\.1\.16") {
# # it is gateway -- proceed to ACLs
# route(3);
# break;
# };
#
# /* ... and also report on missed calls ... */
# setflag(3);
#
# # we now know we may, we know where, let it go out now!
# append_hf("P-hint: USRLOC\r\n");
# if (!t_relay()) {
# sl_reply_error();
# break;
# };
} # route
#----------------- PSTN ----------------------------------------------
# logic for calls to the PSTN
route[3] {
# turn accounting on
setflag(1);
/* require all who call PSTN to be members of the "int" group;
apply ACLs only to INVITEs -- we don't need to protect other requests
, as they
don't imply charges; also it could cause troubles when a call comes i
n via PSTN
and goes to a party that can't authenticate (voicemail, other domain)
-- BYEs would
fail then; exempt Cisco gateway from authentication by IP address --
it does not
support digest
*/
if (src_ip==6.9.1.16) {
log(1, "From ARI Gateway");
}
else {
if ((method=="INVITE") && (!(src_ip==6.2.15.1))) {
log(1, "LOG: need to auth PSTN invite");
if (!proxy_authorize( "ari.com" /* realm */,"subscribe
r" /* table name */)) {
proxy_challenge( "ari.com" /* realm */, "0" /* n
o qop */ );
break;
};
# let's check from=id ... avoids accounting confusion
if (method=="INVITE" & !check_from()) {
log(1, "LOG: From Cheating attempt\n");
sl_send_reply("403", "That is ugly -- use From=i
d next time (gw)");
break;
};
if(!is_user_in("credentials", "int")) {
sl_send_reply("403", "NO PSTN Privileges...");
break;
};
consume_credentials();
}; # INVITE to authorized PSTN
}
# if you have passed through all the checks, let your call go to GW!
log(1, "Rewriting Host and port");
rewritehostport("6.9.1.16:5060");
# snom conditioner
if (method=="INVITE" && search("User-Agent: snom")) {
replace("100rel, ", "");
};
t_relay_to_udp ("6.9.1.16","5060");
t_relay_to_tcp ("6.9.1.16","5060");
break;
}
# all incoming replies for t_onrepli-ed transactions enter here
onreply_route[1] {
log(1, "-------------------------------------------\n");
log(1, "onreply_route[1] entered\n");
if (isflagset(6)) {
log(1, "transaction was sent to a NATED client -> fix nated cont
act\n");
fix_nated_contact();
append_hf("P-hint: fixed NAT contact for response\r\n");
}
if ( (status=~"100") ) {
log(1, "status 100 received\n");
};
if ( (status=~"180") ) {
log(1, "status 180 received\n");
};
if ( (status=~"202") ) {
log(1, "status 202 received\n");
};
if ( (status=~"200" || status=~"183") ) {
log(1, "status 2xx or 183");
if ( isflagset(7) ) {
log(1, "marked(7) as NATED-INVITE -> force_rtp_proxy \n"
);
force_rtp_proxy();
append_hf("P-hint: response forced to rtp proxy\r\n");
};
};
}
#------------------- OUTBOUND ----------------------------------------
# routing logic for outbound requests targeted out of our domain
# (keep in mind messages to our users can end up here too: for example,
# an INVITE may be UsrLoc-ed, then the other party uses outbound
# proxy with r-uri=the usr_loced addredd (typically IP))
route[2] {
append_hf("P-hint: OUTBOUND\r\n");
t_relay();
}
#------- ALIASED OUTBOUND --------------------------------------------
# routing logic for inbound requests aliased outbound; unlike
# with real outbound requests we do not force authentication
# as these calls are server by our server and we do not want
# to disqualify unathenticated request originatiors from other
# domains
route[5] {
append_hf("P-hint: ALIASED-OUTBOUND\r\n");
t_relay();
}
Hello everyone,
I've succesfully compiled and installed SER 0.8.14 on a redhat 7.3.
Got an Xlite and a Grandstream Budgetone-100 registered and they both
could communicate between them.
Now, I want to use RADIUS with SER. I got SER compiled with RADIUS
support, and also compiled the radiusclient 0.4.3, and it seems
everything went fine.
I added both dictionary.ser and dictionary.sip to my dictionary, and I
believe there is something wrong here.
I followed the instrucitions at the RADIUS-HOWTO ...
1) touch digest
2) echo User-Name = "110(a)192.168.1.253", Digest-Response =
"631d6d73147add2f9e437f59bbc3aeb7", Digest-Realm = "testrealm",
Digest-Nonce = "1234abcd" , Digest-Method = "INVITE", Digest-URI =
"sip:5555551212@example.com", Digest-Algorithm = "MD5", Digest-User-Name
= "110(a)192.168.1.253" > digest
3) radclient -f digest localhost auth radiussecret
... And this is the RADIUS OUTPUT ...
radrecv: Access Request from host c0a801fd code=1, id=86, length=174
User-Name = "1992005(a)192.168.1.253"
Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7"
Digest-Attributes = "\001\013testrealm"
Digest-Attributes = "\002\0121234abcd"
Digest-Attributes = "\003\010INVITE"
Digest-Attributes = "\004\034sip:5555551212@example.com"
Digest-Attributes = "\006\005MD5"
Digest-Attributes = "\012\0271992005(a)192.168.1.253"
Username is now 1992005(a)192.168.1.253
Calling station Id is now (null)
Client 1992005(a)192.168.1.253 is PREPAID
credit_amount (19.00)
Sending Access Ack of id 86 to c0a801fd (nas linux)
Credit-Amount =
"V9:T102:L26:683332332d6372656469742d616d6f756e743d31392e3030"
... And this is the radclient OUTPUT ...
Received response ID 86, code 2, length = 52
Vendor-9-Attr-102 =
0x683332332d6372656469742d616d6f756e743d31392e3030
Questions:
1) Although I sent to radius diferent ATTRIBUTES, RADIUS recognized all
of them (except for one, Digest-Response) as Digest-Attributes. Why is
that?
2) All of the values sent to RADIUS, for each attribute, are different
from the ones originally sent. For example ...
sent: Digest-Method = "INVITE"
received: Digest-Attributes = "\003\010INVITE"
So you see the "\003\010" chars in front of the string "INVITE"
... Why is that?
Well, I hope you can clarify some (better if all of them ;-) ) of my
doubts.
Thanx in advance
Regards,
Lucas
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.786 / Virus Database: 532 - Release Date: 29/10/2004
Hi there
I'm trying the acc module with RADIUS support (SER 0.8.14)
and found a small bug. my apologise if it is already known
or fixed on current CVS
this module seems to use modules/acc/etc/sip_dictionary
which has one attribute that is not present on
ser/dictionary.ser
VALUE Acct-Status-Type Failed 15
modules/acc/etc/sip_dictionary seems to unify
dictionary.ser and radiusclient/dictionary.sip (*)
without the Failed value present on radiusclient/dictionary,
SER couldn't initialize with the following error
# ser -ddd -E -P /var/run/ser.pid
[...]
0(17650) ERROR: acc: can't get code for the Failed attribute value
0(17650) init_mod(): Error while initializing module acc
ERROR: error while initializing modules
[...]
to trigger the bug, edit modules/acc/Makefile and
uncomment the following lines
# uncomment the next two lines if you wish to enable RADIUS accounting
DEFS+=-DRAD_ACC -I$(LOCALBASE)/include
LIBS=-L$(LOCALBASE)/lib -lradiusclient
recompile SER and run it with the following in ser.cfg
--- start ---
loadmodule "/usr/lib/ser/modules/tm.so"
loadmodule "/usr/lib/ser/modules/auth.so"
loadmodule "/usr/lib/ser/modules/auth_radius.so"
loadmodule "/usr/lib/ser/modules/acc.so"
modparam("acc", "radius_config", "/etc/radiusclient/radiusclient.conf")
modparam("acc", "radius_flag", 1)
modparam("acc", "radius_missed_flag", 1)
--- end ---
Cheers
!3runo
(*) side note: the RADIUS instructions at iptel.org tells to
cat dictionary.ser >> radiusclient/dictionary
to be able to use RADIUS with SER. I found that
cat radiusclient/dictionary.sip >> radiusclient/dictionary
is also necessary (at least with libradiusclient 0.4.5).
this doesn't seem to be documented anywhere I could find