sr-users June 2008

sr-users@lists.kamailio.org

124 participants
230 discussions

[OpenSER-Users] First route in Route header not being removed

by Robert Dyck

Using 1.3.2 notls I found that when an Ekiga softphone is configured with an outgoing proxy, it will include a Route header in an initial INVITE. The Route header contains a single URI pointing to the outgoing proxy. This allowed according to RFC 3261 section 8.1.1.1 "When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy. " Since the first route in a Route header over rides a request URI, this Route URI must be removed prior to routing or the request will loop. Openser will loop when Ekiga is configured with Openser as the outgoing proxy. Of course the header could be removed using the openser.cfg but the operation should be built in.

15 years, 11 months

[OpenSER-Users] pua_xmpp Notify2Xmpp error

by Gaoqiang Qian

Hello everyone, I have setup my openser 1.3.2 with presence, pua_xmpp, xmpp modules according to the openser.org dokuwiki about pua_xmpp configuration. From SIP client(eyebeam) and XMPP client(pigdin), IM is now working fine between two sides with below destination address: sip: "sip:username<delim>jabber_server@gateway_domain" xmpp: "sip_username<delim>openser_domain@xmpp_domain" But the presence only works in one side, in xmpp client, it shows the availabity of sip contacts, but on sip client, the xmpp contacts are always offline. I got below line error continously loged: Jun 11 20:44:33 ims /home/openser/openser1.3.2/sbin/openser[16077]: ERROR:pua_xmpp:Notify2Xmpp: 'To' header ALREADY PARSED:<sip:test*ovi.com@xmpp.rcs.demo> Could anyone tell me what might be the reason. Thanks a lot in advance.

15 years, 11 months

[OpenSER-Users] Why a $var cannot be 'null' ?

by Iñaki Baz Castillo

Hi, if I set: $var(kk) = null and later printf it (or compare with =~) then I see '0': xlog("L_INFO", "var(kk) = $var(kk)\n"); => var(kk) = 0 But AVP's do allow 'null' value and store 'null' instead of '0'. Is there any reason for it? -- Iñaki Baz Castillo

15 years, 11 months

[OpenSER-Users] compiling ldap module on freebsd 7.0-release

by Dian Dwi Nugraha

Hi, I've been having problem with compiling OpenSER with LDAP module on FreeBSD 7.0-RELEASE. I have 'ldap.so' and put it under /usr/local/lib/ openser/modules/. The problem occured when I tried to run openser. --- Error Message --- Jun 11 19:49:53 [16442] ERROR:core:sr_load_module: could not open module </usr/local/lib/openser/modules/ldap.so>: /usr/local/lib/ openser/modules/ldap.so: Undefined symbol "ber_sockbuf_io_debug" Any advice will help. Thanks. Best regards, --- Dian Dwi Nugraha > Computer Engineering Department > School of Informatics and Electrical Engineering > Institut Teknologi Bandung > dian132(a)students.ee.itb.ac.id

15 years, 11 months

Re: [OpenSER-Users] Error Compiling

by Ali Jawad

Did a chmod 777.. -----Original Message----- From: Henning Westerholt [mailto:henning.westerholt@1und1.de] Sent: Wednesday, June 11, 2008 6:05 PM To: Ali Jawad Subject: Re: [OpenSER-Users] Error Compiling On Wednesday 11 June 2008, Ali Jawad wrote: > Hi Henning > I was able to fix it thanks to your help. I have one last hurdle. When I > try to start openser now I get this error > ERROR:acc:init_acc_rad: failed to open radius config file: > /etc/raddb/clients.conf > > However /etc/raddb/clients.conf exists Hi Ali, perhaps this is a permission problem? Henning -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

15 years, 11 months

[OpenSER-Users] Error Compiling

by Ali Jawad

Hi All I did remove all the radius mods from the exclude section of the Makefile. And I did enable radius in the Makefile of the acc module. All compiled well howver when I try to load the acc module I get the following error ERROR:core:sr_load_module: could not open module </usr/local/lib/openser/modules/acc.so>: libradiusclient-ng.so.2: cannot open shared object file: No such file or directory However the file in question can be found at /usr/local/lib/libradiusclient-ng.so.2 With Regards

15 years, 11 months

[OpenSER-Users] OpenSER-1.1.1 crashes

by dilip.m＠renovau.com

Hello Everyone, I have inlcude auth_diameter module in the openser.cfg. It works fine with DISC. I can authorize the user with same. When i increase the call rate using sipp tool at that time the openser going to crash. It disconnect the connection. The openser shows me this output. 1(19698) SIP Request: 1(19698) method: <REGISTER> 1(19698) uri: <sip:192.168.1.66> 1(19698) version: <SIP/2.0> 1(19698) parse_headers: flags=2 1(19698) end of header reached, state=5 1(19698) parse_headers: Via found, flags=2 1(19698) parse_headers: this is the first via 1(19698) After parse_msg... 1(19698) preparing to run routing scripts... 1(19698) parse_headers: flags=100 1(19698) DEBUG:parse_to:end of header reached, state=10 1(19698) DBUG:parse_to: display={1113}, ruri={sip:1113@192.168.1.66:5060} 1(19698) DEBUG: get_hdr_field: <To> [35]; uri=[sip:1113@192.168.1.66:5060] 1(19698) DEBUG: to body [1113 <sip:1113@192.168.1.66:5060> ] 1(19698) get_hdr_field: cseq <CSeq>: <1> <REGISTER> 1(19698) DEBUG:maxfwd:is_maxfwd_present: value = 70 1(19698) parse_headers: flags=200 1(19698) DEBUG: get_hdr_body : content_length=0 1(19698) found end of header 1(19698) find_first_route: No Route headers found 1(19698) loose_route: There is no Route HF 1(19698) grep_sock_info - checking if host==us: 12==12 && [192.168.1.66] == [192.168.1.66] 1(19698) grep_sock_info - checking if port 5060 matches port 5060 1(19698) grep_sock_info - checking if host==us: 12==12 && [192.168.1.66] == [192.168.1.66] 1(19698) grep_sock_info - checking if port 5060 matches port 5060 1(19698) parse_headers: flags=4000 1(19698) auth_diameter:pre_auth(): Credentials with given realm not found 1(19698) ******* m_id=3 1(19698) DEBUG:do_read (sock=8): whole message read (len=304)! 1(19698) ######## m_id=3 1(19698) parse_headers: flags=ffffffffffffffff 1(19698) check_via_address(192.168.1.1, 192.168.1.1, 0) 1(19698) build_auth_hf(): 'WWW-Authenticate: Digest realm="192.168.1.66", nonce="484e1d9a81643c688e09493c7b615dacbc004e81", qop="auth" ' 1(19698) parse_headers: flags=ffffffffffffffff 1(19698) check_via_address(192.168.1.1, 192.168.1.1, 0) 1(19698) DEBUG:destroy_avp_list: destroying list (nil) 1(19698) receive_msg: cleaning up 4(19703) SIP Request: 4(19703) method: <ACK> 4(19703) uri: <sip:192.168.1.66> 4(19703) version: <SIP/2.0> 4(19703) parse_headers: flags=2 4(19703) end of header reached, state=5 4(19703) parse_headers: Via found, flags=2 4(19703) parse_headers: this is the first via 4(19703) After parse_msg... 4(19703) preparing to run routing scripts... 4(19703) parse_headers: flags=8 4(19703) DEBUG: add_param: tag=71db33f84c952ca903e2273ad59f1848.3074 4(19703) DEBUG:parse_to:end of header reached, state=29 4(19703) DBUG:parse_to: display={sut}, ruri={sip:1113@192.168.1.66:5060} 4(19703) DEBUG: get_hdr_field: <To> [76]; uri=[sip:1113@192.168.1.66:5060] 4(19703) DEBUG: to body [sut <sip:1113@192.168.1.66:5060>] 4(19703) DEBUG: sl_filter_ACK : local ACK found -> dropping it! 4(19703) DEBUG:destroy_avp_list: destroying list (nil) 4(19703) receive_msg: cleaning up 2(19699) SIP Request: 2(19699) method: <REGISTER> 2(19699) uri: <sip:192.168.1.66> 2(19699) version: <SIP/2.0> 2(19699) parse_headers: flags=2 2(19699) end of header reached, state=5 2(19699) parse_headers: Via found, flags=2 2(19699) parse_headers: this is the first via 2(19699) After parse_msg... 2(19699) preparing to run routing scripts... 2(19699) parse_headers: flags=100 2(19699) DEBUG:parse_to:end of header reached, state=10 2(19699) DBUG:parse_to: display={1113}, ruri={sip:1113@192.168.1.66:5060} 2(19699) DEBUG: get_hdr_field: <To> [35]; uri=[sip:1113@192.168.1.66:5060] 2(19699) DEBUG: to body [1113 <sip:1113@192.168.1.66:5060> ] 2(19699) get_hdr_field: cseq <CSeq>: <2> <REGISTER> 2(19699) DEBUG:maxfwd:is_maxfwd_present: value = 70 2(19699) parse_headers: flags=200 2(19699) DEBUG: get_hdr_body : content_length=0 2(19699) found end of header 2(19699) find_first_route: No Route headers found 2(19699) loose_route: There is no Route HF 2(19699) grep_sock_info - checking if host==us: 12==12 && [192.168.1.66] == [192.168.1.66] 2(19699) grep_sock_info - checking if port 5060 matches port 5060 2(19699) grep_sock_info - checking if host==us: 12==12 && [192.168.1.66] == [192.168.1.66] 2(19699) grep_sock_info - checking if port 5060 matches port 5060 2(19699) ******* m_id=3 2(19699) DEBUG:do_read (sock=9): whole message read (len=208)! 2(19699) ######## m_id=3 2(19699) parse_headers: flags=ffffffffffffffff 2(19699) parse_headers: flags=8000000 2(19699) parse_headers: flags=ffffffffffffffff 2(19699) build_contact(): Created Contact HF: Contact: <sip:1113@192.168.1.5:5060>;expires=27, <sip:1113@192.168.1.1:5060>;expires=3600 2(19699) parse_headers: flags=ffffffffffffffff 2(19699) check_via_address(192.168.1.1, 192.168.1.1, 0) 2(19699) DEBUG:destroy_avp_list: destroying list (nil) 2(19699) receive_msg: cleaning up 4(19703) SIP Request: 4(19703) method: <ACK> 4(19703) uri: <sip:192.168.1.66> 4(19703) version: <SIP/2.0> 4(19703) parse_headers: flags=2 4(19703) end of header reached, state=5 4(19703) parse_headers: Via found, flags=2 4(19703) parse_headers: this is the first via 4(19703) After parse_msg... 4(19703) preparing to run routing scripts... 4(19703) parse_headers: flags=8 4(19703) DEBUG: add_param: tag=71db33f84c952ca903e2273ad59f1848.3074 4(19703) DEBUG:parse_to:end of header reached, state=29 4(19703) DBUG:parse_to: display={sut}, ruri={sip:1113@192.168.1.66:5060} 4(19703) DEBUG: get_hdr_field: <To> [76]; uri=[sip:1113@192.168.1.66:5060] 4(19703) DEBUG: to body [sut <sip:1113@192.168.1.66:5060>] 4(19703) DEBUG: sl_filter_ACK : local ACK found -> dropping it! 4(19703) DEBUG:destroy_avp_list: destroying list (nil) 4(19703) receive_msg: cleaning up 10(19717) ERROR: receive_fd: EOF on 8 10(19717) DBG: handle_ser_child: dead child 3, pid 19701 (shutting down?) 10(19717) DBG: io_watch_del (0x6d31a0, 8, -1, 0x0) fd_no=14 called 0(19695) child process 19701 exited by a signal 11 0(19695) core was generated 0(19695) INFO: terminating due to SIGCHLD 8(19712) INFO: signal 15 received 8(19712) 4(19703) 7(19710) Memory status (pkg): 2(19699) INFO: signal 15 received 2(19699) Memory status (pkg): 2(19699) fm_status (0x705700): 2(19699) heap size= 1048576 2(19699) used= 18682, used+overhead=56810, free=991766 2(19699) max used (+overhead)= 61502 2(19699) dumping free list: 2(19699) hash = 1 fragments no.: 2, unused: 0 bucket size: 8 - 8 (first 8) 2(19699) hash = 2 fragments no.: 3, unused: 0 bucket size: 16 - 16 (first 16) 2(19699) INFO: signal 15 received INFO: signal 15 received 8(19712) fm_status (0x705700): 8(19712) heap size= 1048576 8(19712) used= 75736, used+overhead=113464, free=935112 8(19712) 6(19708) hash = 3 fragments no.: 1, unused: 0 bucket size: 24 - 24 (first 30) 2(19699) hash = 6 fragments no.: 1, unused: 0 bucket size: 48 - 48 (first 48) 2(19699) hash = 8 fragments no.: 5, unused: 0 bucket size: 64 - 64 (first 64) 2(19699) 4(19703) 7(19710) INFO: signal 15 received 6(19708) Memory status (pkg): 6(19708) fm_status (0x705700): 6(19708) heap size= 1048576 6(19708) used= 75736, used+overhead=113464, free=935112 6(19708) max used (+overhead)= 113464 6(19708) dumping free list: 6(19708) hash = 27 fragments no.: 1, unused: 0 bucket size: 216 - 216 (first 216) 6(19708) hash = 39 fragments no.: 11, unused: 0 bucket size: 312 - 312 (first 312) 6(19708) hash = 73 fragments no.: 1, unused: 0 bucket size: 584 - 584 (first 584) 6(19708) hash = 192 fragments no.: 1, unused: 0 bucket size: 1536 - 1536 (first 1536) 6(19708) hash = 2054 fragments no.: 1, unused: 0 bucket size: 524288 - 1048576 (first 929344) 6(19708) TOTAL: 15 free fragments = 935112 free bytes 6(19708) ----------------------------- 1(19698) INFO: signal 15 received 1(19698) Memory status (pkg): 1(19698) fm_status (0x705700): 1(19698) heap size= 1048576 1(19698) used= 20040, used+overhead=58424, free=990152 1(19698) max used (+overhead)= 62264 1(19698) dumping free list: 1(19698) hash = 1 fragments no.: 2, unused: 0 bucket size: 8 - 8 (first 8) 1(19698) hash = 2 fragments no.: 3, unused: 0 bucket size: 16 - 16 (first 16) 1(19698) hash = 3 fragments no.: 1, unused: 0 bucket size: 24 - 24 (first 30) 1(19698) hash = 6 fragments no.: 1, unused: 0 bucket size: 48 - 48 (first 48) 1(19698) hash = 8 fragments no.: 5, unused: 0 bucket size: 64 - 64 (first 64) 1(19698) hash = 9 fragments no.: 9, unused: 0 bucket size: 72 - 72 (first 72) 1(19698) hash = 10 fragments no.: 1, unused: 0 bucket size: 80 - 80 (first 80) 1(19698) hash = 11 fragments no.: 1, unused: 0 bucket size: 88 - 88 (first 88) 1(19698) hash = 15 fragments no.: 1, unused: 0 bucket size: 120 - 120 (first 120) 10(19717) INFO: signal 15 received 10(19717) Memory status (pkg): 10(19717) fm_status (0x705700): I have also try with to solve it with gdb,but cant help. The gdb output as follows, (gdb) Loaded symbols for /usr/local/lib64/openser/modules/auth_diameter.so Reading symbols from /usr/local/lib64/openser/modules/domain.so...done. Loaded symbols for /usr/local/lib64/openser/modules/domain.so Reading symbols from /lib64/libnss_files.so.2...done. Loaded symbols for /lib64/libnss_files.so.2 Core was generated by `openser'. Program terminated with signal 11, Segmentation fault. #0 0x00002aaaabfa2b72 in AAAAddAVPToMessage (msg=0x713cd8, avp=0x713330, position=0x713b08) at avp.c:178 178 for(avp_t=msg->avpList.head;avp_t&&avp_t!=position;avp_t=avp_t->next); (gdb) What was the problem ?? Please explain me. Thanks in advance. Regards, Dilip Modi

15 years, 11 months

Re: [OpenSER-Users] Why can't I "append_branch()" in FAILURE_ROUTE if reply is 6XX ??

by Igor Sidorov

Hi! Yes, it is very important and for us! LCR module. If we get 6XX response from the first gateway, it is impossible to redirect request to any others gateways . We have very strange situation! If the first gateway (with the best priority for some distinations) due his reasons answer with 6XX it destroy lcr logic at all !!! (and we do not want to change this gateway because we have no problems with others destinations(and some others reasons)) please, change this tm behavior asap. Or if you can suggest something else (i mean some rows of config code) ? thank you. >Why? doesn't it make sense to forward to some destination even if the negative >reply is a 4XX or 6XX? -- View this message in context: http://www.nabble.com/Why-can%27t-I-%22append_branch%28%29%22-in-FAILURE_RO… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

15 years, 11 months

[OpenSER-Users] stun

by Pezhman Lali

--- On Mon, 6/9/08, Pezhman Lali <pezhman_lali(a)yahoo.com> wrote: > From: Pezhman Lali <pezhman_lali(a)yahoo.com> > Subject: stun > To: pezhman.lali(a)gmail.com > Date: Monday, June 9, 2008, 6:02 PM > Dear, > does setting the ip of stun server in the sip-phones, > behind the symmetric nat, make the problem ? > my experience with stund 0.96, said yes. > the stun server, can detects the type of nats properly, but > the sip-phones behind the un-symmetric nat, can not > register, or one-way calling. > > ????

15 years, 11 months

Re: [OpenSER-Users] stun

by Aymeric Moizard

On Tue, 10 Jun 2008, David Villasmil wrote: > True (about getting the IP from the register), but that's putting more > processing on the server, I'd rather let ths UAC do the ip resolution when > we're talking thousands of clients (Which I am) The behavior I described is made on the client/endpoint which look at the received and rport in the answer to a request sent to the server. (and this is not a DNS resolution: this is just "looking at"...) The server in this case don't have any processing to do anymore: he always receive the correct contact header. No need for STUN to have a correct IP/port for SIP even behind symmetric NAT. ;) tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/ > Cheers > > On Tue, Jun 10, 2008 at 1:59 PM, Aymeric Moizard <jack(a)atosc.org> wrote: > >> >> Stun can work even behind symmetric NAT if the stun server was >> running on the same socket the SIP server is running... I hope >> this feature will come soon! >> >> I can help with this. >> >> Also, SIP don't need to use STUN to work: you can discover your >> IP address and port very easily by looking at the REGISTER answer >> or OPTIONS answer which contains the "received" and "rport" >> parameter. >> >> Of course, symmetric NAT are a nightmare for RTP, but not for SIP... >> >> tks, >> Aymeric MOIZARD / ANTISIP >> amsip - http://www.antisip.com >> osip2 - http://www.osip.org >> eXosip2 - http://savannah.nongnu.org/projects/exosip/ >> >> >> >> On Tue, 10 Jun 2008, Iñaki Baz Castillo wrote: >> >> El Tuesday 10 June 2008 10:44:51 Ali Jawad escribió: >>> >>>> Hi All >>>> >>>> I had a lot of problems with STUN and symmetric NAT. The thing is that >>>> it does not always work with symmetric NAT. That would be mostly routers >>>> based on Linux IPTABLES. >>>> >>> >>> STUN **CANNOT** work with symetric NAT. The NAT router maps the internal >>> port >>> with a different public port *depending* on the destination IP:port, so >>> STUN >>> can't work. >>> >>> -- >>> Iñaki Baz Castillo >>> ibc(a)in.ilimit.es >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)lists.openser.org >>> http://lists.openser.org/cgi-bin/mailman/listinfo/users >>> >> >> _______________________________________________ >> Users mailing list >> Users(a)lists.openser.org >> http://lists.openser.org/cgi-bin/mailman/listinfo/users >> >> >

15 years, 11 months

← Newer
1
...
13
14
15
16
17
18
19
...
23
Older →

Jump to page:

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 2008