sr-users June 2003

sr-users@lists.kamailio.org

55 participants
81 discussions

Re: [Serusers] rewrite & ACK forwarding problem
by lgfausak＠august.net 30 Apr '04

30 Apr '04

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 >

4 5

Re: [Serusers] 483 - Too many hops
by Andy Blen 04 Jul '03

04 Jul '03

(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

5 8

RE: [Serusers] Problem with fifo cmds.
by Marcelo Schmidt 01 Jul '03

01 Jul '03

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

2 1

RE: [Serusers] Problem with fifo cmds.
by Marcelo Schmidt 30 Jun '03

30 Jun '03

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/

2 1

[Serusers] PRACK
by Reinhard Hainz 30 Jun '03

30 Jun '03

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

3 6

[Serusers] Problem with fifo cmds.
by Marcelo Schmidt 30 Jun '03

30 Jun '03

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.

2 1

[Serusers] ser, pstn gateways
by Jev 27 Jun '03

27 Jun '03

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

4 4

RE: [Serusers] rewrite & ACK forwarding problem
by Marcelo Schmidt 27 Jun '03

27 Jun '03

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

1 0

[Serusers] rewrite & ACK forwarding problem
by Alexander Mayrhofer 27 Jun '03

27 Jun '03

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

3 2

RE: [Serusers] Need Routing Help
by Wasik, Paul 27 Jun '03

27 Jun '03

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]#

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users June 2003