Re: [asterisk-dev] chan_cellphone - Mantis issue 8919
On Monday 14 May 2007 9:18 am, Steve Totaro wrote: Sort of like name Asterisk Asterisk. It is a wildcard that covers everything. Ok, so it's settled then. chan_asterisk. -A. ___ --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
Re: [asterisk-dev] chan_cellphone - Mantis issue 8919
On Thursday 10 May 2007 2:26 pm, Olle E Johansson wrote: chan_pan :-) PAN/nokia PAN/peter PAN = Personal Area Network Eww... this isn't using the PAN profile at all, so I don't think that'd be right... chan_HFP or HSP would be my guess if you wanted to go that route... but yeah chan_bluetooth should really be what this should be called, since it'll handle damn near everything. -A. ___ --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
Re: [asterisk-dev] M9645: provide zaptel master timing to spans
On Wednesday 02 May 2007 10:41 am, Tzafrir Cohen wrote: What do you think of expanding the patch to disable interrupts on subsequent cards? That approach helps for multiple cards that are driven by the same driver. What about a system with two different card types? Why would it matter? All zaptel cards do work on a 1ms interval. The wct4xx driver does more than the wcfxo for sure, but the interrupt timing and structure is the same. I took a (very) quick look at wcfxo.c, wct1xxp.c and wct4xxp/base.c. When you get an interrupt, couldn't you simply chain through their respective handlers? I don't see any reason why not. Also consider an mISDN card providing timing through the ztdummy external timing patch: http://bugs.digium.com/view.php?id=8896 Yes, this appears to be a first-pass implementation of having Zaptel able to take interrupts from one place and using them. -A. ___ --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
Re: [asterisk-dev] M9645: provide zaptel master timing to spans
On Wednesday 02 May 2007 1:43 pm, Matthew Fredrickson wrote: Because if you're dealing with a DMA'd buffer, the data in the buffer could be in an inconsistent state. For example, if you ran zt_receive on your buffer, and the data in the buffer hasn't changed yet, you get your old data twice, because your card's timing isn't in synchronization with the master card's timing. The same thing happens with zt_transmit and transmit buffers. You can potentially skip data if you update your transmit data before the card has transmitted the last data. True, but would it not be possible to synchronize the DMA engine to an external clock source? i.e. Span 1 on card 1 is the clock source. all spans on card one are naturally synchronized to this source (no changes to current driver, this is how it is.) spans on card 2, instead of just running free from the on-card timer, would get kicked whenever the handler that card 1 installed runs. Cards 3 and 4 would operate exactly the same as card 2. -A. ___ --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
Re: [asterisk-dev] extensions.conf included contexts priorities
On Tuesday 24 April 2007 4:38 pm, Steve Murphy wrote: You only need one such 'catchall' in the include hierarchy. They will all be searched. The first matching exact-match or pattern match will take the prize. That's my point, exactly. If I want a different catchall action in a particular context, it needs to be separated from that context and included, or it will never get used. As far as overriding goes, I'd guess you put your most specific stuff in the highest-level context, and include more general sorts of stuff. Sort of inside-out, but still very workable...? Yeah, I dunno... I'm kind of aggravated with this nonintuitive stuff and am trying to help get the system to a path of least surprise kind of operation. The it's always been that way type of arguments against change have never had much pull with me. We all drove horse-drawn carriages before the motorcar, so why design the motorcar? It's always been done that way! ... or something like that. Cue the I get 12 rods to the hogshead and that's the way I likes it and the old welshmen competition about who had it harder. :-) Back in my day, we had to dial with our fingers and hope that nobody else was using the party line! Party line? Heaven! When I was a youngster we didn't have a telephone, all we could do were send smoke signals, and by gum we liked it, too! Smoke signals? We dinna even have FIRE! -A. ___ --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
Re: [asterisk-dev] extensions.conf included contexts priorities
On Wednesday 25 April 2007 10:04 am, Steve Murphy wrote:
Well, I guess the magic of putting the _1NXXNXX exten in the local
context wouldn't be useful until you define an untrusted context:
I generally build my contexts as small and modular blocks, and then
build grouping contexts which assemble them into various classes (trusted,
untrusted, internal, etc.)
[untrusted]
include = local
Pretty much, yes...
And, maybe, it'd be better to define the local this way instead:
[local]
exten = _NXXNXX,1,Playback(gojumpinthelake)
exten = _011.,1,Playback(gojumpinthelake)
exten = _NXX,1,Dial(...)
so, sip.conf might have
[lobbyphone]
context = untrusted
(all you want folks using the phone in the lobby for is dialing local
numbers)
Very close. sip.conf is pretty much identical to how I'd do it, but untrusted
would look like this:
[untrusted]
include = nine11
include = local
exten = _X.,1,Playback(invalid)
which, of course, doesn't work under this system, since _X. will match before
anything that is included. I'd have to have this:
[untrusted]
include = nine11
include = local
exten = i,1,System(/usr/local/scripts/detonate_handset ${CID(num)})
So, now, a single local context can serve both trusted and untrusted
situations.
The gojumpinthelake message will only get played when not overridden by
higher contexts.
Yes, but a hell of a lot messier, no?
It's backwards to what you are accustomed to, but still useful.
I don't doubt that the system works, I'm just trying to understand the
reasonings behind it and suggest better ways of doing things. Having
wildcard matches in [local], [longdistance], etc. to handle this seems like a
hell of a way to do it.
-A.
___
--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
Re: [asterisk-dev] extensions.conf included contexts priorities
On Wednesday 25 April 2007 10:37 am, Leif Madsen wrote:
[long_distance]
exten = _1NXXNXX,1,Dial(IAX2/${UPSTEAM}/${EXTEN})
exten = h,1,Verbose(1|This would actually get hit, and not the _. pattern)
include = match_all
[match_all]
exten = _.,1,NoOp()
exten = _.,n,Playback(cant-let-you-do-that)
Having _. matching oshiatT is a HUGE design mistake, IMO.
Only the order of includes should matter, and not where they are placed in
the dialplan in relation to extensions in the same context.
See, I very much disagree. The order is important, but not the placement...
seems very... awkward. In other words, include placement is only relevant to
other includes, but not to the rest of the dialplan? And wildcards match up
most-specific first, excluding included contexts? It's confusing.
At the *very* least, includes should throw a big fat warning if they are
placed above extensions in a context.
-A.
___
--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
Re: [asterisk-dev] extensions.conf included contexts priorities
On Wednesday 25 April 2007 11:47 am, Steve Murphy wrote: I do propose that we make the following change to the extensions.conf.sample file to minimize user misunderstanding/frustration over include directives the reason this thread began... Do you think this might help? Is the English proper? I'd mention that wildcards are also searched depth-first, and that if a wildcard in the current context matches, a more specific extension in an included (or switched) context will NOT get executed. This is the most confusing part for me. I was under the impression (and it always seemed to work) that wildcards were searched DEAD LAST, since an included context with an extension with fewer (incl. 0) wildcards was a better match than an extension with more wildcards. What's scary (to me) is that my dialplans have been working just fine until very, very recently. -A. ___ --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
Re: [asterisk-dev] Is ast_channel-uniqueid really unique ?
On Monday 22 January 2007 4:03 pm, Tzafrir Cohen wrote: How can you tell when the unique ID is the same on two servers? An ipv4 address might have been a nice identifier, if you can actually assume all hosts share the same IPv4 namespace. However you have to consider NAT, that may segment your namespace, and IPv6, that uses 128 bits. Why not just use the MAC ID, or allow uidprefix=### in asterisk.conf? -A. ___ --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
Re: [asterisk-dev] Is ast_channel-uniqueid really unique ?
On Monday 22 January 2007 3:55 pm, Russell Bryant wrote: This is already accounted for in Asterisk 1.4. If you set the systemname option in asterisk.conf, it will be used as the prefix for the uniqueid. If you set this to a different value on each box, this problem is solved. :) Doh! There goes my idea. :-) -A. ___ --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
Re: [asterisk-dev] IAX2 deadlock in trunk - out of free iax2 threads
On Sunday 08 October 2006 08:40, Anton wrote: Just found an issue, while loading trunk asterisk with live calls (~30 sim calls) after a while (20 - 30m) asterisk deadlocked and does not accept anymore IAX2 calls. I've seen this in the last week, but unloading (noload in modules.conf) app_queue.so fixed it. I was led there by analyzing the stack traces of the core dumps I had (I kill -9'd asterisk to recover from that) I am not so sure it's a chan_iax2 problem. I never hit that kind of call volume with Asterisk, and I never use queues. :-) -A. ___ --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
Re: [asterisk-dev] Rate limiting traffic to address potential DoS issues?
On Sunday 08 October 2006 18:06, Edwin Groothuis wrote: http://www.unicom.com/pw/reply-to-harmful.html http://www.metasystema.net/essays/reply-to.mhtml I've always found his essay humorous; reasonable this and reasonable that -- but in all honesty, if you're using a reasonable MUA, you can reply to ONLY the list *and* ONLY the author, or BOTH with ease, and you don't screw up anything else. I prefer to have reply-to the author, as I don't find any of his reasons compelling in any way whatsoever, and in fact do find it harmful. Anyway just my $0.02. -A. ___ --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
Re: [asterisk-dev] Rate limiting traffic to address potential DoS issues?
On Saturday 07 October 2006 23:07, Rich Adamson wrote: Really had not thought to much about the source of the improper/bogus packets, but since I'm heavily involved with I/T security assessments, my comments were more oriented towards what might reduce the load on an asterisk box when a hacker (or otherwise tosses packets at asterisk. Wasn't thinking at all in terms of broken clients and such. Wouldn't you have to keep track of who? Or was the intention to simply stop responding to *all* SIP packets? If so, that seems like an easy DoS... Easier than what we currently have. -A. ___ --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
Re: [asterisk-dev] Rate limiting traffic to address potential DoS issues?
On Saturday 07 October 2006 11:28, Rich Adamson wrote: I'd suggest making two important tunable parameters accessible from some conf file though; 1. number of improper/bogus signaling packet threshold 2. amount of time before clearing the able Something like... after 10 bogus attempts, add the IP address in the table and stop responding. Then after 60 seconds, clear that IP address from the table (and start over). I'd add one more tunable parameter: improper/bogus signaling packet count expire time. i.e. if you have the limit set to 10 bogus packets in 30s, it would trip off, but if 9 were received in 30 seconds and at the 32nd second a 10th would come in, the 1st of the 9 would have aged out, and thus you'd still be at 9 packets. I thought of %age too, but you'd still need to keep track of the time the bogus packet came in so it'd be *additional* code. I'm thinking specifically about sort of broken clients being improperly (and regularly) ignored due to too simplistic an algorithm. SIP's an enormous protocol and Asterisk needs to deal with half-assed peers *all* the time. Obviously, it would be nice to see some sort of log entry that indicated the above action was taken. TOTALLY. At a minimum: received bogus packet from a.b.c.d, count=x, threshhold=y, too many bogus packets from a.b.c.d, ignoring for x seconds, and no longer ignoring peer a.b.c.d... -A. ___ --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
[asterisk-dev] Call priority and Dial()
I've opened up bug 7882: http://bugs.digium.com/view.php?id=7882
Now seeing as (as far as I can tell) it involves adding a variable to the
channel structure, I'd like to get some input from the developers before I
put a lot of blood, sweat and tears into solving this particular issue.
I know that messing around with ast_channel can only be done when all other
options are evaluated; that's what this thread has been started for.
Essentially what I am trying to do is allow Dial() to terminate a
lower-priority call in order to place a higher-priority one if and only if
there are no available channels. This can currently be done in a hackish way
with an AGI or perhaps even the Manager interface, but race conditions
abound. If I can put this in app_dial I can eliminate a lot of headaches.
Another way to achieve this would be to create a set of dialplan functions
which would allow the dialplan to snoop the channel variables of *any*
channel in the system. However the security implications of this aren't to
be taken lightly, and the race conditions still exist.
My theoretical way of doing this WITHOUT playing with app_dial is to use a
channel variable and a global dialplan variable, a dialer macro which is used
for ALL outgoing calls, and an AGI: [macro-dialout] checks to see if the
global variable ${EMERGENCY_MODE} is set and if so, does not allow any
outgoing calls unless the channel variable ${EMERGENCY_CALL} is set. An
emergency call sets ${EMERGENCY_CALL} before Macro(dialout,911) is executed.
The macro sets ${EMERGENCY_MODE} if ${EMERGENCY_CALL} is set, and
ChanIsAvail()s the normal outgoing channel set (think Zap/g1 for example).
If a channel is available, it places the call. If a channel is NOT
available, the AGI must scan all of the channels that it would normally place
an emergency call through and if ${EMERGENCY_CALL} is not set, soft hangup
the channel and dial the emergency call.
${EMERGENCY_MODE} needs to be UN-set at some point to allow more calls once
the emergency call is in-progress, but it cannot be set until AFTER the
Dial() is done to prevent a race condition (when the soft hung-up channel is
freed but another non-emergency call steals the channel) -- that's what the
${EMERGENCY_MODE} global variable is for, but it's a little brutal...
Thoughts?
-A.
___
--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
Re: [asterisk-dev] Call priority and Dial()
I forgot to mention what I was planning on adding to app_dial. :-) What I'm suggesting is adding a call priority field to ast_channel. This field would default to a value of -1 (no priority), and the dial flag R(x) would be added to app_dial, which would set the priority for the new call leg to 'x'. If app_dial cannot locate a free channel in its list of technologies to dial out of, it would search the list in exactly the same order that it does now, this time looking for the first channel that has a lower priority than 'x'. The first matching channel would then be soft hung-up, and Dial() would do its normal job using this newly freed channel. If no channels with a lower priority than 'x' are found, Dial() would return CHANUNAVAIL or CONGESTION as usual. I can already see someone wanting the option of playing a sound file to the channel (and its bridge peer) before hanging up, and a delay would also be required for analog (and some digital) Zaptel channels to allow this to work correctly. Further, I can see people wanting to be able to set a default priority for a given channel technology, so hooks in the various technology-specific files may be a good idea (defaultprio=5 or something). This is all blowing up the original scope significantly though; I'm not suggesting doing all of this at once, but rather only being aware that it may be desired and not coding so tightly that it becomes problematic later. -A. ___ --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
Re: [asterisk-dev] iax2 connection drops after some minutes
On Tuesday 05 September 2006 08:27, Pavel Jezek wrote: I'm experiencing iax2 connection drops after three-ten minutes (connection was successfully established before drop) connection is dropped in one direction only, so one site hear, but oposite site no, this messages appears in asterisk console any idea? We need the output of IAX2 debug at the very least, and ideally a packet dump showing the entire call setup and eventual drop. If you can provide this, make sure to change your passwords and not to talk about anything you'd not want public. :-) -A. ___ --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
Re: [asterisk-dev] RS232
On Wednesday 23 August 2006 14:54, Erv Bauman wrote: To clarify, we are looking for Asterisk to RS232 for use with Property Management Systems in the Hospitality industry. Interfacing to other hardware systems isn't really an asterisk-specific task. Nevertheless, it should be pretty straightforward to do. Feel free to contact me offlist if you would like to discuss specific implementation details, as i have a lot of experience in interfacing dissimilar systems. :-) -A. ___ --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
Re: [asterisk-dev] Question about ast_async_goto()
On Tuesday 22 August 2006 09:50, Kevin P. Fleming wrote: This should be handled by ast_do_masquerade(). However, if nothing is reading from that channel, then the pending hangup will never get processed. It's not clear exactly why this isn't working in your application, though. I've always wondered when/how to use ast_do_masquerade() -- what exactly is channel masquerading, when is it to be used, when is it not to be used? It seems to be black magic. I understand that do_masquerade sucks the info about one channel into another, but why is this necessary? -A. ___ --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
Re: [asterisk-dev] Question about ast_async_goto()
On Tuesday 22 August 2006 10:56, Joshua Colp wrote: It's used for things like attended transfers. Basically you have two channels in a bridge talking to eachother, but you want to replace one. Currently we don't have a way of interacting with the bridge itself to do this (it is something that myself and others would like to see). This is where masquerading comes into play. Without touching the bridge, you masquerade the new channel into the channel you want to replace. The old channel dies off, and the two other ones then talk to each other. It's more complicated internally naturally, but you get the drift. It's also used for things like optimizations of channels in chan_local (this is what happens when you don't have /n on the end). Once both Local channels are bridged to other channels (like SIP ones) then they can masquerade themselves out of existence and the other channels can talk directly. Ok, so if I understand correctly (based on this and our IRC discussions): Point 1: The bridging code currently has no provision to say stop bridging A-B and bridge A-C instead Point 2: The ability to switch bridge endpoints is very necessary So, ast_do_masquerade() shifts the channels around under the bridge's nose. It basically flips some pointers around, copies some values from the old bridged channel to the new to-be-bridged channel, stuffs some pins in some dolls and performs a virgin sacrifice... in the end, the to-be-bridged channel looks and acts like the was-bridged channel it replaces, at least to the bridge code, and the system works as you expected it to. Is that about right? The masqueraded channel must keep some old identity information around though, as the CDRs aren't screwed up and various status commands report the correct channel names. When you say a channel just dies off -- what happens? The equivalent of a hangup (from which perspective, asterisk hanging up the channel, or the channel hanging up on asterisk?) -A. ___ --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
Re: [asterisk-dev] 'IAX2 call variable passing between servers '
On Friday 11 August 2006 14:43, Tilghman Lesher wrote:
Just nitpicking, but this should be:
Set(IAXVAR(CHANNELTYPE)=SIP)
Set(IAXVAR(DNID)=${CALLERID(dnid)})
Set(IAXVAR(RDNIS)=${CALLERID(rdnis)})
Bah, total brainfart there. Thank you. :-)
-A.
___
--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
Re: [asterisk-dev] 'IAX2 call variable passing between servers '
On Friday 11 August 2006 15:00, Douglas Garstang wrote:
It's my understanding that rdnis comes from the phone. When someone
forwards their calls, the phone sends back the 'Moved Temporarily' message
to Asterisk. Asterisk interprets the SIP message and passes rdnis, dnid and
extension back to the dial plan when it re-enters it. It tries to dial the
new extension. My original DIAL() command has 'g' in it... which I guess is
what causes Asterisk to re-enter the dial plan as it does, and try to find
a match for the new extension.
Asterisk doesn't re-enter the dialplan, it CONTINUES along the SAME
extension, at the next priority when option 'g' is used for Dial().
e.g.
[ooga]
exten = 500,1,Dial(SIP/500,,)
exten = 500,n,NoOp(After trying 500...)
exten = 501,1,Dial(SIP/501,,g)
exten = 501,n,NoOp(After trying 501...)
exten = 501,n,Goto(${RDNIS},1)
(this is all untested, I don't have a SIP phone handy.)
In this example, if 500 has a redirect, Asterisk will (should) send back a
CHANUNAVAIL to whoever tried to call 500. However, whomever called 501
(which has the same redirect) should get another kick at the cat with
whatever the RDNIS was set to.
I think.
-A.
___
--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
Re: [asterisk-dev] Routing data modem calls
On Friday 28 July 2006 05:27, Brian Candler wrote: Furthermore, a G.711 call uses a large bandwidth (up to ~120kbps), even for a low data rate modem, or when no data is being transmitted. A typical ADSL line has an uplink capacity of 288kbps, so 2 calls would eat all that up. ?? Most ADSL lines around here (southwestern Ontario, Canada) are 800kbps up, but yes, we can get pretty low depending on distance from CO. My home, for example, has an uplink of 512kbps. Also, a ulaw audio stream in RTP is about 80kbps. Of course that is 80kbps upstream, 80kbps downstream, but you don't get to add them together and say it's 160kbps (or 120kbps in your example). 4. V.42 error correction is implemented using HDLC frames. If there was an RTP payload type for carrying HDLC frames, these could be exchanged end-to-end. It would have the advantage of performing end-to-end error correction, data compression and flow control between the endpoint modems, without the intervening network having to get involved. This would be nifty. I've also noted that most POS terminals use 2400 baud since there is no channel equalization or excessive training performed and this keeps call length to a bare minimum. (Useful because they typically dial some 800# and the POS vendor likely has 1/1 billing on their 800 line.) I've not noticed much trouble with 2400-baud modem connections over stable IP networks, but then again I'm not willing to say it will always work, either. :-) Faxes are more of a problem because their lower-end connection rate is typically 9600 baud. Although some will train down (Mr. Underwood would be the authoritative source on these terms and implementation) to 2400 or even 1200 baud, I have not seen this much in practice. These points aside, you have put a lot of thought into this and I hope some decent conversation and even feasible goals come out of this. I'll be watching this thread carefully. :-) -A. ___ --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
Re: [asterisk-dev] Beta testers needed for new sound files (now version 1.4.1)
On Wednesday 19 July 2006 14:33, Kevin P. Fleming wrote: This was a mistake in the packaging process. The files were not trimmed and padded properly; I have uploaded version 1.4.1 of the tarballs with this corrected. These sounds are much, much better. As requested on IRC, here's a few of the sounds I've noticed that need trimming up: message has a delay on the end of it yet am is a little off, but pm is perfect first (and maybe second/third/fourth, etc.) need some trimming on the end That's it for now... but wow these are great. And just as I was starting to get used to the William Shatner style... :-) -A. ___ --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
Re: [asterisk-dev] rel eng suggestion: -current tgz
On Wednesday 21 June 2006 15:42, Marc Blanchet wrote: not sure if this is the really right place to discuss since it is more a release engineering question, but I'll go: to help people get the current official release of asterisk when they download it without having to look at all releases (I just got that question and the current bottom of the list is currently: 1.2.9 while the latest is 1.2.9.1), I would suggest to have a symbolic link for all tar files in http://ftp.digium.com/pub/asterisk/releases/ such as: ln -s asterisk-1.2.9.1.tar.gz asterisk-current.tar.gz same for other tgz... Personally I *HATE* software releases like this (just a symlink to the latest) -- you download -current.tgz and in 1 week have no idea what version it is. You can't untar it because it untars to asterisk/ (again no version info, not even asterisk-current/) and is just a generally messy way to do things. If -current.tgz untarred to asterisk-1.2.9.1/ or something it'd be much better. Personally I am a fan of the directory structure having the latest in root and an old_releases/ or archive/ directory with all the old ones. -A. ___ --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
Re: [asterisk-dev] rel eng suggestion: -current tgz
On Thursday 22 June 2006 10:10, Tzafrir Cohen wrote: As it is a symlink to a tarball that is untarred to asterisk-1.2.9.1 , you have nothing to worry about. If that's the case then I'm all for it! -A. ___ --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
Re: [asterisk-dev] Postgres Realtime driver
On Tuesday 04 April 2006 15:00, [EMAIL PROTECTED] wrote: DBLib for some operations. The big advantage to ODBC is the software you write can be made to work with any RDBMS backend that has an ODBC driver (which is about all of them) without ANY change to the software. Also, a In an ideal world, yes. But RDBMSes have slightly different ways of wanting things worded, some may run faster if you order them in a particular way and so on... It's good to code as flexibly as possible but sometimes you need to go around the driver or the SQL95 conformance to get something done better. -A. ___ --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
Re: [asterisk-dev] Bug marshal
On Monday 06 March 2006 12:07, Rich Adamson wrote: Given the cards you have available, might want to take a look at trying to identify why the TDM and X100p cards inject a transmission loss into the audio stream. Have a look at the old bugs 2022 and 2023. I was evaluating a condition where a TDM card (TE405 rev1) would not send ANY audio frames whilst transmitting DTMF. It should have been returning muted (silent) audio frames but had *no* data for the driver while the driver was sending DTMF. I have it in as bug 4226 for those interested. I'm in the middle of documenting specifically the transmission loss associated with the TDM vs Sangoma card. For example, if rxgain and txgain are set to 0, and one dials a milliwatt generator (or uses a direct attached tone generator), there is a significant transmission loss. I was not experimenting with *any* gains at all during this testing, but it's been almost a year since I was playing with it. -A. ___ --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
Re: [Asterisk-Dev] ParkAndAnnounce() - trying to add var to indicate parked exten
On Tuesday 13 December 2005 14:47, Andrew Latham wrote: I looked at this I am playing with an Idea for a fix they problem is fun :) I've already got it fixed, but the patch hasn't yet made it into svn TRUNK. If you're interested I'll pass the patch on. -A. ___ --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
Re: [Asterisk-Dev] RFC2833 Event Duration
On Saturday 05 November 2005 14:17, Kevin P. Fleming wrote: It is by design, i.e. not accidental. There is no way to pass on the duration at this time, because incoming events are turned into AST_FRAME_DTMF as they pass through the Asterisk core, and those frames do not currently have any way to carry duration information. Keep in mind that Asterisk is used in many applications that are not SIP-SIP, so just because in your situation there is an 'incoming event duration' that doesn't mean there is in all other applications :-) Why not just specify a reasonable duration? Or put it in sip.conf on a global/peer basis? -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] multiple registrations of same credentials
On Friday 21 October 2005 08:02, Jason Pyeron wrote: This will be looked at after 1.2 release. yes, but my client needs it now. Holy hell I hate this attitude. You have NO idea how much. You've been given alternatives, which you don't WANT to do, although they'd solve the problem just fine. You want it to work just like something else, so why don't you just USE that something else? My guess is that they got sick of your But I want it THIS way! attitude and stopped supporting you, so you are now here. The same will happen here if you don't adjust your attitude. You've already been told that is not how it works here due to architecture fundamentals. This is unacceptable to you, so I suggest you break out your programmer hat and do it yourself. It won't make it back into the public tree due the architecture differences already mentioned, but hey you've GOT to have it so you'll be able to allocate resources to keep it in sync with Asterisk's other feature developments. If you're incapable, break out your wallet and post a sizeable bounty. If you're still incapable, it can't be done, and no amount of but it works this way on some other system and But I need it for a client NOW will change that. Asterisk and the Asterisk community doesn't owe you ANYTHING. Please lose this entitlement attitude you've got. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Echo cancellation on GPU
On Sunday 25 September 2005 14:09, [EMAIL PROTECTED] wrote: I've been thinking off and on about echo cancellation and the use of a GPU board to run it. Unfortunately it increases latency and PCI bus utilization... which I think are the two reasons that it was dismissed in the past when it was brought up. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] need help
On Wednesday 21 September 2005 16:01, Paul wrote: It doesn't work so well when the sponsor ahs both forums and mail lists. Some companies eliminate the lists when they switch to forums. Some forum software allows users to get email copies of all posts. You still have to login and post via web. The lists aren't going anywhere. The forums are there for those who like that solution better. Most old-timers and technical gurus dislike forums and the reasons have been discussed many, many times on this and -users. Forums are, in my opinion, a non-solution. But others love them. To each their own. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Questions
On Wednesday 21 September 2005 16:36, Brian K. West wrote: If I read this right this is ABE only and locks anyone wanting to use Asterisk with Dialogic cards would have to buy an ABE license. This also takes away the freedom of being able to really make a flexible solution based on Asterisk because you don't get the source code that ABE is compiled with thus you're stuck. You're using proprietary and very expensive cards... I am not sure I see the issue... Yes I realize that there's no TECHNICAL reason why it shouldn't work... it's all politicking. Fun. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Re: PostgreSQL support in Asterisk 1.2?
On Wednesday 10 August 2005 11:46, Begumisa Gerald M wrote: For most critical applications it may not be too wise to lean fully on the RDBMS to protect you from your inexperience. I'm sorry, but if I tell my DB to only accept dates into a column, that does NOT imply if I don't give you a date, make it one. One of the biggest reasons to use a DB in the first place is to hand off the data consistency checking to it! If I can't trust it to do that what's the point? A DB has a lot of overhead and resources that it takes away from the rest of my system... if I have to check over its shoulder constantly I may as well be doing everything myself. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Re: PostgreSQL support in Asterisk 1.2?
On Wednesday 10 August 2005 12:21, Tilghman Lesher wrote: In that case, SQLite cannot be considered to be a DB under your definition, either. From the documentation [0]: ...SQLite support[s] the concept of type affinity on columns. The type affinity of a column is the recommended type for data stored in that column. The key here is that the type is recommended, not required. Any column can still store any type of data... So much for data consistency checking. Yeah really, I did not realize that... Is MySQL so forward about the artistic license it takes with my constraints? Further, I am pretty damn sure that SQLite isn't trying to come across as ACID-compliant. And while I realize I'm stretching for reasons to like SQLite now I do want to make note that most systems that would implement SQLite are using it strictly for a lite SQL layer in which to work -- especially since SQLite has no network layer at this time. Having the 'C' in ACID isn't nearly as important if you're the only app capable of accessing the DB (crazily contrived examples of file locking and such preemptively excluded). -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Re: PostgreSQL support in Asterisk 1.2?
On Sunday 07 August 2005 01:03, Peter Nixon wrote: Asterisk on the other hand seems to crash a couple of times a day under minimal load. When you can run Asterisk in production for 3 months without seeing a single core file then your point begins to hold water.. you've got other problems if Asterisk is crashing on you several times a day under minimal load. My Asterisk boxes never crash. Ever. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] PostgreSQL support in Asterisk 1.2?
On Thursday 04 August 2005 01:52, Adam Goryachev wrote: For an environment with very few writes and a lot of selects, his solution might be the best one, or, at least, it probably isn't worth changing it until he reaches some limitation. What *you* are forgetting is that people bitch and whine about the performance of Asterisk's flat file configuration format and point to Realtime for performance increases and instant-updates... and then they throw MySQL into the mix and completely undermine everything they've been bitching about! What the hell good is MySQL in a realtime Asterisk environment when you go to update a user and the entire PBX waits because some table is locked? What the hell good is MySQL when you've got a dozen Asterisk boxes now (your business is booming) and MySQL's sputtering and pissing about because it's crumbling under the load? Oh, failover and redundancy I hear you say but let's face it -- use the proper tools for the job in the first place and you won't end up with a duct-tape and JBWeld abomination that yes, works, but is so brittle and inflexible that you've now painted yourself into a corner? Of course, by the time you've reached this point you'll have so much time and energy invested into your hacked up solution that you will refuse to accept that you made a mistake early on and will instead religiously defend your choice of tools, well beyond any rational argument. PS, why do people insist on talking about old versions of software in order to tell you it is bad? The past has been and gone... IMHO, focus on the here and now, or even better, the near future. Until I have it installed on my system, it's vapour. PPS, this is totally off-topic, and should be saved for some other mailing list somewhere else, where people are actually interested in talking about whose DB is bigger/faster/more colourful No actually it's relevant, even if only peripherally. People need to know what they're getting in to. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] PostgreSQL support in Asterisk 1.2?
On Thursday 04 August 2005 04:50, Bob Goddard wrote: http://sql-info.de/mysql/gotchas.html Amazing, according to that site, neither Oracle nor PostgreSQL has any gotchas. You've got to be kidding me. http://sql-info.de/postgresql/postgres-gotchas.html There's very little info on Oracle on that site at all, but compare the Postgres gotchas to the mysql gotchas and tell me which you'd prefer. Seriously. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] spike / asterisk hang? - On a 360MHz CPU - no, 440 :)
On Saturday 16 July 2005 01:14, James Sharp wrote: I don't have a sun4u available to test on it, but I wonder if the compiler is even emitting semi-optimized instructions for sparc. If you twiddle the makefiles right and run a decent enough version of GCC, it should spit out VIS-based instructions (MMX-style SIMD instructions in sparc64) The devil's in the details, as always. :-) I would imagine that the SIMD instructions on most processors like the algorithms to be implemented the same way (i.e. working on larger datasets at once) so I imagine that if the original poster did a little research and testing he could squeeze a few more calls out of those boxes. :-) -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] karma on mantis?
On Monday 30 May 2005 20:22, Brian West wrote: your terminal.. because people in their right minds DO NOT START asterisk like that and all reality asterisk should have died if you did that and NOT continued to run. But then again still not major. NEXT!!! I run all my asterisk servers in screen sessions with -c. It's the only way I can get colour console in a screen session. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] karma on mantis?
On Monday 30 May 2005 22:22, Brian West wrote: I get color if I export TERM=xterm 90% of the boxes i'm on... It should work with termtype screen just like everything else. :-) (yes I do plan on posting a patch) -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] High resolution timers using POSIX clocks instead of zaptel
On May 27, 2005 12:32 pm, Tilghman Lesher wrote: On Friday 27 May 2005 05:33, David Woodhouse wrote: Using zaptel just for a time source is silly. We should use POSIX timers instead. Here's a start, but I don't know how long it'll be before I can get to finish it, so I thought I'd post it here in the hope that someone else will pick it up. As noted here: http://lists.digium.com/pipermail/asterisk-users/2002-April/002072.html software timers are lacking. That link doesn't have *any* information whatsoever on why. 1000Hz should be trivial to generate on a PC. hell I was doing this back in the DOS days with the PIT. Granted things have changed a bit since then but I hardly think that a crystal oscillator on a PCI chipset *designed* to be as cheap as humanly possible is great precision as the link indicates. :-) -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Re: ztdummy accuracy improvements on kernel 2.6
On May 16, 2005 08:59 am, Tony Mountifield wrote: I think what is happening is that the zaptel processing invoked by ztdummy is not happening quite often enough due to missed jiffies. Consequently I suspect the incoming IAX channels are not being serviced often enough, and are building up a backlog. If ztdummy's hitting it 1024 times a second instead of 1000 wouldn't that indicate that it was servicing it too often? -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] [Rant] [long] - code style and quality
On May 10, 2005 09:56 pm, Brian West wrote: Lets clarify.. the power that be is Mark Spencer... I doubt he seen this thread. Nonsense. You read it. I read it. many people who contribute to asterisk read it, and many people who may want to start their patching foray will read it. It really is a shame that Mark doesn't, but he's unbelievably busy and he gets his news through the grapevine, of which anyone who talks to him is part, and it's THOSE people who are reading this. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] PRI/Zap
On May 4, 2005 12:25 pm, Steven wrote: That is configurable. In fact, it was a question we received while ordering our channelized T1 if we wanted round robin ascend/descend or in order ascend/descend. Don't seem to remember it with out PRI, but I'm sure it is an option as well. No, I realize practically everything's configurable... I'm just saying it seems that most times this is how the channel allocations are done. In fact, doing it this way (always starting at the lowest/highest) is probably less likely to cause glare. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Benchmark numbers....
On May 3, 2005 03:57 pm, Kevin P. Fleming wrote: Speaking of that... the change to ast_copy_string() (and more like them that are on the way) are really targeted at increasing Asterisk's BHCA numbers, as opposed to simultaneous call handling. It'd be really cool I'm sorry... for the list perhaps? What's BHCA? -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] I don't need libpri..please continue...
On May 2, 2005 06:15 pm, Matthew Boehm wrote: chan_zap.c:61:2: #error You need newer libpri make[1]: *** [chan_zap.o] Error 1 make[1]: Leaving directory `/usr/src/asterisk/channels' make: *** [subdirs] Error 1 The machine I am compiling asterisk on has no PRI/Zap cards connected to it. So why is libpri necessary to download? Shouldn't it say You don't have libpri installed so I am skipping the following... and keep compiling? Basically it sees you have zaptel installed so it's trying to compile chan_zap, which requires a newer libpri. If you're sufficiently proficient, work around it. Otherwise, just do what it says; it's not like libpri's huge. :-) -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] I don't need libpri..please continue...
On May 2, 2005 07:12 pm, Brian West wrote: I bet its just finding the libpri headers.. Well he says he doesn't need Zap and chan_zap's getting built, which indicates to me that it found zaptel code. :-) -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] TDM-fxo card and zttest logic issues?
On April 23, 2005 11:49 am, Rich Adamson wrote: I posted this to the -user list earlier and no responses as yet. Is there anyone on the -dev list that would have an interest in working with me to identify bus throughput issues with the digium TDM04b (analog fxo) card? Me. I have no phone lines at my house but could set up a test system at work. I have FXS lines at home and work and they both have trouble with passing faxes to a real, honest fax machine. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Queues observations
On April 27, 2005 10:59 am, Kevin P. Fleming wrote:
That is not necessary at all. You send the caller into the queue, if
they return from it, it's because they could not be connected to an
agent for some reason. The QUEUESTATUS variable will tell you why, and
depending on the options you have set that may have been caused by a
timeout, a lack of agents logged in, a lack of agents available, etc.
In other words, you can already accomplish what you want without adding
a new application.
Totally unrelated, but you cannot transfer a call that you've picked up from a
queue... you get
Apr 21 15:26:27 DEBUG[12947]: Async goto not applicable on call 5
if (iaxs[fr.callno]-owner iaxs[fr.callno]-owner-bridge
ies.called_number)
{
Do some transfer stuff
}
else
{
error
}
iaxs[fr.callno]-owner-bridge is NULL... so it fails. this variable
represents who we're talking to -- who we're bridged to. It's NULL when the
call came from a queue.
-A.
___
Asterisk-Dev mailing list
Asterisk-Dev@lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] US$200 bounty for * paging feature
On April 19, 2005 10:43 pm, Matt Darnell wrote: OK I am done defending this guy who did nothing wrong. he crossposted a bounty to the -dev list. That *is* something wrong. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Dialplan 'i' and DIALSTATUS bugs
On April 15, 2005 11:37 am, Eric Wieling wrote: exten = 555-0001,1,NoOp(0001) exten = 555-0001,2,Hangup Next time try to use ACTUAL stuff from your dialplan. 555-1212 is NOT correct unless your telco is REALLY REALLY WEIRD. The telco will send 5551212 Telephone numbers do not contain non-numbers. This was an example; of course there's no dashes in the real thing... Please try to see beyond the obvious bugs... I've been using Asterisk for well over a year now and push many tens of thousands of calls through it. :-) -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Re: BOUNTY: app_hangup from exten = h
On April 14, 2005 10:01 am, Tony Mountifield wrote: There is no app_hangup.c. The Hangup command is implemented in pbx.c by the function pbx_builtin_hangup(), which does nothing except return non-zero. The PBX core then initiates a hangup because the app returned a non-zero status, which it would for ANY app that did so. In my opinion the correct fix would be for Asterisk, when an app returns non-zero, to check if it has already called the h extension for the channel, and if so, NOT to go to h,1 again. This should be done using a flag rather than checking the extension, so that it still works if the dialplan does a Goto out of the h extension to somewhere else. Have you ever seen Asterisk loop when Hangup is called from h? I certainly never have... -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Re: BOUNTY: app_hangup from exten = h
On April 14, 2005 10:40 am, Eric Wieling wrote: No, but I have seen many a time where people have exten = _.,Hangup which is not a good thing most of the time. Agreed. :-) I might take a crack at having the PBX throw up warnings if _. matches a special extension. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Intel Open Source Fast Math Library
On April 9, 2005 07:20 pm, Richard Scobie wrote: I'm sure the developers that would use something like this are already aware of it, but just in case this may be of use in the dsp/echo canceler area of Asterisk on PIII/IV CPU's. What is it licensed under? They will need a specific exception for asterisk since asterisk is dual-licensed. Also I have seen several benchmarks that show Intel's 'fast math library' isn't really as optimized as people think. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Petition for IAX firmware
On April 6, 2005 10:32 pm, Jared Smith wrote: On Wed, 2005-04-06 at 20:22 -0400, Andrew Kohlsmith wrote: I guess; but in my mind Digium improved upon the Zaptel design and closed it. Not exactly what the original poster was getting at. You have a point, but I for one am glad they're building good hardware. Let's not forget that the money Digium makes from selling hardware cards (even if they are closed) helps sponsor Asterisk development. I think the recent announcement about Kevin being hired (congrats Kevin!) is possible, for the most part, because Digium continues to sell their hardware cards. Let me be clear -- I never said that improving on the design and closing it was bad. That is fully within their right and it has worked for them! I am ONLY suggesting that saying that Zaptel was a success because of the open design is perhaps a little misleading. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Petition for IAX firmware
On April 6, 2005 11:15 pm, Nick Bachmann wrote: The specs are open source, Digium modified the open source, the Digium firmware should be open source. Simple concept. I'm not sure what you're refering to here (which is why I don't like top-posting)... the specs for what? Zaptel cards? They don't really have firmware. You bet your ass they do. The Xilinx Spartan II is an FPGA. The TDM400P has a (very small) FPGA on it as well. The VHDL and/or schematic for the logic inside these devices is what I would consider firmware for this discussion. Again -- they don't have to open it up, and I'm certainly not demanding they do. But saying that Digium's hardware is open or can't be open is misleading at best. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Petition for IAX firmware
On April 6, 2005 10:36 pm, Jeremy McNamara wrote: That is totally incorrect. Digium created a totally new design which just happens to be compatible with the Zaptel API. The TEXXP cards are based on a much much more powerful T/E/J-1 Framer Chip instead of the old, dumb Dallas chip the Tormenta (Zapata) board designs utilize. Fair enough; I thought that the TExxxP were incremental improvements on Tormentia, not radically new designs. My mistake, and my apologies. You must not forget how much Mark/Digium contributed back to Jim/Zapata/Zaptel, before embarking on his own design. I didn't forget it; as I said I thought these new cards were improvements on the original design, not brand new designs. :-) I appreciate you clearing this up, since I *know* I'm not the only one who was working off bad information. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] rewriting asterisk as a state machine? - Not
On March 4, 2005 09:52 am, Paul Mahler wrote: We are getting over 5000 simultaneous calls with our PBX hardware with less than 50% CPU utilization, so I'm not sure this is much of a problem. ;-) What hardware and what types (channels) of calls? I'm just curious, especially as to what you do for redundancy and failover. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] 'tonezone' in chan_zap.c
On March 1, 2005 10:21 pm, [EMAIL PROTECTED] wrote: All I said is that if one needs assistance to 'grep tonezone */*c', one probably won't be a good contributor, and instead would just sap our time with requests for help. Nothing is wrong with requests for help - but if you didn't do your homework, expect to be flamed. Also, if one complains 'I can't understand your code therefore it must be your problem, and you must help me understand' - again, expect to be flamed for that. Do you disagree? No, I don't disagree at all. Perhaps I misunderstood what you had written. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Digium's G.729A codec problem
On March 2, 2005 05:50 pm, Jeremy McNamara wrote: There is no OPEN SOURCE implementation of G.729.Refrain from posting illegal links. He never said it was open source, and his website clearly says you need to adhere to your country's patent laws... I don't see the problem? -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] how to design digim clone card?
Easy. Take the open-source tormentia cards and improve on them. If you require more details, my consulting rates are available by email. I'm not cheap. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] IAX2 trunk really should send timestamps as part of iax2_meta_trunk_entry..
On February 4, 2005 11:06 am, [EMAIL PROTECTED] wrote: Mark feels it can be done, and also doesn't want to agree because of the wire cost of the extra info. Make it optional. Problem solved. Don't send the per-channel timestamps at the end and it uses the trunk's timestamp. Send it at the end and the code simply copies each channel's timestamp over top of the default trunk timestamp the channel got when it was being demultiplexed. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] is this a bug?
On January 25, 2005 02:54 pm, Eric Wieling wrote: As you can see -c means CONSOLE, not COLOR. Then why does asterisk -vvg spit up a CLI, and asterisk -vvgc spit up the same CLI in colour? :-) I will admit that lacking a '-c' does not give me a CLI, but it also gives me colour output. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] is this a bug?
Please don't post with HTML, **ESPECIALLY** in the -dev list. On January 25, 2005 02:35 pm, Alexander Lopez wrote: ^c. = interrupt ^d = eof Etc I've been using Unix for 10 years, I know what they mean. I am saying that if they *don't* cause * to crash without -c, why do they cause * to crash with -c... also why are they not being trapped and handled properly instead of literally crashing the server. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] whee, floating point exception with app_rxfax
This machine has successfully received no fewer than 261 faxes over the past month or so -- slackware 10.0 with spandsp 0.0.6 and the correct libtiff. Asterisk CVS-HEAD-12/16/04-19:12:41 built by [EMAIL PROTECTED] on a i686 running Linux I'd like to help fix this, but I need some assistance in processing the backtrace. Can anyone help? -A. (gdb) bt #0 0x40755e8f in process_baud () from /usr/lib/libspandsp.so.0 #1 0x40755497 in v27ter_rx () from /usr/lib/libspandsp.so.0 #2 0x40748cff in fax_rx_process () from /usr/lib/libspandsp.so.0 #3 0x407295cc in rxfax_exec (chan=0xa46c9e0, data=0xa46c9e0) at app_rxfax.c:274 #4 0x08082b43 in pbx_extension_helper (c=0xa46c9e0, con=0x0, context=0xa46cb2c macro-receive-fax, exten=0xa46cc20 s, priority=4, label=0x0, callerid=0xbe1f90ec /var/spool/asterisk/faxin/1105633566.5506.tiff, action=135616584) at pbx.c:475 #5 0x08081432 in ast_spawn_extension (c=0x0, context=0x0, exten=0x0, priority=0, callerid=0x0) at pbx.c:1819 #6 0x4062c634 in macro_exec (chan=0xa46c9e0, data=0x4) at app_macro.c:153 #7 0x08082b43 in pbx_extension_helper (c=0xa46c9e0, con=0x0, context=0xa46cb2c macro-receive-fax, exten=0xa46cc20 s, priority=1, label=0x0, callerid=0xbe1fd85c receive-fax, action=0) at pbx.c:475 #8 0x0807b430 in ast_pbx_run (c=0xa46c9e0) at pbx.c:1819 #9 0x08083221 in pbx_thread (data=0x0) at pbx.c:2064 #10 0x40024cc4 in pthread_detach () from /lib/libpthread.so.0 #11 0x401f1037 in clone () from /lib/libc.so.6 ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] RFC: Moderating the Asterisk Mailing Lists
On January 7, 2005 05:42 am, Brian Wilkins wrote: If the project is ongoing, why are the docs on the www.asterisk.org website outdated? The Asterisk Handbook: Second Draft was last published in March, 2003! That's the problem -- the handbook isn't what I was referring to. http://www.asteriskdocs.org/ Last updated: 5 Jan 2005. I don't think the list is the problem, it's simple lack of good, solid documentation. Newbies will always have questions, but we can't blame them for asking when a lot of the information on the wiki is outdated, plus we don't even have a recent handbook published. Look at the mysql website (another open source project), they have loads of documentation and it is easily searchable. Agreed -- the trick is in the documentation and as I put it, yodelling it from the rooftops. :-) -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] RFC: Moderating the Asterisk Mailing Lists
On January 7, 2005 10:51 am, Gregory Junker wrote: Thank you for pointing out exactly what is wrong (specifically, your attitude) with the majority of open-source projects. While I agree that Alex's attitude is poor that is actually part of the beauty of open source and why it makes people money. If you don't want to deal with primadonnas and socially awkward hackers, find yourself a consulting company to manage your asterisk installation. They possess the thick skin and ability to interact with the community; you'll get a stable asterisk installation. There are plenty of people here who possess tact and diplomacy. You seem to expect those qualities to be a requirement; they're not. -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] My current features/tweaks that need community involvement
On January 3, 2005 12:10 am, Kevin P. Fleming wrote: -1 from me. What's wrong with Goto(m-done)? (I'm talking about being abel to set labels and use them in CVS HEAD's extensions.conf parser) There's nothing really wrong with that, other than an unnecessary application being executed. Well MacroDone() and Goto(m-done) both seem to be the same number of applications to run, unless you're including the NoOp or whatever at m-done. :-) -A. ___ Asterisk-Dev mailing list Asterisk-Dev@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] 16 KHz audio ?
On December 17, 2004 05:49 am, Eric Bart wrote: I've seen nowhere a plan to improve audio quality. Possibly because there's no real need to? It seems that the Skype success is partly due to its 16 KHz audio bandwidth. It gives users the feeling that the far party is in the same room. I've never heard any complaints about regular telephone quality, and that's 8-bit 8kHz (64kbps). Are you sure that this is something that really needs consideration over perhaps working out a way to get packet loss concealment into *? -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] BUG MARSHALS - Where are you???????????????????????
On December 13, 2004 01:35 pm, Olle E. Johansson wrote: There are a lot of interesting bug reports. If you have nothing to do this calm and quiet time before christmas - start coding and fix them. Also, Calm and quiet time before Christmas? You're smoking crack, aren't you! :-) -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
FIXED Re: [Asterisk-Dev] zapata.conf priindication option
On December 6, 2004 07:46 am, Andrew Kohlsmith wrote: I'm still trying to discover how to get IAX2 to see the BUSY now (Dial via IAX2 and remote has a busy you still get CHANUNAVAIL) but at least the PRI is working as it should. http://bugs.digium.com/bug_view_page.php?bug_id=0002989 Patch attached to the bug. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] zapata.conf priindication option
On December 5, 2004 02:12 pm, Matthew Simpson wrote: This was discovered because calling a busy POTS line from a PRI returned DIALSTATUS of CHANUNAVAIL instead of BUSY. hrm... I have the same problem... anyone with some insight? Well what I have done is with priindication=outofband you get HANGUPCAUSE set correctly. DIALSTATUS is still wrong IMO (UNAVAIL instead of BUSY) but if you check HANGUPCAUSE first you will have a good starting point. I'm still trying to discover how to get IAX2 to see the BUSY now (Dial via IAX2 and remote has a busy you still get CHANUNAVAIL) but at least the PRI is working as it should. -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Re: [Asterisk-Users] SIP SECURITY WARNING: v1-0 (cvs today) sip context in general section ignored goes to default instead - allowing unauthorized sip devices to place calls in default context
On December 4, 2004 07:40 pm, Tracy R Reed wrote: Personally, I think it is about time that lack of attention to security finally started costing someone some real money. I have always maintained that stupidity should be painful. -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] why not disable clock when using multiple Zaptel cards?
On November 28, 2004 04:23 am, Peter Svensson wrote:
If there are several digium cards with 1kHz interrupts then maybe only one
of them should be causing interrupts. The other cards could be serviced
from within that handler. It does sound a bit tricky.
This is what I'm not getting; why it's tricky.
Say you have an ISR with a list of cards to service. Normally the list has
only one entry: the entry for its own card.
Now with two cards installed, the module init code would see the second card,
disable the timer interrupt on the second and add card 2's address to the
list of cards to service.
Something like (oversimplified I am sure):
Existing way:
init_card(void *card)
{
enable_timer(card);
}
process_interrupt(void *card)
{
process(card);
}
new way:
void *cardlist[MAX_CARDS];
static int n_cards = 0;
init_card(void *card)
{
cardlist[n_cards++] = card;
if(n_cards == 1)
disable_timer(card)
else
enable_timer(card);
}
process_interrupt(void **cardlist)
{
int i;
void *card;
for(i=0; in_cards; i++)
{
card = cardlist[i];
process(card);
}
}
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] libpri ISDN features
On November 24, 2004 05:04 pm, you wrote: (_free_ :-) ) documents on the ECMA website. The specs that I'm refencing for MWI are ECMA-241 and ECMA-242 and are available on the ECMA website for download. Where did you get any useful information out of those documents? I grabbed etc_3001960[1-6]e01p and etc300650e01p and they were completely useless to me. capi20-3 from the CAPI website was far more informative. -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] Sending ISDN q.931 messages to Zap span?
I tried #asterisk-dev but everyone there is lurking or has me on /ignore. :-) I'm trying to send ISDN MWI indication to a PRI on a Zap span. From what I gather from the CAPI documentation is that I send a FACILITY_REQUEST message with parameter set to 0x0003 and function 0x0013 (MWI Activate), filling in the supplimentary structure to indicate number of messages, message status, destination facility number, source facility, etc., etc. Where I'm getting tripped up is in how to send this information over a PRI. What is the most straightforward or perhaps more accurately, the most flexible way of sending an arbitrary q.931 message over a Zap span? the zapata.conf mailbox settings are only attached to individual channels, and since I can't assign mailbox settings to the D channel that's out. I was thinking perhaps something in the dialplan (perhaps a q931()) application) but perhaps wedging this into zapata.conf is better in the long run, at least for voicemail notification. Can anyone assist me in getting started? -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] DUNDi(tm) = Gnutella?
On October 21, 2004 08:15 am, Craig Southeren wrote: Ummm...no, it's not even close to being basically the same as Gnutella. If anything, it's closer to DNS. Seems closer to Gnutella than DNS to me. DNS is hierarchial; DUNDi is not. DUNDi is not used for exchanging multi-megabyte media files - it's used for making very small routing requests. Gnutella's routing is also very small, but tons of routes adds up to big bandwidth, as Gnutella found out. -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] dking @ pimpsoft revealed as paid OSS goodwill saboteur
On Wednesday 06 October 2004 19:16, [EMAIL PROTECTED] wrote: That is not true and unless you can prove it (And I know you cant) you have no right to slander my name. I have done nothing but help and support the open source community and anyone else that says otherwise is a no good liar. Pot, meet kettle. Kettle, pot. -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Asterisk channel variable access: a proposal
On Wednesday 18 August 2004 14:32, Tilghman Lesher wrote: On Tuesday 17 August 2004 08:46, John Todd wrote: I hadn't really considered actually making it a filesystem in exactly the same way /proc worked; I just wanted to lay out the structure with the / as the inter-field designator, but keep the data inside astdb (or a shim in front of astdb.) However, I suppose asterisk -rx database get channels/SIP/2109-996a codec-in would work for you to allow external programs to access that data in a hypothetical example. Ack. No. Please. Don't put transient call-related information into astdb (or even in front of it, using a shim). Astdb is for information that you want to remain across calls and across invocations of Asterisk. It is _NOT_ for information which is call-specific. That's why we have channel variables. Note that I have no problem with the information being available in that format, just with the idea of placing it within the database (or making it seem like it comes out of the database). I quoted your entire response as I'm a little lazy and didn't want to cut and paste and attempt to reconstruct what you'd said. :-) What are your feelings on a /proc-style filesystem for asterisk live data? That's precisely what /proc is like under Linux and it seems to make a *lot* of sense, at least in a transient data kind of sense. /ast/IAX2/35210/codec /ast/IAX2/35210/peers /ast/IAX2/35210/jitter ... sounds *great* to me. I agree though that it should not hit any kind of real DB... that would hammer your I/O. -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Asterisk channel variable access: a proposal
On Monday 16 August 2004 21:55, John Todd wrote: I've been trying to get my head around some statistics and reporting of Asterisk channels, and I'm having a fairly difficult time of it. I currently have no way (as an example) of seeing what codec my IAX calls are using, or seeing how many rings I typically have on an inbound call before pickup (hint: both of these things have economics associated with them.) The only additional data I would want would be the PIDs and process names of any external processes associated with the channel... say mpg123 for MOH, for example. That way if I wanted to directly manipulate the external process (say sending signals to select previous/next song, for example), I could do so without any screwing around. Regards, Andrew ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[Asterisk-Dev] CVS HEAD (20040807) jitter buffer questions
I've been keeping an eye on the jitter buffer ever since upgrading and using Steve's patch to fix the 65s dead air problem but I've been noticing something... ... Asterisk frequently gets lag and jitter mixed up. This directly affects the jitter buffer, as the jitter buffer only grows when jitter grows. To better explain what I mean I'll show you the output from 'iax2 show channels': *CLI iax2 show channels Peer UsernameID (Lo/Rem) Seq (Tx/Rx) Lag Jitter JitBuf Format 192.168.2.2 benphone9/16384 00047/00050 6ms 0001ms 0051ms GSM 1 active IAX channel(s) This is good. *CLI iax2 show channels Peer UsernameID (Lo/Rem) Seq (Tx/Rx) Lag Jitter JitBuf Format 192.168.2.2 benphone3/16385 8/5 0ms ms 0050ms GSM 192.168.2.2 benphone9/16384 00072/00074 2ms ms 0050ms GSM 66.225.202.72benshaw 00013/00207 5/8 0ms 0015ms 0080ms GSM This is not. How can I possibly have 0ms lag? This was a decent call, some have like 182ms jitter which is even beyond normal lag measurements I have seen (normally 26-35ms, sometimes as high as 50 to 80ms). The measurements are consistent too -- I can run the command a 20 times in a minute and get 0ms lag on the channel(s) every single time with the jitter staying consistent. It's not a one-off thing. Sometimes it's one channel where the others look normal, sometimes it's a half dozen channels showing 0ms lag and high jitter with the few remaining channels showing normal, sometimes they're all normal. *CLI iax2 show channels Peer UsernameID (Lo/Rem) Seq (Tx/Rx) Lag Jitter JitBuf Format 192.168.2.2 benphone3/16385 00017/00015 0ms ms 0050ms GSM 192.168.2.2 benphone9/16384 00088/00090 -1ms ms 0050ms GSM 66.225.202.72benshaw 00013/00207 00015/00017 0ms 0015ms 0080ms GSM Similar here -- I see the meter itself is fixed (not 6553434665234265ms lag g) but how is negative lag possible? I believe I have also seen negative *jitter* -- and this causes the jitter buffer to grow without necessity. Relevant iax2.conf settings: pingtime=5 lagrqtime=5 jitterbuffer=yes dropcount=2 maxjitterbuffer=500 maxexcessbuffer=100 minexcessbuffer=50 jittershrinkrate=1 All peers have trunk=off (I was getting bunched and gappy audio the odd time... definitely not every time but especially noticeable right after a clean shutdown and restart of Asterisk)... By bunched and gappy I mean the received audio sounded like this: Hellohowareyouto.dayIhaven't.heardfromy.ouina.while I understand that a few months ago this was a consistent bug when enabling trunking and jitter buffer but I've been running trunking and jitter buffer for a while now without issue (well just the once in a while issue I just mentioned here). I'll be able to provide iax2 debug logs and packet dumps if anyone's interested. Regards, Andrew ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] voicemail message number limits
On Sunday 25 July 2004 13:22, Tilghman Lesher wrote: No, he would refuse to merge it, because it wasn't DISCLAIMED to Digium. Granting a specific license and assigning copyright are two very different things. NEITHER of the disclaimers currently in use by Digium assign your copyright to Digium. Thank you for clearing this up -- I had it wrong too, I see. -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] UK Caller ID patch and new CVS
On Friday 23 July 2004 10:29, Conroy, Lawrence (SMTP) wrote: Frankly though, I don't think ANYONE should buy these cards, clone or no -- Get the TDMxx series. Why? Does progress tone/call supervision/CLI work in the UK for the TDM4xx? (at least now CLI works with the X100P :). The TDM card is a true Digium product, not an OEM card resold by Digium. IIRC the FXO module is far higher quality too. In my experience, ISDN works very well with Junghanns's excellent chan_capi (and the AVM passive cards are cheaper) so if a couple of lines is all you need, ... The X101P doesn't support ISDN. I thought we were talking PSTN here not ISDN? -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] channel driver sample - Coding/Transcoding/Conferences
On Saturday 03 July 2004 12:22, Jeremy McNamara wrote: With todays CPU power there is absolutely no need for expensive DSPs. This is why Digium didn't design hardware with DSPs on board. You're gonna put a Pentium III/IV in a desk phone? DSPs are still very much alive and kicking, although the line between microprocessor and digital signal processor is getting more and more blurred every day. -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Advanced ADSI scripts
On Saturday 26 June 2004 10:27, TC wrote: Well take a look in app_adsi this is the app the takes the adsi script and loads it into the phone see compile_script it runs adsi_process adsi_process does not recognize a lot of the adsi key words in the this adsi v2 script ? granted the basic functions in res/res_adsi.c are generic but if you want the full power of the attached script you need to implement an adsi2_process in app_adsi then we can see the ability to write very powerfull adsi client side scripts Why not just use a commercial ADSI package to create the scripts and then upload them to the phone? Am I missing something? IIRC the ADSI interpreter in * was only used to take the english scripts and convert them to whatever the phones use to run ADSI? -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] OMG THE SKY IS FALLING!! NOT!!!
Usually and ironically my butt set and cloths served as ID. I initially read that as my butt and clothes :-) -A. ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] switch = Parking/companya
http://bugs.digium.com/bug_view_page.php?bug_id=0001494 MERRY NEW YEAR... and happy parking So I read the bug and (briefly) perused the patch... And I don't think I fully understand the extent or gain over regular parking. Can you provide a better example? The reason I'm interested is because I was currently in the process of hacking res_parking to emit a variable with the parking lot the call was placed in, and to allow the announcement to be optional. Regards, Andrew ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] switch = Parking/companya
You can transfer a call to 701 you just blind transfer it to 701 and it will park, If you transfer another caller to 701 while a call is parked it will bridge those calls up. Which is how the current parking works :P and since the lot can be as big as needed you can just say Bob your parking exten is 701, Mary your's is 702.. and so on. It has one problem that I'm going to talk to anthm about tomorrow. Ok... but couldn't you do that already (Bob, you're 701, Mary you're 702... ??) [company1] switch = Parking/company1 [company2] switch = Parking/company2 Now company1 and company2 have their own parking lots. :) With that example you just gave, is it impossible to park a call somwhere in company1's parking lot and allow someone in the company2 context to get to it? Do they both work off the same parking.conf file? John's post seems to indicate that any undefined extension can be used as a parking extension -- how is this configured in parking.conf differently than what we had yesterday? I feel like I'm missing an important step. Forgive me for being so dense, I'm just trying to grasp the greatness achieved here. You certainly seem excited about it so I'm trying ot share in that excitement. :-) Regards, Andrew ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] TE405P *hardware* question
As for TTL specification, 0 voltage must be between 0 and 0.8V, and 1 voltage must be between 2.4 and 5V, so LVTTL (3.3V)with their levels must comply with TTL spec. So, I don't see any is no problem if you connect zener-protected pins (5V tolerant) to 3.3V system. This is the biggie -- it's already all 5V compliant and safe, and the PCI 2.2 spec says that everything on the PCI bus must be 5V tolerant (it's been a while since I've been reading the spec, I might be wrong) -- but yeah -- Voh on the Spartan-II is 90% of Vcco on both the 5V and 3.3V pads. Interestingly enough the PCI33_3 minimum Voh is 300mV higher than the PCI33_5 pad specification. There was for Xilinx. But what about PEF? As I see for one used for TE410P (to remember - I don't have TE405P to check which chips used for it), there was 3.3V-only chips, so IMHO TE405P must have any sort of 3.3V source (from onboard regulator or from PCI connector). PEF? You mean the quad T1 framer? That is all sufficiently isolated from the PCI bus that I don't think it'd be a problem, and 5V power is available even on 3.3V PCI sockets. Any way, I don't see any problems to connect TE405P to 3.3V bus (after making second, 3.3V, key hole). But I'm not Digium's hardware engineer... ;-)' I think there would be dual-voltage TE405P+ cards (TE405P with two key holes) available when all TE410P already-made will be sold out. ;-)' Well I am glad that I'm not the only one who thinks it might be possible. I realize that neither of us have the real answer. I am hoping that someone from Digium replies with a definitely UNSUPPORTED, WARRANTY-VOIDING type of response. I'm gonna give it a few more days to build up my courage about frying a $1500 card and possibly high-end motherboard too... but this is the kind of thing I live for. :-) Regards, Andrew ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] asterisk crushes DEll PE 1750 SMP
Interrupt handler not syncing Killing Interrupt handler. Asterisk is not a kernel module -- you are having kernel issues. It very well could be the Zaptel driver, though. Have you tried using one of the dummy timing sources? Regards, Andrew ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Raising loop current limit on the Proslic (reg.71)
The 20ma loop is sort of typical. It actually can range from a low of about 12 ma up to about 30+ ma depending upon how far away from the central office the user happens to be, the gauge of copper plant, the telco engineers, etc. uh... The whole *point* of current loops is that they are insensitive to distance and have better noise immunity when compared to voltage signalling. And even 30AWG is capable of handling 20mA. :-) The only thing that would affect the loop in your list is the telco engineers, I'm afraid... That and craptastic sourcing equipment. Regards, Andrew ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [Asterisk-Dev] Digium TE410P Card
Just a suggestion, Tyan (notably the 2720 dual Xeon motherboard) provides 4 64 bit 3.3V pci slots. Yes, and for a single TE410P it's brutal overkill of a motherboard. A simple Duron-based system will have plenty of horsepower for what I'm looking for... Not really looking to cheap out on hardware but I also don't want to spend a pile of money on a motherboard whose feature set I'll never use ONLY to get some 3.3V PCI slots. Regards, Andrew ___ Asterisk-Dev mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-dev
