sr-users

sr-users@lists.kamailio.org

52 participants
37559 discussions

[Serusers] Simple methods
by Anuradha Kalyan 11 Feb '03

11 Feb '03

hello, we are using ser 0.8.10. it worked fine with SIP methods. we would like to know whether we can use the ser to test the simple methods (simple, subscribe and notify methods) with thanks and regards, Anuradha -- ************************************************************** eRiva provides IT Solutions & Services to companies worldwide. Our State of the Art Research & Development Center provides Innovative Solutions to global customers. eRiva's unique value proposition is further delivered through our Offshore Outsourcing Model and stringent Quality Processes of SEI / ISO and Six Sigma. [www.erivasystems.com] ************************************************************** --

2 1

[Serusers] Bug in new_hash2() function [patch]
by Maxim Sobolev 09 Feb '03

09 Feb '03

Folks, There is a bug in ser, which results in different hashes to be generated if some of the fields participating in hash generation has extra spaces before value in reply that were not present in request, i.e.: request: From: <vasia_pupkin(a)1.2.3.4> reply: From: <vasia_pupkin(a)1.2.3.4> This leads to matching failure and as a result causes useless retransmition, if tm module is used. For example, Vovida's SIP stack is found to be guilty in inserting extra spaces into reply's headers (which isn't really prohibited by the RFC). Attached little patch should fix the problem. It would be nice to have it integrated into the next release. Thanks! -Maxim

3 3

[Serusers] SER and SIP-CGI
by Stephan Reiff-Marganiec 07 Feb '03

07 Feb '03

Hi, I was wondering whether there is a ser module for SIP-CGI. Or whether there are attempts at creating one? If so, could anyone point me in the right direction? thanks, Stephan -- Dr Stephan Reiff-Marganiec Research Fellow Department of Computing Science; University of Stirling email: srm(a)cs.stir.ac.uk tel: 01786 46 7448 -- The University of Stirling is a university established in Scotland by charter at Stirling, FK9 4LA. Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not disclose, copy or deliver this message to anyone and any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of the University of Stirling shall be understood as neither given nor endorsed by it.

2 1

[Serusers] core when running the rad_acc module
by Claudio Thorell dos Santos 07 Feb '03

07 Feb '03

Hello, I'm trying to setup the radius accounting module but SER craches wherever I make a call. The call does complete, but the core is generated a couple seconds later. Without rad_acc moudule SER works fine, so I assume this have something to do with the module. I'm attaching some resumed debugs for the crash. I also have the complete debug (log level 10), wich is quite big so I decided not so send it to the list unless the following debugs are not enough. Any ideas on what's the problem? Thanks and regards, Claudio Thorell ########### ... 6(24956) qm_free(0x80adf80, 0x80b5174), called from parser/msg_parser.c: free_sip_msg(487) 6(24956) qm_free: freeing block alloc'ed from action.c: do_action(346) 6(24956) qm_free(0x80adf80, 0x80b5090), called from parser/parse_via.c: free_via_param_list(1816) 6(24956) qm_free: freeing block alloc'ed from parser/parse_via.c: parse_via(1642) 6(24956) qm_free(0x80adf80, 0x80b52ec), called from parser/parse_via.c: free_via_list(1828) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: get_hdr_field(85) 6(24956) qm_free(0x80adf80, 0x80b5128), called from parser/hf.c: free_hdr_field_lst(103) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229) 6(24956) qm_free(0x80adf80, 0x80b4ff0), called from parser/hf.c: free_hdr_field_lst(103) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229) 6(24956) qm_free(0x80adf80, 0x80b4fa4), called from parser/hf.c: free_hdr_field_lst(103) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229) 6(24956) qm_free(0x80adf80, 0x80b46cc), called from parser/parse_to.c: free_to(741) 6(24956) qm_free: freeing block alloc'ed from parser/parse_to.c: parse_to_param(265) 6(24956) qm_free(0x80adf80, 0x80b482c), called from parser/parse_to.c: free_to(744) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: get_hdr_field(123) 6(24956) qm_free(0x80adf80, 0x80b479c), called from parser/hf.c: free_hdr_field_lst(103) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229) 6(24956) qm_free(0x80adf80, 0x80b51dc), called from parser/hf.c: free_hdr_field_lst(103) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229) 6(24956) qm_free(0x80adf80, 0x80b47e8), called from parser/parse_cseq.c: free_cseq(94) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: get_hdr_field(104) 6(24956) qm_free(0x80adf80, 0x80b5228), called from parser/hf.c: free_hdr_field_lst(103) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229) 6(24956) qm_free(0x80adf80, 0x80b4f58), called from parser/hf.c: free_hdr_field_lst(103) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229) 6(24956) qm_free(0x80adf80, 0x80b50dc), called from parser/hf.c: free_hdr_field_lst(103) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229) 6(24956) qm_free(0x80adf80, 0x80b4c70), called from parser/hf.c: free_hdr_field_lst(103) 6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229) 6(24956) qm_free(0x80adf80, 0x80b4d08), called from data_lump.c: free_lump_list(248) 6(24956) qm_free: freeing block alloc'ed from data_lump.c: del_lump(153) 6(24956) qm_free(0x80adf80, 0x80b475c), called from data_lump.c: free_lump(212) 6(24956) qm_free: freeing block alloc'ed from textops.c: append_hf(231) 6(24956) qm_free(0x80adf80, 0x80b4418), called from data_lump.c: free_lump_list(237) 6(24956) qm_free: freeing block alloc'ed from data_lump.c: insert_new_lump_before(129) 6(24956) qm_free(0x80adf80, 0x80b4cbc), called from data_lump.c: free_lump_list(248) 6(24956) qm_free: freeing block alloc'ed from data_lump.c: anchor_lump(183) 6(24956) qm_free(0x80adf80, 0x80b54bc), called from parser/msg_parser.c: free_sip_msg(493) 6(24956) qm_free: freeing block alloc'ed from receive.c: receive_msg(83) 6(24956) qm_free(0x80adf80, 0x80b4adc), called from receive.c: receive_msg(177) 6(24956) qm_free: freeing block alloc'ed from receive.c: receive_msg(63) 6(24956) qm_malloc(0x80adf80, 356) called from receive.c: receive_msg(63) 6(24956) qm_malloc(0x80adf80, 356) returns address 0x80b4adc on 0 -th hit 6(24956) qm_malloc(0x80adf80, 415) called from receive.c: receive_msg(83) 6(24956) qm_malloc(0x80adf80, 416) returns address 0x80b54bc on 0 -th hit 6(24956) SIP Request: 6(24956) method: <ACK> 6(24956) uri: <sip:1005@200.219.173.141;branch=0> 6(24956) version: <SIP/2.0> 6(24956) parse_headers: flags=1 6(24956) qm_malloc(0x80adf80, 28) called from parser/msg_parser.c: parse_headers(229) 6(24956) qm_malloc(0x80adf80, 28) returns address 0x80b4cbc on 0 -th hit 6(24956) qm_malloc(0x80adf80, 104) called from parser/msg_parser.c: get_hdr_field(85) 6(24956) qm_malloc(0x80adf80, 104) returns address 0x80b52ec on 0 -th hit 0(24946) child process 24961 exited by a signal 11 0(24946) core was generated 0(24946) INFO: terminating due to SIGCHLD 4(24954) Memory status (pkg): 4(24954) qm_status (0x80adf80): 4(24954) heap size= 1022872 4(24954) used= 1040, used+overhead=27272, free=995600 4(24954) max used (+overhead)= 27340 4(24954) dumping all allocked. fragments: ...

1 0

Re: [Serusers] How to configure Serweb
by Jiri Kuthan 06 Feb '03

06 Feb '03

Dan Austin's howto (see SER webpage) is probably the currently most extensive documentation available. -Jiri At 05:16 PM 2/6/2003, Jerry Yin wrote: >Hi All, > >Can somebody tell me how to configure the serweb? Which directory should I >put those files and which file and parameters should I modify. Or maybe this >question was asked previously by somebody already, then please provide me a >like to those answers. > >Thanks, > >Jerry Yin >Mitel Networks. >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers -- Jiri Kuthan http://iptel.org/~jiri/

1 0

[Serusers] How to configure Serweb
by Jerry Yin 06 Feb '03

06 Feb '03

Hi All, Can somebody tell me how to configure the serweb? Which directory should I put those files and which file and parameters should I modify. Or maybe this question was asked previously by somebody already, then please provide me a like to those answers. Thanks, Jerry Yin Mitel Networks.

1 0

RE: [Serusers] ser crashes
by Klaus Darilion 06 Feb '03

06 Feb '03

Hi! I'm really very sorry that I have wasted your time - I've made a really stupid mistake. Now I fixed the proper line (103) and everything works fine. No messages in the log file, no crashes. Thanks a lot! Klaus > -----Original Message----- > From: Jan Janak [mailto:J.Janak@sh.cvut.cz] > Sent: Thursday, February 06, 2003 4:45 PM > To: Klaus Darilion > Cc: serusers(a)lists.iptel.org > Subject: Re: [Serusers] ser crashes > > > On 06-02 16:25, Klaus Darilion wrote: > > My experience is the following: > > > > Line 109 in t_msgbuilder.c: > > > > len += USER_AGENT_LEN + CRLF_LEN; > > ==> ser crashes when I send the special invite! > > > > *len += USER_AGENT_LEN + CRLF_LEN; > > ==> ser doesn't crash but logs this in /val/log/messages: > > Feb 6 15:48:24 obelix /usr/local/sbin/ser[6985]: ERROR: > > t_build_and_send_CANCEL: cannot allocate memory > > > > > > hope my explanation is a little bit clearer now: > > i also downloaded > > ftp://ftp.berlios.de/pub/ser/0.8.10/src/ser-0.8.10_src.tar.gz > > and this tarball contains: *len += USER_AGENT_LEN + CRLF_LEN; > > > > That's another line, look at line 103: > > len+=((hdr->body.s+hdr->body.len ) - hdr->name.s ) + > CRLF_LEN; > > This should be changed to: > > *len+=((hdr->body.s+hdr->body.len ) - hdr->name.s ) + > CRLF_LEN; > > regards, Jan. > >

1 0

RE: [Serusers] ser crashes
by Klaus Darilion 06 Feb '03

06 Feb '03

My experience is the following: Line 109 in t_msgbuilder.c: len += USER_AGENT_LEN + CRLF_LEN; ==> ser crashes when I send the special invite! *len += USER_AGENT_LEN + CRLF_LEN; ==> ser doesn't crash but logs this in /val/log/messages: Feb 6 15:48:24 obelix /usr/local/sbin/ser[6985]: ERROR: t_build_and_send_CANCEL: cannot allocate memory hope my explanation is a little bit clearer now: i also downloaded ftp://ftp.berlios.de/pub/ser/0.8.10/src/ser-0.8.10_src.tar.gz and this tarball contains: *len += USER_AGENT_LEN + CRLF_LEN; regards, klaus > -----Original Message----- > From: Jan Janak [mailto:J.Janak@sh.cvut.cz] > Sent: Thursday, February 06, 2003 4:19 PM > To: Klaus Darilion > Cc: serusers(a)lists.iptel.org > Subject: Re: [Serusers] ser crashes > > > Hello, > > On 06-02 16:02, Klaus Darilion wrote: > > Thank you, the path to the modules was the problem! > > > > Now ser runs also as self compiled version and doesnt > crash. I didn't > > had to change the source because the source code available > to download > > is already corrected. To proof your guess I inserted the > error again ( > > len+=) and than it crashes again. > > ser-0.8.10_src.tar.gz has this bug too. > > > Conclusion: with the source code version from 0.8.10 ser > doesn't crash > > anymore. Nevertheless, /var/log/messages shows an error > message when I > > send my special invite: > > > > Feb 6 15:48:24 obelix /usr/local/sbin/ser[6985]: ERROR: > > t_build_and_send_CANCEL: cannot allocate memory > > That's the bug I told you about, AFAIK it is caused by the missing > dereference operator in t_msgbuilder.c. See my previous email for > description how to fix it. (rewrite len+= to *len+=, recompile and > reinstall). > > regards, Jan. > >

2 1

RE: [Serusers] ser crashes
by Klaus Darilion 06 Feb '03

06 Feb '03

Thank you, the path to the modules was the problem! Now ser runs also as self compiled version and doesnt crash. I didn't had to change the source because the source code available to download is already corrected. To proof your guess I inserted the error again ( len+=) and than it crashes again. Conclusion: with the source code version from 0.8.10 ser doesn't crash anymore. Nevertheless, /var/log/messages shows an error message when I send my special invite: Feb 6 15:48:24 obelix /usr/local/sbin/ser[6985]: ERROR: t_build_and_send_CANCEL: cannot allocate memory thanks and regards, Klaus > -----Original Message----- > From: Jan Janak [mailto:J.Janak@sh.cvut.cz] > Sent: Thursday, February 06, 2003 3:36 PM > To: Klaus Darilion > Cc: serusers(a)lists.iptel.org > Subject: Re: [Serusers] ser crashes > > > Double check path of the modules. Probably you are using > config file from the rpm package, after make install the > modules will be in /usr/local/lib/ser/modules. The rpm > package installs them in /usr/lib/ser/modules so you will > have to change it. > > There is no uninstall in the makefiles, you can uninstall > only by hand right now. > > regards, Jan. > > On 06-02 15:19, Klaus Darilion wrote: > > Hello! > > > > I have problems running the self compiled ser version (without any > > sourcecode changes). > > > > I uninstalled the rpms ("rpm -e ser-mysql" and "rpm -e ser" - I use > > the mysql authentication). Then I compiled ser with "make > all" without > > errors. I installed ser with "make install". Then I tried > to start ser > > with: > > # /usr/local/sbin/ser -f /etc/ser/ser.cfg > > ERROR: bad config file (25 errors) > > > > Why does my config file doesn't work anymore (it worked > with the rpm > > version)? When I start ser with -f, than it starts (but than it > > doesn't use the mysql database). > > > > Have I done something wrong during the installation/compiling? > > > > How can I delete the files that were installed by "make > install"? make > > uninstall? > > > > regards, > > klaus > > > > > -----Original Message----- > > > From: Jan Janak [mailto:J.Janak@sh.cvut.cz] > > > Sent: Thursday, February 06, 2003 12:12 AM > > > To: Klaus Darilion > > > Cc: serusers(a)lists.iptel.org > > > Subject: Re: [Serusers] ser crashes > > > > > > > > > Hello, > > > > > > I wasn't able to reproduce it, but I think I know where the > > > problem is. There is a bug in 0.8.10 which shows up when an > > > INVITE contains Route header field. The bug has been fixed > > > in the CVS already. > > > > > > If you can compile ser from sources, you can easily fix > it in your > > > release: > > > > > > 1) Edit ser-0.8.10/modules/tm/t_msgbuilder.c > > > 2) Jump to line 103 > > > 3) replace len+= with *len+= > > > 4) Recompile ser > > > > > > I can send you a patch if it is more convinient for you. > > > > > > regards, Jan. > > > > > > On 05-02 12:13, Klaus Darilion wrote: > > > > Hello! > > > > > > > > During playing around with route headers I discovered that > > > ser crashes > > > > reproduceable when I send the following request to it with > > > sipsak, I > > > > think the invite is a valid request with strict routing. > > > > > > > > sipsak.exe -f invite3.txt -s sip:obelix.ict.tuwien.ac.at -vvv > > > > > > > > invite3.txt: > > > > INVITE sip:obelix.ict.tuwien.ac.at SIP/2.0 > > > > Via: SIP/2.0/UDP 128.131.80.191:5070;branch=z9hG4bK2024693217 > > > > Route: <sip:iptel.org> > > > > Route: <sip:klaus3000@klausix.ict.tuwien.ac.at> > > > > From: <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618 > > > > To: <sip:klaus3000@iptel.org> > > > > Call-ID: 744056460(a)128.131.80.191 > > > > CSeq: 20 INVITE > > > > Contact: <sip:brutus@128.131.80.191:5070> > > > > max-forwards: 10 > > > > user-agent: oSIP/Linphone-0.9.1 > > > > Content-Type: application/sdp > > > > Content-Length: 335 > > > > > > > > .. > > > > sdp > > > > .. > > > > > > > > > > > > then ser stops to respond: > > > > > > > > >[root@obelix darilion]# /etc/init.d/ser status > > > > >ser dead but subsys locked > > > > > > > > and in /var/log/messages > > > > Feb 5 11:57:21 obelix ser: Listening on > > > > Feb 5 11:57:21 obelix ser: 128.131.80.136 > > > > [128.131.80.136]::5060 > > > > Feb 5 11:57:21 obelix ser: Aliases: > obelix.ict.tuwien.ac.at:5060 > > > > Feb 5 11:57:21 obelix ser: ser startup succeeded Feb > 5 11:57:21 > > > > obelix /usr/sbin/ser[21426]: mod_init(): Database connection > > > > opened successfuly Feb 5 11:57:21 obelix /usr/sbin/ser[21426]: > > > > INFO: > > > udp_init: SO_RCVBUF > > > > is initially 65535 > > > > Feb 5 11:57:21 obelix /usr/sbin/ser[21426]: INFO: > > > udp_init: SO_RCVBUF > > > > is finally 131070 > > > > Feb 5 11:57:21 obelix /usr/sbin/ser[21432]: INFO: fifo process > > > > starting: 21432 > > > > Feb 5 11:57:21 obelix /usr/sbin/ser[21432]: SER: > > > open_uac_fifo: fifo > > > > server up at /tmp/ser_fifo... > > > > > > > > ..up to here everything works fine, than I send the request: > > > > > > > > Feb 5 11:57:30 obelix /usr/sbin/ser[21428]: BUG: qm_*: fragm. > > > > 0x422b9ad0 end overwritten(35322e64, 39306665)! Feb 5 > > > 11:57:30 obelix > > > > /usr/sbin/ser[21426]: child process 21428 exited by a signal 11 > > > > Feb 5 11:57:30 obelix /usr/sbin/ser[21426]: core was not > > > > generated Feb 5 11:57:30 obelix /usr/sbin/ser[21426]: INFO: > > > terminating due to > > > > SIGCHLD > > > > > > > > Here is the ngrep output: > > > > > > > > U 128.131.80.101:1558 -> 128.131.80.136:5060 > > > > INVITE sip:obelix.ict.tuwien.ac.at SIP/2.0..Via: SIP/2.0/UDP > > > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP > > > > 128.131.80.191:5070;branch=z9hG4bK2024693217..Route: <sip:iptel. > > > > org>..Route: <sip:klaus3000@klausix.ict.tuwien.ac.at>..From: > > > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > > > <sip:klaus3000@iptel.org>..Call-ID: 744056460(a)128.131.80 > > > > .191..CSeq: 20 INVITE..Contact: > > > > <sip:brutus@128.131.80.191:5070>..max-forwards: 10..user-agent: > > > > oSIP/Linphone-0.9.1..Content-Type: > > > > application/sdp..Content-Length: > > > > 335 .... > > > > v=0..o=brutus 123456 654321 IN IP4 128.131.80.191..s=A > > > > c..onversation..c=IN IP4 128.131.80.191..t=0 0..m=audio > > > 7078 RTP/AVP 3 > > > > 115 8 110 111 101..a=rtpmap:3 gsm/8000/1..a=rtp > > > > map:115 lpc10-1.5/8000/1..a=rtpmap:8 PCMA/8000/1..a=rtpmap:110 > > > > speex-4/8000/1..a=rtpmap:111 speex_lbr-4/8000/1..a=rtpmap:101 > > > > telephone-event/8000..a=fmtp:101 0-11.. > > > > # > > > > U 128.131.80.136:5060 -> 128.131.80.101:1557 > > > > SIP/2.0 100 trying -- your call is important to us..Via: > > > SIP/2.0/UDP > > > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP > > > > 128.131.80.191:5070;branch=z9hG4bK2024693217..From: <sip > > > > :brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > > > <sip:klaus3000@iptel.org>..Call-ID: > > > 744056460@128.131.80.191..CSeq: 20 > > > > INVITE..Server: Sip EXpress router (0.8.10 (i386/l > > > > inux))..Content-Length: 0..Warning: 392 > > > 128.131.80.136:5060 "Noisy > > > > feedback tells: pid=21552 req_src_ip=128.131.80.101 > > > > in_uri=sip:obelix.ict.tuwien.ac.at out_uri=sip:iptel.o > > > > rg via_cnt==2".... > > > > > > > > # > > > > U 128.131.80.136:5060 -> 195.37.77.101:5060 > > > > INVITE sip:iptel.org SIP/2.0..Via: SIP/2.0/UDP > > > > 128.131.80.136;branch=z9hG4bK3a6d.25ef09d1.0..Via: SIP/2.0/UDP > > > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP 128.131.80.191: > > > > 5070;branch=z9hG4bK2024693217..Route: > > > > <sip:klaus3000@klausix.ict.tuwien.ac.at>..From: > > > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > > > <sip:klaus3000@iptel.org>..Call > > > > -ID: 744056460@128.131.80.191..CSeq: 20 INVITE..Contact: > > > > <sip:brutus@128.131.80.191:5070>..max-forwards: 9 ..user-agent: > > > > oSIP/Linphone-0.9.1..Content-Type: application/sdp.. > > > > Content-Length: 335 ....v=0..o=brutus 123456 654321 IN IP4 > > > > 128.131.80.191..s=A c..onversation..c=IN IP4 > 128.131.80.191..t=0 > > > > 0..m=audio 7078 RTP/AVP 3 115 8 110 111 101..a=r > > > > tpmap:3 gsm/8000/1..a=rtpmap:115 lpc10-1.5/8000/1..a=rtpmap:8 > > > > PCMA/8000/1..a=rtpmap:110 speex-4/8000/1..a=rtpmap:111 > > > > speex_lbr-4/8000/1..a=rtpmap:101 telephone-event/8000..a > > > > =fmtp:101 0-11.. > > > > > > > > # > > > > U 195.37.77.101:5060 -> 128.131.80.136:5060 > > > > SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP > > > > 128.131.80.136;branch=z9hG4bK3a6d.25ef09d1.0..Via: SIP/2.0/UDP > > > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP 12 > > > > 8.131.80.191:5070;branch=z9hG4bK2024693217..From: > > > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > > > > <sip:klaus3000@iptel.org>;tag=fb86ad2694115d75c77dce61523c9f07.3f3c > > > > ..Call-ID: 744056460@128.131.80.191..CSeq: 20 > > > > INVITE..Proxy-Authenticate: Digest realm="iptel.org", > > > > nonce="3e40f29900000000d6e1790446755f1b4b96f5f5bd97b283", > > > > algorithm=MD5.. > > > > Server: Sip EXpress router (0.8.9 > (i386/linux))..Content-Length: > > > > 0..Warning: 392 195.37.77.101:5060 "Noisy feedback > tells: pid=7651 > > > > req_src_ip=128.131.80.136 in_uri=sip:ipte > > > > l.org out_uri=sip:klaus3000@klausix.ict.tuwien.ac.at > > > via_cnt==3".... > > > > > > > > # > > > > U 128.131.80.136:5060 -> 128.131.80.101:1557 > > > > SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP > > > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP > > > > 128.131.80.191:5070;branch=z9hG4bK2024693217..From: > <sip:brutus@o > > > > belix.ict.tuwien.ac.at>;tag=262992618..To: > > > > > > > > <sip:klaus3000@iptel.org>;tag=fb86ad2694115d75c77dce61523c9f07.3f3c. > > > .C > > > > al > > > > l-ID: 744056460@128.131.80.191..CSeq: 20 INVITE..Proxy-Aut > > > > henticate: Digest realm="iptel.org", > > > > nonce="3e40f29900000000d6e1790446755f1b4b96f5f5bd97b283", > > > > algorithm=MD5..Server: Sip EXpress router (0.8.9 > > > > (i386/linux))..Content-Length > > > > : 0..Warning: 392 195.37.77.101:5060 "Noisy feedback > > > tells: pid=7651 > > > > req_src_ip=128.131.80.136 in_uri=sip:iptel.org > > > > out_uri=sip:klaus3000@klausix.ict.tuwien.ac.at via_cnt==3 > > > > ".... > > > > > > > > # > > > > U 128.131.80.136:5060 -> 195.37.77.101:5060 > > > > ACK sip:iptel.org SIP/2.0..Via: SIP/2.0/UDP > > > > 128.131.80.136;branch=z9hG4bK3a6d.25ef09d1.0..From: > > > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..Call-ID: > > > > 744056460(a)128.13 > > > > 1.80.191..To: > > > > > > > <sip:klaus3000@iptel.org>;tag=fb86ad2694115d75c77dce61523c9f07 > > > .3f3c..CSe > > > > q: 20 ACK.. > > > > > > > > > > > > > > > > If you need more details please let me know. > > > > > > > > regards, > > > > Klaus > > > > _______________________________________________ > > > > Serusers mailing list > > > > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > >

2 1

RE: [Serusers] ser crashes
by Klaus Darilion 06 Feb '03

06 Feb '03

Hello! I have problems running the self compiled ser version (without any sourcecode changes). I uninstalled the rpms ("rpm -e ser-mysql" and "rpm -e ser" - I use the mysql authentication). Then I compiled ser with "make all" without errors. I installed ser with "make install". Then I tried to start ser with: # /usr/local/sbin/ser -f /etc/ser/ser.cfg ERROR: bad config file (25 errors) Why does my config file doesn't work anymore (it worked with the rpm version)? When I start ser with -f, than it starts (but than it doesn't use the mysql database). Have I done something wrong during the installation/compiling? How can I delete the files that were installed by "make install"? make uninstall? regards, klaus > -----Original Message----- > From: Jan Janak [mailto:J.Janak@sh.cvut.cz] > Sent: Thursday, February 06, 2003 12:12 AM > To: Klaus Darilion > Cc: serusers(a)lists.iptel.org > Subject: Re: [Serusers] ser crashes > > > Hello, > > I wasn't able to reproduce it, but I think I know where the > problem is. There is a bug in 0.8.10 which shows up when an > INVITE contains Route header field. The bug has been fixed > in the CVS already. > > If you can compile ser from sources, you can easily fix it in your > release: > > 1) Edit ser-0.8.10/modules/tm/t_msgbuilder.c > 2) Jump to line 103 > 3) replace len+= with *len+= > 4) Recompile ser > > I can send you a patch if it is more convinient for you. > > regards, Jan. > > On 05-02 12:13, Klaus Darilion wrote: > > Hello! > > > > During playing around with route headers I discovered that > ser crashes > > reproduceable when I send the following request to it with > sipsak, I > > think the invite is a valid request with strict routing. > > > > sipsak.exe -f invite3.txt -s sip:obelix.ict.tuwien.ac.at -vvv > > > > invite3.txt: > > INVITE sip:obelix.ict.tuwien.ac.at SIP/2.0 > > Via: SIP/2.0/UDP 128.131.80.191:5070;branch=z9hG4bK2024693217 > > Route: <sip:iptel.org> > > Route: <sip:klaus3000@klausix.ict.tuwien.ac.at> > > From: <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618 > > To: <sip:klaus3000@iptel.org> > > Call-ID: 744056460(a)128.131.80.191 > > CSeq: 20 INVITE > > Contact: <sip:brutus@128.131.80.191:5070> > > max-forwards: 10 > > user-agent: oSIP/Linphone-0.9.1 > > Content-Type: application/sdp > > Content-Length: 335 > > > > .. > > sdp > > .. > > > > > > then ser stops to respond: > > > > >[root@obelix darilion]# /etc/init.d/ser status > > >ser dead but subsys locked > > > > and in /var/log/messages > > Feb 5 11:57:21 obelix ser: Listening on > > Feb 5 11:57:21 obelix ser: 128.131.80.136 > > [128.131.80.136]::5060 > > Feb 5 11:57:21 obelix ser: Aliases: obelix.ict.tuwien.ac.at:5060 > > Feb 5 11:57:21 obelix ser: ser startup succeeded > > Feb 5 11:57:21 obelix /usr/sbin/ser[21426]: mod_init(): Database > > connection opened successfuly > > Feb 5 11:57:21 obelix /usr/sbin/ser[21426]: INFO: > udp_init: SO_RCVBUF > > is initially 65535 > > Feb 5 11:57:21 obelix /usr/sbin/ser[21426]: INFO: > udp_init: SO_RCVBUF > > is finally 131070 > > Feb 5 11:57:21 obelix /usr/sbin/ser[21432]: INFO: fifo process > > starting: 21432 > > Feb 5 11:57:21 obelix /usr/sbin/ser[21432]: SER: > open_uac_fifo: fifo > > server up at /tmp/ser_fifo... > > > > ..up to here everything works fine, than I send the request: > > > > Feb 5 11:57:30 obelix /usr/sbin/ser[21428]: BUG: qm_*: fragm. > > 0x422b9ad0 end overwritten(35322e64, 39306665)! Feb 5 > 11:57:30 obelix > > /usr/sbin/ser[21426]: child process 21428 exited by a signal 11 > > Feb 5 11:57:30 obelix /usr/sbin/ser[21426]: core was not generated > > Feb 5 11:57:30 obelix /usr/sbin/ser[21426]: INFO: > terminating due to > > SIGCHLD > > > > Here is the ngrep output: > > > > U 128.131.80.101:1558 -> 128.131.80.136:5060 > > INVITE sip:obelix.ict.tuwien.ac.at SIP/2.0..Via: SIP/2.0/UDP > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP > > 128.131.80.191:5070;branch=z9hG4bK2024693217..Route: <sip:iptel. > > org>..Route: <sip:klaus3000@klausix.ict.tuwien.ac.at>..From: > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > <sip:klaus3000@iptel.org>..Call-ID: 744056460(a)128.131.80 > > .191..CSeq: 20 INVITE..Contact: > > <sip:brutus@128.131.80.191:5070>..max-forwards: 10..user-agent: > > oSIP/Linphone-0.9.1..Content-Type: application/sdp..Content-Length: > > 335 .... > > v=0..o=brutus 123456 654321 IN IP4 128.131.80.191..s=A > > c..onversation..c=IN IP4 128.131.80.191..t=0 0..m=audio > 7078 RTP/AVP 3 > > 115 8 110 111 101..a=rtpmap:3 gsm/8000/1..a=rtp > > map:115 lpc10-1.5/8000/1..a=rtpmap:8 PCMA/8000/1..a=rtpmap:110 > > speex-4/8000/1..a=rtpmap:111 speex_lbr-4/8000/1..a=rtpmap:101 > > telephone-event/8000..a=fmtp:101 0-11.. > > # > > U 128.131.80.136:5060 -> 128.131.80.101:1557 > > SIP/2.0 100 trying -- your call is important to us..Via: > SIP/2.0/UDP > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP > > 128.131.80.191:5070;branch=z9hG4bK2024693217..From: <sip > > :brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > <sip:klaus3000@iptel.org>..Call-ID: > 744056460@128.131.80.191..CSeq: 20 > > INVITE..Server: Sip EXpress router (0.8.10 (i386/l > > inux))..Content-Length: 0..Warning: 392 > 128.131.80.136:5060 "Noisy > > feedback tells: pid=21552 req_src_ip=128.131.80.101 > > in_uri=sip:obelix.ict.tuwien.ac.at out_uri=sip:iptel.o > > rg via_cnt==2".... > > > > # > > U 128.131.80.136:5060 -> 195.37.77.101:5060 > > INVITE sip:iptel.org SIP/2.0..Via: SIP/2.0/UDP > > 128.131.80.136;branch=z9hG4bK3a6d.25ef09d1.0..Via: SIP/2.0/UDP > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP 128.131.80.191: > > 5070;branch=z9hG4bK2024693217..Route: > > <sip:klaus3000@klausix.ict.tuwien.ac.at>..From: > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > <sip:klaus3000@iptel.org>..Call > > -ID: 744056460@128.131.80.191..CSeq: 20 INVITE..Contact: > > <sip:brutus@128.131.80.191:5070>..max-forwards: 9 ..user-agent: > > oSIP/Linphone-0.9.1..Content-Type: application/sdp.. > > Content-Length: 335 ....v=0..o=brutus 123456 654321 IN IP4 > > 128.131.80.191..s=A c..onversation..c=IN IP4 128.131.80.191..t=0 > > 0..m=audio 7078 RTP/AVP 3 115 8 110 111 101..a=r > > tpmap:3 gsm/8000/1..a=rtpmap:115 lpc10-1.5/8000/1..a=rtpmap:8 > > PCMA/8000/1..a=rtpmap:110 speex-4/8000/1..a=rtpmap:111 > > speex_lbr-4/8000/1..a=rtpmap:101 telephone-event/8000..a > > =fmtp:101 0-11.. > > > > # > > U 195.37.77.101:5060 -> 128.131.80.136:5060 > > SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP > > 128.131.80.136;branch=z9hG4bK3a6d.25ef09d1.0..Via: SIP/2.0/UDP > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP 12 > > 8.131.80.191:5070;branch=z9hG4bK2024693217..From: > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..To: > > <sip:klaus3000@iptel.org>;tag=fb86ad2694115d75c77dce61523c9f07.3f3c > > ..Call-ID: 744056460@128.131.80.191..CSeq: 20 > > INVITE..Proxy-Authenticate: Digest realm="iptel.org", > > nonce="3e40f29900000000d6e1790446755f1b4b96f5f5bd97b283", > > algorithm=MD5.. > > Server: Sip EXpress router (0.8.9 (i386/linux))..Content-Length: > > 0..Warning: 392 195.37.77.101:5060 "Noisy feedback tells: pid=7651 > > req_src_ip=128.131.80.136 in_uri=sip:ipte > > l.org out_uri=sip:klaus3000@klausix.ict.tuwien.ac.at > via_cnt==3".... > > > > # > > U 128.131.80.136:5060 -> 128.131.80.101:1557 > > SIP/2.0 407 Proxy Authentication Required..Via: SIP/2.0/UDP > > klausix.ict.tuwien.ac.at:1557..Via: SIP/2.0/UDP > > 128.131.80.191:5070;branch=z9hG4bK2024693217..From: <sip:brutus@o > > belix.ict.tuwien.ac.at>;tag=262992618..To: > > > <sip:klaus3000@iptel.org>;tag=fb86ad2694115d75c77dce61523c9f07.3f3c..C > > al > > l-ID: 744056460@128.131.80.191..CSeq: 20 INVITE..Proxy-Aut > > henticate: Digest realm="iptel.org", > > nonce="3e40f29900000000d6e1790446755f1b4b96f5f5bd97b283", > > algorithm=MD5..Server: Sip EXpress router (0.8.9 > > (i386/linux))..Content-Length > > : 0..Warning: 392 195.37.77.101:5060 "Noisy feedback > tells: pid=7651 > > req_src_ip=128.131.80.136 in_uri=sip:iptel.org > > out_uri=sip:klaus3000@klausix.ict.tuwien.ac.at via_cnt==3 > > ".... > > > > # > > U 128.131.80.136:5060 -> 195.37.77.101:5060 > > ACK sip:iptel.org SIP/2.0..Via: SIP/2.0/UDP > > 128.131.80.136;branch=z9hG4bK3a6d.25ef09d1.0..From: > > <sip:brutus@obelix.ict.tuwien.ac.at>;tag=262992618..Call-ID: > > 744056460(a)128.13 > > 1.80.191..To: > > > <sip:klaus3000@iptel.org>;tag=fb86ad2694115d75c77dce61523c9f07 > .3f3c..CSe > > q: 20 ACK.. > > > > > > > > If you need more details please let me know. > > > > regards, > > Klaus > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers > > >

2 1

Jump to page:

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