sr-users July 2005

sr-users@lists.kamailio.org

199 participants
544 discussions

[Serusers] libradiusclient-ng2 ?? Installing acc-radius in ver 0.9.3

by Jose Bertuzzi

Hello, i am trying to test radius acc in version 0.9.3 on a debian box. I compiled and installed radiusclient-ng version 0.5.1 and i tried to install the debian acc-radius package. It seems that libradiusclient-ng2 is missing. Where can I get that file ? debian:/usr/src/ser# dpkg -i ser-acc-radius-module_0.9.3-0.2_i386.deb (Reading database ... 13617 files and directories currently installed.) Preparing to replace ser-acc-radius-module 0.9.3-0.2 (using ser-acc-radius-module_0.9.3-0.2_i386.deb) ... Unpacking replacement ser-acc-radius-module ... dpkg: dependency problems prevent configuration of ser-acc-radius-module: ser-acc-radius-module depends on libradiusclient-ng2; however: Package libradiusclient-ng2 is not installed. dpkg: error processing ser-acc-radius-module (--install): dependency problems - leaving unconfigured Errors were encountered while processing: ser-acc-radius-module kind regards, Pablo __________________________________ Discover Yahoo! Find restaurants, movies, travel and more fun for the weekend. Check it out! http://discover.yahoo.com/weekend.html

18 years, 10 months

[Users] OpenSER 0.9.5

by Bogdan-Andrei Iancu

Hi folks, OpenSER 0.9.5 is available for download now at http://openser.org/pub/openser/0.9.5/ This is just a re-packing to include juha's lcr module and postgres package. Minor packaging fixes are also there (like default config files and some dependencies). GCC 4.0 warnings were fixed also. See the changeLog file for more details. Also radius debian packages are available. For now, the solaris binaries are not yet generated. So, the CVS tag is the same rel_0_9_0, but subversion was increased from 4 to 5. regards, bogdan

18 years, 10 months

[Serusers] sipsak EoH ERROR

by Daniel Poulsen

Hi, I am trying to send a SIP NOTIFY from my voicemail server to my SER that looks like this: NOTIFY sip:2125553720@sip.domain.net SIP/2.0 Via: SIP/2.0/UDP 192.168.1.10:5060 <http://192.168.1.10:5060> From: <sip:vmserver@sip.domain.net> To: <sip:2124003720@sip.domain.net> Contact: <sip:3720@192.168.1.10> Call-ID: 4d61cf9e505d40e905032a18329d61ec at 192.168.1.10<http://192.168.1.10> CSeq: 1 NOTIFY User-Agent: VoiceMail Event: message-summary Content-Type: application/simple-message-summary Content-Length: 39 Messages-Waiting: yes Voicemail: 2/8 but SER gives me the error: Jul 1 10:59:38 sip ser[10363]: ERROR: t_newtran: EoH not parsed Jul 1 10:59:38 sip ser[10363]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL) Can anyone offer a suggestion? Thank you for your time. Dan

18 years, 10 months

[Serusers] Cancel an Invite on ser 0.9.3

by Toni Barata

Hi again, Same issue on the release 0.9.3. Regards, Toni ________________________________ From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Toni Barata Sent: sexta-feira, 1 de Julho de 2005 15:55 To: serusers(a)lists.iptel.org Subject: [Serusers] Cancel an Invite on ser 0.8.14 Hi All, Can someone checks why, in the situation of a client that cancels a call before the destination send a "180 ringing" to the proxy, that causes some troble to the proxy because it is not forwarding the cancel to the destination. See the following 2 examples : In this situation the cancel works fine: 651.327850 10.112.128.220 -> 10.112.128.247 SIP/SDP Request: INVITE sip:testef03@teste.pt, with session description 651.328725 10.112.128.247 -> 10.112.128.220 SIP Status: 100 trying -- your call is important to us 651.328778 10.112.128.247 -> 10.112.128.187 SIP/SDP Request: INVITE sip:testef03@10.112.128.187:7678, with session description 651.576892 10.112.128.187 -> 10.112.128.247 SIP Status: 180 Ringing 651.577005 10.112.128.247 -> 10.112.128.220 SIP Status: 180 Ringing 651.722172 10.112.128.220 -> 10.112.128.247 SIP Request: CANCEL sip:testef03@teste.pt 651.723047 10.112.128.247 -> 10.112.128.187 SIP Request: CANCEL sip:testef03@10.112.128.187:7678 651.723084 10.112.128.247 -> 10.112.128.220 SIP Status: 200 cancelling 651.723622 10.112.128.247 -> 10.112.128.220 SIP Status: 487 Request cancelled 651.724792 10.112.128.220 -> 10.112.128.247 SIP Request: ACK sip:testef03@teste.pt 651.899824 10.112.128.187 -> 10.112.128.247 SIP Status: 200 OK 651.900593 10.112.128.187 -> 10.112.128.247 SIP Status: 487 Request Terminated 651.900666 10.112.128.247 -> 10.112.128.187 SIP Request: ACK sip:testef03@10.112.128.187:7678 In this one, the cancel never reaches the destination client, so it keeps ringing... 657.866834 10.112.128.220 -> 10.112.128.247 SIP/SDP Request: INVITE sip:testef03@teste.pt, with session description 657.867667 10.112.128.247 -> 10.112.128.220 SIP Status: 100 trying -- your call is important to us 657.867720 10.112.128.247 -> 10.112.128.187 SIP/SDP Request: INVITE sip:testef03@10.112.128.187:7678, with session description 658.068940 10.112.128.247 -> 10.112.128.187 SIP/SDP Request: INVITE sip:testef03@10.112.128.187:7678, with session description 658.083368 10.112.128.220 -> 10.112.128.247 SIP Request: CANCEL sip:testef03@teste.pt 658.084201 10.112.128.247 -> 10.112.128.220 SIP Status: 200 ok -- no more pending branches 658.084948 10.112.128.247 -> 10.112.128.220 SIP Status: 487 Request cancelled 658.085933 10.112.128.220 -> 10.112.128.247 SIP Request: ACK sip:testef03@teste.pt 658.228348 10.112.128.187 -> 10.112.128.247 SIP Status: 180 Ringing 658.232010 10.112.128.187 -> 10.112.128.247 SIP Status: 180 Ringing Thanks, Toni

18 years, 10 months

Re: [Serusers] SER + Remote MySQL Server

by Iqbal

jan posted this modparam("auth_db|usrloc", "db_url", "mysql://ser:heslo@server_host/ser") so replace ser with your username helso with ur password server_host with the Ip address of your mysql server leave the second ser alone, since thats the DB name, and I am guessing you have installed it with default name Iqbal Sebastian Kigelman wrote: >Thank you Iqbal for your answer... Have you the right line that I need to >put on my ser.cfg?, I will really appreciate if you can provide me the >information. > >-----Original Message----- >From: Iqbal [mailto:iqbal@gigo.co.uk] >Sent: Friday, 01 July, 2005 08:24 >To: Sebastian Kigelman >Cc: serusers(a)lists.iptel.org >Subject: Re: [Serusers] SER + Remote MySQL Server > >Yup, I think thats how most have it, on a remote server, have you tried >connecting from your command line where ser is to the remote mysql >machine, if that fails, which it normally does, its down to a >permissions problem in Mysql. > >Otherwise in ser.cfg you can define the IP address of your remote mysql >server > >Iqbal > >Sebastian Kigelman wrote: > > > >> Finally, I know why I am having problems with SER + MySQL: I think >>is that because I trying to run SER and MySQL in different machines. Per >> >> >the > > >>installation instructions that I found in www.iptel.org, I have installed >>SER on other machine in the same subnet, and I was able to create and >>initialize the DB with the "ser_mysql create" command. I do that modifying >>the ser_mysql.sh and serctl.sh scripts setting DBHOST=<MySQL IP Address> on >>both files. I thought that those changes would allow to ser application to >>start using the remote MySQL server, but analyzing the ser debug messages, >> >> >I > > >>understand that the application is trying to locate the DB on the local >>machine. >> >> So, there is somebody that there is implemented SER + Remote MySQL >>Server?... can you tell me what I need to do to tell to SER that the DB is >>located on a remote machine?... >> >> Thanxs in advance! >> >>Zeva >> >> >>----- Original Message ----- >>From: "Sebastian Kigelman" <sebastian(a)kigelman.com.ar> >>To: <serusers(a)lists.iptel.org> >>Sent: Wednesday, June 29, 2005 11:34 AM >>Subject: [Serusers] 2nd try: SER does not start with MySQL >> >> >> >> >> >> >>>Hi there!!!... Iam newy in SER mailing list, and I have a problem with my >>>SER installation that I saw that other members have before, but I can't >>>find >>>a solution to the issue. >>> >>>I have installed the SER (v0.8.14), all works fine until I add MySQL >>>support >>>to get persistent users. after that, when I run "serctl start" I get this >>>error: >>> >>>---------------------------------------------------------------- >>>Starting SER : cat: /var/run/ser.pid: No such file or directory >>>started pid() >>>---------------------------------------------------------------- >>> >>>I have made some test to troubleshot this issue, for exsaplme: remplacing >>>DIR=... with the full path to SER executable in "serctl"... and also I >>>increase the debug level in "ser.cfg" to 7, and I get this output: >>> >>>---------------------------------------------------------------- >>>MyHost:/etc/ser# ser -c >>>0(2577) loading module /usr/lib/ser/modules/mysql.so >>>0(2577) loading module /usr/lib/ser/modules/sl.so >>>0(2577) loading module /usr/lib/ser/modules/tm.so >>>0(2577) loading module /usr/lib/ser/modules/rr.so >>>0(2577) loading module /usr/lib/ser/modules/maxfwd.so >>>0(2577) loading module /usr/lib/ser/modules/usrloc.so >>>0(2577) loading module /usr/lib/ser/modules/registrar.so >>>0(2577) loading module /usr/lib/ser/modules/auth.so >>>0(2577) loading module /usr/lib/ser/modules/auth_db.so >>>0(2577) set_mod_param_regex: usrloc matches module usrloc >>>0(2577) set_mod_param_regex: found <db_mode> in module usrloc >>>[/usr/lib/ser/modules/usrloc.so] >>>0(2577) set_mod_param_regex: auth_db matches module auth_db >>>0(2577) set_mod_param_regex: found <calculate_ha1> in module auth_db >>>[/usr/lib/ser/modules/auth_db.so] >>>0(2577) set_mod_param_regex: auth_db matches module auth_db >>>0(2577) set_mod_param_regex: found <password_column> in module auth_db >>>[/usr/lib/ser/modules/auth_db.so] >>>0(2577) set_mod_param_regex: rr matches module rr >>>0(2577) set_mod_param_regex: found <enable_full_lr> in module rr >>>[/usr/lib/ser/modules/rr.so] >>>0(2577) find_export: found <mf_process_maxfwd_header> in module >>>maxfwd_module [/usr/lib/ser/modules/maxfwd.so] >>>0(2577) find_export: found <sl_send_reply> in module sl_module >>>[/usr/lib/ser/modules/sl.so] >>>0(2577) find_export: found <sl_send_reply> in module sl_module >>>[/usr/lib/ser/modules/sl.so] >>>0(2577) find_export: found <record_route> in module rr >>>[/usr/lib/ser/modules/rr.so] >>>0(2577) find_export: found <loose_route> in module rr >>>[/usr/lib/ser/modules/rr.so] >>>0(2577) find_export: found <t_relay> in module tm >>>[/usr/lib/ser/modules/tm.so] >>>0(2577) find_export: found <www_authorize> in module auth_db >>>[/usr/lib/ser/modules/auth_db.so] >>>0(2577) find_export: found <www_challenge> in module auth >>>[/usr/lib/ser/modules/auth.so] >>>0(2577) find_export: found <save> in module registrar >>>[/usr/lib/ser/modules/registrar.so] >>>0(2577) find_export: found <lookup> in module registrar >>>[/usr/lib/ser/modules/registrar.so] >>>0(2577) find_export: found <sl_send_reply> in module sl_module >>>[/usr/lib/ser/modules/sl.so] >>>0(2577) find_export: found <t_relay> in module tm >>>[/usr/lib/ser/modules/tm.so] >>>0(2577) find_export: found <sl_reply_error> in module sl_module >>>[/usr/lib/ser/modules/sl.so] >>>0(2577) routing table 0: >>>...blah >>>...blah >>>...blah >>>...blah >>>WARNING: could not rev. resolve 192.168.0.4 >>>Listening on >>> 127.0.0.1 [127.0.0.1]:5060 >>> 192.168.0.4 [192.168.0.4]:5060 >>>Aliases: MyHost:5060 localhost:5060 localhost.localdomain:5060 >>>config file ok, exiting... >>>0(2577) DEBUG: tm_shutdown : start >>>0(2577) DEBUG: tm_shutdown : empting hash table >>>0(2577) DEBUG: tm_shutdown: releasing timers >>>0(2577) DEBUG: tm_shutdown : removing semaphores >>>0(2577) DEBUG: tm_shutdown : done >>>0(2577) shm_mem_destroy >>>0(2577) destroying the shared memory lock >>>---------------------------------------------------------------- >>> >>>I couldn't find what is wrong in my configuration... >>> >>>BTW, I can add, remove and edit users in MySQL Database using "serctl" >>>subscribers commands (that means that my SER machine is talking with MySQL >>>server as in expected) >>> >>> >>>_______________________________________________ >>>Serusers mailing list >>>serusers(a)lists.iptel.org >>>http://lists.iptel.org/mailman/listinfo/serusers >>> >>> >>> >>> >> >>_______________________________________________ >>Serusers mailing list >>serusers(a)lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers >> >>. >> >> >> >> >> > > > >. > > >

18 years, 10 months

[Serusers] Cancel an Invite on ser 0.8.14

by Toni Barata

Hi All, Can someone checks why, in the situation of a client that cancels a call before the destination send a "180 ringing" to the proxy, that causes some troble to the proxy because it is not forwarding the cancel to the destination. See the following 2 examples : In this situation the cancel works fine: 651.327850 10.112.128.220 -> 10.112.128.247 SIP/SDP Request: INVITE sip:testef03@teste.pt, with session description 651.328725 10.112.128.247 -> 10.112.128.220 SIP Status: 100 trying -- your call is important to us 651.328778 10.112.128.247 -> 10.112.128.187 SIP/SDP Request: INVITE sip:testef03@10.112.128.187:7678, with session description 651.576892 10.112.128.187 -> 10.112.128.247 SIP Status: 180 Ringing 651.577005 10.112.128.247 -> 10.112.128.220 SIP Status: 180 Ringing 651.722172 10.112.128.220 -> 10.112.128.247 SIP Request: CANCEL sip:testef03@teste.pt 651.723047 10.112.128.247 -> 10.112.128.187 SIP Request: CANCEL sip:testef03@10.112.128.187:7678 651.723084 10.112.128.247 -> 10.112.128.220 SIP Status: 200 cancelling 651.723622 10.112.128.247 -> 10.112.128.220 SIP Status: 487 Request cancelled 651.724792 10.112.128.220 -> 10.112.128.247 SIP Request: ACK sip:testef03@teste.pt 651.899824 10.112.128.187 -> 10.112.128.247 SIP Status: 200 OK 651.900593 10.112.128.187 -> 10.112.128.247 SIP Status: 487 Request Terminated 651.900666 10.112.128.247 -> 10.112.128.187 SIP Request: ACK sip:testef03@10.112.128.187:7678 In this one, the cancel never reaches the destination client, so it keeps ringing... 657.866834 10.112.128.220 -> 10.112.128.247 SIP/SDP Request: INVITE sip:testef03@teste.pt, with session description 657.867667 10.112.128.247 -> 10.112.128.220 SIP Status: 100 trying -- your call is important to us 657.867720 10.112.128.247 -> 10.112.128.187 SIP/SDP Request: INVITE sip:testef03@10.112.128.187:7678, with session description 658.068940 10.112.128.247 -> 10.112.128.187 SIP/SDP Request: INVITE sip:testef03@10.112.128.187:7678, with session description 658.083368 10.112.128.220 -> 10.112.128.247 SIP Request: CANCEL sip:testef03@teste.pt 658.084201 10.112.128.247 -> 10.112.128.220 SIP Status: 200 ok -- no more pending branches 658.084948 10.112.128.247 -> 10.112.128.220 SIP Status: 487 Request cancelled 658.085933 10.112.128.220 -> 10.112.128.247 SIP Request: ACK sip:testef03@teste.pt 658.228348 10.112.128.187 -> 10.112.128.247 SIP Status: 180 Ringing 658.232010 10.112.128.187 -> 10.112.128.247 SIP Status: 180 Ringing Thanks, Toni

18 years, 10 months

Re: [Serusers] Instant Messaging User Agent Interoperabilityproblem

by Victor Huertas Garcia

Thank you very much! A very good explanation. Victor >From: "Samuel Osorio Calvo" <samuel.osorio(a)nl.thalesgroup.com> >To: <vhuertas(a)hotmail.com>, <jan(a)iptel.org>, <klaus.mailinglists(a)pernau.at> >CC: <serusers(a)lists.iptel.org> >Subject: Re: [Serusers] Instant Messaging User Agent >Interoperabilityproblem >Date: Fri, 01 Jul 2005 13:27:53 +0200 > >Hi! > >Regarding IM within SIP, there are two modes: paging and session. >The first is a kind of sms service, where users sends *few* messages(if you >are not a teenager... ;) ) . This is provided by the standard SIP request >MESSAGE. >The session mode provides the typical chat scenario, where users are typing >*constantly* message and they are exchanged in (soft) real time. This is >provided by the MSRP protocol defined by the IETF's group SIMPLE. In that >case, the MSRP session parameters are carried in the SDP body of the >INVITE. Once the Offer/Answer is completed, both end points can send >messages via the MSRP session. > >For both modes, SIP proxies (SER) do not require extended capabilities >because in both cases SIP requests (MESSAGE for paging and INVITE for >session) are proxied normally and finally arrive to the end points. The >main difference lies in the UA: the paging mode is widely supported because >almost all UA supports MESSAGE request, while the session mode is not yet >so extended because MSRP is quite new. > >Although Messenger started (>4.6 I think) with plain SIP supporting only >MESSAGE requests, it needed a chat session mode to be implemented and since >MSRP was not still finished, microsoft decided to develop its own protocol >(strange, isn't it?). That is why new versions of microsoft messenger are >not compatible with standard SIP UA. > >Once MSRP is extended (there's an open source implementation in >www.sipfoundry.org), standard SIP UA (excluding microsfot thing) will be >fully interoperable both in paging mode (MESSAGE) and session mode (MSRP). > >My 0.02, > >Samuel. > > >Unclassified. > >>> "Victor Huertas Garcia" <vhuertas(a)hotmail.com> 07/01/05 12:40PM >>> > > >Hi all, > >I am testing the Instant Message Service with the SER v0.8.14 and I see >that >it routes them correctly towards the destination user agent. However, what >I >have seen is a tremendous imcompatibility between user agents of different >vendors. > >Here just a bit of this: > >IM between two Windows Messenger 4.7. > >What I see it that the very first MESSAGE in the conversation is sent >towards the SER and it routes it perfectly but the subsequent MESSAGES are >exchange between both Messengers directly!!! It is weird... but this is how >it is working. > >IM between Window Messenger 4.7 and EyeBeam v1.1 > >The EyeBeam always send the MESSAGES towards the SIP proxy and messenger >receive them with no problem. However, when the messenger tries to send a >MESSAGE in the conversation it even doesn't send the packet (I tried to >capture it with Ethereal and no packet was sent at all) and subsequently >tell you that the text message could not be delivered to the destination. > >IM between EyeBeam v1.1 > >No problem at all. > >IM involving Windows Messenger 5.1 > >This version of messenger sends an INVITE to the destination before issuing >the MESSAGE. With EyeBeam is a total disaster and the comunication is not >possible. > > >My conclusion is that the SER has not implication in such incompatibility >at >all and that is a matter of interoperability among vendors and different >implementations of SIMPLE. Do you agree? > >Thanks in advance > >Victor > > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers >

18 years, 10 months

[Serusers] Error starting ser 0.9.3 with mysql

by leo＠ltcjp.com

Dear serusers, BACKGROUND: 1) I have installed FC4 successfully. 2) I have installed SER 0.9.3 WITHOUT mysql support successfully. I even made phone calls. 3) I then ran the ser_mysql.sh script successfully. I see the 'ser' database with its tables in mysql. 4) I them modifed ser.cfg to allow authentication. 5) I now get this message in the /var/log/messages file: Jun 30 16:02:09 sip ser: ERROR: load_module: could not open module </usr/local/lib/ser/modules/mysql.so>: libmysqlclient.so.12: cannot open shared object file: No such file or directory Jun 30 16:02:09 sip ser: parse error (35,13-14): failed to load module QUESTION: Why do I get the above error message? For reference the 1st 35 lines of my ser.cfg are enclosed. The above seems to be complaining about line 35, line 14, and line 15 # # $Id: ser.cfg,v 1.25.2.1 2005/02/18 14:30:44 andrei Exp $ # # simple quick-start config script # # ----------- global configuration parameters ------------------------ #debug=3 # debug level (cmd line: -dddddddddd) #fork=yes #log_stderror=no # (cmd line: -E) /* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */ check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) #port=5060 #children=4 fifo="/tmp/ser_fifo" fifo_mode=0666 #---leo's stuff listen=69.0.78.113 alias=sip.telecomcto.com alias=69.0.78.113 alias=telecomcto.com # ------------------ module loading ---------------------------------- # Uncomment this if you want to use SQL database loadmodule "/usr/local/lib/ser/modules/mysql.so" Sincerely, Leo P.

18 years, 10 months

[Serusers] call an user of another domain using a satndard phone

by Rosario Pingaro

I would like to configure ser to be able to seup call form two user from different domain using the standard phone. I'd like to rewrite request_uri with the second domain if the request uri is not present in my location tab. How to do it? Thanks

18 years, 10 months

[Serusers] SIP 481 in accounts

by Iqbal

Hi Some users seems to be getting BYE in acc with 481, which is obvioulsy corrupting the acc table, because I get say 4 BYE for 1 INVITE, 1 of the BYE is 200, the other 481, which after looking at the RFC has something to do with call leg transaction missing. Is this a client issue, and if so is there any fix, or is it better to ignore those acc records :-) Iqbal

18 years, 10 months

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