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
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
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
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
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
>>
>>.
>>
>>
>>
>>
>>
>
>
>
>.
>
>
>
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
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
>
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.
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
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