Hi guys,
I'd like to propose another possibility for a highly-available and
scalable system design based on SER:
The problems I've encountered for scalable systems are:
- Distribution of the user location and alias location among the nodes
(user location is based on registrations, alias location comes from
web interfaces and is used for call forwarding).
- Reloading up to date location tables after breakdown and recovery of a
node
So I'm just thinking loud about the following provisioning system:
- Write a client which fulfills the this demands:
- Receive one or more locations from SER via a SER module or from a
web application and distribute them to other
known clients. Take care of retransmissions if a client isn't
reachable or reports a temporary failure.
- Receive one or more locations from other clients and write
them into the SER FIFO. If writing into the FIFO fails, try to
write directly into the database (location-table, alias-table etc.).
Report a temporary failure if this also fails.
Maybe a centralized server should be used which receives the locations
from the clients and distributes them to other clients, so that the
nodes just know about the server and nothing about other nodes. This
would make integration of new nodes easy.
On the other hand, it's another single point of failure, so a
decentralized solution should be considered. But that would mean that
you've to inform every node about the existence of a new node.
The protocol used between the nodes should be simple and fast. So I
think SOAP drops out here. Maybe XMLRPC or ICE
(http://www.zeroc.com/ice.html) could be used.
One might think now why not just use replication on SIP layer, but
t_replicate only supports one peer and you've no possibility to get
locations on a node while it's down. Replication of other location
tables like the alias-table is also not possible.
I'd be willing to release these parts as GPL for creating an open
framework for carrier-grade SER integration, so any feedback,
improvements or flames are highly welcome.
Cheers,
Andy
I am relatively new to SER. My SIP service provider requires me to
present the ANI in the "From" field in my INVITE message header in E.164
format. I am currently sending this information as follows:
From: "2125551212" <sip:2125551212@xxx.xxx.xxx.xxx>
They want it in E.164 format as follows:
From: "+12125551212" <sip:+12125551212@xxx.xxx.xxx.xxx>
I see function only to modify the SIP URI but not the other header or
SDP fields.
Could someone help me with a code snippet that I can use in ser.cfg to
do this conversion?
Regards,
SCM
Does anyone know if there is a way to authenticate SER to MS Active
Directory? I'd like to use an existing user database instead of
having to manage users myself, and most of our users are in Active
Directory.
Has anyone tried this?
What are most SER users using for authentication? Is anyone here
tying into any kind of existing organization user database?
We are using SER with the PostgreSQL module, so that SER and our
Asterisk PSTN gateway and voice mail system can use the same back-end
database for user records. (Anyone who's interested in how we did this,
let me know -- it's still a little shaky, but it pretty much works.)
Recently we have encountered a problem: it seems that if any database
error occurs, SER hangs or crashes. We have so far been able to mostly
work around these conditions by being Really Careful with the database,
but it is a little unsettling.
The database schema we're working from is practically identical to the
MySQL schema that ships with SER. Notably for this problem the lengths
of all CHARACTER VARYING fields are the same. The User-Agent field is
CHARACTER VARYING(50), for instance.
So ... today boss got a copy of Xten's "eyeBeam" software, set it up
to register to our SER ... and SER promptly locked up. I looked in the
PostgreSQL database log and found this:
Feb 10 13:39:32 mabell postgres[13058]: [267] ERROR: value too long for
type character varying(50)
Whoops. SER tried to insert eyeBeam's User-Agent data, PostgreSQL
returned a data integrity error, and SER went bye-bye.
So I did a little ALTER TABLE and adjusted the field to length 128 ...
then put this in ser.cfg:
# Disallow long user-agent
if (search("^User-Agent: .{100,}") ) {
log(1, "LOG: User agent too long\n");
sl_send_reply("479", "User agent too long!");
break;
};
But this is obviously a kludge ... and doesn't fix the problem of one of
the *other* fields being over-long.
Anyone have any thoughts on this? Robustness patches for the PostgreSQL
module or usrloc? Better ser.cfg workarounds to protect the world from
malformed or over-long SIP header fields? Should I just change all the
database fields to TEXT instead of CHARACTER VARYING(whatever) ?
--
Karl A. Krueger <kkrueger(a)whoi.edu>
Network Security -- Linux/Unix Systems Support -- Etc.
Woods Hole Oceanographic Institution
Hi Jiri.
Two questions please.
1.)
Jiri Kuthan HYPERLINK
"mailto:serusers%40iptel.org?Subject=%5BSerusers%5D%20ENUM%20variable%20TLD%
3F&In-Reply-To=4032B769.8000804%40august.net"jiri at iptel.org
Wed Feb 18 02:25:07 CET 2004
* Previous message: HYPERLINK
"http://lists.iptel.org/pipermail/serusers/2004-February/006025.html"[Seruser
s] ENUM variable TLD?
* Next message: HYPERLINK
"http://lists.iptel.org/pipermail/serusers/2004-February/006022.html"[Seruser
s] current uri
* Messages sorted by: HYPERLINK
"http://lists.iptel.org/pipermail/serusers/2004-February/date.html#6026"[
date ] HYPERLINK
"http://lists.iptel.org/pipermail/serusers/2004-February/thread.html#6026"[
thread ] HYPERLINK
"http://lists.iptel.org/pipermail/serusers/2004-February/subject.html#6026"[
subject ] HYPERLINK
"http://lists.iptel.org/pipermail/serusers/2004-February/author.html#6026"[
author ]
_____
on development branch there is an updated enum module which
allows you to use private enum trees the way you are asking.
If you need it, there should be no conflicts if you take
devel version of enum and put it in your 8.12 source tree.
-jiri
At 01:52 AM 2/18/2004, Greg Fausak wrote:
>Normally I do enum lookups inside my
>domain, however, I want to be able to do
>an enum lookup at other TLD. Is there a
>way to do that? Maybe enum_query("e164.other.com")??
>
I have downloaded the latest code as you suggested but have not been able to
figure out how to specify a different TLD.
I have looked a documentation but that has not helped either.
Can you please tell me what the function I need is called?
2.)
Is there an updated ENUM module that would allow me to preform an ENUM query
based on a spcified prefix?
In other words, what if I would like to preform an ENUM query when a number
comes in with a "**" instead of the "+".
I have modified the c code to do this for me but was wondering if you have
released a "production" version of this code.
Thanks,
David Schwartz
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.796 / Virus Database: 540 - Release Date: 11/13/2004
Hello list.
I have a question about reliability in SER. Suppose that for
certain reason, the process "ser" fails, and therefore the SIP Server is
down. Is there a way to keep trace of the "ser" process status?? and if the
process is not running start a script to restart the process. I know that
maybe the "crond" command could be useful for this purpose. Does someone
have any clue about this? Or maybe SER has his own "crond" module or
something.?
I really need and advice about this issue.
Thanks in advance
Regards,
Ricardo Martinez Ogalde.-
Hi All,
For the 0_9_0 branch, what is the 'best practice' for implementing
parallel forking?
We used to be able to point one alias at several accounts, but that
feature has regressed.
Thanks,
-Jev
Hi,
I have in my ser.cfg:
modparam("tm","fr_inv_timer",40)
set as a timer so that INVITEs coming from PSTN callers go to
voicemail after 40 seconds. This works great for inbound called,
however it seems to be a limitation for outbound calls. If the
outbound INVITE doesn't receive an ACK in that time period, the call
gets cancelled and drops to fast busy.
Is there a way around this? Can I set different timers for inbound and
outbound calls? 40 seconds seems to be a good amount time so that
most outbound calls get answered by voicemail or actual people, but
occastionally users will still get a fast busy.
Any advice is greatly appreciated.
Dan
Dear ALL:
I try to make a call from UA1 to UA2, and UA2 is busy. So the call
will forward to another UA3.
UA1 ==> UA2(busy) ==> UA3
But when I watch the log, I find that miss the following log (diff
with call from UA1 to UA2 and directly forward to UA3)
UA1 ==> UA2(callfwd) ==> UA3
Feb 22 12:15:07 ser mediaproxy[18476]: session
16AA8C75-5EAC-403C-85DA-C5D9BDFD15C7(a)10.18.1.70: started. listening on
xxx.xxx.190.248:35026
When I make a callfwd call, the call will run route[2] but not failure_route[1].
UA1==>UA2(callfwd)==>route[2]==>UA3
And I make a fwdbusy call, the call will run route[2] then pass
failure_route[1],
and return to route[2].
UA1==>UA2(fwdbusy)==>failure_route[1]==>route[2] =XXX=> UA3 ????
Why does the method be failed? Do I must "end_media_session()" before
start a busy call?
How can I modify it?
My snippet ser.cfg :
--------------------------------------------------------------------------------------------------------------
route[2] {
log(1, "SER: SIP Call On-Net section route(2)\n");
if ((method=="INVITE") && !allow_trusted()) {
if (!proxy_authorize("", "subscriber")) {
proxy_challenge("", "0");
break;
} else if (!check_from()) {
log(1, "Spoofed SIP call attempt");
sl_send_reply("403", "Use From=ID");
break;
} else if (!(is_from_local() || is_uri_host_local())) {
sl_send_reply("403", "Please register to use our service");
break;
};
};
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;
};
if (method=="INVITE" || method=="ACK") {
use_media_proxy();
};
t_on_failure("1");
t_on_reply("1");
if (!t_relay()) {
if (method=="INVITE" || method=="ACK") {
end_media_session();
};
sl_reply_error();
};
}
failure_route[1] {
log(1, "SER: Failure Route section failure_route(1)\n");
# if caller hung up then don't sent to voicemail
if (t_check_status("487")) {
break;
};
if (isflagset(26) && t_check_status("486")) {
# forward busy is flag 26
if (avp_pushto("$ruri", "s:fwdbusy")) {
log(1, "SER: fork to fwdbusy\n");
avp_delete("s:fwdbusy");
append_branch();
resetflag(26);
# test for domestic PSTN gateway
if (uri=~"^sip:0[0-9]{9}@") {
# if (avp_check("$fwd_busy_type", "eq/dom/i")) {
# test for domestic PSTN gateway
log(1, "SER: Busy Failure and Jump to route(3)\n");
route(3);
} else if (uri=~"^sip:002[1-9][0-9]*@") {
# } else if (avp_check("$fwd_busy_type", "eq/int/i")) {
# test for international PSTN gateway
log(1, "SER: Busy Failure and Jump to route(6)\n");
route(6);
} else {
# default to sip call
log(1, "SER: Busy Failure and Jump to route(2)\n");
route(2);
};
break;
};
};
# here we can have either voicemail __OR__ forward no answer
if (isflagset(27) && t_check_status("408")) {
# forward no answer is flag 27
if (avp_db_load("$ruri/username", "s:fwdnoanswer")) {
avp_pushto("$ruri", "s:fwdnoanswer");
log(1, "SER: fork to fwdnoanswer\n");
avp_delete("s:fwdnoanswer");
append_branch();
resetflag(27);
if (uri=~"^sip:0[0-9]{9}@") {
# if (avp_check("$fwd_no_answer_type", "eq/dom/i")) {
# test for domestic PSTN gateway
log(1, "SER: No Answer Failure and Jump to route(3)\n");
route(3);
} else if (uri=~"^sip:002[1-9][0-9]*@") {
# } else if (avp_check("$fwd_no_answer_type", "eq/int/i")) {
# test for international PSTN gateway
log(1, "SER: No Answer Failure and Jump to route(6)\n");
route(6);
} else {
# default to sip call
log(1, "SER: No Answer Failure and Jump to route(2)\n");
route(2);
};
break;
};
} else if (isflagset(31) && avp_pushto("$ruri", "$voicemail")) {
avp_delete("$voicemail");
log(1, "SER: No Answer Failure and Jump to route(4)\n");
route(4);
break;
};
}