|
List Info
Thread: Too many calls, we're busy!
|
|
| Too many calls, we're busy! |
  Germany |
2007-07-06 04:02:31 |
Hi,
we are using the mozphone together with an asterisk 1.2.18.
The mozphone logs in and is called in the dialplan by a
dialcommand. The
mozphone is set to autoanswer, I have not yet figured out if
that
changes something.
Randomly the mozphone replies in iax2 debug "Too many
calls, we're
busy!", even if the mozphone has never
had a call and just logged in.
I think it is caused by something in the iaxclient library,
there are
some commented lines in iaxclient_lib.c like:
//iax_reject(e->session, "Too many calls, we're
busy!"); //frik:
replaced this with busy instead
As this is uncommented there are only two possibilities for
this line to
occur in the asterisk log:
1. The Line was uncommented recently/or even after the
iaxclient library
found its way into mozphone
2. Its somewhere else and I have overseen
Shall I update the iaxclient library in my testenvironment
to figure out
if this happens too with the newer library - will
a newer library work at all?
Knud
The Asterisk Log:
Verbosity is at least 999
-- Remote UNIX connection
Tx-Frame Retry[000] -- OSeqno: 026 ISeqno: 028 Type: IAX
Subclass: PING
Timestamp: 100001ms SCall: 00003 DCall: 05545
[XXX.XXX.XXX.XXX:4569]
Tx-Frame Retry[000] -- OSeqno: 027 ISeqno: 028 Type: IAX
Subclass: LAGRQ
Timestamp: 100004ms SCall: 00003 DCall: 05545
[XXX.XXX.XXX.XXX:4569]
Rx-Frame Retry[ No] -- OSeqno: 028 ISeqno: 027 Type: IAX
Subclass: ACK
Timestamp: 100001ms SCall: 05545 DCall: 00003
[XXX.XXX.XXX.XXX:4569]
Rx-Frame Retry[ No] -- OSeqno: 028 ISeqno: 027 Type: IAX
Subclass: PONG
Timestamp: 100001ms SCall: 05545 DCall: 00003
[XXX.XXX.XXX.XXX:4569]
RR_JITTER : 38
RR_LOSS : 0
RR_PKTS : 4999
RR_DELAY : 117
RR_DROPPED : 1
RR_OUTOFORDER : 17
Tx-Frame Retry[-01] -- OSeqno: 027 ISeqno: 029 Type: IAX
Subclass: ACK
Timestamp: 100001ms SCall: 00003 DCall: 05545
[XXX.XXX.XXX.XXX:4569]
Rx-Frame Retry[ No] -- OSeqno: 028 ISeqno: 028 Type: IAX
Subclass: ACK
Timestamp: 100004ms SCall: 05545 DCall: 00003
[XXX.XXX.XXX.XXX:4569]
Rx-Frame Retry[ No] -- OSeqno: 029 ISeqno: 028 Type: IAX
Subclass: LAGRP
Timestamp: 100004ms SCall: 05545 DCall: 00003
[XXX.XXX.XXX.XXX:4569]
Tx-Frame Retry[-01] -- OSeqno: 028 ISeqno: 030 Type: IAX
Subclass: ACK
Timestamp: 100004ms SCall: 00003 DCall: 05545
[XXX.XXX.XXX.XXX:4569]
Rx-Frame Retry[ No] -- OSeqno: 030 ISeqno: 028 Type: IAX
Subclass: PING
Timestamp: 103340ms SCall: 05545 DCall: 00003
[XXX.XXX.XXX.XXX:4569]
Tx-Frame Retry[000] -- OSeqno: 028 ISeqno: 031 Type: IAX
Subclass: PONG
Timestamp: 103340ms SCall: 00003 DCall: 05545
[XXX.XXX.XXX.XXX:4569]
RR_JITTER : 0
RR_LOSS : 0
RR_PKTS : 1
RR_DELAY : 40
RR_DROPPED : 0
RR_OUTOFORDER : 0
Rx-Frame Retry[ No] -- OSeqno: 031 ISeqno: 029 Type: IAX
Subclass: ACK
Timestamp: 103340ms SCall: 05545 DCall: 00003
[XXX.XXX.XXX.XXX:4569]
== Parsing '/etc/asterisk/manager.conf': Found
== Manager 'dialer' logged on from XXX.XXX.XXX.XXX
Tx-Frame Retry[000] -- OSeqno: 000 ISeqno: 000 Type: IAX
Subclass: NEW
Timestamp: 00014ms SCall: 00002 DCall: 00000
[XXX.XXX.XXX.XXX:4569]
VERSION : 2
CALLED NUMBER : s
CODEC_PREFS : (ulaw|gsm)
CALLING NUMBER : 5512
CALLING PRESNTN : 0
CALLING TYPEOFN : 0
CALLING TRANSIT : 0
LANGUAGE : en
USERNAME : 99999_agent1
FORMAT : 2
CAPABILITY : 63494
ADSICPE : 0
DATE TIME : 2007-07-06 09:44:02
== Manager 'dialer' logged off from XXX.XXX.XXX.XXX
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX
Subclass: ACK
Timestamp: 00014ms SCall: 05548 DCall: 00002
[XXX.XXX.XXX.XXX:4569]
Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 001 Type: IAX
Subclass:
REJECT
Timestamp: 00060ms SCall: 05548 DCall: 00002
[XXX.XXX.XXX.XXX:4569]
CAUSE : Too many calls, we're busy!
Jul 6 09:44:04 WARNING[23340]: chan_iax2.c:7118
socket_read: Call
rejected by XXX.XXX.XXX.XXX: Too many calls, we're busy!
> Channel IAX2/99999_agent1-2 was never answered.
Tx-Frame Retry[-01] -- OSeqno: 001 ISeqno: 001 Type: IAX
Subclass: ACK
Timestamp: 00060ms SCall: 00002 DCall: 05548
[XXX.XXX.XXX.XXX:4569]
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
Jul 6 09:44:04 NOTICE[23340]: chan_iax2.c:1629
iax2_destroy: Avoiding
IAX destroy deadlock
-- Hungup 'IAX2/99999_agent1-2'
-- Executing Conference("OutgoingSpoolFailed",
"failed") in new stack
Jul 6 09:44:04 NOTICE[19113]: member.c:415 member_exec: [
$Revision:
1.9 $ ] begin processing member thread, channel =>
OutgoingSpoolFailed
Jul 6 09:44:04 ERROR[19113]: member.c:427 member_exec:
unable to answer
call
== Spawn extension (democonference, failed, 1) exited
non-zero on
'OutgoingSpoolFailed'
-- Executing Conference("OutgoingSpoolFailed",
"h") in new stack
Jul 6 09:44:04 NOTICE[19113]: member.c:415 member_exec: [
$Revision:
1.9 $ ] begin processing member thread, channel =>
OutgoingSpoolFailed
Jul 6 09:44:04 ERROR[19113]: member.c:427 member_exec:
unable to answer
call
== Spawn extension (democonference, h, 1) exited non-zero
on
'OutgoingSpoolFailed'
--
Knud A. Müller
_______________________________________________
Moziax mailing list
Moziax mozdev.org
http://mozd
ev.org/mailman/listinfo/moziax
|
|
| Re: Too many calls, we're busy! |
  French Polynesia |
2007-07-15 15:05:46 |
Hi Knud,
Sorry for late reply, I'm currently on vacations, with
limited access to
email.
Knud Müller a écrit :
> Hi,
>
> we are using the mozphone together with an asterisk
1.2.18.
> The mozphone logs in and is called in the dialplan by a
dialcommand. The
> mozphone is set to autoanswer, I have not yet figured
out if that
> changes something.
> Randomly the mozphone replies in iax2 debug "Too
many calls, we're
> busy!", even if the mozphone has never
> had a call and just logged in.
>
> I think it is caused by something in the iaxclient
library, there are
> some commented lines in iaxclient_lib.c like:
>
> //iax_reject(e->session, "Too many calls, we're
busy!"); //frik:
> replaced this with busy instead
>
> As this is uncommented there are only two possibilities
for this line to
> occur in the asterisk log:
> 1. The Line was uncommented recently/or even after the
iaxclient library
> found its way into mozphone
> 2. Its somewhere else and I have overseen
>
> Shall I update the iaxclient library in my
testenvironment to figure out
> if this happens too with the newer library - will
> a newer library work at all?
A newer library will not work without some modifications
(I've sent a
patch of my modifications to old libiaxclient on the mailing
list, if
you're interested). I don't know if it would solve this
problem. I've
tried using newer versions of the library but some problems
(reported on
the list or in my test environment) appear where old version
did work
fine...
Best regards,
--
Jean-Denis Girard
SysNux Systèmes Linux en Polynésie
française
http://www.sysnux.pf/
Tél: +689 483 527 / GSM: +689 797 527
_______________________________________________
Moziax mailing list
Moziax mozdev.org
http://mozd
ev.org/mailman/listinfo/moziax
|
|
| Re: Too many calls, we're busy! |
  Germany |
2007-07-16 02:00:43 |
Hi Jean-Denis,
thanks for your reply. I didn't wan't to disturb you on your
vacations!
Where do a French Polynesian go on vacation? French
Polynesia - must be
paradise?
Knud
Jean-Denis Girard schrieb:
> Hi Knud,
>
> Sorry for late reply, I'm currently on vacations, with
limited access to
> email.
>
> Knud Müller a écrit :
>
>> Hi,
>>
>> we are using the mozphone together with an asterisk
1.2.18.
>> The mozphone logs in and is called in the dialplan
by a dialcommand. The
>> mozphone is set to autoanswer, I have not yet
figured out if that
>> changes something.
>> Randomly the mozphone replies in iax2 debug
"Too many calls, we're
>> busy!", even if the mozphone has never
>> had a call and just logged in.
>>
>> I think it is caused by something in the iaxclient
library, there are
>> some commented lines in iaxclient_lib.c like:
>>
>> //iax_reject(e->session, "Too many calls,
we're busy!"); //frik:
>> replaced this with busy instead
>>
>> As this is uncommented there are only two
possibilities for this line to
>> occur in the asterisk log:
>> 1. The Line was uncommented recently/or even after
the iaxclient library
>> found its way into mozphone
>> 2. Its somewhere else and I have overseen
>>
>> Shall I update the iaxclient library in my
testenvironment to figure out
>> if this happens too with the newer library - will
>> a newer library work at all?
>>
>
> A newer library will not work without some
modifications (I've sent a
> patch of my modifications to old libiaxclient on the
mailing list, if
> you're interested). I don't know if it would solve this
problem. I've
> tried using newer versions of the library but some
problems (reported on
> the list or in my test environment) appear where old
version did work
> fine...
>
>
> Best regards,
> --
> Jean-Denis Girard
>
> SysNux Systèmes Linux en Polynésie
française
> http://www.sysnux.pf/
Tél: +689 483 527 / GSM: +689 797 527
>
> _______________________________________________
> Moziax mailing list
> Moziax mozdev.org
> http://mozd
ev.org/mailman/listinfo/moziax
>
>
--
Knud A. Müller
Geschäftsführer
Tel.: 040/398053-11
Fax: 040/398053-29
e-Mail: k.mueller portrix.net
portrix.net GmbH
Stresemannstr. 375
22761 Hamburg
HRB 79850 (Amtsgericht Hamburg)
Geschäftsführer: Knud Alex Müller, Henning Voss, Niclas
Schroeder
http://www.portrix.net
_______________________________________________
Moziax mailing list
Moziax mozdev.org
http://mozd
ev.org/mailman/listinfo/moziax
|
|
| Re: Too many calls, we're busy! |
  Germany |
2007-07-16 02:49:56 |
Hi Jean-Denis,
another Question: which compiler do you use to build the
windows exe. We
tried Visual c++ and had Problems, tried the Borland and
Intel and had
Problems too.
Knud
Jean-Denis Girard schrieb:
> Hi Knud,
>
> Sorry for late reply, I'm currently on vacations, with
limited access to
> email.
>
> Knud Müller a écrit :
>
>> Hi,
>>
>> we are using the mozphone together with an asterisk
1.2.18.
>> The mozphone logs in and is called in the dialplan
by a dialcommand. The
>> mozphone is set to autoanswer, I have not yet
figured out if that
>> changes something.
>> Randomly the mozphone replies in iax2 debug
"Too many calls, we're
>> busy!", even if the mozphone has never
>> had a call and just logged in.
>>
>> I think it is caused by something in the iaxclient
library, there are
>> some commented lines in iaxclient_lib.c like:
>>
>> //iax_reject(e->session, "Too many calls,
we're busy!"); //frik:
>> replaced this with busy instead
>>
>> As this is uncommented there are only two
possibilities for this line to
>> occur in the asterisk log:
>> 1. The Line was uncommented recently/or even after
the iaxclient library
>> found its way into mozphone
>> 2. Its somewhere else and I have overseen
>>
>> Shall I update the iaxclient library in my
testenvironment to figure out
>> if this happens too with the newer library - will
>> a newer library work at all?
>>
>
> A newer library will not work without some
modifications (I've sent a
> patch of my modifications to old libiaxclient on the
mailing list, if
> you're interested). I don't know if it would solve this
problem. I've
> tried using newer versions of the library but some
problems (reported on
> the list or in my test environment) appear where old
version did work
> fine...
>
>
> Best regards,
> --
> Jean-Denis Girard
>
> SysNux Systèmes Linux en Polynésie
française
> http://www.sysnux.pf/
Tél: +689 483 527 / GSM: +689 797 527
>
> _______________________________________________
> Moziax mailing list
> Moziax mozdev.org
> http://mozd
ev.org/mailman/listinfo/moziax
>
>
--
Knud A. Müller
Geschäftsführer
Tel.: 040/398053-11
Fax: 040/398053-29
e-Mail: k.mueller portrix.net
portrix.net GmbH
Stresemannstr. 375
22761 Hamburg
HRB 79850 (Amtsgericht Hamburg)
Geschäftsführer: Knud Alex Müller, Henning Voss, Niclas
Schroeder
http://www.portrix.net
_______________________________________________
Moziax mailing list
Moziax mozdev.org
http://mozd
ev.org/mailman/listinfo/moziax
|
|
[1-4]
|
|