As a follow up question . Do we have a mechanism by which a SER proxy can
get/pull information from another SER proxy about clients registered. Here
is a scenario.
I have deployed a SER proxy - "PROXY-A" to which a very large number of
users are registered. I need to bring down PROXY-A for maintenance and
replace it with PROXY-B but donot want the users to register again. Is there
some way by which PROXY-B can pull the info out of PROXY-A so that the
customers donot see this transition.
Is it possible for a SER Proxy to fwd all the learnt registration
information to a backend central registrar. If any call needs to be routed
(eg: an invite message being received) the proxy can lookup the central
registrar and route the call .
thanks,
sandeep
>
> On 10/20/05, sandeep kamath <sandyk76(a)gmail.com> wrote:
>
> > Hi,
> > I had posted this query to the SIP implementors mailing list . So for
> > those who have not read this let me summarise the problem.
> >
> > "I wanted to know if there is a mechanism where registration information
> > could be shared among SIP proxies.wrt to SER . This is helpful in a farm
> > that is being loadbalanced.
> >
> > The topology is a vserver that has two SER proxies S1 and S2 on UDP.
> >
> > A client 'A' sends a register request to the loadbalancer vip/vserver
> > and the load balancer chooses a service S1 tied on the vip/vserver . The
> > client is registered at the server S1. Now a new call comes for this client,
> > hits the vip and the call hashes to the other service S2 bound to the vip.
> > If S1 and S2 are not sharing the same DB or are not talking to the same
> > registrar we will have a problem. "
> >
> > As a solution Dale R. Worley from pingtel suggested that A SIP registrar
> > can actively duplicate its information into another SIP
> > registrar by doing third-party REGISTERs to it
> > .
> >
> > So my question is how do I set up this third party Registration
> > mechanism in SER so that a client registers with one proxy and inturn the
> > proxy transfers this registration info to other participating proxies?
> >
> > thanks,
> > sandeep
> >
> >
> >
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> >
> >
> >
>
Hello all
I am using SER together with Asterisk as a voicemail server.
When the user does not pick up the call for 15 s the SER is rewriting the
url and forward it to the Asterisk
t_on_reply("1");
t_on_failure("1");
if (!t_relay()) {
if(isflagset(6)) {
unforce_rtp_proxy();
}
sl_reply_error();
};
failure_route[1]{
log(1,"!!!!!!!!!!! Timeout!!!!!!!!!!!!!!!!");
revert_uri();
rewritehostport("10.1.3.11:5061");
append_branch();
t_relay();
break();
}
But my problem is that SER still rewrites the url and forwards it to
asterisk even that the calling person has hung up.
Does anyone know how to do it that SER will forward the call only in case of
time out and will not forward when the caller hang up.
Any help will be welcome.
Best regards
Jarek
Hi all,
is it possible to distinguish between messages coming out of a network and messages coming from the ser-fifo?
I get SIP-messages from the fifo and I would like to treat them differently from messages of hte network in ser.cfg!
Thanks
Thorsten
hello ser users,
i am trying to insert mysql and authorisation modules in to ser. i want to control the user logins.
after refering to the SER getting started document i have loaded mysql and auth etc.. modules in to the ser.cfg. then i tried creating the database 'ser' with 'subscriber' table and "username , domain , password" as fields. but when i used the command "serctl add 1000 password user1@nowhere" it is giving the following error "SER/FIFO not accessible: 2". then when i started SER , i got the following messages in /var/log
Oct 20 16:57:30 localhost ser: WARNING: fix_socket_list: could not rev. resolve 192.168.1.247
Oct 20 16:57:30 localhost ser: WARNING: fix_socket_list: could not rev. resolve 192.168.1.247
Oct 20 16:57:30 localhost ser[7006]: Maxfwd module- initializing
Oct 20 16:57:30 localhost ser[7007]: WARNING: no fifo_db_url given - fifo DB commands disabled!
i am giving my ser.cfg file:
#debug=3 # debug level (cmd line: -dddddddddd)
#fork=yes
#log_stderror=no # (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/ser_fifo"
fifo_db_url="mysql://ser:heslo@192.168.1.247/ser"
# ------------------ 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/textops.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"
loadmodule "/usr/local/lib/ser/modules/uri_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)
modparam("auth_db|uri_db|usrloc", "db_url", "mysql://ser:heslo@192.168.1.247/ser")
# -- 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")
modparam("usrloc", "db_mode", 2)
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
#modparam("pa","default_expires",1800)
#modparam("pa","timer_interval",10)
#modparam("pa","use_db",0)
#modparam("pa","use_place_table",0)
#modparam("pa","use_bsearch",0)
#modparam("pa","use_location_package",0)
#modparam("pa","pa_domain","bigU.edu")
# ------------------------- 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 >= 2048 ) {
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") 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==myself) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
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) {
#rupesh code start
if (method=="INVITE")
{
route(2);
break;
}
else if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication
sl_send_reply("100", "Trying");
if (!www_authorize("192.168.1.247", "subscriber")) {
www_challenge("192.168.1.247", "0");
break;
};
if (!check_to())
{
sl_send_reply("401", "Unauthorized");
break;
};
consume_credentials();
if(!save("location"))
{
sl_reply_error();
};
break;
};
lookup("aliases");
if (!uri==myself) {
append_hf("P-hint: outbound alias\r\n");
route(1);
break;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
};
append_hf("P-hint: usrloc applied\r\n");
route(1);
}
route[1]
{
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
}
route[2]
{
if(!proxy_authorize("192.168.1.247","subscriber"))
{
proxy_challenge("192.168.1.247","0");
break;
}
else if(!check_from())
{
sl_send_reply("403", "Use From=ID");
break;
};
consume_credentials():
lookup("aliases");
if(uri!=myself)
route(1);
break;
};
if(!lookup("location"))
{
sl_send_reply("404", "User Not Found");
break;
};
route(1);
}
hope some one can give me some guidance regarding the same, thank you,
Rupesh
Hi list,
Does postgresql-8.0.4 compatible with ser-0.9.4?
Although /lib/ser/modules/postgres.so exists, I have got this error
ERROR: load_module: could not open module </lib/ser/modules/postgres.so>:
libpq.so.4: cannot open shared object file: No such file or directory
Regards,
Chia
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.4/143 - Release Date: 10/19/2005
Hi,
I had posted this query to the SIP implementors mailing list . So for those
who have not read this let me summarise the problem.
"I wanted to know if there is a mechanism where registration information
could be shared among SIP proxies.wrt to SER . This is helpful in a farm
that is being loadbalanced.
The topology is a vserver that has two SER proxies S1 and S2 on UDP.
A client 'A' sends a register request to the loadbalancer vip/vserver and
the load balancer chooses a service S1 tied on the vip/vserver . The client
is registered at the server S1. Now a new call comes for this client, hits
the vip and the call hashes to the other service S2 bound to the vip. If S1
and S2 are not sharing the same DB or are not talking to the same registrar
we will have a problem. "
As a solution Dale R. Worley from pingtel suggested that A SIP registrar can
actively duplicate its information into another SIP
registrar by doing third-party REGISTERs to it
.
So my question is how do I set up this third party Registration mechanism
in SER so that a client registers with one proxy and inturn the proxy
transfers this registration info to other participating proxies?
thanks,
sandeep
Hi again,
Having solved the previous topic using Bogdan's hint
I stumbled straight into a new problem. Is there a
workaround for not being able to use the avp-ops
from onreply_route?
Some details on the reason: We implement the Service-
Route extension according to RFC 3608. The registrar
returns in the 200OK a ServiceRoute header where all
proxies on the (return) path register themselves.
The last proxy (that forwards the 200 OK to the UA) is
supposed to store the ServiceRoute locally. Our plan
was straight-forward: to store the header field's
content via avp-ops from within the onreply_route.
Unfortunately avp-ops are not available in onreply_route -
Bogdan explains the reason why in
<http://www.archivum.info/serdev%40iptel.org/2005-02/msg00274.html>
Is there a specific reason why the access to the avp list
is not synchronized? Performance? Basically, provided a
good description of the implementation and concept, imho
it could be left to users to restrict themselves to have
avpops writes in only in their onreply_routes for a
specific avp pair. Or, provide synchronized avps?
So, does anyone have an idea how we can:
- Store an AVP containing header fields extracted from a
200 OK message
- Retrieve this AVP on incoming invites in order to place
these values into the message (security check and/or
Route enforcement).
Thanks in advance,
best regards
--Joachim
Hi All,
I have just installed openser 0.9.5 I have connected in a simple test case. Now
I am trying to implement the nathelper an I can no longer login with my sip client.
My openser box is not behind a firewall, but the clients I am using are. I
copies the config file for nat+rtpproxy from onsip.org. It starts fine and sees
rtpproxy, but when I try to login I get
check_response(): Our result = '62ae83e04a67107edf9981943597e4c2'
0(8432) check_response(): Authorization is OK
0(8432) check_username(): Digest username and URI username do NOT match
0(8432) parse_headers: flags=-1
I have tried everything I can think of to solve this problem, No luck.
Any help would be great!
Thanks
Glenn
Glenn MacGregor
HighStreet Networks
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
