Hi,
Are there any plans to add SIP Symmetric Response support
(http://www.iptel.org/info/players/ietf/firewall/nat/draft-ietf-sip-symmetri…)
into SER, so that it would be possible to use compliant UAs behind NATs
with SER being on a public IP? The idea is simple: when the SIP packet
is received from UA, the server checks if an empty `rport' parameter
is present in the first Via field, and if yes then compares IP:PORT in
the first Via header with the actual IP:PORT this request came from,
and adds `received' and `rport' parameters into the header if either
doesn't match before forwarding request further.
Then, when replying or forwarding the request, the server checks if
any of received or rport is present and uses it instead of the
UA-provided values in corresponding Via header.
Please let me know if there are work in progress on this, so that
I will not have to reinvent the wheel.
Thanks!
-Maxim
Hi,
I am wondering if this is the right place to ask, but here it goes.
Is the SER software going to incorporate the client side of FCP (Firewall
Control Protcol) as a module at some point?
Regards,
Jaime
*******************************************************************************
Important.
Confidentiality: This communication is intended for the above-named person and
may be confidential and/or legally privileged. Any opinions expressed in this
communication are not necessarily those of the company. If it has come to you
in error you must take no action based on it, nor must you copy or show it to
anyone; please delete/destroy and inform the sender immediately.
Monitoring/Viruses
Orange may monitor all incoming and outgoing emails in line with current
legislation. Although we have taken steps to ensure that this email and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.
Orange PCS Limited is a subsidiary of Orange SA and is registered in England No
2178917, with its address at St James Court, Great Park Road, Almondsbury Park,
Bradley Stoke, Bristol BS32 4QJ.
*******************************************************************************
hi,
i have met the same problem with acc. i can get the invite message for accounting,but i can't get the bye message, i also capture the udp packages on ser server, i use MSN for UA, i find the sip messeges like: invite,100 trying,180 ringing ,200 ok(for invite),but when i hangup, there are not bye message, it's like sending bye message from UA to UA directly,while not going throug ser server,so there is not BYE message for accounting, is it true?
how to get the bye message for accounting? please help.
my ser.cfg is like:
..
loadmodule "/usr/local/lib/ser/modules/mysql.so"
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/acc.so"
#loadmodule "/usr/local/lib/ser/modules/auth.so"
loadmodule "/usr/local/lib/ser/modules/print.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"
..
modparam("acc", "db_url","sql://ser:heslo@localhost/ser")
modparam("acc","report_ack",1)
modparam("acc","log_level",1)
modparam("acc", "acc_flag", 1 )
modparam("acc", "missed_flag", 3 )
# -- tm params --
modparam("tm", "fr_timer", 10 )
modparam("tm", "fr_inv_timer", 20 )
modparam("tm", "wt_timer", 10 )
..
route{
# initial sanity checks -- messages with
# max_forwars==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (len_gt( max_len )) {
sl_send_reply("513", "Message too big");
break;
};
# Do strict routing if pre-loaded route headers present
rewriteFromRoute();
# 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) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication
# if (!www_authorize("192.168.139.125", "subscriber")) {
# www_challenge("192.168.139.125", "0");
# break;
# };
save("location");
break;
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
};
# set for accounting (the same value as in acc_flag!)
if (method=="INVITE" || method=="BYE"){
setflag(1);
# ... and also report on missed calls ... note that reporting
# on missed calls is mutually exclusive with silent C timer
#
setflag(3);
};
# forward to current uri now
if (!t_relay()) {
sl_reply_error();
};
}
thanks!
Dear Sirs,
Our company is currently evaluating several freely available SIP
proxy/registrars to extend our VoIP billing engine, which currently
only supports H323, to support SIP as well. We found SER to be one of
the best for our needs: speed, documentation, flexibility - everything
is great. Hovewer, since our billing engine uses Radius for AAA, we need
to get Radius modules working. Unfortunately, we can't compile radius
modules with virgin radiusclient 0.3.2 as suggested in documentation - it
seems that some SIP-specific changes need to be applied to radiusclient
headers, see the following log:
gcc -fPIC -DPIC -pipe -O -mpreferred-stack-boundary=2 -march=pentium2 -funroll-loops -Wcast-align -Wall -minline-all-stringops -malign-double -falign-loops -DNAME='"ser"' -DVERSION='"0.8.10"' -DARCH='"i386"' -DOS='"freebsd"' -DCOMPILER='"gcc 3.2"' -D__CPU_i386 -DCFG_DIR='"/usr/local/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DDNS_IP_HACK -DUSE_IPV6 -DDBG_QM_MALLOC -DFAST_LOCK -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_SOCKADDR_SA_LEN -I/usr/local/include -c acc.c -o acc.o
acc.c: In function `radius_log_reply':
acc.c:125: `PW_SIP_METHOD' undeclared (first use in this function)
acc.c:125: (Each undeclared identifier is reported only once
acc.c:125: for each function it appears in.)
acc.c:136: `PW_SIP_RESPONSE_CODE' undeclared (first use in this function)
acc.c:156: `PW_SIP_FROM_TAG' undeclared (first use in this function)
acc.c:189: `PW_SIP_TO_TAG' undeclared (first use in this function)
acc.c:213: `PW_SIP_CSEQ' undeclared (first use in this function)
acc.c:288: `PW_SIP_TRANSLATED_REQ_URI' undeclared (first use in this function)
acc.c: In function `radius_log_ack':
acc.c:434: `PW_SIP_METHOD' undeclared (first use in this function)
acc.c:442: `PW_SIP_RESPONSE_CODE' undeclared (first use in this function)
acc.c:461: `PW_SIP_FROM_TAG' undeclared (first use in this function)
acc.c:491: `PW_SIP_TO_TAG' undeclared (first use in this function)
acc.c:514: `PW_SIP_CSEQ' undeclared (first use in this function)
acc.c:588: `PW_SIP_TRANSLATED_REQ_URI' undeclared (first use in this function)
acc.c: In function `rad_acc_request':
acc.c:733: `PW_SIP_METHOD' undeclared (first use in this function)
acc.c:744: `PW_SIP_RESPONSE_CODE' undeclared (first use in this function)
acc.c:764: `PW_SIP_FROM_TAG' undeclared (first use in this function)
acc.c:797: `PW_SIP_TO_TAG' undeclared (first use in this function)
acc.c:821: `PW_SIP_CSEQ' undeclared (first use in this function)
acc.c:904: `PW_SIP_TRANSLATED_REQ_URI' undeclared (first use in this function)
Would you be so kind to provide us with your changes for radiusclient or
point out where that modified version can be downloaded?
Thank you in advance!
On a separate note I would like to ask you to let me know if there is
any progress on pre-paid module discussed on this list recently. Since we
will also need this functionality, perhaps we can team-up to implement it.
Sincerely,
Maxim Sobolev
PortaOne Ltd
I really hate answering my own question :-)
> } else if(method=="BYE") {
> setflag(1);
> forward(uri:host, uri:port);
I changed this to t_relay() and then I get the BYE
ACC output in the syslog file. This explains something else
(I think). Sometimes the BYE would work, sometimes it would
not make it all the way to the other device (either the PSTN gateway or the
UA). That is probably because forward() simply bounces the
packet via UDP and the UDP can fail ??? t_relay() retries??
Does this make sense?
---greg
>
>Hi,
>
>I am trying to create a basic script for routing calls to and from
>the PSTN. I have experimented with many scripts over the last month,
>this included script is an example. I can use a UA on my
>laptop called 'estara' and REGISTER with my ser sip server.
>I can make a phone call (INVITE) to the PSTN. I can hang up the call
>from either end (BYE) and everything seems to work well.
>
>I am trying to get accounting working. I see the call acceptance
>record in my syslog file:
>
>Jan 7 00:21:09 build ser[3507]: ACC: transaction answered: method=INVITE, i-uri=sip:92143357976@build.august.net, o-uri=sip:2143357976@64.90.42.16:5060, call_id= 847b3d22-131d-46b0-abcb-dc8e6a9f32b5(a)192.168.100.100, from= greg <sip:1107@build.august.net>;tag=3a7b9c52, code=200
>
>However, I can't get the 'BYE' event to record the transaction to the
>syslog file. The 'BYE' event is bouncing through my SIP server.
>Can someone give me a hint?
>
>Thank you,
>---greg
>Greg Fausak
>
>Included file----example.cfg----------------------------------------
>debug=1 # debug level (cmd line: -dddddddddd)
>fork=yes
>log_stderror=no # (cmd line: -E)
>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"
>
>loadmodule "/usr/local/lib/ser/modules/sl.so"
>loadmodule "/usr/local/lib/ser/modules/tm.so"
>loadmodule "/usr/local/lib/ser/modules/acc.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"
>modparam("acc", "log_level", 1)
>modparam("acc", "acc_flag", 1 )
>
>route{
> # filter too old messages
> if (!mf_process_maxfwd_header("10")) {
> log("LOG: Too many hops\n");
> sl_send_reply("483","Too Many Hops");
> break;
> };
> if (len_gt( max_len )) {
> sl_send_reply("513", "Wow -- Message too large");
> break;
> };
>
> /* ********* RR ********************************** */
>
> /* Do strict routing if route headers present */
> rewriteFromRoute();
> /* record-route INVITEs -- all subsequent requests must visit us */
> if (method=="INVITE") {
> addRecordRoute();
> } else if (method=="REGISTER") {
> log("here is a register");
> save("location");
> break;
> };
>
> # now check if it really is a PSTN destination which should be handled
> # by our gateway; if not, and the request is an invitation, drop it --
> # we cannot terminate it in PSTN; relay non-INVITE requests -- it may
> # be for example BYEs sent by gateway to call originator
> if (!uri=~"sip:9[2-9][0-9]{9}@.*") {
> if (method=="INVITE") {
> sl_send_reply("403", "Call cannot be served here");
> } else if(method=="BYE") {
> setflag(1);
> forward(uri:host, uri:port);
> } else {
> forward(uri:host, uri:port);
> };
> break;
> };
>
> # account completed transactions via syslog
> setflag(1);
>
> strip(1);
>
>
> rewritehostport("64.90.42.16:5060");
>
> # forward the request now
> if (!t_relay()) {
> sl_reply_error();
> break;
> };
>}
>_______________________________________________
>Serusers mailing list
>serusers(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
>
hi,
i have a problem about qm_malloc.
my ser has been running correctly before sevral days. but on the day before yesterday it doesn't work suddenly, in the debug mode, the output informations are:
..
0(1114) find_export: found <~db_insert> in module mysql [/usr/local/lib/ser/modules/mysql.so]
0(1114) find_export: found <~db_delete> in module mysql [/usr/local/lib/ser/modules/mysql.so]
0(1114) find_export: found <~db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so]
0(1114) qm_malloc(0x80adf80, 24) called from dbase.c: db_init(266)
0(1114) qm_malloc(0x80adf80, 24) returns address 0x80b43d0 on 0 -th hit
0(1114) qm_malloc(0x80adf80, 30) called from dbase.c: connect_db(69)
0(1114) qm_malloc(0x80adf80, 32) returns address 0x80b4418 on 0 -th hit
0(1114) qm_malloc(0x80adf80, 544) called from dbase.c: connect_db(89)
0(1114) qm_malloc(0x80adf80, 544) returns address 0x80b4468 on 0 -th hit
0(1114) qm_free(0x80adf80, 0x80b4418), called from dbase.c: connect_db(106)
0(1114) qm_free: freeing block alloc'ed from dbase.c: connect_db(69)
0(1114) mod_init(): Database connection opened successfuly
Maxfwd module- initializing
rr - initializing
0(1114) TM - initializing...
0(1114) DEBUG: register_fifo_cmd: new command (t_uac) registered
0(1114) DEBUG: register_fifo_cmd: new command (t_uac_from) registered
0(1114) DEBUG: register_fifo_cmd: new command (t_hash) registered
0(1114) qm_malloc(0x4212f000, 1572864) called from h_table.c: init_hash_table(276)
0(1114) qm_malloc(0x4212f000, 1572864) returns address 0x421354b8 on 0 -th hit
0(1114) DEBUG: lock_initialize: lock initialization started
0(1114) qm_malloc(0x4212f000, 16) called from lock.c: lock_initialize(169)
0(1114) qm_malloc(0x4212f000, 16) returns address 0x422b54e8 on 0 -th hit
0(1114) qm_malloc(0x4212f000, 448) called from timer.c: tm_init_timers(484)
0(1114) qm_malloc(0x4212f000, 448) returns address 0x422b5528 on 0 -th hit
0(1114) qm_malloc(0x4212f000, 40) called from t_stats.c: init_tm_stats(110)
0(1114) qm_malloc(0x4212f000, 40) returns address 0x422b5718 on 0 -th hit
0(1114) qm_malloc(0x4212f000, 12) called from t_stats.c: init_tm_stats(118)
0(1114) qm_malloc(0x4212f000, 12) returns address 0x422b5770 on 0 -th hit
..
stateless - initializing
0(1114) qm_malloc(0x4212f000, 320) called from sl_stats.c: init_sl_stats(128)
0(1114) qm_malloc(0x4212f000, 320) returns address 0x422b5824 on 0 -th hit
0(1114) DEBUG: register_fifo_cmd: new command (sl_stats) registered
0(1114) DEBUG: MD5 calculated: d907c037823644515dfe0ede38ca9976
0(1114) qm_malloc(0x4212f000, 4) called from sl_funcs.c: sl_startup(65)
0(1114) qm_malloc(0x4212f000, 4) returns address 0x422b5994 on 0 -th hit
mysql - initializing
0(1114) qm_malloc(0x4212f000, 396) called from main.c: main(1363)
0(1114) qm_malloc(0x4212f000, 396) returns address 0x422b59c8 on 0 -th hit
0(0) fixing /usr/local/lib/ser/modules/maxfwd.so mf_process_maxfwd_header
0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply
0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply
0(0) fixing /usr/local/lib/ser/modules/rr.so rewriteFromRoute
0(0) fixing /usr/local/lib/ser/modules/registrar.so save
0(0) qm_malloc(0x4212f000, 16) called from dlist.c: new_dlist(87)
0(0) qm_malloc(0x4212f000, 16) returns address 0x422b5b84 on 0 -th hit
...
0(0) qm_malloc(0x80adf80, 96) called from db_row.c: convert_row(49)
0(0) qm_malloc(0x80adf80, 96) returns address 0x80b47cc on 0 -th hit
0(0) qm_malloc(0x80adf80, 96) called from db_row.c: convert_row(49)
0(0) qm_malloc(0x80adf80, 96) returns address 0x80b485c on 0 -th hit
Segmentation fault
it seems that ser can't allocate memory by qm_malloc function. what's wrong with it?
i have tried to reinstall my linux8.0 OS, but the problem is still existed.
please help me!
thanks!
regards,Joe_chen
Hi,
I am trying to create a basic script for routing calls to and from
the PSTN. I have experimented with many scripts over the last month,
this included script is an example. I can use a UA on my
laptop called 'estara' and REGISTER with my ser sip server.
I can make a phone call (INVITE) to the PSTN. I can hang up the call
from either end (BYE) and everything seems to work well.
I am trying to get accounting working. I see the call acceptance
record in my syslog file:
Jan 7 00:21:09 build ser[3507]: ACC: transaction answered: method=INVITE, i-uri=sip:92143357976@build.august.net, o-uri=sip:2143357976@64.90.42.16:5060, call_id= 847b3d22-131d-46b0-abcb-dc8e6a9f32b5(a)192.168.100.100, from= greg <sip:1107@build.august.net>;tag=3a7b9c52, code=200
However, I can't get the 'BYE' event to record the transaction to the
syslog file. The 'BYE' event is bouncing through my SIP server.
Can someone give me a hint?
Thank you,
---greg
Greg Fausak
Included file----example.cfg----------------------------------------
debug=1 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no # (cmd line: -E)
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"
loadmodule "/usr/local/lib/ser/modules/sl.so"
loadmodule "/usr/local/lib/ser/modules/tm.so"
loadmodule "/usr/local/lib/ser/modules/acc.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"
modparam("acc", "log_level", 1)
modparam("acc", "acc_flag", 1 )
route{
# filter too old messages
if (!mf_process_maxfwd_header("10")) {
log("LOG: Too many hops\n");
sl_send_reply("483","Too Many Hops");
break;
};
if (len_gt( max_len )) {
sl_send_reply("513", "Wow -- Message too large");
break;
};
/* ********* RR ********************************** */
/* Do strict routing if route headers present */
rewriteFromRoute();
/* record-route INVITEs -- all subsequent requests must visit us */
if (method=="INVITE") {
addRecordRoute();
} else if (method=="REGISTER") {
log("here is a register");
save("location");
break;
};
# now check if it really is a PSTN destination which should be handled
# by our gateway; if not, and the request is an invitation, drop it --
# we cannot terminate it in PSTN; relay non-INVITE requests -- it may
# be for example BYEs sent by gateway to call originator
if (!uri=~"sip:9[2-9][0-9]{9}@.*") {
if (method=="INVITE") {
sl_send_reply("403", "Call cannot be served here");
} else if(method=="BYE") {
setflag(1);
forward(uri:host, uri:port);
} else {
forward(uri:host, uri:port);
};
break;
};
# account completed transactions via syslog
setflag(1);
strip(1);
rewritehostport("64.90.42.16:5060");
# forward the request now
if (!t_relay()) {
sl_reply_error();
break;
};
}
Hi All,
I am newbie of this field, thanks everyone help me.
I am interesting in B2BUA, however, except some brief defination in 3261, I could not find any further defination or how to implement about B2BUA, I noticed that SER could be implemented as a B2BUA, where can I find some implementation? or where can I get any description?
Koalas
I just setup an account on iptel.org (joejoe(a)iptel.org)
and I connected it to it fine with Messenger which leads me to believe
that I have done something wrong with my ser installation.
thanks,
-joe
Hi,
I've got ser installed and running (0.8.10 on Linux 2.4.18-18.8.0) I
attempt to connect to it with MS "Windows Messenger" version
4.7.0104 on WindowsXP, but it never connected and I don't see
anything in the logfile showing even an attempt to connect.
Just to make sure that I didn't have any firewall rules blocking
access, I wrote a little script to connect to port 5060 on the sip
server and send it "Asdf\n", that appeared to work fine, as this
appeared in my log:
Jan 6 10:57:39 dell1 /usr/local/sbin/ser[14077]: ERROR: parse_first_line: message too short: 5
Jan 6 10:57:39 dell1 /usr/local/sbin/ser[14077]: ERROR:parse_first_line: bad message
Jan 6 10:57:39 dell1 /usr/local/sbin/ser[14077]: ERROR: parse_msg: message=<Asdf >
Jan 6 10:57:39 dell1 /usr/local/sbin/ser[14077]: ERROR: receive_msg: parse_msg failed
So it appears that packets can get to the sip server fine from the
machine that runs the Messenger client.
I also ran serctl moni and didn't see any different output when I
tried to connect with Messenger, i.e. there is no indication that a
connection attempt is even made.
Is there another IM client I can try connecting with? Any other
tricks to know about Messenger other than what I found at:
http://www.iptel.org/ietf55/use_msn.html
BTW, this is using the mysql module and I created a user with serctl
Jan 6 10:53:50 dell1 ser: ser startup succeeded
Jan 6 10:53:50 dell1 /usr/local/sbin/ser[14068]: mod_init(): Database connection opened successfuly
Jan 6 10:53:50 dell1 /usr/local/sbin/ser[14068]: INFO: udp_init: SO_RCVBUF is initially 65535
Jan 6 10:53:50 dell1 /usr/local/sbin/ser[14068]: INFO: udp_init: SO_RCVBUF is finally 131070
Jan 6 10:53:50 dell1 /usr/local/sbin/ser[14068]: INFO: udp_init: SO_RCVBUF is initially 65535
Jan 6 10:53:50 dell1 /usr/local/sbin/ser[14068]: INFO: udp_init: SO_RCVBUF is finally 131070
Jan 6 10:53:50 dell1 /usr/local/sbin/ser[14080]: INFO: fifo process starting: 14080
Jan 6 10:53:50 dell1 /usr/local/sbin/ser[14080]: SER: open_uac_fifo: fifo server up at /tmp/ser_fifo...
thanks,
-joe
