I have also had problems with getting the ACK back.
I don't completely understand your configuration, you
must allow for packets going both directions, right?
Here is my config :
route
{
# check to see if the message has been around too long
# probably means that it is looping
#
if (!mf_process_maxfwd_header("10"))
{
log("LOG: Too many hops\n");
sl_send_reply("483","Too Many Hops");
break;
};
#
# make sure the length of the message isn't too long!
#
if (len_gt( max_len ))
{
sl_send_reply("513", "Wow -- Message too large");
break;
};
#
# do the loose-routing thing, this is important!
#
if(loose_route())
{
log(1,"doing top loose route");
t_relay();
break;
};
# this is where I was dropping the ACKS.
# I was simply dropping these, but they must be relayed
# because they can be ACKs
if(!(uri==myself))
{
if(!t_relay())
{
sl_reply_error();
break;
};
break;
};
This gets the ACKs through for me.
By the way, I have this configured with Cisco ATAs, version 2.16.
---greg
>
>I have the same problem and posed it to the group yesterday ([Serusers]
>Ignored 200 OK message.) So far the only workaround that I have found is to
>use the rules in my gateway to rewrite the dialed digits before sending them
>to the PSTN PRI, thus leaving the origianl URI intact for SIP
>communications.
>
>One person told me that this is a bug in the Cisco ATA, but it happens on my
>IPDialog phones also. It seems to me that the INVITE is being processed by
>the SER dial rules and is rewritten, but the ACK is not.
>
>Sean
>_______________________________________________
>
>Sean Robertson
>
>NETXUSA
>p. 800-289-6389
>f. 864-233-4344 "Ask me about Voice over IP."
>http://www.netxusa.com/
>
>----- Original Message -----
>From: "Alexander Mayrhofer" <axelm(a)nic.at>
>To: <serusers(a)lists.iptel.org>
>Sent: Friday, June 27, 2003 12:15 PM
>Subject: [Serusers] rewrite & ACK forwarding problem
>
>
>>
>> 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
>>
>> _______________________________________________
>> 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
>
(you forgot to CC the mailing list)
a possibility is that the contacts you registered cause a loop.
andy
At 06:22 PM 6/24/2003, Chintan Thakker wrote:
>Hi,
> Seems I missed something, I am sending INVITE to sip:9727610001@192.1.2.17 with Route: <sip:192.1.2.17;lr> to the proxy server ('ser') running on 192.1.2.17 and getting 483 - too many hops message. I modified ser.conf to add alias = "192.1.2.17" but it still gives me the same problem.
> What am I missing out ?. I guess an 'alias=192.1.2.17' entry should return a true to 'uri==myself' matching performed in the script and make the server process that request rather than forwarding it (to itself in this case)
>
>Thanks,
>Chintan
>
>-- ser.cfg --
>
> 1 #
> 2 # $Id: ser.cfg,v 1.20 2003/05/31 21:12:19 jiri Exp $
> 3 #
> 4 # simple quick-start config script
> 5 #
> 6
> 7 # ----------- global configuration parameters ------------------------
> 8
> 9 debug=3 # debug level (cmd line: -dddddddddd)
> 10 fork=yes
> 11 log_stderror=no # (cmd line: -E)
> 12
> 13 /* Uncomment these lines to enter debugging mode
> 14 debug=7
> 15 fork=no
> 16 log_stderror=yes
> 17 */
> 18
> 19 check_via=no # (cmd. line: -v)
> 20 dns=no # (cmd. line: -r)
> 21 rev_dns=no # (cmd. line: -R)
> 22 port=5060
> 23 children=4
> 24 fifo="/tmp/ser_fifo"
> 25
> 26 # ------------------ module loading ----------------------------------
> 27
> 28 # Uncomment this if you want to use SQL database
> 29 #loadmodule "/usr/local/lib/ser/modules/mysql.so"
> 30
> 31 loadmodule "/usr/local/lib/ser/modules/sl.so"
> 32 loadmodule "/usr/local/lib/ser/modules/tm.so"
> 33 loadmodule "/usr/local/lib/ser/modules/rr.so"
> 34 loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
> 35 loadmodule "/usr/local/lib/ser/modules/usrloc.so"
> 36 loadmodule "/usr/local/lib/ser/modules/registrar.so"
> 37
> 38 # Uncomment this if you want digest authentication
> 39 # mysql.so must be loaded !
> 40 #loadmodule "/usr/local/lib/ser/modules/auth.so"
> 41 #loadmodule "/usr/local/lib/ser/modules/auth_db.so"
> 42
> 43 # ----------------- setting module-specific parameters ---------------
> 44
> 45 # -- usrloc params --
> 46
> 47 modparam("usrloc", "db_mode", 0)
> 48
> 49 # Uncomment this if you want to use SQL database
> 50 # for persistent storage and comment the previous line
> 51 #modparam("usrloc", "db_mode", 2)
> 52
> 53 # -- auth params --
> 54 # Uncomment if you are using auth module
> 55 #
> 56 #modparam("auth_db", "calculate_ha1", yes)
> 57 #
> 58 # If you set "calculate_ha1" parameter to yes (which true in this config),
> 59 # uncomment also the following parameter)
> 60 #
> 61 #modparam("auth_db", "password_column", "password")
> 62
> 63 # ------------------------- request routing logic -------------------
> 64
> 65 #add aliases
> 66 alias="192.1.2.17"
> 67
> 68 # main routing logic
> 69
> 70 route{
> 71
> 72 # initial sanity checks -- messages with
> 73 # max_forwards==0, or excessively long requests
> 74 if (!mf_process_maxfwd_header("10")) {
> 75 sl_send_reply("483","Too Many Hops");
> 76 break;
> 77 };
> 78 if (len_gt( max_len )) {
> 79 sl_send_reply("513", "Message too big");
> 80 break;
> 81 };
> 82
> 83 # we record-route all messages -- to make sure that
> 84 # subsequent messages will go through our proxy; that's
> 85 # particularly good if upstream and downstream entities
> 86 # use different transport protocol
> 87 record_route();
> 88 # loose-route processing
> 89 if (loose_route()) {
> 90 t_relay();
> 91 break;
> 92 };
> 93
> 94 # if the request is for other domain use UsrLoc
> 95 # (in case, it does not work, use the following command
> 96 # with proper names and addresses in it)
> 97 if (uri==myself) {
> 98
> 99 if (method=="REGISTER") {
> 100
> 101 # Uncomment this if you want to use digest authentication
> 102 # if (!www_authorize("iptel.org", "subscriber")) {
> 103 # www_challenge("iptel.org", "0");
>
>53,1 65%
> 104 # break;
> 105 # };
> 106
> 107 save("location");
> 108 break;
> 109 };
> 110
> 111 # native SIP destinations are handled using our USRLOC DB
> 112 if (!lookup("location")) {
> 113 sl_send_reply("404", "Not Found");
> 114 break;
> 115 };
> 116 };
> 117 #Let tje server [rpcess tje cirremt reqiest
> 118 #if(uri =~ "^sip:(.+@)?(192\.1\.2\.17)([:;\?].*)?$" )
> 119 #{
> 120 # break;
> 121 #};
> 122
> 123 # forward to current uri now; use stateful forwarding; that
> 124 # works reliably even if we forward from TCP to UDP
> 125 if (!t_relay()) {
> 126 sl_reply_error();
> 127 };
> 128
> 129 }
> 130
>- end ser.cfg --
>Andy Blen wrote:
>
>>most likely a misconfig issue on your side, feel free to read the doc, http://www.iptel.org/ser/doc/prerelease/x1026.html#AEN1032
>>
>>andy
>>
>>At 12:18 AM 6/21/2003, Chintan Thakker wrote:
>>
>>
>>>Hi,
>>>Consider the following scenario. UA1 is trying to call UA2 both registered with the same proxy. (UA1 -> 'ser' -> UA2)
>>>
>>>1.
>>>UA1 sends INVITE to the proxy with request uri set to UA2. It also sets the Route header in the invite to that of the proxy.
>>>This returns a 483 - too many hops to UA1
>>>
>>>It seems that in the above mentioned scenario, the proxy loops back the INVITE multiple times locally. This decrements the Max Forwards value every time until it becomes zero and hence sends 483 back to UA1. It seems to me this is not the correct behavior of the server. It should forward the request to UA2.
>>>
>>>Thanks in advance,
>>>
>>>Chintan
>>>
>>>-- Start trace --
>>>
>>>U 2003/06/20 15:24:42.362466 192.1.2.88:5060 -> 192.1.2.17:5060
>>>INVITE sip:9727610001@192.1.2.17 SIP/2.0.Via: SIP/2.0/UDP 192.1.2.88:5060;b
>>>ranch=z9hG4bK421668676.Max-Forwards: 70.From: 9727619271 <sip:9727619271@19
>>>2.1.2.88>;tag=421668676.To: 9727610001 <sip:9727610001@192.1.2.17>.Call-ID:
>>>421668676(a)192.1.2.88.CSeq: 1 INVITE.Contact: <sip:9727619271@192.1.2.88>.C
>>>ontent-Type: application/sdp.Content-Length: 138.Route: <sip:192.1.2.17;lr>
>>>..v=0.o=username 421668676 421668676 IN IP4 192.1.2.88.s=Session SDP.c=IN I
>>>P4 192.1.2.88.t=0 0.m=audio 54454 RTP/AVP 0.a=rtpmap:0 PCMU/8000.
>>>
>>>U 2003/06/20 15:24:42.363813 192.1.2.17:5060 -> 192.1.2.88:5060
>>>SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 192.1.
>>>2.88:5060;branch=z9hG4bK421668676..From: 9727619271 <sip:9727619271@192.1.2
>>>.88>;tag=421668676.To: 9727610001 <sip:9727610001@192.1.2.17>.Call-ID: 4216
>>>68676(a)192.1.2.88.CSeq: 1 INVITE.Server: Sip EXpress router (0.8.11pre29 (i3
>>>86/linux))..Content-Length: 0..Warning: 392 192.1.2.17:5060 "Noisy feedback
>>>tells: pid=15107 req_src_ip=192.1.2.88 req_src_port=5060 in_uri=sip:97276
>>>10001(a)192.1.2.17 out_uri=sip:9727610001@192.1.2.17 via_cnt==1"....
>>>#
>>>U 2003/06/20 15:24:42.794681 192.1.2.17:5060 -> 192.1.2.88:5060
>>>SIP/2.0 483 Too Many Hops..Via: SIP/2.0/UDP 192.1.2.88:5060;branch=z9hG4bK4
>>>21668676..From: 9727619271 <sip:9727619271@192.1.2.88>;tag=421668676.To: 97
>>>27610001 <sip:9727610001@192.1.2.17>;tag=b27e1a1d33761e85846fc98f5f3a7e58.4
>>>632.Call-ID: 421668676(a)192.1.2.88.CSeq: 1 INVITE.Server: Sip EXpress router
>>>(0.8.11pre29 (i386/linux))..Content-Length: 0..Warning: 392 192.1.2.17:506
>>>0 "Noisy feedback tells: pid=15107 req_src_ip=192.1.2.17 req_src_port=5060
>>>in_uri=sip:9727610001@192.1.2.17 out_uri=sip:9727610001@192.1.2.17 via_cnt
>>>==71"....
>>>
>>>-- End trace --
>>>
>>>ps: We checked it with loose routing(suceeding ';lr' present in URIs in Route) as well as strict routing(suceeding ';lr' not present in URIs in Route). Should the type of routing used matter ?
>>>
>>>_______________________________________________
>>>Serusers mailing list
>>>serusers(a)lists.iptel.org
>>>http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>
>>--
>>Andy Blen
>>iptel.org Services
>>
>
>
--
Andy Blen
iptel.org Services
Actually it happened to be a build error:
SunOS www-test101 5.8 Generic_108528-20 sun4u sparc SUNW,Ultra-5_10
cd utils/gen_ha1; /usr/local/bin/make all
make[1]: Entering directory
`/export/home/mschmidt/build-dir/sip_router/utils/gen_ha1'
gcc -o gen_ha1 gen_ha1.o calc.o ../../md5.o
../../md5.o: In function `MD5Init':
/export/home/mschmidt/build-dir/sip_router/md5.c:113: undefined
reference to `_mcount'
../../md5.o: In function `MD5Update':
/export/home/mschmidt/build-dir/sip_router/md5.c:131: undefined
reference to `_mcount'
../../md5.o: In function `MD5Final':
/export/home/mschmidt/build-dir/sip_router/md5.c:173: undefined
reference to `_mcount'
../../md5.o: In function `MD5Transform':
/export/home/mschmidt/build-dir/sip_router/md5.c:202: undefined
reference to `_mcount'
../../md5.o: In function `Encode':
/export/home/mschmidt/build-dir/sip_router/md5.c:296: undefined
reference to `_mcount'
../../md5.o:/export/home/mschmidt/build-dir/sip_router/md5.c:314: more
undefined references to `_mcount' follow
collect2: ld returned 1 exit status
make[1]: *** [gen_ha1] Error 1
make[1]: Leaving directory
`/export/home/mschmidt/build-dir/sip_router/utils/gen_ha1'
make: *** [utils/gen_ha1/gen_ha1] Error 2
> make --version
GNU Make 3.80
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
> ld --version
GNU ld 2.11.2
Copyright 2001 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License. This program has absolutely no
warranty.
Supported emulations:
elf32_sparc
elf64_sparc
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Monday, June 30, 2003 2:35 PM
To: Marcelo Schmidt; serusers(a)lists.iptel.org
Subject: RE: [Serusers] Problem with fifo cmds.
At 11:29 PM 6/30/2003, Marcelo Schmidt wrote:
>This 8.11 version it doesn't run in solaris at all.
Can you be please more specific?
Thank you,
-jiri
>I am running out of
>time here so I guess I will move to Linux... what Linux (kernel) you're
>using with 8.10/8.11?
jiri@fox:~$ uname -a
Linux fox 2.4.20-xfs #1 SMP Fri Mar 28 17:04:13 CET 2003 i686 GNU/Linux
This 8.11 version it doesn't run in solaris at all. I am running out of
time here so I guess I will move to Linux... what Linux (kernel) you're
using with 8.10/8.11?
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Monday, June 30, 2003 12:57 PM
To: Marcelo Schmidt; serusers(a)lists.iptel.org
Subject: Re: [Serusers] Problem with fifo cmds.
serctl had many solaris portability shortcomings which are (hopefuly)
fixed in 8.11 -- I recommend you to upgrade to the latest CVS version
(stable branch)
-- see www.iptel.org/ser/cvs.
-Jiri
At 09:49 PM 6/30/2003, Marcelo Schmidt wrote:
>SunOS www-test101 5.8 Generic_108528-20 sun4u sparc SUNW,Ultra-5_10
>
>version: ser 0.8.10 (sparc/solaris)
>flags: STATS:Off, USE_IPV6, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
>DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024,
>MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE
>3040
>@(#) $Id: main.c,v 1.126 2002/11/11 22:36:41 andrei Exp $ main.c
>compiled on 11:22:18 Jun 30 2003 with gcc 3.2
>
>When I do: serctl ps (or any other but moni)
>
>41(15163) ERROR: fifo_server: command must begin with :: -e
>:ps:ser_receiver_15183
>41(15163) INFO: fifo_server: command empty
>
>Thanks,
>Marcelo.
>
>_______________________________________________
>Serusers mailing list
>serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
Hi,
is ser supporting the SIP Request PRACK ? I get this Requests when i am
forwarding an incoming call from a cisco router back to it (with an
other number) --> the destination telephone rings but i do not hear the
signals (ringing) on my calling phone. When the called phone accepts the
call then everything works fine.
In more detail:
The cisco router sends 2 PRACK Requests:
1. to the phone that is the destination of the forward (after
forwarding)
2. to the phone with the forwarding set
But not to the phone which initialises the call.
Regards,
Reinhard
Hello all,
Im using ser, with esteras softphone, and a couple of cisco ata186's. I
have to say I really like ser, as it is small fast, and reliable without
being over complicated.
I would like to know what other ser users and developers use for pstn
gateways? I have a openline4 card from voictronix, but there is no
software support for sip (When I bought it I thought I would use h.323).
I have looked at cisco's pstn gateway modules, but was turned off them
because of price, and lack of clear straight forward information to name
but two reasons.
Ideally what I would like to have is a solution that would support at
least 4 pstn lines (expandable to maybe 8), that would run on FreeBSD
(or at worst linux), works well with sip & ser, with high quality audio,
and minimal delays when dialing in out.
TIA,
-Emil
We know that, we just want you to start guessing harder :)
-----Original Message-----
From: Jiri Kuthan [mailto:jiri@iptel.org]
Sent: Friday, June 27, 2003 1:46 PM
To: Sean P. Robertson; Alexander Mayrhofer; serusers(a)lists.iptel.org
Subject: Re: [Serusers] rewrite & ACK forwarding problem
Gentlemen,
the answer is always the same -- send us message dumps and configuration
files. Misconfiguration hunting is hard to impossible otherwise.
-Jiri
ps -- I don't think this is related to ATA, there were some other
problems with it. I think it is an error in SER configuration.
At 06:39 PM 6/27/2003, Sean P. Robertson wrote:
>I have the same problem and posed it to the group yesterday ([Serusers]
>Ignored 200 OK message.) So far the only workaround that I have found
>is to use the rules in my gateway to rewrite the dialed digits before
>sending them to the PSTN PRI, thus leaving the origianl URI intact for
>SIP communications.
>
>One person told me that this is a bug in the Cisco ATA, but it happens
>on my IPDialog phones also. It seems to me that the INVITE is being
>processed by the SER dial rules and is rewritten, but the ACK is not.
>
>Sean
>_______________________________________________
>
>Sean Robertson
>
>NETXUSA
>p. 800-289-6389
>f. 864-233-4344 "Ask me about Voice over IP."
>http://www.netxusa.com/
>
>----- Original Message -----
>From: "Alexander Mayrhofer" <axelm(a)nic.at>
>To: <serusers(a)lists.iptel.org>
>Sent: Friday, June 27, 2003 12:15 PM
>Subject: [Serusers] rewrite & ACK forwarding problem
>
>
>>
>> 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
>>
>> _______________________________________________
>> 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
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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]#
