That 100% radius... I've been thru it.
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Jan Janak
Sent: Thursday, March 09, 2006 2:23 PM
To: sip
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Radius Accounting encoding issues.
Are you sure this encoding is done by SER ? I have never seen this,
perhaps
it is server-side problem ? Can you try to see what is in RADIUS packets
sent by SER ?
Jan.
sip wrote:
> I've set up radius accounting in SER 0.9.6 and I'm sure I'm missing
something
> obvious, but when it encodes the URIs for things like CalledStationID
or
> UserName, it's encoding the non-standard characters as hex. For
instance, *
> becomes =2A , so my URI ends up looking like
sip:=2A850XXXXXXX@domain.com
> where it should be sip:*850XXXXXXX@domain.com
>
> Is there something I'm missing in the table setup for the radacct
table or a
> modparam somewhere that I missed in the README?
>
> N.
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
I've set up radius accounting in SER 0.9.6 and I'm sure I'm missing something
obvious, but when it encodes the URIs for things like CalledStationID or
UserName, it's encoding the non-standard characters as hex. For instance, *
becomes =2A , so my URI ends up looking like sip:=2A850XXXXXXX@domain.com
where it should be sip:*850XXXXXXX@domain.com
Is there something I'm missing in the table setup for the radacct table or a
modparam somewhere that I missed in the README?
N.
Hi Everyone,
I am really stuck here. I really need help!
I receive the following ACK request in SER from a Linksys/PAP user agent
that SER should forward to the destination User Agent: 1234560133.
------------------------------------------------------------------------
---------------------------------------------------
ACK sip:10.1.10.65;ftag=cff8d63370ff3ed5o0 SIP/2.0
Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5b186b5;rport
From: 1234560133
<sip:2224440133@host.domain.name>;tag=cff8d63370ff3ed5o0
To: <sip:1234560131@host.domain.name>;tag=26001139010904
Call-ID: 9b54d80b-81b366dd(a)172.16.15.51
CSeq: 101 ACK
Max-Forwards: 70
Route: <sip:1234569999@10.1.10.65:5060>
Contact: 1234560133 <sip:1234560133@172.16.15.51:5060>
User-Agent: Linksys/PAP2-3.1.5(LS)
Content-Length: 0
------------------------------------------------------------------------
---------------------------------------------------
But the loose_route function transforms it to the following and as a
result it is routed
back to SER and therefore falls into an infinite loop as shown by the
couple of ACKs
that get looped through SER:
------------------------------------------------------------------------
---------------------------------------------------
ACK sip:10.1.10.65;ftag=cff8d63370ff3ed5o0 SIP/2.0
Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on>
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5b186b5;rport=5060
From: 2224440133 <sip:2224440133@cl1.glphone.com>;tag=cff8d63370ff3ed5o0
To: <sip:2224440131@cl1.glphone.com>;tag=26001139010904
Call-ID: 9b54d80b-81b366dd(a)172.16.15.51
CSeq: 101 ACK
Max-Forwards: 16
Contact: 2224440133 <sip:2224440133@172.16.15.51:5060>
User-Agent: Linksys/PAP2-3.1.5(LS)
Content-Length: 0
------------------------------------------------------------------------
---------------------------------------------------
ACK sip:10.1.10.65;ftag=cff8d63370ff3ed5o0 SIP/2.0
Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on>
Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on>
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5b186b5;rport=5060
From: 2224440133 <sip:2224440133@cl1.glphone.com>;tag=cff8d63370ff3ed5o0
To: <sip:2224440131@cl1.glphone.com>;tag=26001139010904
Call-ID: 9b54d80b-81b366dd(a)172.16.15.51
CSeq: 101 ACK
Max-Forwards: 15
Contact: 2224440133 <sip:2224440133@172.16.15.51:5060>
User-Agent: Linksys/PAP2-3.1.5(LS)
Content-Length: 0
------------------------------------------------------------------------
---------------------------------------------------
ACK sip:10.1.10.65;ftag=cff8d63370ff3ed5o0 SIP/2.0
Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on>
Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on>
Record-Route: <sip:10.1.10.65;ftag=cff8d63370ff3ed5o0;lr=on>
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 10.1.10.65;branch=0
Via: SIP/2.0/UDP 172.16.15.51:5060;branch=z9hG4bK-5b186b5;rport=5060
From: 2224440133 <sip:2224440133@cl1.glphone.com>;tag=cff8d63370ff3ed5o0
To: <sip:2224440131@cl1.glphone.com>;tag=26001139010904
Call-ID: 9b54d80b-81b366dd(a)172.16.15.51
CSeq: 101 ACK
Max-Forwards: 14
Contact: 2224440133 <sip:2224440133@172.16.15.51:5060>
User-Agent: Linksys/PAP2-3.1.5(LS)
Content-Length: 0
I put some debug messages in rr and this is what I get:
DEBUG: -ramin- modules/rr/loose_route: jumping to after_strict
after_strict: No next URI found
It seems as if the after_strict is invoked and it can not find the next
URI!
Can you please tell me why SER can not route this properly!
Thank you so much for your kind help
ramin
Hehe.. still u have to go to digium and/or search for asterisk
documentation or/and go to asterisk mailing list to get answer to ur
question,
Ser is signaling only PROXY/REGISTRAR server, all conference/codec
issues will be done on asterisk, ser can only forward the call to
asterisk.
I do not think here is educational license... but u can buy real one for
10$ only, or there is some information about g729 that provided by Intel
as demo/test of their processors that can be hacked to work with
asterisk, looks for that keywords on Google or ask on asterisk forums,
SER has nothing with it.
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Kapil Dhawan
Sent: Thursday, March 09, 2006 12:26 PM
To: rjgonzale(a)gmail.com
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] g729
Hi Rodrigo
Thx for the reply. Well i am aware of this fact so i mentioned that i
need
it for Conferencing.
>From: Rodrigo Gonzalez <rjgonzale(a)gmail.com>
>To: Kapil Dhawan <sersavvy(a)hotmail.com>
>CC: serusers(a)lists.iptel.org
>Subject: Re: [Serusers] g729
>Date: Thu, 09 Mar 2006 14:14:40 -0300
>
>http://www.digium.com/
>
>SER does not know about codecs, this is for Asterisk
>
>Kapil Dhawan wrote:
>
>>Hi Guys
>>
>>I want to try g729 with SER + Asterisk with conferencing. Where can i
get
>>an educational license from.
>>
>>_________________________________________________________________
>>All that you wanted to know about Ms Beautiful Lips
>>http://server1.msn.co.in/Profile/katrina.asp
>>
>>_______________________________________________
>>Serusers mailing list
>>serusers(a)lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serusers
>>
_________________________________________________________________
STILL SINGLE? Get married through MSN Matrimony. Join now for FREE!
http://www.shaadi.com/msn/matrimonials.php
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
1. I never used forward, see my example, I do not know if it
actually relay call or not
2. if you do not have NAT between client and server you do not need
force_rport, and try to avoid any nat_uac_test, etc if you are actually
working on private ips without nat
3. you MUST enable proxy also for reply
route[x] {
.....
force_rtp_proxy();
t_on_reply("1");
rewritehostport("x.x.x.x:5060");
if (!t_relay()) {
sl_reply_error();
};
}
onreply_route[1] {
if (!(status=~"183" || status=~"200"))
break;
force_rtp_proxy("");
}
________________________________
From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On
Behalf Of Script Head
Sent: Wednesday, March 08, 2006 6:29 PM
To: users(a)openser.org
Subject: [Users] forcing rtpproxy on a call
Hello everyone,
I am trying to debug why my rtpproxy isn't working. I have the following
setup, on my LAN.
softphone (192.168.1.100) -> openser/rtpproxy ( 192.168.1.10
<http://192.168.1.10> ) -> asterisk (192.168.1.12)
The rtpproxy is running and I see commands flying thru it.
the following route works
if(method=="INVITE") {
if(uri=~"^sip:[0-9]{6}1[0-9]*{10}@") {
forward(192.168.1.12,5060);
};
}
when I replace it with this route
if(method=="INVITE") {
if(uri=~"^sip:[0-9]{6}1[0-9]*{10}@") {
forward(192.168.1.12,5060);
};
force_rport();
force_rtp_proxy();
}
I get dead air while asterisk logs show that my test message is playing.
How should I proceed to debug this?
ScriptHead
Hi Guys
I want to try g729 with SER + Asterisk with conferencing. Where can i get an
educational license from.
_________________________________________________________________
All that you wanted to know about Ms Beautiful Lips
http://server1.msn.co.in/Profile/katrina.asp
Ok, I've roughly used the examples that are included in the
modules/mediaproxy/ser.cfg file to use mediaproxy. The initial call is set
up very nicely. However reinvites don't seem to be processsed right.
When I place the call on hold, I can see that mediaproxy sees the call on
hold (with the sessions tool). However, when I return to the call from
hold, the reinvite just sets the devices up to each other direct without
the mediaproxy. Mediaproxy will for about 1 second show the call come back
to "ACTIVE" and then to "IDLE". I'm sure the rtp isn't being proxied
because 1. I can kill the proxy, and still pass audio 2. the sessions tool
doesn't show packets being transmitted 3. the SDP isn't pointing to the
mediaproxy.
I can't figure out what I'm doing wrong. However, mediaproxy sees to be
very sensitive on how it's called. Per the example, use_media_proxy() will
be called TWICE for a new call. This works for the initial call.. However,
I removed the initial call to use_media_proxy and only left the one in the
on_reply route. Doing this totally broke it and routed the calls without
media proxy.
**** Oh, something that is worth mentioning. In the example file, there is
an end_media_session() at the begining of the on_reply block. If this is
in there, no calls will goto the mediaproxy ever. I get an error message:
3(3114) error: use_media_proxy(): empty response from mediaproxy
So I removed it to get where I am now.
Here are the relevant parts of my config:
# $Id: openser.cfg,v 1.6 2006/02/15 18:23:46 bogdan_iancu Exp $
#
# simple quick-start config script
#
# ----------- global configuration parameters ------------------------
debug=2 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=yes # (cmd line: -E)
/* Uncomment these lines to enter debugging mode
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/openser_fifo"
fifo_db_url="mysql://ser:xxxxx@172.16.10.103:3306/ser"
#
# uncomment the following lines for TLS support
#disable_tls = 0
#listen = tls:your_IP:5061
listen=192.168.1.10:5060
#tls_verify = 1
#tls_require_certificate = 0
#tls_method = TLSv1
#tls_certificate = "/usr/local/etc/openser/tls/user/user-cert.pem"
#tls_private_key = "/usr/local/etc/openser/tls/user/user-privkey.pem"
#tls_ca_list = "/usr/local/etc/openser/tls/user/user-calist.pem"
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database
loadmodule "/usr/local/lib/openser/modules/mysql.so"
loadmodule "/usr/local/lib/openser/modules/sl.so"
loadmodule "/usr/local/lib/openser/modules/tm.so"
loadmodule "/usr/local/lib/openser/modules/rr.so"
loadmodule "/usr/local/lib/openser/modules/maxfwd.so"
loadmodule "/usr/local/lib/openser/modules/usrloc.so"
loadmodule "/usr/local/lib/openser/modules/textops.so"
loadmodule "/usr/local/lib/openser/modules/uri.so"
loadmodule "/usr/local/lib/openser/modules/uri_db.so"
loadmodule "/usr/local/lib/openser/modules/registrar.so"
loadmodule "/usr/local/lib/openser/modules/mediaproxy.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
loadmodule "/usr/local/lib/openser/modules/auth.so"
loadmodule "/usr/local/lib/openser/modules/auth_db.so"
loadmodule "/usr/local/lib/openser/modules/domain.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
modparam("auth_db","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser")
modparam("uri_db","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser")
modparam("domain","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser")
modparam("dip","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser")
modparam("usrloc","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser")
modparam("domain","domain_table","domain")
modparam("domain","domain_col","domain")
modparam("domain","db_mode",0)
modparam("auth_db","use_domain",1)
#
modparam("usrloc", "db_mode", 2)
# 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)
modparam("auth_db", "load_credentials", "rpid,vm_timer")
modparam("tm", "fr_inv_timer_avp", "vm_timer")
#
# 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("mediaproxy", "natping_interval", 60)
modparam("registrar" , "nat_flag", 2)
# ------------------------- 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");
return;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
return;
};
# 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
### Fix natted requests
if (client_nat_test("3")) {
log(1,"***** PERFORMING NAT FIXUP\n");
setflag(2);
force_rport();
fix_contact();
};
record_route();
if (client_nat_test("3") && !search("^Record-Route:")) {
# Mark call as being natted
force_rport();
fix_contact();
};
#### Process registrations
if (method=="REGISTER") {
log(1,"***** REGISTERING\n");
if (is_from_local()) {
log(1,"**** IS FROM LOCAL\n");
# Mark as NAT'ed
if (client_nat_test("3")) {
log(1,"***** PERFORMING NAT FIXUP\n");
setflag(2);
force_rport();
fix_contact();
};
if (!www_authorize("", "subscriber")) {
log(1,"**** ASKING FOR CREDS\n");
www_challenge("", "0");
return;
} else if (!check_to()) {
sl_send_reply("403", "Username!=To not allowed");
return;
};
log(1,"*** ATTEMPTING TO SAVE CONTACT\n");
if (!save("location")) {
sl_reply_error();
};
} else {
sl_send_reply("403", "This domain is not served here");
};
return;
};
### All invites must be authenticated.. do this first
if (method=="INVITE") {
if(!www_authorize("","subscriber")) {
log(1,"**** ASKING FOR CREDS\n");
www_challenge("","0");
return;
} else if (!check_from()) {
sl_send_reply("403", "Username must equal the from address");
return;
};
log(1,"**** APPENDING RPID\n");
append_rpid_hf("<sip:", "@192.168.1.10>;privacy=off");
}
# make sure a leg is local somewhere
if (method=="INVITE") {
if (!(is_from_local() || is_uri_host_local())) {
sl_send_reply("403", "Relaying is forbidden");
return;
}
t_on_failure("1");
} else if (method == "BYE" || method == "CANCEL") {
log(1,"Ending session sec-1\n");
end_media_session();
};
# resolve aliases
if (!lookup("aliases")) {
log(1,"*** Call is not in aliases table\n");
}
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
log(2,"**** PERFORMING LOOSE ROUTE\n");
if (method=="INVITE" || method=="ACK"){
use_media_proxy();
};
append_hf("P-hint: rr-enforced\r\n");
log(1," *** USE MEDIA PROXY\n");
t_relay();
return;
};
if (method == "INVITE") {
t_on_reply("1");
};
if (is_uri_host_local()) {
if (!lookup("location")) {
log(1," **** location lookup failed\n");
# lookup failed.. probably a pstn call
use_media_proxy();
rewritehostport("voip_gw");
if (!t_relay()) {
sl_reply_error();
return;
}
return;
}
}
if (method=="INVITE" || method =="ACK") {
log(1," *** USE MEDIA PROXY\n");
use_media_proxy();
}
if (method=="OPTIONS") {
sl_send_reply("404", "Pong - Go away");
return;
}
if (!t_relay()) {
if (method=="INVITE" || method=="ACK") {
end_media_session();
log (1," Ending session sec-2\n");
};
sl_reply_error();
return;
}
}
failure_route[1] {
end_media_session();
log(1,"Ending session sec-3\n");
}
onreply_route[1] {
end_media_session();
log(1,"******* In onreply route block\n");
if (status=~"(183)|(2[09][09])") {
if (client_nat_test("1")) {
fix_contact();
};
use_media_proxy();
}
}
Ok, I've roughly used the examples that are included in the
modules/mediaproxy/ser.cfg file to use mediaproxy. The initial call is set
up very nicely. However reinvites don't seem to be processsed right.
When I place the call on hold, I can see that mediaproxy sees the call on
hold (with the sessions tool). However, when I return to the call from
hold, the reinvite just sets the devices up to each other direct without
the mediaproxy. Mediaproxy will for about 1 second show the call come back
to "ACTIVE" and then to "IDLE". I'm sure the rtp isn't being proxied
because 1. I can kill the proxy, and still pass audio 2. the sessions tool
doesn't show packets being transmitted 3. the SDP isn't pointing to the
mediaproxy.
I can't figure out what I'm doing wrong. However, mediaproxy sees to be
very sensitive on how it's called. Per the example, use_media_proxy() will
be called TWICE for a new call. This works for the initial call.. However,
I removed the initial call to use_media_proxy and only left the one in the
on_reply route. Doing this totally broke it and routed the calls without
media proxy.
**** Oh, something that is worth mentioning. In the example file, there is
an end_media_session() at the begining of the on_reply block. If this is
in there, no calls will goto the mediaproxy ever. I get an error message:
3(3114) error: use_media_proxy(): empty response from mediaproxy
So I removed it to get where I am now.
Here are the relevant parts of my config:
# $Id: openser.cfg,v 1.6 2006/02/15 18:23:46 bogdan_iancu Exp $
#
# simple quick-start config script
#
# ----------- global configuration parameters ------------------------
debug=2 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=yes # (cmd line: -E)
/* Uncomment these lines to enter debugging mode
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/openser_fifo"
fifo_db_url="mysql://ser:xxxxx@172.16.10.103:3306/ser"
#
# uncomment the following lines for TLS support
#disable_tls = 0
#listen = tls:your_IP:5061
listen=192.168.1.10:5060
#tls_verify = 1
#tls_require_certificate = 0
#tls_method = TLSv1
#tls_certificate = "/usr/local/etc/openser/tls/user/user-cert.pem"
#tls_private_key = "/usr/local/etc/openser/tls/user/user-privkey.pem"
#tls_ca_list = "/usr/local/etc/openser/tls/user/user-calist.pem"
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database
loadmodule "/usr/local/lib/openser/modules/mysql.so"
loadmodule "/usr/local/lib/openser/modules/sl.so"
loadmodule "/usr/local/lib/openser/modules/tm.so"
loadmodule "/usr/local/lib/openser/modules/rr.so"
loadmodule "/usr/local/lib/openser/modules/maxfwd.so"
loadmodule "/usr/local/lib/openser/modules/usrloc.so"
loadmodule "/usr/local/lib/openser/modules/textops.so"
loadmodule "/usr/local/lib/openser/modules/uri.so"
loadmodule "/usr/local/lib/openser/modules/uri_db.so"
loadmodule "/usr/local/lib/openser/modules/registrar.so"
loadmodule "/usr/local/lib/openser/modules/mediaproxy.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
loadmodule "/usr/local/lib/openser/modules/auth.so"
loadmodule "/usr/local/lib/openser/modules/auth_db.so"
loadmodule "/usr/local/lib/openser/modules/domain.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
modparam("auth_db","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser")
modparam("uri_db","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser")
modparam("domain","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser")
modparam("dip","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser")
modparam("usrloc","db_url","mysql://ser:xxxxx@172.16.10.103:3306/ser")
modparam("domain","domain_table","domain")
modparam("domain","domain_col","domain")
modparam("domain","db_mode",0)
modparam("auth_db","use_domain",1)
#
modparam("usrloc", "db_mode", 2)
# 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)
modparam("auth_db", "load_credentials", "rpid,vm_timer")
modparam("tm", "fr_inv_timer_avp", "vm_timer")
#
# 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("mediaproxy", "natping_interval", 60)
modparam("registrar" , "nat_flag", 2)
# ------------------------- 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");
return;
};
if (msg:len >= 2048 ) {
sl_send_reply("513", "Message too big");
return;
};
# 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
### Fix natted requests
if (client_nat_test("3")) {
log(1,"***** PERFORMING NAT FIXUP\n");
setflag(2);
force_rport();
fix_contact();
};
record_route();
if (client_nat_test("3") && !search("^Record-Route:")) {
# Mark call as being natted
force_rport();
fix_contact();
};
#### Process registrations
if (method=="REGISTER") {
log(1,"***** REGISTERING\n");
if (is_from_local()) {
log(1,"**** IS FROM LOCAL\n");
# Mark as NAT'ed
if (client_nat_test("3")) {
log(1,"***** PERFORMING NAT FIXUP\n");
setflag(2);
force_rport();
fix_contact();
};
if (!www_authorize("", "subscriber")) {
log(1,"**** ASKING FOR CREDS\n");
www_challenge("", "0");
return;
} else if (!check_to()) {
sl_send_reply("403", "Username!=To not allowed");
return;
};
log(1,"*** ATTEMPTING TO SAVE CONTACT\n");
if (!save("location")) {
sl_reply_error();
};
} else {
sl_send_reply("403", "This domain is not served here");
};
return;
};
### All invites must be authenticated.. do this first
if (method=="INVITE") {
if(!www_authorize("","subscriber")) {
log(1,"**** ASKING FOR CREDS\n");
www_challenge("","0");
return;
} else if (!check_from()) {
sl_send_reply("403", "Username must equal the from address");
return;
};
log(1,"**** APPENDING RPID\n");
append_rpid_hf("<sip:", "@192.168.1.10>;privacy=off");
}
# make sure a leg is local somewhere
if (method=="INVITE") {
if (!(is_from_local() || is_uri_host_local())) {
sl_send_reply("403", "Relaying is forbidden");
return;
}
t_on_failure("1");
} else if (method == "BYE" || method == "CANCEL") {
log(1,"Ending session sec-1\n");
end_media_session();
};
# resolve aliases
if (!lookup("aliases")) {
log(1,"*** Call is not in aliases table\n");
}
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
log(2,"**** PERFORMING LOOSE ROUTE\n");
if (method=="INVITE" || method=="ACK"){
use_media_proxy();
};
append_hf("P-hint: rr-enforced\r\n");
log(1," *** USE MEDIA PROXY\n");
t_relay();
return;
};
if (method == "INVITE") {
t_on_reply("1");
};
if (is_uri_host_local()) {
if (!lookup("location")) {
log(1," **** location lookup failed\n");
# lookup failed.. probably a pstn call
use_media_proxy();
rewritehostport("voip_gw");
if (!t_relay()) {
sl_reply_error();
return;
}
return;
}
}
if (method=="INVITE" || method =="ACK") {
log(1," *** USE MEDIA PROXY\n");
use_media_proxy();
}
if (method=="OPTIONS") {
sl_send_reply("404", "Pong - Go away");
return;
}
if (!t_relay()) {
if (method=="INVITE" || method=="ACK") {
end_media_session();
log (1," Ending session sec-2\n");
};
sl_reply_error();
return;
}
}
failure_route[1] {
end_media_session();
log(1,"Ending session sec-3\n");
}
onreply_route[1] {
end_media_session();
log(1,"******* In onreply route block\n");
if (status=~"(183)|(2[09][09])") {
if (client_nat_test("1")) {
fix_contact();
};
use_media_proxy();
}
}
I suspect that asterisk is not seeing the ACK and BYE as part of the
session, since the original INVITE was sent to XXXX(a)pbx.nexusmgmt.com
and all other SIP messages are forwarded to 65.126.236.148.
I have tried to change the forward from the IP to the FQDN, but the
invite no longer reaches the internal UA if I do.
Is there a setting to instruct ser to do a lookup on a forward, or is
forward limited to IP address?
Bart...
-----Original Message-----
From: Dr. Rodney G. McDuff [mailto:mcduff@its.uq.edu.au]
Sent: 09 March 2006 00:43
To: Bart J. Smit
Subject: Re: [Serusers] SER + Asterisk; BYE gets 404
Hi Bart
Bart J. Smit wrote:
> Hi Rodney,
>
> The entire conversation is in UDP. I've attached the SIP packets from
> the ethereal trace.
>
>
Firstly it seems that the ACKs from SJPhone in response to the 200 OK
from your asterisk box arn't getting thru to the asterisk box. Thats why
the asterisk box continues to send the 200 OKs. Eventually the SJPhone
send a BYE (is that you or a timeout?). What is strange is the SER box
authored the 404 Not found response.
If the SER and asterisk is on the same box can you run ethereal this box
and can change the capture filter to get the both sides of the
conversation. Maybe something like 'port 5060 or port 5065'. Also what
is 80.176.149.91?
> Bart...
>
> -----Original Message-----
> From: Dr. Rodney G. McDuff [mailto:mcduff@its.uq.edu.au]
> Sent: 07 March 2006 23:38
> To: Bart J. Smit; serusers(a)lists.iptel.org
> Subject: Re: [Serusers] SER + Asterisk; BYE gets 404
>
> Hi Bart
> Have you got the SER box doing any (TCP/UDP) protocol conversion.
> Ie is your phone using TCP (as * only does UDP).
>
> Bart J. Smit wrote:
>
>> I am running ser 0.9.6 on CentOS 4.2 with asterisk on the same box
>> listening on 5065.
>>
>> When I register a phone with ser, I can call XXXX(a)pbx.nexusmgmt.com
>>
> and
>
>> these calls are forwarded to the asterisk on a forward(<external
>> IP>,5065). I've attached my full routing block below.
>>
>> After hanging up from either phone, the BYE packet never gets
>>
> delivered.
>
>> It shows up in ethereal as being addressed to the external IP address
>>
> of
>
>> the box and it gets a 404 in reply.
>>
>> When I register a phone directly with the Asterisk, I can hang up
from
>> either end as normal, so the issue must be with ser.
>>
>> Any hints on how I can route the BYE packets correctly?
>>
>> Thanks,
>>
>> Bart...
>>
>>
>> route {
>>
>> #
>> -----------------------------------------------------------------
>> # Sanity Check Section
>> #
>> -----------------------------------------------------------------
>> if (!mf_process_maxfwd_header("10")) {
>> sl_send_reply("483", "Too Many Hops");
>> break;
>> };
>>
>> if (msg:len > max_len) {
>> sl_send_reply("513", "Message Overflow");
>> break;
>> };
>> #
>> -----------------------------------------------------------------
>> # Record Route Section
>> #
>> -----------------------------------------------------------------
>> if (method!="REGISTER") {
>> record_route();
>> };
>>
>> #
>> -----------------------------------------------------------------
>> # Loose Route Section
>> #
>> -----------------------------------------------------------------
>> if (loose_route()) {
>> t_relay();
>> break;
>> };
>>
>> #
>> -----------------------------------------------------------------
>> # Call Type Processing Section
>> #
>> -----------------------------------------------------------------
>> if (uri=~"sip:[0-9]{4}@pbx\.nexusmgmt\.com") {
>> forward(65.126.236.148,5065);
>> break;
>> };
>> if (uri!=myself) {
>> route(1);
>> break;
>> };
>>
>> if (method=="CANCEL") {
>> route(1);
>> break;
>> } else if (method=="INVITE") {
>> route(3);
>> break;
>> } else if (method=="REGISTER") {
>> route(2);
>> break;
>> };
>>
>> lookup("aliases");
>> if (uri!=myself) {
>> route(1);
>> break;
>> };
>>
>> if (!lookup("location")) {
>> sl_send_reply("404", "User Not Found");
>> break;
>> };
>>
>> route(1);
>> }
>>
>> route[1] {
>>
>> #
>> -----------------------------------------------------------------
>> # Default Message Handler
>> #
>> -----------------------------------------------------------------
>>
>> t_on_reply("1");
>>
>> if (!t_relay()) {
>> sl_reply_error();
>> };
>> }
>>
>> route[2] {
>>
>> #
>> -----------------------------------------------------------------
>> # REGISTER Message Handler
>> #
>> ----------------------------------------------------------------
>>
>> sl_send_reply("100", "Trying");
>>
>> if (!www_authorize("","subscriber")) {
>> www_challenge("","0");
>> break;
>> };
>>
>> if (!check_to()) {
>> sl_send_reply("401", "Unauthorized");
>> break;
>> };
>>
>> consume_credentials();
>>
>> if (!save("location")) {
>> sl_reply_error();
>> };
>> }
>>
>> route[3] {
>>
>> #
>> -----------------------------------------------------------------
>> # INVITE Message Handler
>> #
>> -----------------------------------------------------------------
>>
>> if (!proxy_authorize("","subscriber")) {
>> proxy_challenge("","0");
>> log(1,"authenticate please\n");
>> break;
>> } else if (!check_from()) {
>> sl_send_reply("403", "Use From=ID");
>> break;
>> };
>>
>> lookup("aliases");
>> if (uri!=myself) {
>> route(1);
>> break;
>> };
>>
>> if (!lookup("location")) {
>> sl_send_reply("404", "User Not Found");
>> break;
>> };
>>
>> route(1);
>> }
>>
>> _______________________________________________
>> Serusers mailing list
>> serusers(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>
>
>
--
Dr. Rodney G. McDuff |Ex ignorantia ad sapientiam
Manager, Strategic Technologies Group| Ex luce ad tenebras
Information Technology Services |
The University of Queensland |
EMAIL: mcduff(a)its.uq.edu.au |
TELEPHONE: +61 7 3365 8220 |
