Hi,
we're running SER together with a PSTN Gateway. Before a call get's
forwarded to the gateway, we are rewriting the request URI to make
rewriting on the GW as simple as possible:
route {
...
strip(3); # +43xxx -> xxx
prefix("0"); # xxx -> 0xxx
rewritehostport(xxx.xxx.xxx.xxx, 5060); # request to gateway
route(1);
break;
...
SIP call flow looks like (record route enabled):
(1) phone -> SER
INVITE sip:*43699xxxxxxxx@nic.at43.at SIP/2.0
(2) SER -> phone
SIP/2.0 100 trying -- your call is important to us
(3) SER -> GW
INVITE sip:0699xxxxxxxx@xx.xx.xx.xx:5060 SIP/2.0
(4) GW -> SER
SIP/2.0 100 Trying
(5) GW -> SER
SIP/2.0 183 Session Progress
(6) SER -> phone
SIP/2.0 183 Session Progress
(7) GW -> SER
SIP/2.0 180 Ringing
(8) SER -> phone
SIP/2.0 180 Ringing
(9) GW -> SER
SIP/2.0 200 OK
Contact: <sip:0699xxxxxxxx@xx.xx.xx.xx:5060>
(10) SER -> phone
SIP/2.0 200 OK
Contact: <sip:0699xxxxxxx@xx.xx.xx.xx:5060>
[ call established, we can talk, but ... ]
(11) phone -> SER
ACK sip:0699xxxxxxxx@xx.xx.xx.xx:5060 SIP/2.0
--> Here starts the problem. That ACK (11) never gets forwarded to the
Gateway, so after a few seconds, the GW starts over at (9). Those three
packets (9-11) repeat a few times until GW runs into a timeout and drops
the call.
I have the impression that SER can't match the packet to the previous
requests because of the rewritten URI. Is that correct?
The only output at debug level 3 is:
Warning: sl_send_reply: I won't send a reply for ACK!!
Is that a routing goof somewhere in our scripts or is that a more
generic problem? Is the problem that the warning indicates somehow
related to the fact that the ACK is not being forwarded?
Help appreciated.
cheers
axelm
Jan,
Thanks. I think I finally found the problem. I'm not so good at script
constructs. I tried a few things and I finally got it to work with simple
routing logic. I just didn't understand exactly where to place the routing
block.
Thanks again,
Paul
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: Friday, June 27, 2003 1:08 PM
To: Wasik, Paul
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Need Routing Help
Hello,
Hmm, there were some problems with RH9 but they have been fixed. Could
you, please, try the latest stable CVS version ? You can get it from
here:
http://iptel.org/ser/cvs/stable
jan.
On 27-06 13:05, Wasik, Paul wrote:
> Jan,
>
> I set debug=9 and log_stderr=yes. Log is attached. I don't see any clues
to
> what is wrong.
>
> Paul
>
> -----Original Message-----
> From: Jan Janak [mailto:jan@iptel.org]
> Sent: Friday, June 27, 2003 12:58 PM
> To: Wasik, Paul
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] Need Routing Help
>
>
> Hello,
>
> set debug=9 and log_stderr=yes and restart ser and it should tell you
> what's wrong.
>
> Jan.
>
> On 27-06 12:54, Wasik, Paul wrote:
> > Jan,
> >
> > My SER SIP server works fine with the default config script. As soon as
I
> > add some simple static routing such as:
> >
> > if (uri=~"^sip:9[0-9]*@rtcsol.local) {
> > forward( 159.63.73.165, 5060 );
> >
> > to the script and restart ser, my log looks like the attached. There is
a
> > ser process running but it is not normal and no network SIP ports ie
5060
> > are opened.
> >
> > The command line returns:
> >
> > [root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser stop
> > Stopping ser: [ OK ]
> > [root@FFDCTSERSIP ser]#
> > [root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser start
> > Starting ser: Terminated
> > [root@FFDCTSERSIP ser]#
> > [root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser status
> > ser (pid 7309) is running...
> > [root@FFDCTSERSIP ser]#
> >
> > I'm running the 0.8.11pre29 for test bed only on a Red Hat 9 system.
What
> > could I be doing wrong?
> >
> > Paul
> >
> > -----Original Message-----
> > From: Jan Janak [mailto:jan@iptel.org]
> > Sent: Thursday, June 26, 2003 2:02 PM
> > To: Wasik, Paul
> > Cc: serusers(a)lists.iptel.org
> > Subject: Re: [Serusers] Need Routing Help
> >
> >
> > Edit your configuration file and set log_stderror to yes. By default the
> > server uses syslog to do the output so you will find it in
> > /var/log/messages or /var/log/daemon (depending on your distribution).
> > If you set the variable then ser will output all messages to the
> > standard output.
> >
> > Jan.
> >
> > On 26-06 14:01, Wasik, Paul wrote:
> > > Jan,
> > >
> > > I don't see any error output on the command line. Is there a log file
> > > somewhere? All I see is "Terminated" when attempting to start SER.
> > >
> > > Paul
> > >
> > > -----Original Message-----
> > > From: Jan Janak [mailto:jan@iptel.org]
> > > Sent: Thursday, June 26, 2003 1:58 PM
> > > To: Wasik, Paul
> > > Cc: serusers(a)lists.iptel.org
> > > Subject: Re: [Serusers] Need Routing Help
> > >
> > >
> > > Hello,
> > >
> > > and what is the problem ? If your ser doesn't start anymore then your
> > > configuration file contains some mistake. In that case the output of
ser
> > > tells you on what line the mistake is, for example:
> > >
> > > 0(6704) parse error (75,36-37): syntax error
> > > 0(6704) parse error (75,36-37): invalid route statement
> > > 0(6704) parse error (75,38-39):
> > > ERROR: bad config file (3 errors)
> > >
> > > means that there is an error on line 75 of the configuration file.
> > >
> > > Jan.
> > >
> > >
> > > On 26-06 13:53, Wasik, Paul wrote:
> > > > Hi all,
> > > >
> > > > I've got SER running on a Red Hat 9 platform. I've got MySQL and
> serweb
> > > > working and using the default ser.cfg file I can register UAs and
make
> > > local
> > > > calls within the proxy. What I have not been able to do is get
routing
> /
> > > > dial plan stuff to work via a Cisco SIP gateway. I cannot get SER to
> run
> > > > once I add any routing information to the ser.cfg script. I tried
> > > following
> > > > the examples like the following from the "How to" guide:
> > > >
> > > > # attempt handoff to PSTN
> > > > if (uri=~"^sip:9[0-9]*@mydomain.com") { ## This assumes that the
> caller
> > is
> > >
> > > > log("Forwarding to PSTN\n"); ## registered in our realm
> > > > t_relay_to( "192.168.0.2", "5060"); ## Our Cisco router
> > > > break;
> > > > };
> > > > Anyone have any ser.cfg script files that work succesfully for
simple
> > dial
> > > > plan / routing to a SIP gatewat they could share? I'm having a hard
> time
> > > > with the routing.
> > > > Thanks,
> > > > Paul
> > > >
> > > >
> > > > _______________________________________________
> > > > Serusers mailing list
> > > > serusers(a)lists.iptel.org
> > > > http://lists.iptel.org/mailman/listinfo/serusers
> >
>
> > Jun 27 12:42:16 FFDCTSERSIP ser: ser shutdown succeeded
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 14)
called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
returns
> address 0x80bc5b0 frag. 0x80bc598 (size=16) o
> > n 1 -th hit
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 30)
called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32)
returns
> address 0x80bc5f0 frag. 0x80bc5d8 (size=32) o
> > n 1 -th hit
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
> /usr/lib/ser/modules/mysql.so
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
called
> from sr_module.c: register_module(135)
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
returns
> address 0x80bc640 frag. 0x80bc628 (size=16) o
> > n 1 -th hit
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 27)
called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28)
returns
> address 0x80bc680 frag. 0x80bc668 (size=28) o
> > n 1 -th hit
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
> /usr/lib/ser/modules/rr.so
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
called
> from sr_module.c: register_module(135)
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
returns
> address 0x80bc6cc frag. 0x80bc6b4 (size=16) o
> > n 1 -th hit
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 31)
called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32)
returns
> address 0x80bc70c frag. 0x80bc6f4 (size=32) o
> > n 1 -th hit
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
> /usr/lib/ser/modules/maxfwd.so
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
called
> from sr_module.c: register_module(135)
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
returns
> address 0x80bc75c frag. 0x80bc744 (size=16) o
> > n 1 -th hit
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 34)
called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 36)
returns
> address 0x80bc79c frag. 0x80bc784 (size=36) o
> > n 1 -th hit
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
> /usr/lib/ser/modules/registrar.so
> > Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
called
> from sr_module.c: register_module(135)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
returns
> address 0x80bc7f0 frag. 0x80bc7d8 (size=16) o
> > n 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28)
called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28)
returns
> address 0x80bc830 frag. 0x80bc818 (size=28) o
> > n 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) loading module
> /usr/lib/ser/modules/uri.so
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
called
> from sr_module.c: register_module(135)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
returns
> address 0x80bc87c frag. 0x80bc864 (size=16) o
> > n 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 31)
called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32)
returns
> address 0x80bc8bc frag. 0x80bc8a4 (size=32) o
> > n 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) loading module
> /usr/lib/ser/modules/usrloc.so
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
called
> from sr_module.c: register_module(135)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16)
returns
> address 0x80bc90c frag. 0x80bc8f4 (size=16) o
> > n 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 7) called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 8)
returns
> address 0x80bc94c frag. 0x80bc934 (size=8) on
> > 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 8) called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 8)
returns
> address 0x80bc984 frag. 0x80bc96c (size=8) on
> > 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 9) called
> from modparam.c: set_mod_param_regex(85)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 12)
returns
> address 0x80bc9bc frag. 0x80bc9a4 (size=12) o
> > n 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) set_mod_param_regex: usrloc
> matches module usrloc
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) set_mod_param_regex: found
> <db_mode> in module usrloc [/usr/lib/ser/modules/us
> > rloc.so]
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_free(0x80b5f60, 0x80bc9bc),
> called from modparam.c: set_mod_param_regex(143
> > )
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_free: freeing frag.
0x80bc9a4
> alloc'ed from modparam.c: set_mod_param_regex
> > (85)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 25)
called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28)
returns
> address 0x80bc9f8 frag. 0x80bc9e0 (size=28) o
> > n 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 3) called
> from cfg.lex: addstr(404)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 4)
returns
> address 0x80bc9bc frag. 0x80bc9a4 (size=12) on
> > 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) find_export: found
> <mf_process_maxfwd_header> in module maxfwd_module [/usr/li
> > b/ser/modules/maxfwd.so]
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32)
called
> from route_struct.c: mk_action(87)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32)
returns
> address 0x80bca44 frag. 0x80bca2c (size=32) o
> > n 1 -th hit
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 20)
called
> from route_struct.c: mk_elem(68)
> > Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256)
> > [root@FFDCTSERSIP ser]#
>
> > _______________________________________________
> > Serusers mailing list
> > serusers(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
>
> Jun 27 13:02:53 FFDCTSERSIP ser: ser shutdown succeeded
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 14) called
from cfg.lex: addstr(404)
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) returns
address 0x80bc5b0 frag. 0x80bc598 (size=16) on 1 -th hit
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 30) called
from cfg.lex: addstr(404)
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 32) returns
address 0x80bc5f0 frag. 0x80bc5d8 (size=32) on 1 -th hit
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) loading module
/usr/lib/ser/modules/mysql.so
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) returns
address 0x80bc640 frag. 0x80bc628 (size=16) on 1 -th hit
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 27) called
from cfg.lex: addstr(404)
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 28) returns
address 0x80bc680 frag. 0x80bc668 (size=28) on 1 -th hit
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) loading module
/usr/lib/ser/modules/sl.so
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) returns
address 0x80bc6cc frag. 0x80bc6b4 (size=16) on 1 -th hit
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 27) called
from cfg.lex: addstr(404)
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 28) returns
address 0x80bc70c frag. 0x80bc6f4 (size=28) on 1 -th hit
> Jun 27 13:03:00 FFDCTSERSIP ser: 0(7436) loading module
/usr/lib/ser/modules/tm.so
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) returns
address 0x80bc758 frag. 0x80bc740 (size=16) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 27) called
from cfg.lex: addstr(404)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 28) returns
address 0x80bc798 frag. 0x80bc780 (size=28) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) loading module
/usr/lib/ser/modules/rr.so
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) returns
address 0x80bc7e4 frag. 0x80bc7cc (size=16) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 31) called
from cfg.lex: addstr(404)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 32) returns
address 0x80bc824 frag. 0x80bc80c (size=32) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) loading module
/usr/lib/ser/modules/maxfwd.so
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) returns
address 0x80bc874 frag. 0x80bc85c (size=16) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 31) called
from cfg.lex: addstr(404)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 32) returns
address 0x80bc8b4 frag. 0x80bc89c (size=32) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) loading module
/usr/lib/ser/modules/usrloc.so
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) returns
address 0x80bc904 frag. 0x80bc8ec (size=16) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 34) called
from cfg.lex: addstr(404)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 36) returns
address 0x80bc944 frag. 0x80bc92c (size=36) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) loading module
/usr/lib/ser/modules/registrar.so
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) returns
address 0x80bc998 frag. 0x80bc980 (size=16) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 28) called
from cfg.lex: addstr(404)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 28) returns
address 0x80bc9d8 frag. 0x80bc9c0 (size=28) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) loading module
/usr/lib/ser/modules/uri.so
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 16) returns
address 0x80bca24 frag. 0x80bca0c (size=16) on 1 -th hit
> Jun 27 13:03:01 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 7) called
from cfg.lex: addstr(404)
> Jun 27 13:03:02 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 8) returns
address 0x80bca64 frag. 0x80bca4c (size=8) on 1 -th hit
> Jun 27 13:03:02 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 8) called
from cfg.lex: addstr(404)
> Jun 27 13:03:02 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 8) returns
address 0x80bca9c frag. 0x80bca84 (size=8) on 1 -th hit
> Jun 27 13:03:02 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 9) called
from modparam.c: set_mod_param_regex(85)
> Jun 27 13:03:02 FFDCTSERSIP ser: 0(7436) qm_malloc(0x80b5f60, 12) returns
address 0x80bcad4 frag. 0x80bcabc (size=12) on 1 -th hit
> Jun 27 13:03:02 FFDCTSERSIP ser: 0(7436) set_mod_param_regex: usrloc
matches module usrloc
> Jun 27 13:03:02 FFDCTSERSIP ser: 0(7436) set_mod_param_regex: found
<db_mode> in module usrloc [/usr/lib/ser/modules/usrloc.so]
> Jun 27 13:03:02 FFDCTSERSIP ser: 0(7436) qm_free(0x80b5f60, 0x80bcad4),
called from modparam.c: set_mod_param_regex(143)
> [root@FFDCTSERSIP ser]#
Jan,
I set debug=9 and log_stderr=yes. Log is attached. I don't see any clues to
what is wrong.
Paul
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: Friday, June 27, 2003 12:58 PM
To: Wasik, Paul
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Need Routing Help
Hello,
set debug=9 and log_stderr=yes and restart ser and it should tell you
what's wrong.
Jan.
On 27-06 12:54, Wasik, Paul wrote:
> Jan,
>
> My SER SIP server works fine with the default config script. As soon as I
> add some simple static routing such as:
>
> if (uri=~"^sip:9[0-9]*@rtcsol.local) {
> forward( 159.63.73.165, 5060 );
>
> to the script and restart ser, my log looks like the attached. There is a
> ser process running but it is not normal and no network SIP ports ie 5060
> are opened.
>
> The command line returns:
>
> [root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser stop
> Stopping ser: [ OK ]
> [root@FFDCTSERSIP ser]#
> [root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser start
> Starting ser: Terminated
> [root@FFDCTSERSIP ser]#
> [root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser status
> ser (pid 7309) is running...
> [root@FFDCTSERSIP ser]#
>
> I'm running the 0.8.11pre29 for test bed only on a Red Hat 9 system. What
> could I be doing wrong?
>
> Paul
>
> -----Original Message-----
> From: Jan Janak [mailto:jan@iptel.org]
> Sent: Thursday, June 26, 2003 2:02 PM
> To: Wasik, Paul
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] Need Routing Help
>
>
> Edit your configuration file and set log_stderror to yes. By default the
> server uses syslog to do the output so you will find it in
> /var/log/messages or /var/log/daemon (depending on your distribution).
> If you set the variable then ser will output all messages to the
> standard output.
>
> Jan.
>
> On 26-06 14:01, Wasik, Paul wrote:
> > Jan,
> >
> > I don't see any error output on the command line. Is there a log file
> > somewhere? All I see is "Terminated" when attempting to start SER.
> >
> > Paul
> >
> > -----Original Message-----
> > From: Jan Janak [mailto:jan@iptel.org]
> > Sent: Thursday, June 26, 2003 1:58 PM
> > To: Wasik, Paul
> > Cc: serusers(a)lists.iptel.org
> > Subject: Re: [Serusers] Need Routing Help
> >
> >
> > Hello,
> >
> > and what is the problem ? If your ser doesn't start anymore then your
> > configuration file contains some mistake. In that case the output of ser
> > tells you on what line the mistake is, for example:
> >
> > 0(6704) parse error (75,36-37): syntax error
> > 0(6704) parse error (75,36-37): invalid route statement
> > 0(6704) parse error (75,38-39):
> > ERROR: bad config file (3 errors)
> >
> > means that there is an error on line 75 of the configuration file.
> >
> > Jan.
> >
> >
> > On 26-06 13:53, Wasik, Paul wrote:
> > > Hi all,
> > >
> > > I've got SER running on a Red Hat 9 platform. I've got MySQL and
serweb
> > > working and using the default ser.cfg file I can register UAs and make
> > local
> > > calls within the proxy. What I have not been able to do is get routing
/
> > > dial plan stuff to work via a Cisco SIP gateway. I cannot get SER to
run
> > > once I add any routing information to the ser.cfg script. I tried
> > following
> > > the examples like the following from the "How to" guide:
> > >
> > > # attempt handoff to PSTN
> > > if (uri=~"^sip:9[0-9]*@mydomain.com") { ## This assumes that the
caller
> is
> >
> > > log("Forwarding to PSTN\n"); ## registered in our realm
> > > t_relay_to( "192.168.0.2", "5060"); ## Our Cisco router
> > > break;
> > > };
> > > Anyone have any ser.cfg script files that work succesfully for simple
> dial
> > > plan / routing to a SIP gatewat they could share? I'm having a hard
time
> > > with the routing.
> > > Thanks,
> > > Paul
> > >
> > >
> > > _______________________________________________
> > > Serusers mailing list
> > > serusers(a)lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
>
> Jun 27 12:42:16 FFDCTSERSIP ser: ser shutdown succeeded
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 14) called
from cfg.lex: addstr(404)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc5b0 frag. 0x80bc598 (size=16) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 30) called
from cfg.lex: addstr(404)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32) returns
address 0x80bc5f0 frag. 0x80bc5d8 (size=32) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/mysql.so
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc640 frag. 0x80bc628 (size=16) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 27) called
from cfg.lex: addstr(404)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28) returns
address 0x80bc680 frag. 0x80bc668 (size=28) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/rr.so
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc6cc frag. 0x80bc6b4 (size=16) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 31) called
from cfg.lex: addstr(404)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32) returns
address 0x80bc70c frag. 0x80bc6f4 (size=32) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/maxfwd.so
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc75c frag. 0x80bc744 (size=16) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 34) called
from cfg.lex: addstr(404)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 36) returns
address 0x80bc79c frag. 0x80bc784 (size=36) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/registrar.so
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc7f0 frag. 0x80bc7d8 (size=16) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28) returns
address 0x80bc830 frag. 0x80bc818 (size=28) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/uri.so
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc87c frag. 0x80bc864 (size=16) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 31) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32) returns
address 0x80bc8bc frag. 0x80bc8a4 (size=32) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/usrloc.so
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc90c frag. 0x80bc8f4 (size=16) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 7) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 8) returns
address 0x80bc94c frag. 0x80bc934 (size=8) on
> 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 8) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 8) returns
address 0x80bc984 frag. 0x80bc96c (size=8) on
> 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 9) called
from modparam.c: set_mod_param_regex(85)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 12) returns
address 0x80bc9bc frag. 0x80bc9a4 (size=12) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) set_mod_param_regex: usrloc
matches module usrloc
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) set_mod_param_regex: found
<db_mode> in module usrloc [/usr/lib/ser/modules/us
> rloc.so]
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_free(0x80b5f60, 0x80bc9bc),
called from modparam.c: set_mod_param_regex(143
> )
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_free: freeing frag. 0x80bc9a4
alloc'ed from modparam.c: set_mod_param_regex
> (85)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 25) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28) returns
address 0x80bc9f8 frag. 0x80bc9e0 (size=28) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 3) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 4) returns
address 0x80bc9bc frag. 0x80bc9a4 (size=12) on
> 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) find_export: found
<mf_process_maxfwd_header> in module maxfwd_module [/usr/li
> b/ser/modules/maxfwd.so]
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32) called
from route_struct.c: mk_action(87)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32) returns
address 0x80bca44 frag. 0x80bca2c (size=32) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 20) called
from route_struct.c: mk_elem(68)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256)
> [root@FFDCTSERSIP ser]#
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
Jan,
My SER SIP server works fine with the default config script. As soon as I
add some simple static routing such as:
if (uri=~"^sip:9[0-9]*@rtcsol.local) {
forward( 159.63.73.165, 5060 );
to the script and restart ser, my log looks like the attached. There is a
ser process running but it is not normal and no network SIP ports ie 5060
are opened.
The command line returns:
[root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser stop
Stopping ser: [ OK ]
[root@FFDCTSERSIP ser]#
[root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser start
Starting ser: Terminated
[root@FFDCTSERSIP ser]#
[root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser status
ser (pid 7309) is running...
[root@FFDCTSERSIP ser]#
I'm running the 0.8.11pre29 for test bed only on a Red Hat 9 system. What
could I be doing wrong?
Paul
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: Thursday, June 26, 2003 2:02 PM
To: Wasik, Paul
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Need Routing Help
Edit your configuration file and set log_stderror to yes. By default the
server uses syslog to do the output so you will find it in
/var/log/messages or /var/log/daemon (depending on your distribution).
If you set the variable then ser will output all messages to the
standard output.
Jan.
On 26-06 14:01, Wasik, Paul wrote:
> Jan,
>
> I don't see any error output on the command line. Is there a log file
> somewhere? All I see is "Terminated" when attempting to start SER.
>
> Paul
>
> -----Original Message-----
> From: Jan Janak [mailto:jan@iptel.org]
> Sent: Thursday, June 26, 2003 1:58 PM
> To: Wasik, Paul
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] Need Routing Help
>
>
> Hello,
>
> and what is the problem ? If your ser doesn't start anymore then your
> configuration file contains some mistake. In that case the output of ser
> tells you on what line the mistake is, for example:
>
> 0(6704) parse error (75,36-37): syntax error
> 0(6704) parse error (75,36-37): invalid route statement
> 0(6704) parse error (75,38-39):
> ERROR: bad config file (3 errors)
>
> means that there is an error on line 75 of the configuration file.
>
> Jan.
>
>
> On 26-06 13:53, Wasik, Paul wrote:
> > Hi all,
> >
> > I've got SER running on a Red Hat 9 platform. I've got MySQL and serweb
> > working and using the default ser.cfg file I can register UAs and make
> local
> > calls within the proxy. What I have not been able to do is get routing /
> > dial plan stuff to work via a Cisco SIP gateway. I cannot get SER to run
> > once I add any routing information to the ser.cfg script. I tried
> following
> > the examples like the following from the "How to" guide:
> >
> > # attempt handoff to PSTN
> > if (uri=~"^sip:9[0-9]*@mydomain.com") { ## This assumes that the caller
is
>
> > log("Forwarding to PSTN\n"); ## registered in our realm
> > t_relay_to( "192.168.0.2", "5060"); ## Our Cisco router
> > break;
> > };
> > Anyone have any ser.cfg script files that work succesfully for simple
dial
> > plan / routing to a SIP gatewat they could share? I'm having a hard time
> > with the routing.
> > Thanks,
> > Paul
> >
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> -----Original Message-----
> From: Alexander Mayrhofer [mailto:axelm@nic.at]
> Sent: Friday, June 27, 2003 6:15 PM
> To: serusers(a)lists.iptel.org
> Subject: [Serusers] rewrite & ACK forwarding problem
> ...
>
> SIP call flow looks like (record route enabled):
>
Is it applicable for you to disable record route? Then, the ACK will be
sent directly to the GW.
Klaus
I am testing Nathelper module. It works well delivering SIP messages.
However, natping-interval function seems malfunction.
The NAT scenario is simulated by a microsoft ICS. There is a Cisco ATA
behind NAT with internal address 192.168.0.2 and it's mapped to external
address 192.17.1.22. Ser is listening on external address 192.17.1.173. I
added "modparam("nathelper", "natping-interval", 5) " to the nathelper.cfg
file.
When ATA registered to Ser, I noticed 192.168.0.2:5056(UDP) is mapped to
192.17.1.22:1025(UDP). Register is successful and call could be established
between internal ATA and external ATA(one way audio). It's expected that
Ser should send a UDP packet to 192.17.1.22:1025(UDP) every 5 seconds.
However, the UDP packet is actually sent to 192.17.1.22:260(UDP). I wonder
what's the problem?
ATA-------------------->NAT------------------------>Ser
From:192.168.0.2:5060 From:192.17.1.22:1025
To: 192.17.1.173:5060 To: 192.17.1.173:5060
ATA NAT<-------------------------Ser
From: 192.17.1.173:5060
To: 192.17.1.22:260
ATA NAT-------------------------->Ser
Destination Unreachable
When does SER perform DNS lookups? Is it a matter of how the entry is
made in the ser.cfg? I ask because one of our customers changed their
DNS servers and the SER proxy was not updated. In the ser.cfg all
routing is done by IP (or I had thought it was). However, the site
started experiencing some very odd call drops and after updating the
resolv.conf on the proxy server with the proper DNS servers (one of them
had changed) everything was fine.
Should IP address entries be quoted or non-quoted? Does the presence of
the quotes cause a DNS lookup even though the item in them is purely
numeric (i.e. "162.128.33.54"). Is there a way to avoid the DNS
lookups?
--
Jamin W. Collins
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
I am trying to get SER 0.8.10 working with a VegaStream Vega 100 VoIP gateway and the SER appears to be ignoring the 200 OK message from the Vega signaling that the call has been answered on the PSTN side.
I saw a ticket to this effect in the bugs area, but the patch for that did not help.
Attached is an NGREP log from the SER machine and a SIP LOG from the VegaStream units point of view.
Everything looks good from both points of view, but there should be an Ack sent back to the Vega right after the first 200 message. The rest of the 200 messages are retrying in case the first message got lost.
Any ideas?
_______________________________________________
Sean Robertson
NETXUSA
p. 800-289-6389
f. 864-233-4344 "Ask me about Voice over IP."
http://www.netxusa.com/
I've got a couple situations I'd like to log.
One is this:
if(!(uri==myself))
{
log(1, "domain not mine $uri");
};
In the above example, I'd like to see the uri in
the log file. Another example:
if (!is_user_in("credentials","local"))
{
log(1,"NO local calls permitted for $uri");
rewriteuri("sip:addaline.com-EN_US-error.not_authorized@64.90.42.15");
t_relay();
break;
};
In this example I'd like to see who actually tried to make
a non-authorized call. Is there an printf() like log, and if
there is what variables do I have access to for printing?
---greg
Jan,
I don't see any error output on the command line. Is there a log file
somewhere? All I see is "Terminated" when attempting to start SER.
Paul
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: Thursday, June 26, 2003 1:58 PM
To: Wasik, Paul
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Need Routing Help
Hello,
and what is the problem ? If your ser doesn't start anymore then your
configuration file contains some mistake. In that case the output of ser
tells you on what line the mistake is, for example:
0(6704) parse error (75,36-37): syntax error
0(6704) parse error (75,36-37): invalid route statement
0(6704) parse error (75,38-39):
ERROR: bad config file (3 errors)
means that there is an error on line 75 of the configuration file.
Jan.
On 26-06 13:53, Wasik, Paul wrote:
> Hi all,
>
> I've got SER running on a Red Hat 9 platform. I've got MySQL and serweb
> working and using the default ser.cfg file I can register UAs and make
local
> calls within the proxy. What I have not been able to do is get routing /
> dial plan stuff to work via a Cisco SIP gateway. I cannot get SER to run
> once I add any routing information to the ser.cfg script. I tried
following
> the examples like the following from the "How to" guide:
>
> # attempt handoff to PSTN
> if (uri=~"^sip:9[0-9]*@mydomain.com") { ## This assumes that the caller is
> log("Forwarding to PSTN\n"); ## registered in our realm
> t_relay_to( "192.168.0.2", "5060"); ## Our Cisco router
> break;
> };
> Anyone have any ser.cfg script files that work succesfully for simple dial
> plan / routing to a SIP gatewat they could share? I'm having a hard time
> with the routing.
> Thanks,
> Paul
>
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
