Kevin P. Fleming wrote:
I'm sorry it took me so long to get back to this thread... there have been many
good points raised and I'm happy to see that the general sense in the community
is along the same lines as my original thinking :-)
The issue that started this discussion is NOT an extreme v
Inline... general comments
I am working on trying to track down and eliminate echo on a PRI.
I'm using Gen 2 TE-405P cards, w/ the MG2 echo canceller. I cannot enabnle
AGGRESSIVE_SUPPRESSION because that causes dropouts in the speech that are
unacceptable to my customers needs. I am awaiting
Russell Bryant wrote:
On Fri, 2006-07-28 at 05:30 -0200, Kaloyan Kovachev wrote:
In 1.2 timstamps option in asterisk.conf have added timestamps not just in
logs (actually changes the way they appear), but also to the cli for all
actions including dialplan messages and devices registration.
In tr
Obelix wrote:
I want to run a trunk version of Asterisk with the ability to switch back to a
stable version.
Because they will be running with the same .conf files and call management
database, I want to be able to switch between them just my running a simple
script - either by copying them to a
I need two things -- strict policy, and info about what patch would be
commited, if some issues would fixes, and what patch would not be
commited, and I doesn't need to spend my time for supporting this patches.
There is no answer to that question before the patch exists. We can
certainly tell
We are using Asterisk 1.2 and have a TDM 400P installed with 2 FXO ports
– each of these is plugged into a separate PSTN line with its own phone
number. We have everything configured pretty well, but one strange issue
is occurring which I’m hoping you can shed some light on. We use call
forward
Joseph Rothstein wrote:
I have already posted this several times on the users list, and have never
gotten a response.
http://lists.digium.com/pipermail/asterisk-users/2006-January/135205.html
http://lists.digium.com/pipermail/asterisk-users/2006-January/136122.html
Other people seem to be havin
> Olle suggested that I email this list with respect to offering my
> services as a bug marshal. I currently know my way around chan_zap and
> some of the zaptel code as a result of maintaining the history buffer
> patches over the last year or so.
>
> If there's any area that needs urgent atten
> > that'll surely increase scalability, when the bugs are ironed out. well
> > done, mark !
>
> Bugs? We've been beating it up for like 3 hours now and it seems to be
> dealing with things quite nicely.
Is the impact of this change primarily oriented toward the registration
process, or will
> > > Back in Asterisk 1.0.5, when we sent our SDP packet to the distant end,
> > > we sent
> > > m=audio RTP/AVP 101
> > > where the 101 which indicated that we wanted to get RFC2833 DTMF from our
> > > other end.
> > >
> > > Now it's missing, and my peer (level3) is sending me inband DTM
> I have a siemens ewsd switch, it supports gr303 links. What i want to do is
> have one
asterisk server connected to
> the switch(gr-303) passing calls . Then use asterisk servers at customer
> locations to
handle voice and data either
> over a data t1 or voice and data t1. Can asterisk be us
> >- ensure that you are testing against inexpensive equipment (Sipura
> > is an SRTP device which is cheap...)
>
> Did Sipura ever release enough information for folks to make their own
> "mini-certificates"? P.17 - P.19 of 841AdminGuide1105.pdf has some
> good hints, but I haven't been abl
fc3, current cvs-head from 1:25pm today...
make[1]: Leaving directory `/usr/src/asterisk/stdtime'
gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declaration
s -g -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i686 -DZAPTE
L_OPTIMIZATIONS -fomit-frame-
> > I'm interested as well, haven't seen anything on -cvs or in the UPDATE
> > file about this, any more clues? :)
>
> The only things that go into UPDATE are non-backwards-compatible
> changes; if we tried to list every new feature there it would be an
> enormous list.
How difficult (or time
The way that I read it is the drivers (etc) required for the cards are
being jointly developed (doesn't say anything about "who" is selling them),
and it doesn't say that Intel (or whoever) can't sell their cards with
drivers bundled. If you wanted to buy their package and apply it to your
cvs-head
> After months in the bug tracker, we've finally committed a lot of
> changes to the SIP Subscribe subsystem in Asterisk cvs head.
>
> * It now works even if you reload the dial plan
> * It does not accept subscriptions to extensions without hints
> * It will terminate subscriptions if the hint do
> Rich Adamson wrote:
>
> > Are the messages anything that I should be concerned about, or, should
> > I open a bug on this?
>
> Neither; as the message clearly suggests, upgrade udev. Version 039 is
> very old at this point, I believe version 062 is current r
FC3, cvs-head from 10:20pm Aug 6th (current)
Just did a complete checkout and build, and /var/log/messages now contain
the following messages:
Aug 6 22:14:52 phoenix kernel: Found a Wildcard TDM: Wildcard TDM400P REV H (4
modules)
Aug 6 22:14:52 phoenix kernel: Registered tone zone 0 (United St
Did a 'make update' from cvs-head this morning followed by 'make'
and get:
asterisk.o(.text+0x54): In function `ast_register_file_version':
/usr/src/asterisk/asterisk.c:171: undefined reference to `ast_strip'
collect2: ld returned 1 exit status
make: *** [asterisk] Error 1
Anyone else getting t
Would someone hit me with that clue-bat please?
What's the meaning of the message following * compile?
Your Asterisk modules directory, located at
/usr/lib/asterisk/modules
contains modules that were not installed by this
version of Asterisk. Please ensure that these
modules are compatible w
ously impact code such as spandsp.
> From: Andrew Kohlsmith <[EMAIL PROTECTED]>
> On April 27, 2005 09:04 am, Rich Adamson wrote:
> > I would sort of disagree with the spiking thingie (now). If you modify
> > the zttest app to provide timing output in terms of seconds and
> &
> 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
> >
> > ast-one dial(IAX2/)'s ast-two. Both are CVS HEAD within a week of today.
> >
> > ast-two's context for ast-one's type=user is somecontext.
> >
> > [somecontext]
> > exten => 100,1,NoOp(One)
> > exten => 100,2,Hangup
> >
> > exten => 200,1,NoOp(Two)
> > exten => 200,2,Hangup
> >
> > exten =
> >>On April 15, 2005 08:06 am, Rich Adamson wrote:
> >>
> >>>; This section is the Last and handles 'no valid extension'
> >>>[no-match]
> >>>exten => _.,1,Answer
> >>>exten => _.,2,Playback(invalid,skip)
> >
> From: Steve Kann <[EMAIL PROTECTED]>
> Rich Adamson wrote:
>
> >Thanks Steve. How about just adding a new-line at the end of that
> >string so it doesn't mess up the remainder of the debug stuff?
> >
> >
> Each character is printed when a frame
n option to iax2 debug; i.e. iax2 debug
> jitterbuffer and iax2 no debug jitterbuffer or something..
>
> -SteveK
>
>
> Rich Adamson wrote:
>
> >RHv9 system, CVS-HEAD-04/07/05
> >
> >When "iax2 debug" is executed to observe an incoming iax call, cl
RHv9 system, CVS-HEAD-04/07/05
When "iax2 debug" is executed to observe an incoming iax call, cli shows:
Rx-Frame Retry[ No] -- OSeqno: 008 ISeqno: 012 Type: IAX Subclass: LAGRP
Timestamp: 20010ms SCall: 00119 DCall: 1 [217.160.244.186:4569]
Tx-Frame Retry[-01] -- OSeqno: 012 ISeqno
> > I just chated with someone on the asterisk documentation
> > channel, and they explained to me that the wctdm stuff
> > is propiotary to Digium.
> >
> > This is something I did not know.
> >
> > So I am not going to persue trying to figure out that code anymore.
> >
> I'm not sure what you me
Yes, some. Switches forward packets at layer two (mac address), and learn
the location of each mac address by listening to packets. Once it has
learned the switch ports associated with the mac address, the switch will
_not_ forward sip or rtp traffic to other ports not associated with the
sip/rtp s
> >>The Bad News:
> >>
> >>| VoIPong is a utility which detects all Voice Over IP calls on a
> >>| pipeline, and for those which are G711 encoded, dumps actual
> >>| conversation to seperate wave files. It supports SIP, H323, Cisco's
> >>| Skinny Client Protocol, RTP and RTCP.
> >
> >
> > This a
> > So the purpose should be clearly deliniated, and then an eval of how it is
> > not
> > being accomplished, or is being threatend can be done.
> >
> > The concern I have is that people are aware of and even if they disagree or
> > are too lazy, they KNOW the rules of the list.
>
> Perhaps you
Since a lot of folks seem to be sensitive to that 4800 number, keep in
mind the primary issue that is significantly more important is 'how
many simultanous channels in use'. E.g., if zero channels in use, why
is 4800 a problem? (I'm not the original poster but just somebody that
is rather sensitive
available to anyone with the skills to diagnose
the problem, including three pstn numbers to access the system, sip acct,
etc. I'm a non-programmer and really don't have a clue how to get closer
to the problem at this point. Any thoughts?
Rich Adamson
___
> Rich Adamson [EMAIL PROTECTED] wrote:
> > Its also fairly common knowledge the x100p was not designed/built by
> > digium, but rather they choose to use an existing modem card that had
> > the chipsets (etc) that could be used for entry-level systems at a
> > ver
I've not seen the disconnect supervision impact this, however simply picking
up a bridged analog phone for a second or two is usually enough to cause
asterisk to ring the appropriate dialplan entry. The ring detection / processing
happens immediately after the analog phone hangup (not seconds later
I spent a fair amount of time about three or four weeks ago trying the
different options using the Silicon Labs tech sheet. I was attempting
to verify whether the different settings had any impact on echo, and
by simply listening (no instrumentation) I could not detect any impact.
(3 active pstn li
> On 10-Jun-04, at 10:24 PM, Ron Frederick wrote:
>
> > I also have some other devices directly connected to that same phone
> > line,
> > in parallel with the TDM11B. I immediately noticed a problem in this
> > configuration when one of the other devices went back on-hook after
> > using
> > th
Isn't it about time to lock down added functionality to v1.1 and fix
the remaining bugs?
There has been a significant amount of traffic on the cvs list, the irc
and other channels with folks spending time adding new functionality to
Head. Think its time to lock it down, fix the bugs that have bee
> Sadly, the article reads as more bogus than it really is. SIP really is
> weak. RTP stream are almost universally unencrypted right now. Listening
> in to a VoIP within your company is generally much easier than snooping
> on a traditional call. I wonder how long it will take before encryption
> > I agree that a more specific understanding of interactions between
> > 802.11[b,a,g] and SIP RTP sessions would be worthwhile if it could be
> > found or generated and posted to this list. Additionally, what would be
> > more worthwhile would be a similar IAX2 study. I'll put this on my
> > After I hit send I realized I was "out of context" with the original
> > topic. For the central office based loops, the 12 to 30+ still holds
> > true for many CO switches. There are still a large number of CO switches
> > that are not current regulated loops; those are still I=E/R with E fixed
> > 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 tha
> > This never happen to me under redhat 7.3 but I just happen to checkout
> > from cvs under Redhat 9 and now it's happening to me. So, I think is a
> > version related issue with Redhat 9. Unless it's is also happening on Redhat
> > 7.3 ???
>
> We are indeed running on Red Hat 9. I don't rem
> So, the CVS repository has been redone, like we said a couple of weeks ago.
> This means that some modules will have to be checked out fresh -- just doing
> "cvs update" (or "make update") will *NOT* work. The modules in question
> are:
>
> asterisk
> gastman
> gnophone
>
44 matches
Mail list logo
