Hello,
anybody between you knows how we can see SIP messages of the server of
redirect (code 302), and the ser can make the redirection of call???
Thank you in advance
Hassan
CHOUMAR Hassan
cité universitaire de la pacaterie (chambre459)
91400 Orsay
Por :33/0675909977
Email: hmchoumar(a)hotmail.com
I am doing a new install of serweb. I go to the admin
login and attempt to login with default password but
it just returns me to the login screen... it does not
give me any error, just no progress.
Any thoughts?
cameron
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
I had that problem, and found that it was because the admin was in the iptel.org realm, and not in my realm. Just make a user into your realm, make it an admin, and you should be all set.
-----Original Message-----
From: invidious7(a)yahoo.com [mailto:invidious7@yahoo.com]
Sent: Wednesday, August 13, 2003 5:55 PM
To: serusers(a)lists.iptel.org
Subject: [Serusers] serweb wont authenticate me
I am doing a new install of serweb. I go to the admin
login and attempt to login with default password but
it just returns me to the login screen... it does not
give me any error, just no progress.
Any thoughts?
cameron
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
The gateway receives an INVITE with a tag in the "To:" header, but can't find an existing dialog (=call-id + to-tag + from tag) to this INVITE. The gateway doen't treat the INVITE as the beginning of a new dialog, because the TO-tag is already present.
I think SIPPS should not use the to-tag recevied by ser in the second INVITE, as a 4xx respond does not create a dialog.
regards,
Klaus
-----Original Message-----
From: Greg Fausak [mailto:greg@august.net]
Sent: Tue 12.08.2003 22:33
To: 'SER Users'
Cc: sip(a)addaline.com
Subject: [Serusers] SIPPS UA
I've been trying to get the SIPPS UA working with
My addaline.com setup. I keep getting the error:
SIP/2.0 481 Call Leg/Transaction Does Not Exist.
No matter what the far end is. I am able to call this UA from anywhere
After it registers. Anybody have any ideas?
Here is the an example call flow:
http://www.addaline.com/traces/sipp_index.html
The only thing I notice that is weird is the 'Route' in the
F4 packet.
---greg
Greg Fausak
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Dear SER users,
I would like to collect feedback on use of RADIUS with SIP.
There is a concern in the IETF that RADIUS is not good enough
for accounting due to its lack of reliability. On the other hand,
use of RADIUS for us has been one of the most frequently asked
SER features.
Can people with hands on real deployments share their experience
with me? I'm interested in aspects like how the missing reliability
has been stressing your operation, how much they are interested
in fixing it, and what kind of fixes they would welcoyme (transition
to Diameter? adding fail-over capabilities?)
-Jiri
>> There is a believe in the IETF that lack of reliability in RADIUS
>> determines this work to be dropped. (Authentication is a different
>> story, though.)
>
>The point of this particular discussion is to understand whether
>specification of RADIUS transport behavior might be helpful in that
>regard, or whether we've have to go further (such as specifying failover
>behavior).
>
>Reading RFC 2865, one of the reasons that RADIUS was not made to run over
>TCP in the first place was that it was desired that failover occur in a
>timeframe prior to connection failure. RFC 3539 handles this issue by
>defining application-layer timers and heartbeats that allow the AAA
>application to re-send an accounting packet over another connection before
>tearing down a suspect one.
>
>Via the heartbeat mechanism, the AAA client can determine whether the
>issue is due to its immediate connection, or something downstream.
>Failover only occurs if the immediate connection is found to be suspect,
>so failover occurs on a hop-by-hop basis.
>
>RFC 3539 cannot be applied to the RADIUS protocol as it stands because
>RADIUS does not support a heartbeat. As a result, a RADIUS client can
>failover even where its immediate proxy is healthy, because of a problem
>on a downstream RADIUS server. Since RADIUS failover is
>typically end-to-end, there may be no failover in proxies, even if a
>server is not responding to requests proxied to it.
>
>Even if one were to define appropriate RTT/RTO measurements, and use traffic
>from the proxy as a demonstration of "liveness", inappropriate failover
>can still happen in cases where the time between proxy traffic is greater
>than the failover timer.
>
>The end result is that to be able to apply RFC 3539, one would need to add
>a heartbeat command to RADIUS. This is a fairly major step, since it
>would require changing both RADIUS client and server implementations.
>
>So the question is:
>
>"If a major protocol change were to be made to RADIUS to improve
>reliability, would such a change be deployed on RADIUS clients and
>servers and would it be acceptable for the SIP accounting specification
>to depend on such a change?"
>
>If the answer is yes, then a RADIUS failover spec might be worth
>discussing further. If no, then it seems to me that a RADIUS failover spec it might
>not be worth doing -- it's not considered important enough to get over the deployment hurdles.
>That raises the question of whether a dependency even on transport
>behavior improvements is possible, since even this would still require
>changes on RADIUS clients (though not servers).
>
>Comments?
--
Jiri Kuthan http://iptel.org/~jiri/
You have to install php with mysql module support :)
-m
-----Original Message-----
From: Hassan CHOUMAR [mailto:Hassan.Choumar@int-evry.fr]
Sent: Wed 8/13/2003 6:28 AM
To: serusers(a)iptel.org
Cc:
Subject: [Serusers] Hello all
Hello all,
I installed SER, on my PC, and he works well with the data base Mysql,
and with regard to serweb, I configured everything files according to
the guide who exists on the Web site: // iptel.org / ser, but my
problem is that when I open the serweb page to add users, it gives me
an error message:
fatal erreur: call to undefined function :mysql-pconnect() in
/var/www/html/phplib/db_mysql.inc on the line 73
What is that nobody can resolve my problem
Thank you in advance
Hassan
CHOUMAR Hassan
cité universitaire de la pacaterie (chambre459)
91400 Orsay
Por :33/0675909977
Email: hmchoumar(a)hotmail.com
_______________________________________________
Serusers mailing list
Serusers(a)iptel.org
http://mail.iptel.org/mailman/listinfo/serusers
We are a team of students working with SIP for various projects, and SER has
become an important part of our research.
I have been charged with looking into the latest stable build from CVS and
deciding if we should upgrade (currently 0.8.10), and how.
Has anyone moved a working 0.8.10 installation to the latest code? I see
from the mailing list that serweb and ser should be kept "in-sync" to avoid
problems, are there any other issues we should watch out for?
Folks,
I've noticed that 0.8.11pre1 some time ago started sending very strange
messages into the log with 1 minute interval:
[...]
Aug 9 20:08:01 sip ser[54856]: removing spare zombie
'5113210007','sip:51132100
07@200.106.25.235:5060;user=phone;transport=udp'
Aug 9 20:09:02 sip ser[54856]: removing spare zombie
'5113210007','sip:51132100
07@200.62.138.15:5060;user=phone;transport=udp'
Aug 9 20:10:03 sip ser[54856]: removing spare zombie
'5113210007','sip:51132100
07@200.106.25.235:5060;user=phone;transport=udp'
Aug 9 20:11:03 sip ser[54856]: removing spare zombie
'5113210007','sip:51132100
07@200.62.138.15:5060;user=phone;transport=udp'
Aug 9 20:12:04 sip ser[54856]: removing spare zombie
'5113210007','sip:51132100
07@200.62.138.15:5060;user=phone;transport=udp'
[...]
Does anybody have any ideas what is that and how to get rid of it?
-Maxim
Perfect! Thank you. As far as the ideal configuration question below....
Any thoughts around configuration for a single function SIP server
running SER?
Should I stick with Red Hat 9?
Thanks again,
Chad
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: Tuesday, August 12, 2003 8:40 AM
To: Chad Brown
Cc: Daniel-Constantin.Mierla(a)fokus.fraunhofer.de; serusers(a)lists.iptel.org
Subject: Re: [Serusers] SER Service Hanging
The problem has been fixed in the CVS stable version. See
http://iptel.org/ser/cvs for more information on obtaining CVS stable
version.
Jan.
On 12-08 08:39, Chad Brown wrote:
> I installed ser-0.8.10-2.i386.rpm from
> ftp://ftp.berlios.de/pub/ser/latest/packages/redhat/7.x/
>
> What do you think?
>
> Chad
>
>
> -----Original Message-----
> From: Daniel-Constantin Mierla
> [mailto:Daniel-Constantin.Mierla@fokus.fraunhofer.de]
> Sent: Tuesday, August 12, 2003 12:54 AM
> To: Chad Brown
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] SER Service Hanging
>
> Hello,
> what version of SER do you run? Did you install ser from RPMs (pre29)?
> We have fixed a such issue some time ago and we haven't received
> feedback that the problem is still there (btw pre29 has this bug).
> Please take the latest stable CVS snapshot (see
> http://www.iptel.org/ser/cvs/ for guidelines to get it) and try again,
> if you didn't do it yet. Otherwise confirm that latest stable SER
hangs
> at startup.
>
> Best regards,
> Daniel
>
> Chad Brown wrote:
>
> > I am running SER under Red Hat version 9. 30% of the time the SER
> > service will hang when rebooting the server. Simply restarting a
time
> > or two will ultimately take care of the problem. This intermittent
> > problem is very frustrating, does anyone have an idea.
> >
> >
> >
> > This server will be dedicated to running SER and therefore I have
been
>
> > looking for ways to increase performance. Perhaps I should ask for
> > ideas around a configuration that will be solid, reliable and
> > preferment when dedicated to SER. I would be open to switching to a
> > different OS if needed.
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Chad
> >
>
>
>
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
