sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

[Serusers] How to create sip account Ser 0.10
by jean sigue 12 Jan '07

12 Jan '07

All, I have a fresh install ser 0.10 running with mysql. The utility serctl cannot be use to create sip account because the credentials table replaces the subscriber table. Can someone tell me how to create an account ? [root@itiah MySQL-python-1.2.1_p2]# ps -ef | grep ser root 87 7 0 Jan08 ? 00:00:00 [kseriod] root 1696 1 0 Jan08 ? 00:00:00 /usr/bin/hidd --server mysql 9972 9936 0 Jan08 pts/0 00:00:01 /usr/libexec/mysqld --defaults-file=/etc/my.cnf --basedir=/usr --datadir=/var/lib/mysql --user=myl --pid-file=/var/run/mysqld/mysqld.pid --skip-external-locking --socket=/var/lib/mysql/mysql.sock root 21031 1 0 Jan09 ? 00:00:00 ser root 21038 21031 0 Jan09 ? 00:00:00 ser root 21040 21031 0 Jan09 ? 00:00:00 ser root 21042 21031 0 Jan09 ? 00:00:00 ser root 21044 21031 0 Jan09 ? 00:00:00 ser root 21046 21031 0 Jan09 ? 00:00:00 ser root 21048 21031 0 Jan09 ? 00:00:00 ser root 21050 21031 0 Jan09 ? 00:00:00 ser root 21052 21031 0 Jan09 ? 00:00:00 ser root 21053 21031 0 Jan09 ? 00:00:00 ser root 21056 21031 0 Jan09 ? 00:00:00 ser root 21058 21031 0 Jan09 ? 00:00:00 ser root 21060 21031 0 Jan09 ? 00:00:00 ser root 21062 21031 0 Jan09 ? 00:00:00 ser root 21064 21031 0 Jan09 ? 00:00:00 ser root 21066 21031 0 Jan09 ? 00:00:00 ser root 21068 21031 0 Jan09 ? 00:00:00 ser root 21070 21031 0 Jan09 ? 00:00:10 ser root 21072 21031 0 Jan09 ? 00:00:00 ser root 21075 21031 0 Jan09 ? 00:00:00 ser root 21076 21031 0 Jan09 ? 00:00:00 ser root 21077 21031 0 Jan09 ? 00:00:00 ser root 21078 21031 0 Jan09 ? 00:00:00 ser root 21079 21031 0 Jan09 ? 00:00:00 ser root 21080 21031 0 Jan09 ? 00:00:00 ser root 21081 21031 0 Jan09 ? 00:00:00 ser root 21082 21031 0 Jan09 ? 00:00:00 ser root 21083 21031 0 Jan09 ? 00:00:00 ser root 21084 21031 0 Jan09 ? 00:00:00 ser root 17014 31475 0 19:24 pts/2 00:00:00 grep ser

3 3

[Serusers] SER + Asterisk Voice Mail, delay before redirect
by inge 12 Jan '07

12 Jan '07

Hi all, I work on an existing configuration of SER. I'm not able to find the parameter wich define the time in seconds before SER redirect call to Asterisk Voice Mail. In fact, I want to change this timing to put it in SER DB with a usr_preferences table like. Someone have an idea about the kind of line which could be define it ? Thanks for your help.

3 6

[Users] adding aliases does not work
by Cristian Caprar 12 Jan '07

12 Jan '07

Hi, Adding aliases with openserctl does not seem to be working anymore in the latest CVS snapshot. I run the command: /usr/local/sbin/openserctl alias add 00162123456 sip:user@domain.local And the output is: database engine 'MYSQL' loaded Control engine 'FIFO' loaded is_user: user counter=0 check_db_alias: alias counter=0 entering fifo_cmd ul_add aliases 00162123456(a)domain.local sip:user@domain.local 0 1.00 0 0 4294967295 ERROR: Error opening openser's FIFO /tmp/openser_fifo ERROR: Make sure you have line fifo=/tmp/openser_fifo in your config The same command used to work with a snapshot I got around 20 dec. OpenSER starts correctly. Thanks, Cristian

2 2

[Users] Meaning of CS_DIRTY
by Bill Neely 12 Jan '07

12 Jan '07

I get the follwing response from openserctl show ul ~~~Contact(0x284a6880)~~~ domain : 'location' aor : '1020111' Contact : 'sip:1020111@192.168.0.198:5060' Expires : 3592 q : Call-ID : '4ef617d2-8e70ad17(a)192.168.0.198' CSeq : 4249 User-Agent: 'Linksys/SPA3102-5.1.5(GWa)' received : 'sip:67.188.231.188:62292' Path : '' State : CS_DIRTY Flags : 0 Sock : 66.224.20.35:5060 (0x8123fb0) Methods : 5183 next : 0x0 prev : 0x0 ~~~/Contact~~~~ Can anybody tell me the meaning of the CS_DIRTY state reply? -- 702-874-3833 1-866-553-3833

2 1

[Serusers] ser logging into the file? - ser 0.10.99
by TZieleniewski 12 Jan '07

12 Jan '07

Hi ! Is there in ser 0.10.99 a way to send the output to the file instead of syslog?? Previously for ser 0.9.7 I had it done throught the serctl tool. I had the logstderror=yes in my ser.cfg and the output was redirected to log file pointed by SER_LOGFILE inside serctl. Tomasz

4 4

[Serusers] SER with LCR Config
by Arun Kumar 12 Jan '07

12 Jan '07

Hi All, I've posted the working config of LCR with SER and NAT on voipbhiwani.blogspot.com b'coz list is not allowing this much big config file. thanks Arun

1 0

Re: [Serusers] ser-0.10.99-dev64 (ser_ctl)]
by TZieleniewski 11 Jan '07

11 Jan '07

jean sigue napisał(a): > I create the database but the credentials table replaces the old > subscriber table 0.9.6 > > >> From: Hendrik Scholz <hendrik.scholz(a)freenet-ag.de> >> To: jean sigue <jeansigue(a)hotmail.com> >> CC: serusers(a)lists.iptel.org >> Subject: Re: [Serusers] ser-0.10.99-dev64 (ser_ctl) >> Date: Thu, 11 Jan 2007 14:46:36 +0100 >> >> Hi! >> >> jean sigue wrote: >> > MySql password: >> > ERROR 1146 (42S02) at line 1: Table 'ser.subscriber' doesn't exist >> >> Did you create the MySQL tables? >> ser_mysql.sh create (or the *.sql directly) should create them. >> Either way make sure you populate the domain table as well. >> >> Just my $.02, >> Hendrik >> >> -- >> freenet Cityline GmbH, Hamburger Chaussee 2-4, 24114 Kiel, Germany >> Phone: +49 (0)431 9020552, Fax: +49 (0)431 9020559 >> Internet: http://www.freenet.de, eMail: hendrik.scholz(a)freenet-ag.de > > > _______________________________________________ > Serusers mailing list > Serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > create the database with -n option (name of the new database) the same db user but new database for other ser instance there are some other usefull options too:)

1 0

[Serusers] ser-0.10.99-dev64 (ser_ctl)
by jean sigue 11 Jan '07

11 Jan '07

Hi, I am trying to create a sip account. When I enter the command [root@itiah runkit-0.9]# serctl add 7777777(a)vaboomz.com mypass ge(a)vaboomz.com MySql password: ERROR 1146 (42S02) at line 1: Table 'ser.subscriber' doesn't exist error: 500 Command 'ul_show_contact' not found Can anyome tell me where to find ser_ctl or more importantly how to fix it .

2 2

RE: [Users] using multiple DNS servers
by Will Quan 11 Jan '07

11 Jan '07

Yes, I think its DNS related because the callflows look perfect when both my DNS servers are up and running. This scenario only occurs when the primary dns server is offline. I thought maybe my debug trace would tell more of the story. Sorry I dont have a ngrep trace. << primary dns is offline; assuming res_search() considers the secondary in resolv.conf >>Jan 10 20:55:20 www openser[21124]: get_record: lookup(5934.rdtw1.qa2.l1.voiplabs.net, 35) failedJan 10 20:55:20 www openser[21124]: DEBUG:sip_resolvehost2: no valid NAPTR record found for 5934.rdtw1.qa2.l1.voiplabs.net, trying direct SRV lookup...Jan 10 20:55:20 www openser[21346]: get_record: lookup(5934.rdtw1.qa2.l1.voiplabs.net, 35) failedJan 10 20:55:20 www openser[21346]: DEBUG:sip_resolvehost2: no valid NAPTR record found for 5934.rdtw1.qa2.l1.voiplabs.net, trying direct SRV lookup...Jan 10 20:55:20 www openser[21140]: is_from_user_enum(): order 100, pref 100, flen 1, flags 'u', slen 7, services 'SIP+E2U', rlen 43, regexp '!^(.*)$!sip:\1@5934.rdtw1.qa2.l1.voiplabs.net!'Jan 10 20:55:20 www openser[21140]: reg_replace(): pattern: '^(.*)$', replacement: 'sip:\1@5934.rdtw1.qa2.l1.voiplabs.net', string: '+14556660002'Jan 10 20:55:20 www openser[21140]: is_from_user_enum(): resulted in replacement: 'sip:+14556660002@5934.rdtw1.qa2.l1.voiplabs.net'Jan 10 20:55:20 www openser[21140]: DEBUG:sip_resolvehost2: no port, no proto -> do NAPTR lookup!Jan 10 20:55:21 www openser[21233]: get_record: lookup(5934.rdtw1.qa2.l1.voiplabs.net, 35) failedJan 10 20:55:21 www openser[21233]: DEBUG:sip_resolvehost2: no valid NAPTR record found for 5934.rdtw1.qa2.l1.voiplabs.net, trying direct SRV lookup...<<processing 200 OK (invite) for the first time >>Jan 10 20:55:22 www openser[21124]: SIP Reply (status):Jan 10 20:55:22 www openser[21124]: version: <SIP/2.0>Jan 10 20:55:22 www openser[21124]: status: <200>Jan 10 20:55:22 www openser[21124]: reason: <OK>Jan 10 20:55:22 www openser[21124]: parse_headers: flags=2Jan 10 20:55:22 www openser[21124]: Found param type 232, <branch> = <z9hG4bK7d34.d8cbc746.0>; state=16Jan 10 20:55:22 www openser[21124]: end of header reached, state=5Jan 10 20:55:22 www openser[21124]: parse_headers: Via found, flags=2Jan 10 20:55:22 www openser[21124]: parse_headers: this is the first viaJan 10 20:55:22 www openser[21124]: After parse_msg...Jan 10 20:55:22 www openser[21124]: forward_reply: found module tm, passing reply to itJan 10 20:55:22 www openser[21124]: DEBUG: t_check: msg id=19 global id=18 T start=0xffffffffJan 10 20:55:22 www openser[21124]: parse_headers: flags=22Jan 10 20:55:22 www openser[21124]: Found param type 232, <branch> = <z9hG4bK175-64.101.130.210>; state=16Jan 10 20:55:22 www openser[21124]: end of header reached, state=5Jan 10 20:55:22 www openser[21124]: parse_headers: Via found, flags=22Jan 10 20:55:22 www openser[21124]: parse_headers: this is the second viaJan 10 20:55:22 www openser[21124]: DEBUG: add_param: tag=35Jan 10 20:55:22 www openser[21124]: DEBUG:parse_to:end of header reached, state=29Jan 10 20:55:22 www openser[21124]: DBUG:parse_to: display={"18001033799"}, ruri={sip:+18001033799@rdtw1.qa2.l1.voiplabs.net}Jan 10 20:55:22 www openser[21124]: DEBUG: get_hdr_field: <To> [64]; uri=[sip:+18001033799@rdtw1.qa2.l1.voiplabs.net] Jan 10 20:55:22 www openser[21124]: DEBUG: to body ["18001033799" <sip:+18001033799@rdtw1.qa2.l1.voiplabs.net>]Jan 10 20:55:22 www openser[21124]: get_hdr_field: cseq <CSeq>: <1> <INVITE>Jan 10 20:55:22 www openser[21124]: parse_headers: flags=8Jan 10 20:55:22 www openser[21124]: DEBUG: t_reply_matching: hash 17367 label 1685896333 branch 0Jan 10 20:55:22 www openser[21124]: DEBUG:tm:REF_UNSAFE: after is 1Jan 10 20:55:22 www openser[21124]: DEBUG: t_reply_matching: reply matched (T=0x283fe3a8)!Jan 10 20:55:22 www openser[21124]: parse_headers: flags=8Jan 10 20:55:22 www openser[21124]: DBG: trans=0x283fe3a8, callback type 2, id 0 enteredJan 10 20:55:22 www openser[21124]: parse_headers: flags=8Jan 10 20:55:22 www openser[21124]: DEBUG: t_check: msg id=19 global id=19 T end=0x283fe3a8Jan 10 20:55:22 www openser[21124]: DEBUG:tm:reply_received: org. status uas=180, uac[0]=180 local=0 is_invite=1)Jan 10 20:55:22 www openser[21124]: DEBUG:tm:t_should_relay_response: T_code=180, new_code=200Jan 10 20:55:22 www openser[21124]: DEBUG:tm:relay_reply: branch=0, save=0, relay=0Jan 10 20:55:22 www openser[21124]: old size: 844, new size: 783Jan 10 20:55:22 www openser[21124]: build_res_from_sip_res: copied size: orig:289, new: 228, rest: 555 msg= SIP/2.0 200 OK^M Record-Route: <sip:10.88.128.76;lr;ftag=64.101.130.210>^M Record-Route: <sip:10.88.128.77;lr;ftag=64.101.130.210>^M Record-Route: <sip:10.88.128.74;lr;ftag=64.101.130.210>^M Record-Route: <sip:64.101.130.210:5062>^M Via: SIP/2.0/UDP 64.101.130.210:5062;branch=z9hG4bK175-64.101.130.210^M From: "14556660002" <sip:+14556660002@5934.rdtw1.qa2.l1.voiplabs.net>;tag=64.101.130.210^M To: "18001033799" <sip:+18001033799@rdtw1.qa2.l1.voiplabs.net>;tag=35^M Call-ID: 1-1140(a)64.101.130.210^M CSeq: 1 INVITE^M Max-Forwards: 70^M Content-Length: 145^M Contact: "18001033799" <sip:+118001033799@10.88.129.252:6001>^M Content-Type: application/sdp^M ^M v=0^M o=user1 53655765 2353687637 IN IP4 10.88.129.252^M s=SIP Call^M c=IN IP4 10.88.129.252^M t=0 0^M m=audio 10800 RTP/AVP 0^M a=rtpmap:0 PCMU/8000^M Jan 10 20:55:22 www openser[21124]: DEBUG: update_totag_set: new totag Jan 10 20:55:22 www openser[21124]: DEBUG: add_to_tail_of_timer[2]: 0x283fe3f0Jan 10 20:55:22 www openser[21124]: DEBUG:tm:relay_reply: sent buf=0x81351c8: SIP/2.0 2..., shmem=0x283fe090: SIP/2.0 2Jan 10 20:55:22 www openser[21124]: DBG: trans=0x283fe3a8, callback type 128, id 0 enteredJan 10 20:55:22 www openser[21124]: ACC: transaction answered: method=INVITE, i-uri=sip:+18001033799@rdtw1.qa2.l1.voiplabs.net, o-uri=sip:+18001033799@10.88.128.77:5060, call_id=1-1140(a)64.101.130.210, from="14556660002" <sip:+14556660002@5934.rdtw1.qa2.l1.voiplabs.net>;tag=64.101.130.210, code=200, uid=n/a, fromtag=64.101.130.210, fromuri=sip:+14556660002@5934.rdtw1.qa2.l1.voiplabs.net, fromuri=sip:+14556660002@5934.rdtw1.qa2.l1.voiplabs.net, fromuser=+14556660002, fromdomain=5934.rdtw1.qa2.l1.voiplabs.net, to="18001033799" <sip:+18001033799@rdtw1.qa2.l1.voiplabs.net>;tag=35, totag=35, touri=sip:+18001033799@rdtw1.qa2.l1.voiplabs.net, touser=+18001033799, userpart=+18001033799, domain=rdtw1.qa2.l1.voiplabs.netJan 10 20:55:22 www openser[21124]: DEBUG: cleanup_uac_timers: RETR/FR timers resetJan 10 20:55:22 www openser[21124]: DEBUG:tm:UNREF_UNSAFE: after is 0Jan 10 20:55:22 www openser[21124]: DEBUG:destroy_avp_list: destroying list 0x0Jan 10 20:55:22 www openser[21124]: receive_msg: cleaning up<< processing ACK from orig >>Jan 10 20:55:22 www openser[21124]: SIP Request:Jan 10 20:55:22 www openser[21124]: method: <ACK>Jan 10 20:55:22 www openser[21124]: uri: <sip:+18001033799@10.88.129.253>Jan 10 20:55:22 www openser[21124]: version: <SIP/2.0>Jan 10 20:55:22 www openser[21124]: parse_headers: flags=2Jan 10 20:55:22 www openser[21124]: end of header reached, state=5Jan 10 20:55:22 www openser[21124]: parse_headers: Via found, flags=2Jan 10 20:55:22 www openser[21124]: parse_headers: this is the first viaJan 10 20:55:22 www openser[21124]: After parse_msg...Jan 10 20:55:22 www openser[21124]: preparing to run routing scripts...Jan 10 20:55:22 www openser[21124]: DEBUG : sl_filter_ACK: to late to be a local ACK!Jan 10 20:55:22 www openser[21124]: parse_headers: flags=100Jan 10 20:55:22 www openser[21124]: DEBUG: add_param: tag=35Jan 10 20:55:22 www openser[21124]: DEBUG:parse_to:end of header reached, state=29Jan 10 20:55:22 www openser[21124]: DBUG:parse_to: display={"18001033799"}, ruri={sip:+18001033799@rdtw1.qa2.l1.voiplabs.net}Jan 10 20:55:22 www openser[21124]: DEBUG: get_hdr_field: <To> [64]; uri=[sip:+18001033799@rdtw1.qa2.l1.voiplabs.net] Jan 10 20:55:22 www openser[21124]: DEBUG: to body ["18001033799" <sip:+18001033799@rdtw1.qa2.l1.voiplabs.net>]Jan 10 20:55:22 www openser[21124]: get_hdr_field: cseq <Cseq>: <2> <ACK>Jan 10 20:55:22 www openser[21124]: DEBUG:maxfwd:is_maxfwd_present: value = 70 Jan 10 20:55:22 www openser[21124]: parse_headers: flags=200Jan 10 20:55:22 www openser[21124]: is_preloaded: NoJan 10 20:55:22 www openser[21124]: grep_sock_info - checking if host==us: 13==12 && [10.88.129.253] == [10.88.128.74]Jan 10 20:55:22 www openser[21124]: grep_sock_info - checking if port 5060 matches port 5060Jan 10 20:55:22 www openser[21124]: check_self: host != meJan 10 20:55:22 www openser[21124]: grep_sock_info - checking if host==us: 12==12 && [10.88.128.74] == [10.88.128.74]Jan 10 20:55:22 www openser[21124]: grep_sock_info - checking if port 5060 matches port 5060Jan 10 20:55:22 www openser[21124]: after_loose: Topmost route URI: 'sip:10.88.128.74;lr;ftag=64.101.130.210' is meJan 10 20:55:22 www openser[21124]: after_loose: URI to be processed: 'sip:10.88.128.77;lr;ftag=64.101.130.210'Jan 10 20:55:22 www openser[21124]: after_loose: Next URI is a loose routerJan 10 20:55:22 www openser[21124]: DEBUG: t_newtran: msg id=20 , global msg id=19 , T on entrance=0xffffffffJan 10 20:55:22 www openser[21124]: parse_headers: flags=ffffffffffffffffJan 10 20:55:22 www openser[21124]: DEBUG: get_hdr_body : content_length=0Jan 10 20:55:22 www openser[21124]: found end of headerJan 10 20:55:22 www openser[21124]: parse_headers: flags=78Jan 10 20:55:22 www openser[21124]: t_lookup_request: start searching: hash=17364, isACK=1Jan 10 20:55:22 www openser[21124]: DEBUG: proceeding to pre-RFC3261 transaction matchingJan 10 20:55:22 www openser[21124]: DEBUG: t_lookup_request: no transaction foundJan 10 20:55:22 www openser[21124]: DEBUG:tm:t_relay: forwarding ACKJan 10 20:55:22 www openser[21124]: DEBUG: mk_proxy: doing DNS lookup...Jan 10 20:55:22 www openser[21124]: check_via_address(64.101.130.210, 64.101.130.210, 0)Jan 10 20:55:22 www openser[21124]: Sending: ACK sip:+18001033799@10.88.129.253 SIP/2.0^M Via: SIP/2.0/UDP 10.88.128.74;branch=0^M Via: SIP/2.0/UDP 64.101.130.210:5062^M From: "14556660002" <sip:+14556660002@5934.rdtw1.qa2.l1.voiplabs.net>;tag=64.101.130.210^M To: "18001033799" <sip:+18001033799@rdtw1.qa2.l1.voiplabs.net>;tag=35^M Call-ID: 1-1140(a)64.101.130.210^M Cseq: 2 ACK^M Contact: "14556660002" <sip:14556660002@64.101.130.210>^M Max-Forwards: 69^M Record-Route: <sip:64.101.130.210:5062>^M Route: <sip:10.88.128.77;lr;ftag=64.101.130.210>,<sip:10.88.128.76;lr;ftag=64.101.130.210>,"18001033799" <sip:+118001033799@10.88.129.252:6001>^M Content-Length: 0^M ^M .Jan 10 20:55:22 www openser[21124]: orig. len=608, new_len=605, proto=1Jan 10 20:55:22 www openser[21124]: DEBUG:destroy_avp_list: destroying list 0x0Jan 10 20:55:22 www openser[21124]: receive_msg: cleaning up<< strange behavior starts here ... >>Jan 10 20:55:22 www openser[21346]: DEBUG:do_srv_lookup: SRV(_sip._udp.5934.rdtw1.qa2.l1.voiplabs.net) = proxy.5934.rdtw1.qa2.l1.voiplabs.net:5060Jan 10 20:55:22 www openser[21346]: rdtw1.qa2.l1.voiplabs.net-outbound: time_t=1168484116 ^LINE=180 ^FILE=/var/local/ser/ROUTLET/config.pre ^call_id=1-1140(a)64.101.130.210 ^cseq=1 ^contact="14556660002" <sip:+14556660002@64.101.130.210> ^from=sip:+14556660002@5934.rdtw1.qa2.l1.voiplabs.net ^fromtag=64.101.130.210 ^to=sip:+18001033799@rdtw1.qa2.l1.voiplabs.net ^totag=<null> ^method=INVITE ^ruri=sip:+18001033799@rdtw1.qa2.l1.voiplabs.net ^messageid=8^remark=sJan 10 20:55:22 www openser[21346]: rdtw1.qa2.l1.voiplabs.net-RECORDROUTE: time_t=1168484116 ^LINE=180 ^FILE=/var/local/ser/ROUTLET/config.pre ^call_id=1-1140(a)64.101.130.210 ^cseq=1 ^contact="14556660002" <sip:+14556660002@64.101.130.210> ^from=sip:+14556660002@5934.rdtw1.qa2.l1.voiplabs.net ^fromtag=64.101.130.210 ^to=sip:+18001033799@rdtw1.qa2.l1.voiplabs.net ^totag=<null> ^method=INVITE ^ruri=sip:+18001033799@10.88.128.77:5060 ^messageid=8^remark=rdtw1.qa2.l1.voiplabs.netJan 10 20:55:22 www openser[21346]: DEBUG: t_newtran: msg id=8 , global msg id=7 , T on entrance=0xffffffffJan 10 20:55:22 www openser[21346]: parse_headers: flags=ffffffffffffffffJan 10 20:55:22 www openser[21346]: parse_headers: flags=78Jan 10 20:55:22 www openser[21346]: t_lookup_request: start searching: hash=17367, isACK=0Jan 10 20:55:22 www openser[21346]: DEBUG: RFC3261 transaction matched, tid=175-64.101.130.210Jan 10 20:55:22 www openser[21346]: DEBUG:tm:REF_UNSAFE: after is 1Jan 10 20:55:22 www openser[21346]: DEBUG: t_lookup_request: transaction found (T=0x283fe3a8)<< about to reTX the 200 OK (invite) *even though we just finished processing ACK* >>Jan 10 20:55:22 www openser[21346]: DEBUG:tm:t_retransmit_reply: buf=0x28229b40: SIP/2.0 2..., shmem=0x283fe090: SIP/2.0 2 ! ! ! ! ! ! ! !!!!!!!!Jan 10 20:55:22 www openser[21346]: DEBUG:tm:UNREF_UNSAFE: after is 0Jan 10 20:55:22 www openser[21346]: DEBUG:destroy_avp_list: destroying list 0x0Jan 10 20:55:22 www openser[21346]: receive_msg: cleaning up<< orig sends another ACK; to be expected since we just reTX the 200 OK >>Jan 10 20:55:22 www openser[21124]: SIP Request:Jan 10 20:55:22 www openser[21124]: method: <ACK>Jan 10 20:55:22 www openser[21124]: uri: <sip:+18001033799@10.88.129.253>Jan 10 20:55:22 www openser[21124]: version: <SIP/2.0>Jan 10 20:55:22 www openser[21124]: parse_headers: flags=2Jan 10 20:55:22 www openser[21124]: end of header reached, state=5Jan 10 20:55:22 www openser[21124]: parse_headers: Via found, flags=2Jan 10 20:55:22 www openser[21124]: parse_headers: this is the first viaJan 10 20:55:22 www openser[21124]: After parse_msg...Jan 10 20:55:22 www openser[21124]: preparing to run routing scripts...Jan 10 20:55:22 www openser[21124]: DEBUG : sl_filter_ACK: to late to be a local ACK!Jan 10 20:55:22 www openser[21124]: parse_headers: flags=100Jan 10 20:55:22 www openser[21124]: DEBUG: add_param: tag=35Jan 10 20:55:22 www openser[21124]: DEBUG:parse_to:end of header reached, state=29Jan 10 20:55:22 www openser[21124]: DBUG:parse_to: display={"18001033799"}, ruri={sip:+18001033799@rdtw1.qa2.l1.voiplabs.net}Jan 10 20:55:22 www openser[21124]: DEBUG: get_hdr_field: <To> [64]; uri=[sip:+18001033799@rdtw1.qa2.l1.voiplabs.net] Jan 10 20:55:22 www openser[21124]: DEBUG: to body ["18001033799" <sip:+18001033799@rdtw1.qa2.l1.voiplabs.net>]Jan 10 20:55:22 www openser[21124]: get_hdr_field: cseq <Cseq>: <2> <ACK>Jan 10 20:55:22 www openser[21124]: DEBUG:maxfwd:is_maxfwd_present: value = 70 Jan 10 20:55:22 www openser[21124]: parse_headers: flags=200Jan 10 20:55:22 www openser[21124]: is_preloaded: NoJan 10 20:55:22 www openser[21124]: grep_sock_info - checking if host==us: 13==12 && [10.88.129.253] == [10.88.128.74]Jan 10 20:55:22 www openser[21124]: grep_sock_info - checking if port 5060 matches port 5060Jan 10 20:55:22 www openser[21124]: check_self: host != meJan 10 20:55:22 www openser[21124]: grep_sock_info - checking if host==us: 12==12 && [10.88.128.74] == [10.88.128.74]Jan 10 20:55:22 www openser[21124]: grep_sock_info - checking if port 5060 matches port 5060Jan 10 20:55:22 www openser[21124]: after_loose: Topmost route URI: 'sip:10.88.128.74;lr;ftag=64.101.130.210' is meJan 10 20:55:22 www openser[21124]: after_loose: URI to be processed: 'sip:10.88.128.77;lr;ftag=64.101.130.210'Jan 10 20:55:22 www openser[21124]: after_loose: Next URI is a loose routerJan 10 20:55:22 www openser[21124]: DEBUG: t_newtran: msg id=21 , global msg id=20 , T on entrance=0xffffffffJan 10 20:55:22 www openser[21124]: parse_headers: flags=ffffffffffffffffJan 10 20:55:22 www openser[21124]: DEBUG: get_hdr_body : content_length=0Jan 10 20:55:22 www openser[21124]: found end of headerJan 10 20:55:22 www openser[21124]: parse_headers: flags=78Jan 10 20:55:22 www openser[21124]: t_lookup_request: start searching: hash=17364, isACK=1Jan 10 20:55:22 www openser[21124]: DEBUG: proceeding to pre-RFC3261 transaction matchingJan 10 20:55:22 www openser[21124]: DEBUG: t_lookup_request: no transaction foundJan 10 20:55:22 www openser[21124]: DEBUG:tm:t_relay: forwarding ACKJan 10 20:55:22 www openser[21124]: DEBUG: mk_proxy: doing DNS lookup...Jan 10 20:55:22 www openser[21124]: check_via_address(64.101.130.210, 64.101.130.210, 0)Jan 10 20:55:22 www openser[21124]: Sending: ACK sip:+18001033799@10.88.129.253 SIP/2.0^M Via: SIP/2.0/UDP 10.88.128.74;branch=0^M Via: SIP/2.0/UDP 64.101.130.210:5062^M From: "14556660002" <sip:+14556660002@5934.rdtw1.qa2.l1.voiplabs.net>;tag=64.101.130.210^M To: "18001033799" <sip:+18001033799@rdtw1.qa2.l1.voiplabs.net>;tag=35^M Call-ID: 1-1140(a)64.101.130.210^M Cseq: 2 ACK^M Contact: "14556660002" <sip:14556660002@64.101.130.210>^M Max-Forwards: 69^M Record-Route: <sip:64.101.130.210:5062>^M Route: <sip:10.88.128.77;lr;ftag=64.101.130.210>,<sip:10.88.128.76;lr;ftag=64.101.130.210>,"18001033799" <sip:+118001033799@10.88.129.252:6001>^M Content-Length: 0^M ^M .Jan 10 20:55:22 www openser[21124]: orig. len=608, new_len=605, proto=1Jan 10 20:55:22 www openser[21124]: DEBUG:destroy_avp_list: destroying list 0x0Jan 10 20:55:22 www openser[21124]: receive_msg: cleaning upJan 10 20:55:23 www openser[21376]: DEBUG: timer routine:1,tl=0x283fe4d4 next=0x0Jan 10 20:55:23 www openser[21376]: DEBUG: timer routine:4,tl=0x283fe4c4 next=0x0<< repeat reTX 200 OK (invite) / ACK several times >>Any Ideas?Will> Date: Thu, 11 Jan 2007 17:23:10 +0100> From: klaus.mailinglists(a)pernau.at> To: sip(a)voiplabs.net> CC: users(a)openser.org> Subject: Re: [Users] using multiple DNS servers> > Will Quan wrote:> > I have a primary and secondary dns server setup in resolv.conf, with> > a timeout option of 1 second.The idea is when the primary fails, my> > secondary server picks up the workload.When openser is running, and> > primary dns is down, I am seeing several re-transmissions of 200 OK> > (invite) to my originator *after* openser has finished processing> > ACK. I was thinking the final responses would stop reTX after the ACK> > was t_relayed. Have you seen such behavior? And better yet- Is there> > a solution for this?Thanks, Will> > Are you sure this problem is related to DNS failover?> > regards> klaus> > > > > > > ------------------------------------------------------------------------> > > > > > _______________________________________________ Users mailing list > > Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users> > > -- > Klaus Darilion> nic.at>

1 0

[Users] NEW OPTION: "auto_aliases" core parameter
by Bogdan-Andrei Iancu 11 Jan '07

11 Jan '07

Hi everybody, I added a nee core parameter named "auto_aliases" - it controls if aliases should be automatically discovered and added during fixing listening sockets. Formally, this was done with no control over it (to turn it off), which was a security risk (in my opinion) as the server was using auto-discover aliases that were not configured. To maintain backward compatibility, the default value is "on"; Ex: auto_aliases=no or auto_aliases=0 regards, bogdan

2 4

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