[asterisk-dev] RES: asterisk-dev Digest, Vol 24, Issue 5
Roberto
roberto at dialtech.com.br
Tue Jul 4 12:26:04 MST 2006
I have a question:
When we are using digium boards with echo cancelation (i.e. TE407), should
we set echo cancel on .conf files to no ?
Thanks
-----Mensagem original-----
De: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] Em nome de
asterisk-dev-request at lists.digium.com
Enviada em: terça-feira, 4 de julho de 2006 12:50
Para: asterisk-dev at lists.digium.com
Assunto: asterisk-dev Digest, Vol 24, Issue 5
Send asterisk-dev mailing list submissions to
asterisk-dev at lists.digium.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.digium.com/mailman/listinfo/asterisk-dev
or, via email, send a message with subject or body 'help' to
asterisk-dev-request at lists.digium.com
You can reach the person managing the list at
asterisk-dev-owner at lists.digium.com
When replying, please edit your Subject line so it is more specific than
"Re: Contents of asterisk-dev digest..."
Today's Topics:
1. Patch to app_queue to add annoucements to the caller (Tristan)
2. Re: Patch to app_queue to add annoucements to the caller
(Jared Smith)
3. realtime architecture blocks iax network thread (Dawid Mielnik)
4. Re: Character set for AMI/HTTP: UTF8 ? (Jared Smith)
5. Re: realtime architecture blocks iax network thread (Joshua Colp)
6. RE: app_queue (Mailing Lists)
7. Re: realtime architecture blocks iax network thread
(Tony Mountifield)
----------------------------------------------------------------------
Message: 1
Date: Tue, 04 Jul 2006 15:15:23 +0200
From: Tristan <tristan at telemaque.fr>
Subject: [asterisk-dev] Patch to app_queue to add annoucements to the
caller
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <44AA69EB.3030404 at telemaque.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi, here is a patch against 1.2.9.1 to add annoucements to the caller...
This patch is currently in beta here
Please provide comments on the code or the way I did it as it is my first
patch for asterisk...
I'm looking for your answers and any way to improve my codings ;)
Thanks a lot,
Tristan
----------------------------------------------------------------------------
------------------------------------
diff -rdbU3 asterisk-1.2.9.1/apps/app_queue.c
asterisk-current-1.2.9.1/apps/app_queue.c
--- asterisk-1.2.9.1/apps/app_queue.c 2006-06-04 05:43:35.000000000 +0200
+++ asterisk-current-1.2.9.1/apps/app_queue.c 2006-07-04
14:59:56.000000000 +0200
@@ -353,6 +354,9 @@
char sound_thanks[80]; /*!< Sound file: "Thank you for
your patience." (def. queue-thankyou) */
char sound_reporthold[80]; /*!< Sound file: "Hold time"
(def. queue-reporthold) */
char sound_periodicannounce[80];/*!< Sound file: Custom
announce, no default */
+ char sound_callerannounce[80];/*!< Sound file: Custom announce for
caller, no default */
+
+
int count; /*!< How many entries */
int maxlen; /*!< Max number of entries */
@@ -607,6 +611,9 @@
ast_copy_string(q->sound_lessthan, "queue-less-than",
sizeof(q->sound_lessthan));
ast_copy_string(q->sound_reporthold, "queue-reporthold",
sizeof(q->sound_reporthold));
ast_copy_string(q->sound_periodicannounce,
"queue-periodic-announce", sizeof(q->sound_periodicannounce));
+ ast_copy_string(q->sound_callerannounce, "queue-callerannounce",
sizeof(q->sound_callerannounce));
+
+
}
static void clear_queue(struct ast_call_queue *q)
@@ -750,6 +757,8 @@
ast_copy_string(q->sound_lessthan, val,
sizeof(q->sound_lessthan));
} else if (!strcasecmp(param, "queue-thankyou")) {
ast_copy_string(q->sound_thanks, val,
sizeof(q->sound_thanks));
+ } else if (!strcasecmp(param, "queue-callerannounce")) {
+ ast_copy_string(q->sound_callerannounce, val,
sizeof(q->sound_callerannounce));
} else if (!strcasecmp(param, "queue-reporthold")) {
ast_copy_string(q->sound_reporthold, val,
sizeof(q->sound_reporthold));
} else if (!strcasecmp(param, "announce-frequency")) {
@@ -2343,6 +2352,15 @@
}
/* Stop music on hold */
ast_moh_stop(qe->chan);
+
+ /* Play the announcement to the caller */
+
+ if (play_file(qe->chan, qe->parent->sound_callerannounce))
+ ast_log(LOG_WARNING, "Announcement file '%s' is
unavailable, continuing anyway...\n", qe->parent->sound_callerannounce);
+
+ /* End of play for the annoucement of the caller */
+
+
/* If appropriate, log that we have a destination channel */
if (qe->chan->cdr)
ast_cdr_setdestchan(qe->chan->cdr, peer->name);
@@ -2382,6 +2400,7 @@
ast_log(LOG_DEBUG, "app_queue:
sendurl=%s.\n", url);
ast_channel_sendurl(peer, url);
}
+
ast_queue_log(queuename, qe->chan->uniqueid, peer->name,
"CONNECT", "%ld", (long)time(NULL) - qe->start);
if (qe->parent->eventwhencalled)
manager_event(EVENT_FLAG_AGENT, "AgentConnect",
------------------------------
Message: 2
Date: Tue, 04 Jul 2006 07:24:17 -0600
From: Jared Smith <jaredsmith at jaredsmith.net>
Subject: Re: [asterisk-dev] Patch to app_queue to add annoucements to
the caller
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <1152019457.1001.23.camel at frankenbox>
Content-Type: text/plain
On Tue, 2006-07-04 at 15:15 +0200, Tristan wrote:
> Hi, here is a patch against 1.2.9.1 to add annoucements to the caller...
Thanks for submitting a patch! It's always good to have more people
contributing to the code base. Instead of posting your patches to the
mailing list, please post them to the bug tracker (bugs.digium.com)
instead. Also, you'll need to send a disclaimer to Digium (as explained
on the bug tracker) so that they're in good legal standing to actually
read your proposed patch.
-Jared
------------------------------
Message: 3
Date: Tue, 4 Jul 2006 15:25:32 +0200
From: "Dawid Mielnik" <dmielnik at voiceware.pl>
Subject: [asterisk-dev] realtime architecture blocks iax network
thread
To: <asterisk-dev at lists.digium.com>
Message-ID: <009701c69f6d$5435ee30$4301a8c0 at voiceware>
Content-Type: text/plain; format=flowed; charset="iso-8859-2";
reply-type=original
Hi,
We are using asterisk (ver 1.2.9.1) interfaced via realtime (mysql via
res_odbc or res_mysql) with a pretty large database for user authentication.
Recently we have started to observe quite severe call quality issues which
at first looked like network related problems - jitter, etc. After more
intense debugging and adding a few more debug options in chan_iax we have
noticed that realtime manages to effectively block iax's main thread on
database queries. We have started timing execution time of socet_read() in
iax and to our surprise, some unfortunate registration requests manage to
block the thread for couple hundred milliseconds - example below:
Jun 23 20:00:30.029201 DEBUG[32099] chan_iax2.c: Starting processing
'socket_read' (--NOW--)
Jun 23 20:00:30.029230 VERBOSE[32099] logger.c: Rx-Frame Retry[ No] --
OSeqno: 000 ISeqno: 000 Type: IAX Subclass: REGREQ
Jun 23 20:00:30.029259 VERBOSE[32099] logger.c: Timestamp: 00003ms
SCall: 10810 DCall: 00000 [83.15.91.90:3888]
Jun 23 20:00:30.029283 VERBOSE[32099] logger.c: USERNAME : 3764
Jun 23 20:00:30.029309 VERBOSE[32099] logger.c: REFRESH : 60
Jun 23 20:00:30.029326 VERBOSE[32099] logger.c:
Jun 23 20:00:30.243007 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.243031 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.258157 DEBUG[32099] chan_iax2.c: realtime_peer: Registration
for '3764' still active (60/1151085570/1151085630)!
Jun 23 20:00:30.260894 DEBUG[32099] chan_iax2.c: New max nontrunk callno is
13
Jun 23 20:00:30.260926 DEBUG[32099] chan_iax2.c: Creating new call structure
4
Jun 23 20:00:30.260951 DEBUG[32099] chan_iax2.c: Received packet 0, (6, 13)
Jun 23 20:00:30.260969 DEBUG[32099] chan_iax2.c: IAX subclass 13 received
Jun 23 20:00:30.260983 DEBUG[32099] chan_iax2.c: For call=4, set last=3
Jun 23 20:00:30.283004 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.283022 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.323000 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.323016 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.362997 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.363013 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.402995 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.403010 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.443098 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.443127 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.483001 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.483017 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.522996 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.523012 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.562994 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.563036 DEBUG[32093] res_musiconhold.c: Only wrote -1 of 640
bytes to pipe
Jun 23 20:00:30.596691 DEBUG[32099] chan_iax2.c: realtime_peer: Registration
for '3764' still active (60/1151085570/1151085630)!
Jun 23 20:00:30.596740 DEBUG[32092] chan_iax2.c: Checking device state for
device 3764
Jun 23 20:00:30.597436 DEBUG[32092] chan_iax2.c: realtime_peer: Registration
for '3764' still active (60/1151085570/1151085630)!
Jun 23 20:00:30.597455 DEBUG[32092] chan_iax2.c: iax2_devicestate(3764):
Found peer. What's device state of 3764? addr=1515917139, defaddr=0 maxms=0,
lastms=0
Jun 23 20:00:30.599940 DEBUG[32099] chan_iax2.c: realtime_peer: Registration
for '3764' still active (60/1151085570/1151085630)!
Jun 23 20:00:30.602617 DEBUG[32099] chan_iax2.c: Finished processing
'socket_read' (duration: 573 ms)
When we discovered it was the database interface causing all the problems we
have tried using realtime caching in iax, but the current caching
implementation isn't very effective. We have gained something like five
database requests during a call instead of six. What we have done eventually
is we have developed some quick work arounds by extending iax's realtime
caching. We have taken out realtime_update_peer() into a seperate thread
(database updates hurt the most), added a friend option to
ast_load_realtime() which instead of only building a peer also builds a user
and adds him to the user list, etc. In the end we have managed to cut
database interaction down to just one request per user (during
register_verify()) and from then on its all cached. We still have problems
with the one request that's left during first registration (in
register_verify()) since optimally it should be handled asynchronously to
the network thread but we havent managed to properly get inbound
registration out into a seperate thread - there are too many dependancies
there and we always end up in some dead-lock.
Is there anyone who noticed these problems ?
Clearly the current iax realtime implementation is bad and any 'large' iax
installation will run into problems. Database queries should not be handled
by the same thread that processes incoming iax voice frames.
Does this qualify for the bug tracker ? / Or is there anyone interested in
helping us fine brush iax realtime caching and work out a proper patch to
handle database interaction ? Our workarounds are ok in our arrangement
(although we still notice some problems), where all of our iax clients are
users and peers at the same time ..but in order to properly implement the
changes something that would take core iax developer a day or two would take
us a couple of weeks probably.
Thanks,
Dawid
------------------------------
Message: 4
Date: Tue, 04 Jul 2006 07:27:27 -0600
From: Jared Smith <jaredsmith at jaredsmith.net>
Subject: Re: [asterisk-dev] Character set for AMI/HTTP: UTF8 ?
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <1152019647.1001.27.camel at frankenbox>
Content-Type: text/plain
On Tue, 2006-07-04 at 09:22 +0200, Olle E Johansson wrote:
> Since both SIP and IAX2 now is Unicode, I would like to standardize
> the AMI/HTTP interface to UTF8 from start, before we release.
I think this is a good idea, so I'. I know there are others out there
thinking "Eeew... UTF-8. That's scary!" but I agree with Olle -- let's
do this right from the beginning. (It's too bad I can't turn back time
and start out using UTF-8 on several other projects I've worked on in
the past -- it would have saved me considerable headaches.)
-Jared
------------------------------
Message: 5
Date: Tue, 04 Jul 2006 12:10:18 -0300
From: Joshua Colp <jcolp at digium.com>
Subject: Re: [asterisk-dev] realtime architecture blocks iax network
thread
To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
Message-ID: <C0D00B2A.F36F%jcolp at digium.com>
Content-Type: text/plain; charset="US-ASCII"
On 7/4/06 10:25 AM, "Dawid Mielnik" <dmielnik at voiceware.pl> wrote:
> Hi,
>
> We are using asterisk (ver 1.2.9.1) interfaced via realtime (mysql via
> res_odbc or res_mysql) with a pretty large database for user
authentication.
> Recently we have started to observe quite severe call quality issues which
> at first looked like network related problems - jitter, etc. After more
> intense debugging and adding a few more debug options in chan_iax we have
> noticed that realtime manages to effectively block iax's main thread on
> database queries. We have started timing execution time of socet_read() in
> iax and to our surprise, some unfortunate registration requests manage to
> block the thread for couple hundred milliseconds - example below:
This is actually fixed in trunk, chan_iax2 has been multithreaded instead of
using a single thread. It wasn't put in 1.2 because 1.2 is only for bug
fixes, not new experimental features.
--
Joshua Colp
Software Developer
Digium
P - 256-428-6066
C - 506-878-0147
jcolp at digium.com
------------------------------
Message: 6
Date: Tue, 4 Jul 2006 17:24:48 +0200
From: "Mailing Lists" <mailing.lists at ecr-consulting.se>
Subject: RE: [asterisk-dev] app_queue
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Message-ID:
<A6BD87D8D09BAA4EB5E02086E9B0D89611710E at sgex01.lan.sipgear.com>
Content-Type: text/plain; charset="us-ascii"
I'm running 1.2.7 and I can see in the logs that asterisk is not
including agents that are busy on the phone in the dial list when
placing calls to agents. On the other hand if someone has called the
same extension directly (not through the queue) and then someone else is
calling the queue, the agent receives the queued call on the 2nd line
(callwaiting). For me it looks like asterisk is building a list of
agents that is available (not including agents that are known to be
busy) for the head call in the queue. Have I done something totally
wrong here? The strategy is ringall.
/urban
-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Johansson
Olle E
Sent: den 4 juli 2006 12:43
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] app_queue
4 jul 2006 kl. 11.23 skrev Mailing Lists:
> Hi,
>
>
>
> Would it be a lot of work to change app_queue so that SIP agents
> that is
> busy and have callwaiting enabled will be included in the ringall list
> for next call in queue? I have looked in the source code but it's not
> obvious for me where this list is created. Any ideas or hints are
> appreciated and welcome.
If a SIP peer has a device that supports call waiting, Asterisk will
gladly
send the call there, unless there's a call limit that prevents it
from happening.
Or does the queues behave differently here?
/Olle
---
Olle E. Johansson * Asterisk Evangelist, developer * VOOP A/S
olle at voop.com
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
------------------------------
Message: 7
Date: Tue, 4 Jul 2006 15:49:52 +0000 (UTC)
From: tony at softins.clara.co.uk (Tony Mountifield)
Subject: [asterisk-dev] Re: realtime architecture blocks iax network
thread
To: asterisk-dev at lists.digium.com
Message-ID: <e8e2n0$isn$1 at softins.clara.co.uk>
In article <009701c69f6d$5435ee30$4301a8c0 at voiceware>,
Dawid Mielnik <dmielnik at voiceware.pl> wrote:
> Hi,
>
> We are using asterisk (ver 1.2.9.1) interfaced via realtime (mysql via
> res_odbc or res_mysql) with a pretty large database for user
authentication.
> Recently we have started to observe quite severe call quality issues which
> at first looked like network related problems - jitter, etc. After more
> intense debugging and adding a few more debug options in chan_iax we have
> noticed that realtime manages to effectively block iax's main thread on
> database queries.
You might want to try out the Trunk version of Asterisk. It has a multi-
threaded implementation of IAX, which may possibly solve your problem.
Cheers
Tony
--
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org
------------------------------
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
End of asterisk-dev Digest, Vol 24, Issue 5
*******************************************
More information about the asterisk-dev
mailing list