sr-users March 2005

sr-users@lists.kamailio.org

250 participants
627 discussions

[Serusers] get 302 contact in failure route
by Zappasodi Daniele 16 Mar '05

16 Mar '05

Hello, I?m trying to write my module. I need to read the uri in the contact header field of the ?302? response. How can I get this header in the failure route block? ********************************************************************** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. **********************************************************************

1 0

[Serusers] About Serweb's installation
by seebeyond163 16 Mar '05

16 Mar '05

Hi,all I downloaded the serweb-2004-07-24,and untar it.I followed the instruction given by website. But I can not find the file named 'config_paths.php' and 'config_data_layer.php'. What is wrong with my TAR file? And another problem,I want to add user in Redhat with SERCTL ADD command,but error occurs as follows: //////////////////////////// [root@localhost root]# serctl add 118 118 118(a)192.168.1.10 MySql password: MySql password: Enter password: ERROR 1045: Access denied for user: 'ser@localhost' (Using password: NO) introducing a new user to the database failed /////////////////////////// MySql Database's password is null.so I just type 'RETURN' in first and twice prompt. In the third,'Enter password:' ? does the SER DATABASE have a password? and what's it? Thanks In Advance. Best Regards Shibo ＝＝＝＝＝＝＝＝＝＝＝＝＝＝

1 0

[Serusers] Users cannot connect
by Barry Murphy 16 Mar '05

16 Mar '05

FreeBSD 4.10 running ser 0.9.0 (cfg attached) Ok so I finally got ser to start with the correct permissions & got serweb working, my issue is that users cannot register now... I get the following from serctl moni 400: 0 401: 0 403: 0 404: 0 407: 0 408: 0 483: 27 4xx: 0 I get the following in a ser -Eddd Via: SIP/2.0/UDP 203.167.185.63:5060;rport=5060;branch=z9hG4bKB8DC7272F55340C799774EA5E2789B6 A From: test <sip:865656522@voip.fast.co.nz>;tag=720372325 To: test <sip:865656522@voip.fast.co.nz> Contact: "test" <sip:865656522@203.167.185.63:5060> Call-ID: 69553DC01B7C4C06A0B5D19777328A8D(a)voip.fast.co.nz CSeq: 33263 REGISTER Expires: 1800 Max-Forwards: 70 User-Agent: X-Lite release 1103m Content-Length: 0 . 4(49500) orig. len=3294, new_len=3337, proto=1 9(49505) qm_malloc(0x81179c0, 16) called from proxy.c: hostent_cpy(88) 9(49505) qm_malloc(0x81179c0, 16) returns address 0x815113c frag. 0x8151124 (size=28) on 1 -th hit 9(49505) qm_malloc(0x81179c0, 4) called from proxy.c: hostent_cpy(99) 9(49505) qm_malloc(0x81179c0, 4) returns address 0x8150c58 frag. 0x8150c40 (size=4) on 1 -th hit 9(49505) qm_malloc(0x81179c0, 8) called from proxy.c: hostent_cpy(122) 9(49505) qm_malloc(0x81179c0, 8) returns address 0x814d854 frag. 0x814d83c (size=8) on 1 -th hit 9(49505) qm_malloc(0x81179c0, 4) called from proxy.c: hostent_cpy(133) 9(49505) 5(49501) get_record: lookup(_sip._udp.voip.fast.co.nz, 33) failed 5(49501) sip_resolvehost: no SRV record found for voip.fast.co.nz, trying 'normal' lookup... 3(49499) get_record: lookup(_sip._udp.voip.fast.co.nz, 33) failed 3(49499) sip_resolvehost: no SRV record found for voip.fast.co.nz, trying 'normal' lookup... 8(49504) get_record: lookup(_sip._udp.voip.fast.co.nz, 33) failed 8(49504) sip_resolvehost: no SRV record found for voip.fast.co.nz, trying 'normal' lookup... 9 2(49498) qm_malloc(0x81179c0, 756) called from receive.c: receive_msg(92) 2(49498) qm_malloc(0x81179c0, 756) returns address 0x8150e18 frag. 0x8150e00 (size=756) on 1 -th hit 2(49498) SIP Request: 2(49498) method: <REGISTER> 2(49498) uri: <sip:voip.fast.co.nz> 2(49498) version: <SIP/2.0> 2(49498) parse_headers: flags=1 2(49498) qm_malloc(0x81179c0, 32) called from parser/msg_parser.c: parse_headers(279) 2(49498) qm_malloc(0x81179c0, 32) returns address 0x81513f8 frag. 0x81513e0 (size=32) on 1 -th hit 2(49498) qm_malloc(0x81179c0, 120) called from parser/msg_parser.c: get_hdr_field(110) 2(49498) qm_malloc(0x81179c0, 120) returns address 0x8150d38 frag. 0x8150d20 (size=176) on 1 -th hit 2(49498) qm_malloc(0x81179c0, 32) called from parser/parse_via.c: parse_via(1823) 2(49498) qm_malloc(0x81179c0, 32) returns address 0x8151448 frag. 0x8151430 (size=32) on 1 -th hit 2(49498) Found param type 232, <branch> = <0>; state=16 2(49498) end of header reached, state=5 2(49498) parse_headers: Via found, flags=1 2(49498) parse_headers: this is the first via 2(49498) After parse_msg... 2(49498) preparing to run routing scripts... 2(49498) qm_malloc(0x81179c0, 60) called from proxy.c: mk_proxy(208) 2(49498) qm_malloc(0x81179c0, 60) returns address 0x814d584 frag. 0x814d56c (size=64) on 1 -th hit 2(49498) DEBUG: mk_proxy: doing DNS lookup... 4(49500) qm_free(0x81179c0, 0x8153b90), called from forward.c: forward_request(348) 4(49500) qm_free: freeing frag. 0x8153b78 alloc'ed from msg_translator.c: build_req_buf_from_sip_req(1452) 4(49500) qm_free(0x81179c0, 0x814ee1c), called from forward.c: forward_request(349) 4(49500) qm_free: freeing frag. 0x814ee04 alloc'ed from forward.c: forward_request(273) 4(49500) qm_free(0x81179c0, 0x815113c), called from proxy.c: free_hostent(164) 4(49500) qm_free: freeing frag. 0x8151124 alloc'ed from proxy.c: hostent_cpy(88) 4(49500) qm_malloc(0x81179c0, 4) returns address 0x814d820 frag. 0x814d808 (size=4) on 1 -th hit 9(49505) qm_malloc(0x81179c0, 28) called from forward.c: forward_request(273) 9(49505) qm_malloc(0x81179c0, 28) returns address 0x81511ec frag. 0x81511d4 (size=32) on 1 -th hit 9(49505) qm_malloc(0x81179c0, 51) called from msg_translator.c: via_builder(1942) 9(49505) qm_malloc(0x81179c0, 52) returns address 0x8151188 frag. 0x8151170 (size=52) on 1 -th hit 9(49505) check_via_address(202.150.105.150, 202.150.105.150, 0) 9(49505) qm_malloc(0x81179c0, 32) called from data_lump.c: anchor_lump(340) 9(49505) qm_malloc(0x81179c0, 32) returns address 0x815132c frag. 0x8151314 (size=32) on 1 -th hit 9(49505) qm_malloc(0x81179c0, 32) called from data_lump.c: insert_new_lump_before(139) 9(49505) qm_malloc(0x81179c0, 32) returns address 0x815137c frag. 0x8151364 (size=32) on 1 -th hit 9(49505) sqm_malloc(0x81179c0, 1704) called from msg_translator.c: build_req_buf_from_sip_req(1452) 9(49505) qm_malloc(0x81179c0, 1704) returns address 0x81529f8 frag. 0x81529e0 (size=1836) on 1 -th hit 9(49505) Sending: REGISTER sip:voip.fast.co.nz SIP/2.0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 203.167.185.63:5060;rport=5060;branch=z9hG4bKB8DC7272F55340C799774EA5E2789B6 A From: test <sip:865656522@voip.fast.co.nz>;tag=720372325 To: test <sip:865656522@voip.fast.co.nz> Contact: "test" <sip:865656522@203.167.185.63:5060> Call-ID: 69553DC01B7C4C06A0B5D19777328A8D(a)voip.fast.co.nz CSeq: 33263 REGISTER Expires: 1800 Max-Forwards: 70 User-Agent: X-Lite release 1103m Content-Length: 0 . 8(49504) qm_malloc(0x81179c0, 16) called from proxy.c: hostent_cpy(88) 8(49504) qm_malloc(0x81179c0, 16) returns address 0x815113c frag. 0x8151124 (size=28) on 1 -th hit 8(49504) qm_malloc(0x81179c0, 4) called from proxy.c: hostent_cpy(99) 8(49504) qm_malloc(0x81179c0, 4) returns address 0x814d820 frag. 0x814d808 (size=4) on 1 -th hit 8(49504) qm_malloc(0x81179c0, 8) called from proxy.c: hostent_cpy(122) 8(49504) qm_malloc(0x81179c0, 8) returns address 0x814d584 frag. 0x814d56c (size=8) on 1 -th hit 8(49504) qm_malloc(0x81179c0, 4) called from proxy.c: hostent_cpy(133) 8(49504) qm_malloc(0x81179c0, 4) returns address 0x8150c58 frag. 0x8150c40 (size=4) on 1 -th hit 8(49504) qm_malloc(0x81179c0, 28) called from forward.c: forward_request(273) 8(49504) qm_malloc(0x81179c0, 28) returns address 0x815141c frag. 0x8151404 (size=32) on 1 -th hit 8(49504) qm_malloc(0x81179c0, 51) called from msg_translator.c: via_builder(1942) 8(49504) qm_malloc(0x81179c0, 52) returns address 0x815128c frag. 0x8151274 (size=52) on 1 -th hit 8(49504) check_via_address(202.150.105.150, 202.150.105.150, 0) 8(49504) qm_malloc(0x81179c0, 32) called from data_lump.c: anchor_lump(340) 8(49504) qm_malloc(0x81179c0, 32) returns address 0x815132c frag. 0x8151314 (size=32) on 1 -th hit 8(49504) qm_malloc(0x81179c0, 32) called from data_lump.c: insert_new_lump_before(139) 8(49504) qm_malloc(0x81179c0, 32) returns address 0x815137c frag. 0x8151364 (size=32) on 1 -th hit 8(49504) qm_malloc(0x81179c0, 2693) called from msg_translator.c: build_req_buf_from_sip_req(1452) 8(49504) qm_malloc(0x81179c0, 2696) returns address 0x8153534 frag. 0x815351c (size=2780) on 1 -th hit 8(49504) Sending: REGISTER sip:voip.fast.co.nz SIP/2.0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 203.167.185.63:5060;rport=5060;branch=z9hG4bKB8DC7272F55340C799774EA5E2789B6 A From: test <sip:865656522@voip.fast.co.nz>;tag=720372325 To: test <sip:865656522@voip.fast.co.nz> Contact: "test" <sip:865656522@203.167.185.63:5060> Call-ID: 69553DC01B7C4C06A0B5D19777328A8D(a)voip.fast.co.nz CSeq: 33263 REGISTER Expires: 1800 Max-Forwards: 70 User-Agent: X-Lite release 1103m Content-Length: 0 . 8(49504) orig. len=2649, new_len=2692, proto=1 5(49501) qm_malloc(0x81179c0, 16) called from proxy.c: hostent_cpy(88) 5(49501) qm_malloc(0x81179c0, 16) returns address 0x815113c frag. 0x8151124 (size=28) on 1 -th hit 5(49501) qm_malloc(0x81179c0, 4) called from proxy.c: hostent_cpy(99) 5(49501) qm_malloc(0x81179c0, 4) returns address 0x8150c58 frag. 0x8150c40 (size=4) on 1 -th hit 5(49501) qm_malloc(0x81179c0, 8) called from proxy.c: hostent_cpy(122) 5(49501) qm_malloc(0x81179c0, 8) returns address 0x814d854 frag. 0x814d83c (size=8) on 1 -th hit 5(49501) qm_malloc(0x81179c0, 4) called from proxy.c: hostent_cpy(133) 5(49501) qm_malloc(0x81179c0, 4) returns address 0x814d820 frag. 0x814d808 (size=4) on 1 -th hit 5(49501) qm_malloc(0x81179c0, 28) called from forward.c: forward_request(273) 5(49501) qm_malloc(0x81179c0, 28) returns address 0x814ee1c frag. 0x814ee04 (size=44) on 1 -th hit 5(49501) qm_malloc(0x81179c0, 51) called from msg_translator.c: via_builder(1942) 5(49501) qm_malloc(0x81179c0, 52) returns address 0x8151188 frag. 0x8151170 (size=52) on 1 -th hit 5(49501) check_via_address(202.150.105.150, 202.150.105.150, 0) 5(49501) qm_malloc(0x81179c0, 32) called from data_lump.c: anchor_lump(340) 5(49501) qm_malloc(0x81179c0, 32) returns address 0x814d584 frag. 0x814d56c (size=64) on 1 -th hit 5(49501) qm_malloc(0x81179c0, 32) called from data_lump.c: insert_new_lump_before(139) 5(49501) qm_malloc(0x81179c0, 32) returns address 0x814d330 frag. 0x814d318 (size=68) on 1 -th hit 5(49501) qm_malloc(0x81179c0, 3682) called from msg_translator.c: build_req_buf_from_sip_req(1452) 5(49501) qm_malloc(0x81179c0, 3684) returns address 0x8156590 frag. 0x8156578 (size=3684) on 1 -th hit 5(49501) Sending: REGISTER sip:voip.fast.co.nz SIP/2.0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 202.150.105.150;branch=0 Via: SIP/2.0/UDP 203.167.185.63:5060;rport=5060;branch=z9hG4bKB8DC7272F55340C799774EA5E2789B6 A From: test <sip:865656522@voip.fast.co.nz>;tag=720372325 To: test <sip:865656522@voip.fast.co.nz> Contact: "test" <sip:865656522@203.167.185.63:5060> Call-ID: 69553DC01B7C4C06A0B5D19777328A8D(a)voip.fast.co.nz CSeq: 33263 REGISTER Expires: 1800 Max-Forwards: 70 User-Agent: X-Lite release 1103m Content-Length: 0 . 5(49501) orig. len=3638, new_len=3681, proto=1 3(49499) qm_malloc(0x81179c0, 16) called from proxy.c: hostent_cpy(88) 3(49499) qm_malloc(0x81179c0, 16) returns address 0x815113c frag. 0x8151124 (size=28) on 1 -th hit 3(49499) qm_malloc(0x81179c0, 4) called from proxy.c: hostent_cpy(99) 3(49499) qm_malloc(0x81179c0, 4) returns address 0x814d820 frag. 0x814d808 (size=4) on 1 -th hit 3(49499) qm_malloc(0x81179c0, 8) called from proxy.c: hostent_cpy(122) 3(49499) qm_malloc(0x81179c0, 8) returns address 0x814d854 frag. 0x814d83c (size=8) on 1 -th hit 3(49499) qm_malloc(0x81179c0, 4) called from proxy.c: hostent_cpy(133) 3(49499) qm_malloc(0x81179c0, 4) returns address 0x8150c58 frag. 0x8150c40 (size=4) on 1 -th hit 3(49499) qm_malloc(0x81179c0, 28) called from forward.c: forward_request(273) 3(49499) qm_malloc(0x81179c0, 28) returns address 0x815128c frag. 0x8151274 (size=32) on 1 -th hit 3(49499) qm_malloc(0x81179c0, 51) called from msg_translator.c: via_builder(1942) 3(49499) qm_malloc(0x81179c0, 52) returns address 0x8151188 frag. 0x8151170 (size=52) on 1 -th hit 3(49499) check_via_address(202.150.105.150, 202.150.105.150, 0) 3(49499) qm_malloc(0x81179c0, 32) called from data_lump.c: anchor_lump(340) 3(49499) qm_malloc(0x81179c0, 32) returns address 0x81512dc frag. 0x81512c4 (size=32) on 1 -th hit 3(49499) qm_malloc(0x81179c0, 32) called from data_lump.c: insert_new_lump_before(139) 3(49499) qm_malloc(0x81179c0, 32) returns address 0x81511ec frag. 0x81511d4 (size=32) on 1 -th hit 3(49499) qm_malloc(0x81179c0, 560) called from msg_translator.c: build_req_buf_from_sip_req(1452) 3(49499) qm_malloc(0x81179c0, 560) returns address 0x8151534 frag. 0x815151c (size=956) on 1 -th hit qm_free(0x81179c0, 0x814d820), called from proxy.c: free_hostent(169) 4(49500) qm_free: freeing frag. 0x814d808 alloc'ed from proxy.c: hostent_cpy(99) 4(49500) qm_free(0x81179c0, 0x8150c58), called from proxy.c: free_hostent(173) 4(49500) qm_free: freeing frag. 0x8150c40 alloc'ed from proxy.c: hostent_cpy(133) 4(49500) qm_free(0x81179c0, 0x814d854), called from proxy.c: free_hostent(175) 4(49500) qm_free: freeing frag. 0x814d83c alloc'ed from proxy.c: hostent_cpy(122) 4(49500) qm_free(0x81179c0, 0x814d584), called from action.c: do_action(199) 4(49500) qm_free: freeing frag. 0x814d56c alloc'ed from proxy.c: mk_proxy(208) 4(49500) DEBUG:destroy_avp_list: destroying list 0x0 4(49500) receive_msg: cleaning up

1 0

[Serusers] LCR Backport Example For ser-0.9
by Java Rockx 16 Mar '05

16 Mar '05

Hi all. Can anyone shoot me an example on proper use of Juha's LCR module. I thought I had mine right, but then I realized that some re-INVITE messages were not being handled properly and calls were being disconnected. Regards, Paul

3 12

[Serusers] SER consultant required
by Sun Shung 16 Mar '05

16 Mar '05

Hi, I am working on SER and I m looking for acknowledgeable consultant that provide offline support and some technical queries. If you are able to help please quote me your rates and direct email to me. Thanks alot guys. Regards, SunShung _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

1 0

[Serusers] prefixes for dialing codes...is there and easier way than using if...then
by Iqbal 16 Mar '05

16 Mar '05

Hi I currently have several hundred prefixes which a user could dial to, now the way my system is setup is that various of these occur in various packages eg PREF 011 - package A PREF 022 - package B etc etc Is there anyway of looking these up in a DB, and then allowing to a route, rather than putting the prefix in the ser.cfg file. I have all the prefixes added in the lcr table, and each group of prefixes is assigned to a package, and added in the grp table...with each subscriber, and flags set for each group in ser.cfg as in example for free-pstn etc etc Now I need to check for each dial prefix, in ser.cfg so I can route, and thats alot of check statements, even if I can work out some using regex. if uri=011 and flag=1 then call, # if uri =022 and flag =2 then call flag 2 cant call 011, hence I need to have two separate checks...and for all the prefixes I need to have lots and lots...is there a neater/nicer way of doing this. Iqbal

1 0

[Serusers] Connect two GKs
by hwang＠ecs.csus.edu 16 Mar '05

16 Mar '05

I'm trying to connect 2 GKs. Version 2.2.0 is used in both GK. GK_A has an EP registed to it with alias 1001, GK_B has an EP registed to it with alias 2001. In GK_B, I set GK_A as Permanent EP like [RasSrv::PermanentEndpoints] 192.168.2.218=GK_A;1 When I dial 1001 from 2001, I see an ACF from the status port, right after that I get a DCF. By tracing the log in GK_B, I get : ProxyChannel.cxx(1984) Q931 192.168.2.218:1720 DIDN'T ACCEPT THE CALL where 192.168.2.218 is the IP for GK_A. But in GK_A, nothing related to GK_B in the log. Please help me to find out the problem. Thanks.

4 3

RE: [Serusers] Mediaproxy consuming RAM resources.
by Ricardo Martinez 16 Mar '05

16 Mar '05

Hello. Returning to this subject. I upgraded to the new mediaproxy version. 1.2.1, but i still have the same problem. I detected a increasing amount of RAM memory used by mediaproxy. I don't know what's happening. Is this something maybe related to the way i tear dow the session, i'm still confuse with so many IDLE session in my mediaproxy. Can this be the cause of the increasing amount of RAM memory used? Also, is there a way to debug the mediaproxy? or something that help me to understand what's going on? Any help would be appreciated. Thanks Ricardo.- > -----Mensaje original----- > De: Java Rockx [mailto:javarockx@gmail.com] > Enviado el: Viernes, 11 de Marzo de 2005 15:23 > Para: Ricardo Martinez > CC: serusers(a)lists.iptel.org > Asunto: Re: [Serusers] Mediaproxy consuming RAM resources. > > > I'm tearing down my sessions the same way you showed in your first > email. So AFAIK, that is OK. > > Regards, > Paul > > > On Fri, 11 Mar 2005 16:15:38 -0400, Ricardo Martinez > <rmartinez(a)redvoiss.net> wrote: > > Paul, > > I was thinking the same, maybe that's the problem. > > What about the tear down of the sessions? > > > > Thanks! > > > > Regards, > > Ricardo.- > > > > > -----Mensaje original----- > > > De: Java Rockx [mailto:javarockx@gmail.com] > > > Enviado el: Viernes, 11 de Marzo de 2005 15:09 > > > Para: Ricardo Martinez > > > CC: serusers(a)lists.iptel.org > > > Asunto: Re: [Serusers] Mediaproxy consuming RAM resources. > > > > > > > > > Ricardo, > > > > > > I think the release notes on mediaproxy-1.2 say that some resource > > > leaks have been fixed. > > > > > > Perhaps you can try version 1.2 > > > > > > Regards, > > > Paul > > > > > > On Fri, 11 Mar 2005 16:01:59 -0400, Ricardo Martinez > > > <rmartinez(a)redvoiss.net> wrote: > > > > Hello list. > > > > I was looking the process in my SER sip-proxy with the > > > mediaproxy running. > > > > Every time i look, the percetage of used RAM is increasing. > > > It seems like > > > > for some reason mediaproxy is not releasing the resources > > > used in RAM. You > > > > can look this in the next lines : > > > > > > > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM > > > TIME CPU COMMAND > > > > 1952 root 15 0 284M 266M 1628 S 0.0 26.4 > > > 19:22 0 > > > > mediaproxy.py > > > > > > > > Can someone tell me if this is a bug of mediaproxy or maybe a > > > > missconfiguration in my ser.cfg? > > > > > > > > I want to ask a question regarding to tear down sessions > > > with mediaproxy > > > > also. In my ser.cfg i have : > > > > if (loose_route()) { > > > > if (method=="BYE" || method=="CANCEL") { > > > > log(1, "NAT: BYE o CANCEL recibido > > > --> terminando la > > > > sesion de media\n"); > > > > end_media_session(); > > > > setflag(1); > > > > }; > > > > t_relay(); > > > > break; > > > > }; > > > > > > > > Is this ok? I think in some cases (i'm still unable to > > > determine which > > > > ones), SER does not tear down a mediaproxy session. You > > > can see for example > > > > this two session, both of them were ended, but it seems to > > > be active even > > > > before that. (i ommited the source, via and destination > > > IP's in the output > > > > of the session.py) > > > > > > > > Status Duration Codec Type Traffic > > > > > > > -------------------------------------------------------------- > > > -------------- > > > > --- > > > > hold (2430) 40'40" G729 Audio 11.53k/29.58k/18.45k > > > > inactive 0'02" Unknown Audio 0/0/0 > > > > > > > > Can someone tell me what's happening? > > > > I'm runnig : > > > > [root mediaproxy]# ./mediaproxy.py --version > > > > mediaproxy.py 1.0 > > > > > > > > Thanks in advance. > > > > Regards, > > > > > > > > Ricardo M. > > > > > > > > _______________________________________________ > > > > Serusers mailing list > > > > serusers(a)lists.iptel.org > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > >

3 3

[Serusers] Ser & mysql problem
by bouchra benyelloul 15 Mar '05

15 Mar '05

Hi all, I've Problem with ser and mysql databases: In first time, I can connect to ser mysql database without any problem, but when i try to do it twice, I' have this errors : Listening on udp: 127.0.0.1 [127.0.0.1]:5060 udp: 192.168.1.20 [192.168.1.20]:5060 tcp: 127.0.0.1 [127.0.0.1]:5060 tcp: 192.168.1.20 [192.168.1.20]:5060 Aliases: tcp: linux:5060 tcp: linux.local:5060 tcp: localhost:5060 udp: linux:5060 udp: linux.local:5060 udp: localhost:5060 stateless - initializing 0(0) Maxfwd module- initializing textops - initializing acc - initializing 0(4479) new_connection(): Can't connect to MySQL server on '192.168.1.70' (111) 0(4479) db_init(): Could not create a connection 0(4479) ERROR: child_init(0): Error while connecting database 0(4479) init_mod_child(): Error while initializing module usrloc 0(4479) main: error in init_child Thanks for advance. Bouchra. Découvrez nos promotions exclusives "destination de la Tunisie, du Maroc, des Baléares et la Rép. Dominicaine sur Yahoo! Voyages : http://fr.travel.yahoo.com/promotions/mar14.html

3 2

[Serusers] HELP: re-INVITE Sometimes Not Processed Properly
by Java Rockx 15 Mar '05

15 Mar '05

Hi All. I really need some help here. Attached is a call log between my ser-0.9.1 sip proxy and a third party Sonus PSTN gateway. The call was originated on a SIP phone so the Sonus gateway sends re-INVITE messages during the call. The problem is that the re-INIVITE is not properly processed and therefore the PSTN gateway sends a BYE message (not shown). I'm using Juha's LCR module because we have multiple PSTN gateways. Anyhow, it seems like this is happening: INVITE sent to PSTN gateway PSTN GW sends 180 Ringing PSTN GW sends 200 OK, which is sent to the SIP UA SIP UA replied with ACK, which is sent to the PSTN GW Time Elapses PSTN GW sends re-INVITE, which is sent to the SIP UA SIP UA replies with 200 OK, which is sent to the PSTN GW PSTN GW sends another re-INVITE PSTN GW sends an ACK, which is sent to the SIP UA re-INVITE (received immediated before the ACK) is sent to the SIP UA And the call falls apart from here. It's like some sort of timing issue where another INIVITE is recieved before the ACK. My timers in ser.cfg are as follows: modparam("tm", "fr_timer", 22) modparam("tm", "fr_inv_timer", 27) modparam("tm", "wt_timer", 5) modparam("tm", "fr_inv_timer_avp", "inv_timeout") Can anyone give a pointer please? I'm 100% lost on this one. Regards, Paul

2 4

← Newer
1
...
32
33
34
35
36
37
38
...
63
Older →

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 March 2005