Thanks for good advice, will definitely keep these in mind while doing
coding - starting from now :)
On Mon, Feb 13, 2012 at 12:30 PM, Steve Edwards
asterisk@sedwards.comwrote:
On Mon, 13 Feb 2012, Sammy Govind wrote:
Hi again,Just to update I fixed the issue. I read through your reply
On 13 Feb 2012, at 12:06, virendra bhati wrote:
You can't set callerid for outgoing calls in case of PRI.
Why not? Every PRI I have used supported it. Is this a carrier-specific thing?
S
--
_
-- Bandwidth and Colocation
India TRAI rules doesn't allow for CLID setting. They are backwards minded.
If you ever get them to do it let me know ;)
-Bruce
On Mon, Feb 13, 2012 at 8:18 AM, Steven Howes steve-li...@geekinter.netwrote:
On 13 Feb 2012, at 12:06, virendra bhati wrote:
You can't set callerid for outgoing
Thanks for the info. As we move forward, we'll be testing and making a
phone selections. No doubt we'll run into this. Are you saying if the
phone is stated to be a 10/100 phone, it still may not work at 10?
On 2/13/2012 1:32 AM, Benny Amorsen wrote:
Jason W. Parksjason.w.pa...@gmail.com
The existing infrastructure I'm speaking of is the existing voice
infrastructure. It currently supports a digital PBX. No IP whatsoever,
but the wiring is rated for 10BaseT. As we look to replace the digital
PBX with VoIP, my options are to abandon that wiring and start using our
data network,
Jason
A standard SIP VOIP phone will use less than 100k per voice call. For
example I have several bussiness customers that have a dedicated DSL line
and they do up to 6 lines very well on that 1.5x384 (we do g729 which is
37k per call). If your networks drops can test solid at 10mb you
Gotcha! That was my plan. I ran into that exact issue when I was
randomly speed testing a couple of the lines. The computer under test
immediately negotiated to 100Mb and ran just fine, but I know I'm
asking for trouble to keep it that way. I will be forcing all ports
down to 10.
...and thanks
On 02/10/2012 05:30 PM, Mike wrote:
Hi,
I just moved many Polycom phones from firmware v3 to 4.0.1b. Anto-Answer
simply stopped functioning. I can downgrade and make it work, upgrading
kills it again. There obviously is a difference in how the newer
firmware is treating this auto answer sip
Hi all !
We currently have an asterisk box that is rather old (runs Asterisk
1.4.21.2), and it's connected to the PSTN with a sangoma A104d card.
Now we have a new PRI at another location, and I use that occasion to
build 2 new servers, one to replace our aging one and a new one for this new
Thanks Dave, it at least gives me hope that my efforts aren`t wasted.
Mike
-Original Message-
From: asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-
boun...@lists.digium.com] On Behalf Of Dave Fullerton
Sent: Monday, February 13, 2012 9:39 AM
To:
Nevermind,
I checked the code, and A* is not using the F option in MeetMe for
Page(), so it's not working by default.
Attached is a patch which fixes the problem for me, if anyone needs it.
Matteo
Il 11/02/2012 13:53, Matteo Fortini ha scritto:
Noone knows that? Where/whom could I ask?
On Mon, Feb 13, 2012 at 2:48 AM, Hans Witvliet aster...@a-domani.nl wrote:
Even on a 100Mbps network, if one of the machines on the same network is
doing a rsync-job (no saturation), I notice a drop in voip-quality.
That's because you don't know how to properly configure a network.
You could
-- Accepting call from '418nx2' to '418nx1' on channel 0/1,
span 1
-- Executing [418nx1@ael-default:1]
Answer(DAHDI/i1/418nx2-b, ) in new stack
-- Executing [418nx1@ael-default:2]
Wait(DAHDI/i1/418nx2-b, 2) in new stack
-- Executing
On 2/13/2012 10:49 AM, Andres wrote:
-- Accepting call from '418nx2' to '418nx1' on channel
0/1, span 1
-- Executing [418nx1@ael-default:1]
Answer(DAHDI/i1/418nx2-b, ) in new stack
-- Executing [418nx1@ael-default:2]
Wait(DAHDI/i1/418nx2-b, 2) in new stack
Steve Edwards wrote:
On Mon, 13 Feb 2012, Sammy Govind wrote:
On Sat, Feb 11, 2012 at 11:20 PM, Ron Bergin r...@i.frys.com wrote:
Finally, add a couple debugging statements after the get_variable
statements to verify/dump the vars.
Doing any I/O on STDIN or STDOUT will violate the AGI
(...)
My guess is your new setup is trying to do a PRI 2B Transfer (meaning
that Asterisk is trying to handoff two B channels of a PRI to the
upstream switch). It is probably being rejected and the call is hanging
up. You will need to dig into the PRI debug of both scenarios and
compare.
Anyone got a way to pull the Source and Destination IP addresses for a call
so they can be logged in a CDR and or CEL? Also anyone got a slick way for
registring PDD on calls?
Thanks
Bryant
--
_
-- Bandwidth and Colocation
On Sat, Feb 11, 2012 at 11:20 PM, Ron Bergin r...@i.frys.com wrote:
Finally, add a couple debugging statements after the get_variable
statements to verify/dump the vars.
Steve Edwards wrote:
Doing any I/O on STDIN or STDOUT will violate the AGI protocol.
On Mon, 13 Feb 2012, Ron Bergin
Jason W. Parks jason.w.pa...@gmail.com writes:
Thanks for the info. As we move forward, we'll be testing and making a
phone selections. No doubt we'll run into this. Are you saying if the
phone is stated to be a 10/100 phone, it still may not work at 10?
I must admit it isn't something I have
On 02/08/2012 09:28 AM, Josh wrote:
If one has internal networks, accessible via, say eth1 and tun0, and
implements Asterisk to act as the internal/private PBX (without exposing
it to the outside world), then having been forced to use 0.0.0.0 will,
of course, expose Asterisk to any other -
Dear Moderator,
I need an assistance for below problem:
1. there are time incoming call from extension 100 that I don't create, how
to know where is the origin of this extension?
2. when I pick up the call, there is no sound at all, this is very iritating
me due sometime the call is made during
Indian Telcos do allow setting callerid on PRI line and you can set the
callerid to one of the numbers allocated by them for PRI.
--Satish Barot
On Mon, Feb 13, 2012 at 6:49 PM, Ast Coder asteriskcod...@gmail.com wrote:
India TRAI rules doesn't allow for CLID setting. They are backwards
22 matches
Mail list logo