Hi,
we try to compile ser 0.8.10 with radius support under Solaris 8.
First we have a problem with the radius_acc module. We found s
solution in the mailinglist archive. Now we have a problem with the
radius_auth module. If we compile it we get the following error
message:
digest.c -o digest.o
digest.c: In function `radius_authorize':
digest.c:79: `PW_SIP_NONCE' undeclared (first use in this function)
digest.c:79: (Each undeclared identifier is reported only once
digest.c:79: for each function it appears in.)
digest.c:83: `PW_SIP_NONCE_COUNT' undeclared (first use in this
function)
digest.c: In function `radius_authorize_freeradius':
digest.c:160: `PW_DIGEST_USER_NAME' undeclared (first use in this
function)
digest.c:164: `PW_DIGEST_REALM' undeclared (first use in this
function)
digest.c:168: `PW_DIGEST_NONCE' undeclared (first use in this
function)
digest.c:172: `PW_DIGEST_URI' undeclared (first use in this function)
digest.c:176: `PW_DIGEST_METHOD' undeclared (first use in this
function)
digest.c:184: `PW_DIGEST_QOP' undeclared (first use in this function)
digest.c:192: `PW_DIGEST_CNONCE' undeclared (first use in this
function)
digest.c:201: `PW_DIGEST_NONCE_COUNT' undeclared (first use in this
function)
digest.c:211: `PW_DIGEST_BODY_DIGEST' undeclared (first use in this
function)
digest.c:241: `PW_DIGEST_ALGORITHM' undeclared (first use in this
function)
digest.c:252: `PW_DIGEST_ATTRIBUTES' undeclared (first use in this
function)
digest.c:258: `PW_DIGEST_RESPONSE' undeclared (first use in this
function)
gmake: *** [digest.o] Error 1
we think that there some definitions not defined in an header-file. we
included the dict.h file from the radius_acc module(CVS version), so
most of the definitions PW_SIP_* are present.
Is there a possibility to get the missing definitions?
greetings bjoern
Hi,
Can I just cut and paste the script directly into the ser.cfg file?
-Chi
Original Message:
-----------------
From: serusers (Jiri) serusers(a)lists.iptel.org
Date: Tue, 11 Feb 2003 17:30:52 +0100
To: chid(a)eglobalcall.com, serusers(a)lists.iptel.org
Subject: Re: [Serusers] New Setup of SER
At 01:22 PM 2/11/2003, Chi Dang wrote:
>Hi,
>
>Sorry to be greedy but I have two questions. I've just finished
>installed the ser 0.8 version on Solaris 2.8.
>
>1. When I ran ser, it said it is listening to only 3 servers. I have
>added 2 more into my /etc/hosts file but make no difference. Where does
>ser daemon get the ip of servers that it is listening to?
/etc/hosts configures you resolver and does not affect the interfaces
configured on your host. ser determines existing interfaces but does
not care about your resolver's configuration.
>2. I plan to use ser with my cisco voip gateways. Is there anything
>special that I need to configure ser to make it work with Cisco
>gateways?
Maybe access control
http://www.iptel.org/ser/doc/seruser-html/x740.html#AEN786
Note that Cisco gateways have no digest support, so you are left
only with source IP address "authentication".
-Jiri
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
Hi,
Sorry to be greedy but I have two questions. I've just finished
installed the ser 0.8 version on Solaris 2.8.
1. When I ran ser, it said it is listening to only 3 servers. I have
added 2 more into my /etc/hosts file but make no difference. Where does
ser daemon get the ip of servers that it is listening to?
2. I plan to use ser with my cisco voip gateways. Is there anything
special that I need to configure ser to make it work with Cisco
gateways?
Thanks,
Chi Dang
Hi,
I am working on a 3rd Party Call Control implementation. Is it possible
to get notifyed as a 3rd Party (SER owner) when Sip Party A connects SIP
Party B?
Thank you!
karsten
Hi Daniel,
Ok, I found a configuration error on ser.cfg. On the Jaddress parameter the
Ip address had a sintax error (one of the dots was replaceded by a comma).
But now there is another problem:
- When the sip client (messenger) sends a IM to the Jabber client, the
jabber client do not receive the message but he is "notified" that the
sip-client is on-line.
- When the jabber client send an IM to the sip client the messages is
received by the sip client.
Any idea of what is going on?
Best regards,
Toni
-----Original Message-----
From: Daniel-Constantin MIERLA [mailto:mierla@fokus.fraunhofer.de]
Sent: sexta-feira, 31 de Janeiro de 2003 18:30
To: Toni Barata (EPS)
Subject: Re: [Serusers] user permission problem on ser-jabber gw
You have to set debug=9 and log_stderror=yes in ser's config file.
Debug messages will be displayed on console and you can copy/paste in a
file.
If you got that error message, means that ser-jabber gw was connected to
Jabber server, but something was happening and the connection was broken. So
some messages should have been exchanged between ser and Jabber. Did you
check all your network interfaces (I told you in last mail you have to sniff
loopback interface if Jabber server and ser is on the same machine)?
Regards,
Daniel
Toni Barata (EPS) wrote:
Hi,
I forgot to tell you that I put the ethereal sniffing the network and no
packet was sent by the ser-jabber gw to the port 5222 on the jabber server.
I seems that this is an internal problem on the ser-jabber. Is there a way
to send the logs to a file?
Best regards,
Toni
hello,
we are using ser 0.8.10.
it worked fine with SIP methods.
we would like to know whether we can use the ser to test the simple methods (simple, subscribe and notify methods)
with thanks and regards,
Anuradha
--
**************************************************************
eRiva provides IT Solutions & Services to companies worldwide.
Our State of the Art Research & Development Center provides
Innovative Solutions to global customers.
eRiva's unique value proposition is further delivered through our
Offshore Outsourcing Model and stringent Quality Processes
of SEI / ISO and Six Sigma. [www.erivasystems.com]
**************************************************************
--
Folks,
There is a bug in ser, which results in different hashes to be
generated if some of the fields participating in hash generation has
extra spaces before value in reply that were not present in request,
i.e.:
request:
From: <vasia_pupkin(a)1.2.3.4>
reply:
From: <vasia_pupkin(a)1.2.3.4>
This leads to matching failure and as a result causes useless
retransmition, if tm module is used. For example, Vovida's SIP stack
is found to be guilty in inserting extra spaces into reply's headers
(which isn't really prohibited by the RFC).
Attached little patch should fix the problem. It would be nice to have
it integrated into the next release.
Thanks!
-Maxim
Hi,
I was wondering whether there is a ser module for SIP-CGI. Or whether there
are attempts at creating one? If so, could anyone point me in the right
direction?
thanks,
Stephan
--
Dr Stephan Reiff-Marganiec
Research Fellow
Department of Computing Science; University of Stirling
email: srm(a)cs.stir.ac.uk tel: 01786 46 7448
--
The University of Stirling is a university established in Scotland by
charter at Stirling, FK9 4LA. Privileged/Confidential Information may
be contained in this message. If you are not the addressee indicated
in this message (or responsible for delivery of the message to such
person), you may not disclose, copy or deliver this message to anyone
and any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful. In such case, you should destroy this
message and kindly notify the sender by reply email. Please advise
immediately if you or your employer do not consent to Internet email
for messages of this kind. Opinions, conclusions and other
information in this message that do not relate to the official
business of the University of Stirling shall be understood as neither
given nor endorsed by it.
Hello,
I'm trying to setup the radius accounting module but SER craches wherever I make a call. The call does complete, but the core is generated a couple seconds later. Without rad_acc moudule SER works fine, so I assume this have something to do with the module.
I'm attaching some resumed debugs for the crash. I also have the complete debug (log level 10), wich is quite big so I decided not so send it to the list unless the following debugs are not enough.
Any ideas on what's the problem?
Thanks and regards,
Claudio Thorell
###########
...
6(24956) qm_free(0x80adf80, 0x80b5174), called from parser/msg_parser.c: free_sip_msg(487)
6(24956) qm_free: freeing block alloc'ed from action.c: do_action(346)
6(24956) qm_free(0x80adf80, 0x80b5090), called from parser/parse_via.c: free_via_param_list(1816)
6(24956) qm_free: freeing block alloc'ed from parser/parse_via.c: parse_via(1642)
6(24956) qm_free(0x80adf80, 0x80b52ec), called from parser/parse_via.c: free_via_list(1828)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: get_hdr_field(85)
6(24956) qm_free(0x80adf80, 0x80b5128), called from parser/hf.c: free_hdr_field_lst(103)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229)
6(24956) qm_free(0x80adf80, 0x80b4ff0), called from parser/hf.c: free_hdr_field_lst(103)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229)
6(24956) qm_free(0x80adf80, 0x80b4fa4), called from parser/hf.c: free_hdr_field_lst(103)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229)
6(24956) qm_free(0x80adf80, 0x80b46cc), called from parser/parse_to.c: free_to(741)
6(24956) qm_free: freeing block alloc'ed from parser/parse_to.c: parse_to_param(265)
6(24956) qm_free(0x80adf80, 0x80b482c), called from parser/parse_to.c: free_to(744)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: get_hdr_field(123)
6(24956) qm_free(0x80adf80, 0x80b479c), called from parser/hf.c: free_hdr_field_lst(103)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229)
6(24956) qm_free(0x80adf80, 0x80b51dc), called from parser/hf.c: free_hdr_field_lst(103)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229)
6(24956) qm_free(0x80adf80, 0x80b47e8), called from parser/parse_cseq.c: free_cseq(94)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: get_hdr_field(104)
6(24956) qm_free(0x80adf80, 0x80b5228), called from parser/hf.c: free_hdr_field_lst(103)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229)
6(24956) qm_free(0x80adf80, 0x80b4f58), called from parser/hf.c: free_hdr_field_lst(103)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229)
6(24956) qm_free(0x80adf80, 0x80b50dc), called from parser/hf.c: free_hdr_field_lst(103)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229)
6(24956) qm_free(0x80adf80, 0x80b4c70), called from parser/hf.c: free_hdr_field_lst(103)
6(24956) qm_free: freeing block alloc'ed from parser/msg_parser.c: parse_headers(229)
6(24956) qm_free(0x80adf80, 0x80b4d08), called from data_lump.c: free_lump_list(248)
6(24956) qm_free: freeing block alloc'ed from data_lump.c: del_lump(153)
6(24956) qm_free(0x80adf80, 0x80b475c), called from data_lump.c: free_lump(212)
6(24956) qm_free: freeing block alloc'ed from textops.c: append_hf(231)
6(24956) qm_free(0x80adf80, 0x80b4418), called from data_lump.c: free_lump_list(237)
6(24956) qm_free: freeing block alloc'ed from data_lump.c: insert_new_lump_before(129)
6(24956) qm_free(0x80adf80, 0x80b4cbc), called from data_lump.c: free_lump_list(248)
6(24956) qm_free: freeing block alloc'ed from data_lump.c: anchor_lump(183)
6(24956) qm_free(0x80adf80, 0x80b54bc), called from parser/msg_parser.c: free_sip_msg(493)
6(24956) qm_free: freeing block alloc'ed from receive.c: receive_msg(83)
6(24956) qm_free(0x80adf80, 0x80b4adc), called from receive.c: receive_msg(177)
6(24956) qm_free: freeing block alloc'ed from receive.c: receive_msg(63)
6(24956) qm_malloc(0x80adf80, 356) called from receive.c: receive_msg(63)
6(24956) qm_malloc(0x80adf80, 356) returns address 0x80b4adc on 0 -th hit
6(24956) qm_malloc(0x80adf80, 415) called from receive.c: receive_msg(83)
6(24956) qm_malloc(0x80adf80, 416) returns address 0x80b54bc on 0 -th hit
6(24956) SIP Request:
6(24956) method: <ACK>
6(24956) uri: <sip:1005@200.219.173.141;branch=0>
6(24956) version: <SIP/2.0>
6(24956) parse_headers: flags=1
6(24956) qm_malloc(0x80adf80, 28) called from parser/msg_parser.c: parse_headers(229)
6(24956) qm_malloc(0x80adf80, 28) returns address 0x80b4cbc on 0 -th hit
6(24956) qm_malloc(0x80adf80, 104) called from parser/msg_parser.c: get_hdr_field(85)
6(24956) qm_malloc(0x80adf80, 104) returns address 0x80b52ec on 0 -th hit
0(24946) child process 24961 exited by a signal 11
0(24946) core was generated
0(24946) INFO: terminating due to SIGCHLD
4(24954) Memory status (pkg):
4(24954) qm_status (0x80adf80):
4(24954) heap size= 1022872
4(24954) used= 1040, used+overhead=27272, free=995600
4(24954) max used (+overhead)= 27340
4(24954) dumping all allocked. fragments:
...