Check the log of the radius client (on /var/log/messages or
/var/log/syslog typically). There are reports about the error that
happened on the radius side (radius-ing failure).
Regards,
Bogdan
bay2x1 wrote:
> What seems to be the problem?
>
> This is the error log.
>
> Mar 3 15:25:43 ws16 /usr
What seems to be the problem?
This is the error log.
Mar 3 15:25:43 ws16 /usr/sbin/opensips[17364]: ERROR:acc:acc_rad_request:
radius-ing failed
Mar 3 15:26:38 ws16 media-dispatcher[2055]: [-] error: failed to send
radius accounting record: 'Sip-From-Tag'
Mar 3 15:26:38 ws16 /usr/sbin/opens
Any idea where to get this data from? Warning[1]: Impersonate must be
formated as CustomerId.ResellerId
This error happens when I try to supply data on impersonate on cdrtool web
application on edit account.
--
View this message in context:
http://n2.nabble.com/any-idea-on-this-error%21-Warning-
Hi Bodan,
I think that the serial fork have some problem.
On the DB I modified the q value of two user
User1, qvalue=0.1
User2, qvalue=0.2
I insert in the script the following line of code:
$ru=us...@domain.com
Lookup("location");
Append_branch();
$ru=us...@domain.com
Lookup("location");
Seria
Hey Bogdan,
I'm working with Serge on this. Thank you for the helper facts.
The TRACE log is before the error msg in the opensips.log. I've attached the
log to the bottom.
I'm hoping that our changes to the opensips.cfg are the cause of these errors.
We're currently manipulating $avp(i:25) and
2009/3/2 Dan Pascu :
>> Indeed, the OPTIONS may generate more traffic (depends on the
>> implementation - kphone sends with SDP also, other not). But when comes
>> to interoperability, OPTIONS is more accepted by end devices, rather
>> then NOTIFY (where the phone must implement the method and the
Hello Julian,
I have submitted your patch and it has been accepted! It's now in 1.4 branches
and in trunk version too! Bogdan has just asked if it was possible to adapt
it to trunk version (for 1.5.x)!
I haven't try already!
I'll try to do it later this week!
Best Regards!
Le Thursday 26 Februa
On Monday 02 March 2009, Bogdan-Andrei Iancu wrote:
> >> Anyhow, as best practice , the OPTIONS method is more appropriate
> >> for nat pinging.
> >
> > I have to disagree. OPTIONS generate 2-3 times more traffic because
> > of the bigger replies. OTOH, it doesn't really matter if we get a 200
> >
Hi Om,
Can you send me the full debug log (debug=6) for this scenario (you can
send it privately, if too big).
I just want to check exactly what is going one.
Thanks for your help,
Bogdan
Om Bikram Thapa wrote:
> Hi Bogdan,
>
> Seems like I replied too soon. OpenSIPS again crashed on INVITE,
>
Hi Dan,
Dan Pascu wrote:
> On Friday 27 February 2009, Bogdan-Andrei Iancu wrote:
>
>> Hi Carlo,
>>
>> I think the problem is with the phone as they do not understand the
>> "keep-alive" event sent in NOTIFY.
>>
>> It is nothing you can do about this (in is not on the proxy side).
>> Maybe in t
Hi Steven,
doolin wu wrote:
>
> Dear opensips users,
> Opensips 1.4.0 has been installed in my linux server with TLS enabled.
> I am confusing with the scenerio of how to use SIPS/TLS to make
> security VoIP by Opensips.
> I got the information like following from console afte
Hi Sergio,
First, some helper facts:
1) the message buffer is kept in private memory, so it cannot be written
by other processes
2) parsing of the first via is done before starting the script
execution, so, none of the modules can interfere with the buffer.
So, how do you get the TRACE log ?
On Friday 27 February 2009, Bogdan-Andrei Iancu wrote:
> Hi Carlo,
>
> I think the problem is with the phone as they do not understand the
> "keep-alive" event sent in NOTIFY.
>
> It is nothing you can do about this (in is not on the proxy side).
> Maybe in the future we can add a module parameter
13 matches
Mail list logo