[Asterisk-Dev] RE: Help with Call Waiting
Ali Amirrezvani
ali at edealertools.com
Thu May 13 07:39:21 MST 2004
Hi all,
I wanted to write a quick note to thank all over the people whom took
the time to help me figure out the calling waiting issue we were having.
I passed on all of your input to our head developer and he was able to
figure it out and fix the issue. Anyway, just wanted to say thanks.
Ali
-----Original Message-----
From: asterisk-dev-admin at lists.digium.com
[mailto:asterisk-dev-admin at lists.digium.com] On Behalf Of
asterisk-dev-request at lists.digium.com
Sent: Wednesday, May 12, 2004 4:19 AM
To: asterisk-dev at lists.digium.com
Subject: Asterisk-Dev digest, Vol 1 #635 - 10 msgs
Send Asterisk-Dev mailing list submissions to
asterisk-dev at lists.digium.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.digium.com/mailman/listinfo/asterisk-dev
or, via email, send a message with subject or body 'help' to
asterisk-dev-request at lists.digium.com
You can reach the person managing the list at
asterisk-dev-admin at lists.digium.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Asterisk-Dev digest..."
Today's Topics:
1. Re: cisco 7940/7960 call_stats logging (John Todd)
2. Re: Help with Call Waiting (Brian J. Schrock)
3. FW: [Asterisk-Dev] Help with Call Waiting (Alexander Lopez)
4. RE: listening to my messages (leonardo)
5. Re: cisco 7940/7960 call_stats logging (Jared Mauch)
6. Call Quality Measurement idea (was: cisco 7940/7960 call_stats
logging) (John Todd)
7. Where to get 48 volt Power Supplies for Cisco IP Phones (James
Gardiner)
8. Re: Where to get 48 volt Power Supplies for Cisco
IP Phones (Josh Roberson)
--__--__--
Message: 1
Date: Tue, 11 May 2004 11:44:25 -0700
To: asterisk-dev at lists.digium.com
From: John Todd <jtodd at loligo.com>
Subject: Re: [Asterisk-Dev] cisco 7940/7960 call_stats logging
Reply-To: asterisk-dev at lists.digium.com
Having this type of functionality in the CDR records would really be
great. I wish all devices spit out this type of message. A few
hours with Perl and RRDTool and some very, very interesting graphs
could be put together showing call quality based on network range,
time of day, type of UA, etc. Also interesting would be the
statistics from Asterisk's perspective if the media stream were
flowing through Asterisk. In other words, in a media stream that
goes between two endpoints (IAX2, or SIP, or H.323, or whatever) we
have:
UA A <-> * <-> UA2
Now, Asterisk can collect some statistics on both legs of those calls
if we choose to have the media stream go through Asterisk. Can those
be collected in a similar way and inserted into the CDR? Maybe
another log file, perhaps called "CQDR" should be created that
captures this data and associated replies from remote devices like
the Ciscos. Even a single leg call (between a UA and an Asterisk
server with a PRI card) should be able to provide those stats from
the perspective of Asterisk, without any requirement of the UA to
collect and deliver those stats back to * in the BYE message.
Of course, if we were using RTCP and keeping media streams on the
server, we could also fetch similar events through RTCP statistics.
See the archives for some discussion of this last year.
This is (from my non-C-experienced viewpoint) a fairly major
development task. However, it does seem obvious that Asterisk needs
to have some call quality measurement in order to be compared against
the "big boys" of the VoIP world, if only so that an Asterisk admin
can point to a graph and say "See? Call quality is great with my
free software, and I can identify problem customers almost
immediately - how is your million-dollar system doing?" And it's
something that would be useful and universally applicable across all
channel types that involved VoIP of some type. Any takers? :-)
JT
At 11:46 AM -0400 5/11/04, Jared Mauch wrote:
>
> Ideally one would log it as well as the endpoint IPs in order
>to determine if there is a network problem with one of the peoples
links.
>
> I have a lot of users behind various NAT devices on
>dsl/cable and want to use this to pinpoint the source of their
>problems.
>
> - Jared
>
>On Tue, May 11, 2004 at 09:35:23AM -0600, brian k. west wrote:
>> Now if you can make this a config option per peer and copy it into
the
>> cdr->userfield.
>>
>> bkw
>>
>> ----- Original Message -----
>> From: "Jared Mauch" <jared at puck.nether.net>
>> To: <asterisk-dev at lists.digium.com>
>> Cc: "Jared Mauch" <jared at puck.nether.net>
>> Sent: Tuesday, May 11, 2004 8:02 AM
>> Subject: Re: [Asterisk-Dev] cisco 7940/7960 call_stats logging
>>
>>
>> > I've hacked together this which does
>> > the job..
>> >
> > >
>[patch snipped[
> > >
>> >
>> > - Jared
>> >
>> > On Fri, Apr 30, 2004 at 12:23:38AM -0400, Jared Mauch wrote:
>> > >
>> > > so, in the recent SIP firmware on the Cisco phones,
>> > > it sends some data in the BYE message that can be used to
collect
>> > > information about the connection.
>> > >
>> > > I want to collect and parse this data to help show my users
>> > > that have bad connections exactly what we see as compared to
>> > > a non-problematic connection/ISP.
>> > >
>> > > Has anyone been looking at this yet?
>> > >
>> > >
>>
>>http://www.cisco.com/en/US/products/sw/voicesw/ps2156/prod_release_not
e09186a00801d1d80.html#80912
>> > >
>> > > I'm also really interested in the jitter and late/lost pkts
>> > > too..
>> > >
> > > > - jared
--__--__--
Message: 2
From: "Brian J. Schrock" <brians at anistonetech.com>
Organization: Anistone Technologies, LLC
To: asterisk-dev at lists.digium.com
Subject: Re: [Asterisk-Dev] Help with Call Waiting
Date: Tue, 11 May 2004 15:42:02 -0400
Reply-To: asterisk-dev at lists.digium.com
Is this SIP?
If so you can limit the amount of calls a sip phone will take incoming
to one.
That way as long as threeway calling is outgoing only (would it ever not
be)
then you have what you want.
I do not remember how to set it, but do a "sip show inuse" at the
asterisk
console. I did this for a client.
Brian,
On Tuesday 11 May 2004 09:02, Ali Amirrezvani wrote:
> Hi all,
>
> I sent a message out about this a few days ago though I am still
unable to
> figure this out. Any input would be greatly appreciated. Is there a
way
> to disable call waiting, but still be able to use three-way calling?
The
> problem is that when I am on the phone with a customer and someone
calls,
> the call waiting beep cuts off what I am saying and has annoyed one
too
> many potential customers. When I am on the phone, I would much rather
have
> the call go straight to voicemail.
>
> Two possible fixes would be:
>
> 1. Call goes straight to voicemail
> 2. Disable the call waiting beep sound - So, the call is technically
still
> waiting though the sound of the beep has been disabled.
>
> The last time I sent out this message Rich replied with this comment:
>
> It all depends on the phone your using and how it is integrated
into
> *.
>
> If its a Cisco phone (as one example), Settings/Call
> Preferences/Call Waiting = NO will stop the call waiting. 3- way is
> likely implemented as a consultive transfer or something like that,
which
> should not preclude you from
> initiating such calls.
>
> If its some other phone, look for similar setup.
>
> If that's not what you're after, then a better description of
what
> you're trying to accomplish, type of phone, etc, would be helpful.
>
> If anyone has any idea how to make one of these options work, your
input
> would greatly appreciated.
>
> Thanks again!!
>
> Ali
>
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at 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
--
Brian J. Schrock
Anistone Technologies, LLC
Phone: 614-798-9106 ext. 2
Cell: 614-537-2817
E-Mail: brians at anistonetech.com
http://www.anistonetech.com
http://www.vipcomtel.com
--__--__--
Message: 3
Subject: FW: [Asterisk-Dev] Help with Call Waiting
Date: Tue, 11 May 2004 17:23:46 -0400
From: "Alexander Lopez" <alex.lopez at opsys.com>
To: <asterisk-dev at lists.digium.com>
Reply-To: asterisk-dev at lists.digium.com
>>>>-----Original Message-----
>>>>From: Alexander Lopez
>>>>Sent: Tuesday, May 11, 2004 9:36 AM
>>>>To: 'asterisk-dev at lists.digium.com'
>>>>Subject: RE: [Asterisk-Dev] Help with Call Waiting
>>>>
>>>>Ali,
>>>>
>>>> The reason Rich, as well as the rest of us, needs to know what
>>>>phone you re using is because that will tell us what channel driver
you
>>>>are using. (i.e. Zap, Sip, IAX, etc..) Many channels 'pass' the
>>>>function of call waiting to the end point, whereas others handle the
>>>>function within the channel driver. If it is a channel that is
>>>>handling the feature or function then a source code modification
would
>>>>be needed. However if it is handled by the end point then it is
simply a
>>>>matter of changing the configuration on your phone.
>>>>
>>>>By your response and the fact the you need 3way but not call waiting
I
>>>>can deduce that you are on a Zap channel. I would recommend that in
lieu
>>>>of changing source and possibly breaking future CVS updates for
>>>>yourself. That you invest in a SIP device. The time saved will
defiantly
>>>>pay for the cost of the phone itself.
>>>>
>>>>If you need help with the configuration of your SIP device, don't
>>>>hesitate to post to asterisk-users and I an sure that someone there
>>>>could help you. Just make sure you check the Wiki first!!!
>>>>
>>>>Hope this helps.
>>>>
>>>>
>>>>Alex
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: asterisk-dev-admin at lists.digium.com [mailto:asterisk-dev-
>>>>admin at lists.digium.com] On Behalf Of Ali Amirrezvani
>>>>Sent: Tuesday, May 11, 2004 9:03 AM
>>>>To: asterisk-dev at lists.digium.com
>>>>Subject: [Asterisk-Dev] Help with Call Waiting
>>>>
>>>>Hi all,
>>>>
>>>>I sent a message out about this a few days ago though I am still
unable
>>>>to
>>>>figure this out. Any input would be greatly appreciated. Is there
a
>>>>way to
>>>>disable call waiting, but still be able to use three-way calling?
The
>>>>problem is that when I am on the phone with a customer and someone
>>>>calls,
>>>>the call waiting beep cuts off what I am saying and has annoyed one
too
>>>>many
>>>>potential customers. When I am on the phone, I would much rather
have
>>>>the
>>>>call go straight to voicemail.
>>>>
>>>>Two possible fixes would be:
>>>>
>>>>1. Call goes straight to voicemail
>>>>2. Disable the call waiting beep sound - So, the call is technically
>>>>still
>>>>waiting though the sound of the beep has been disabled.
>>>>
>>>>The last time I sent out this message Rich replied with this
comment:
>>>>
>>>> It all depends on the phone your using and how it is integrated
>>>>into
>>>>*.
>>>>
>>>> If its a Cisco phone (as one example), Settings/Call
>>>>Preferences/Call Waiting =3D NO will stop the call waiting. 3-
way is
>>>>likely implemented as a consultive transfer or something like that,
>>>>which
>>>>should not preclude you from
>>>> initiating such calls.
>>>>
>>>> If its some other phone, look for similar setup.
>>>>
>>>> If that's not what you're after, then a better description of
what
>>>>you're trying to accomplish, type of phone, etc, would be
helpful.
>>>>
>>>>If anyone has any idea how to make one of these options work, your
input
>>>>would greatly appreciated.
>>>>
>>>>Thanks again!!
>>>>
>>>>Ali
>>>>
>>>>_______________________________________________
>>>>Asterisk-Dev mailing list
>>>>Asterisk-Dev at 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
--__--__--
Message: 4
Date: Tue, 11 May 2004 07:55:08 -0400
From: leonardo <leonardomateo at optonline.net>
To: asterisk-dev at lists.digium.com
Subject: [Asterisk-Dev] RE: listening to my messages
Reply-To: asterisk-dev at lists.digium.com
can someone please tell me how I can listen to my messages?
regards
leo
--__--__--
Message: 5
Date: Tue, 11 May 2004 22:23:21 -0400
From: Jared Mauch <jared at puck.nether.net>
To: asterisk-dev at lists.digium.com
Subject: Re: [Asterisk-Dev] cisco 7940/7960 call_stats logging
Reply-To: asterisk-dev at lists.digium.com
On Tue, May 11, 2004 at 11:44:25AM -0700, John Todd wrote:
> This is (from my non-C-experienced viewpoint) a fairly major
> development task. However, it does seem obvious that Asterisk needs
> to have some call quality measurement in order to be compared against
> the "big boys" of the VoIP world, if only so that an Asterisk admin
> can point to a graph and say "See? Call quality is great with my
> free software, and I can identify problem customers almost
> immediately - how is your million-dollar system doing?" And it's
> something that would be useful and universally applicable across all
> channel types that involved VoIP of some type. Any takers? :-)
Perhaps we can get the data in asterisk
stored up and output int the same format
as the cisco w/ RTP-RxStat/RTP-TxStat
- Jared
> At 11:46 AM -0400 5/11/04, Jared Mauch wrote:
> >
> > Ideally one would log it as well as the endpoint IPs in order
> >to determine if there is a network problem with one of the peoples
links.
> >
> > I have a lot of users behind various NAT devices on
> >dsl/cable and want to use this to pinpoint the source of their
> >problems.
> >
> > - Jared
> >
> >On Tue, May 11, 2004 at 09:35:23AM -0600, brian k. west wrote:
> >> Now if you can make this a config option per peer and copy it into
the
> >> cdr->userfield.
> >>
> >> bkw
> >>
> >> ----- Original Message -----
> >> From: "Jared Mauch" <jared at puck.nether.net>
> >> To: <asterisk-dev at lists.digium.com>
> >> Cc: "Jared Mauch" <jared at puck.nether.net>
> >> Sent: Tuesday, May 11, 2004 8:02 AM
> >> Subject: Re: [Asterisk-Dev] cisco 7940/7960 call_stats logging
> >>
> >>
> >> > I've hacked together this which does
> >> > the job..
> >> >
> > > >
> >[patch snipped[
> > > >
> >> >
> >> > - Jared
> >> >
> >> > On Fri, Apr 30, 2004 at 12:23:38AM -0400, Jared Mauch wrote:
> >> > >
> >> > > so, in the recent SIP firmware on the Cisco phones,
> >> > > it sends some data in the BYE message that can be used to
collect
> >> > > information about the connection.
> >> > >
> >> > > I want to collect and parse this data to help show my users
> >> > > that have bad connections exactly what we see as compared to
> >> > > a non-problematic connection/ISP.
> >> > >
> >> > > Has anyone been looking at this yet?
> >> > >
> >> > >
> >>
>
>>http://www.cisco.com/en/US/products/sw/voicesw/ps2156/prod_release_not
e09186a00801d1d80.html#80912
> >> > >
> >> > > I'm also really interested in the jitter and late/lost pkts
> >> > > too..
> >> > >
> > > > > - jared
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at 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
--
Jared Mauch | pgp key available via finger from jared at puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only
mine.
--__--__--
Message: 6
Date: Tue, 11 May 2004 22:27:45 -0700
To: asterisk-dev at lists.digium.com
From: John Todd <jtodd at loligo.com>
Subject: [Asterisk-Dev] Call Quality Measurement idea (was: cisco
7940/7960 call_stats
logging)
Reply-To: asterisk-dev at lists.digium.com
I like that format, but I'd also like to see a little more data in the
output if it's possible, since we have the data... Jitter is the
biggest problem I have with my calls right now, and I'd like to get a
better idea of what's going on with that statistic.
AvgJtr = Average Jitter
MaxJtr = Maximum Jitter
JtrSDV = Jitter Standard Deviation
These are the minimal data required to provide meaningful alarm outputs.
One particular call might have one second of really nasty jitter in a 20
minute conversation, which is probably "acceptable", but we'd want to
see that maximum jitter number to notify us that something went wrong
there... somewhere. The average (and even the standard deviation)
numbers wouldn't tell us that.
Also, the term "RTP" shouldn't be used in the stats routines, since if
we include IAX channels then we're not going to be using RTP. Might as
well be pedantic about it. :-)
Let me put on my "wishing hat" for a while. I wish we had...
Perhaps something like this in /var/log/asterisk/cqdr :
Callstart,Callend,OriginIP,DestinationIP,PerspectiveIP,UniqueID,RxPacket
s,RxOctets,RxLatePackets,RxLost,RxAverageJitter,RxMaximumJitter,RxStanda
rdDeviationJitter,TxPackets,TxOctets
Where:
Callstart = Timestamp of call audio setup (starting from RTP startup,
not call startup) Timestamps are generated by local clock, not by
remote devices/endpoints.
Callend = Timestamp of call audio termination (ending at RTP end, not
call end) Timestamps are generated by local clock, and not by remote
devices/endpoints.
OriginIP = The IP of the origin for this leg (who initiated the call.)
In the instance this is the local Asterisk server, it should use the
address of the interface (or whatever was the originating packets) used
to communicate audio data for the session.
DestinationIP = The destination IP address of the call. Again, if it's
the local Asterisk server, the locally defined IP address (interface,
virtual interface, whatever) should be used.
PerspectiveIP = Who is reporting this event? PerspectiveIP should match
_either_ the OriginIP or the DestinationIP. Since we can take reports
in from remote devices, this needs to be included so that we can have
multiple reports of the same call to compare who sees what from various
perspectives. In the event of NAT on the device (SIP or IAX2) then use
the IP address which is seen by the Asterisk server as the "outside"
address.
UniqueID = The unique call ID given to this call. If this is reported
by Asterisk, then it is set to uniqueid (channel unique identifier.)
Messages transmitted back to Asterisk in SIP BYE or other hangup methods
should be tagged with the unique Asterisk identifier to facilitate
matching of CDRs to CQDRs. Zap channels should use the group/channel
number.
Protocol = the protocol of this leg (IAX2, IAX, SIP, H323, MGCP, SCCP,
ZAP, etc.)
Codec = the codec being used on this leg (Recall that Zap is either ULAW
or ALAW, so we could put Zap channels into this mix even though they
would always be 100% "good" in their statistics)
RxPackets = The number of packets received during the session (or
UNKNOWN)
RxOctets = The number of bytes received during the session (or UNKNOWN)
RxLatePackets = The number of late (mis-ordered) packets received during
the session (or UNKNOWN)
RxLost = The number of packets lost during the session (or UNKNOWN)
RxAverageJitter = The average jitter (difference between sequential Rx
packets) during the session (or UNKNOWN)
RxMaximumJitter = The maximum delay between sequential Rx packets during
the session (or UNKNOWN)
RxStandardDeviationJitter = The standard deviation of jitter values
during the session (or UNKNOWN)
TxPackets = The number of packets transmitted during the session (or
UNKNOWN)
TxOctets = The number of bytes transmitted during the session (or
UNKNOWN)
Here's an example of three lines that would appear in the CQDR file if
my mythical call quality system was put in place. While this example
uses RFC1918 addresses, assume that there are no NAT translations
occurring here (not that it makes that much of a difference...):
Asterisk = 10.10.22.9
IAX2 client = 172.16.33.1
Cisco 7960 SIP client = 192.168.34.9
The Asterisk-to-Firefly (IAX2) call, as reported by Asterisk:
"2004-05-12 03:07:39","2004-05-12
03:08:33","10.10.22.9","172.16.33.1","10.10.22.9","123456789012345678901
23456789012","IAX2","ILBC",2922,994322,3,4,12,55,14,3002,942117
The Asterisk-to-7960 leg, as reported by Asterisk:
"2004-05-12 03:07:39","2004-05-12
03:08:33","10.10.22.9","192.168.34.9","10.10.22.9","12345678901234567890
123456789012","SIP","ALAW",9833,1400233,0,3,5,15,6,9660,13894412
The 7960-to-Asterisk leg, as reported by the 7960:
"2004-05-12 03:07:40","2004-05-12
03:08:33","192.168.34.9","10.10.22.9","192.168.34.9","123456789012345678
90123456789012","SIP","ALAW",9654,13893011,1,6,6,"UNKNOWN","UNKNOWN",983
0,1399933
There is no Firefly-to-Asterisk leg, since Firefly doesn't have the
ability to report back that data. Perhaps for that leg we would put in
a "dummy" record that had all "UNKNOWN" values stuff into it for that
perspective's quality reporting? I haven't really thought about that
one much...
Looking at these made-up numbers, we can see that there is pretty good
packet throughput and jitter across these two legs. The numbers are
close enough that we probably wouldn't worry about quality here. Some
quick perl would be able to link CDR's with CQDR's based on uniqueID, or
even (possibly) on the call time, though time is an inadequate method
for matching call legs together. I haven't really figured out how
re-invites would show up in this system; I suppose if they generate a
new uniqueID, they'd create a new set of records. Similiarly, IAX2
calls that native bridge after initial negotiation would just show a
very short CQDR record, but hey, something is better than nothing.
Perhaps eventually we'll see IAX2 report back things like this to the
origin server(s) after hangup, but I don't think that the architecture
needs to change just for this reason...
In any case, someone out there should put this on the "John's Very Large
Pile of Asterisk Ideas Which Will Never Be Implemented". I'm sure
Google will have a good time showing it to people for years and years
when they search on "asterisk call quality" or "IAX2 quality
measurement" or other trivial things like that. :-)
JT
At 10:23 PM -0400 on 5/11/04, Jared Mauch wrote:
>On Tue, May 11, 2004 at 11:44:25AM -0700, John Todd wrote:
>> This is (from my non-C-experienced viewpoint) a fairly major
>> development task. However, it does seem obvious that Asterisk needs
>> to have some call quality measurement in order to be compared against
>> the "big boys" of the VoIP world, if only so that an Asterisk admin
>> can point to a graph and say "See? Call quality is great with my
>> free software, and I can identify problem customers almost
>> immediately - how is your million-dollar system doing?" And it's
>> something that would be useful and universally applicable across all
>> channel types that involved VoIP of some type. Any takers? :-)
>
> Perhaps we can get the data in asterisk
>stored up and output int the same format
>as the cisco w/ RTP-RxStat/RTP-TxStat
>
> - Jared
>
>> At 11:46 AM -0400 5/11/04, Jared Mauch wrote:
>> >
>> > Ideally one would log it as well as the endpoint IPs in order
>> >to determine if there is a network problem with one of the peoples
links.
>> >
>> > I have a lot of users behind various NAT devices on
>> >dsl/cable and want to use this to pinpoint the source of their
>> >problems.
>> >
>> > - Jared
>> >
>> >On Tue, May 11, 2004 at 09:35:23AM -0600, brian k. west wrote:
>> >> Now if you can make this a config option per peer and copy it into
the
>> >> cdr->userfield.
>> >>
>> >> bkw
>> >>
>> >> ----- Original Message -----
>> >> From: "Jared Mauch" <jared at puck.nether.net>
>> >> To: <asterisk-dev at lists.digium.com>
>> >> Cc: "Jared Mauch" <jared at puck.nether.net>
>> >> Sent: Tuesday, May 11, 2004 8:02 AM
>> >> Subject: Re: [Asterisk-Dev] cisco 7940/7960 call_stats logging
>> >>
>> >>
>> >> > I've hacked together this which does
>> >> > the job..
>> >> >
>> > > >
>> >[patch snipped[
>> > > >
>> >> >
>> >> > - Jared
> > >> >
>> >> > On Fri, Apr 30, 2004 at 12:23:38AM -0400, Jared Mauch wrote:
>> >> > >
>> >> > > so, in the recent SIP firmware on the Cisco phones,
>> >> > > it sends some data in the BYE message that can be used to
collect
>> >> > > information about the connection.
>> >> > >
>> >> > > I want to collect and parse this data to help show my users
>> >> > > that have bad connections exactly what we see as compared to
>> >> > > a non-problematic connection/ISP.
>> >> > >
>> >> > > Has anyone been looking at this yet?
>> >> > >
>> >> > >
>> >>
> >
>>http://www.cisco.com/en/US/products/sw/voicesw/ps2156/prod_release_not
e09186a00801d1d80.html#80912
>> >> > >
>> >> > > I'm also really interested in the jitter and late/lost pkts
>> >> > > too..
>> >> > >
> > > > > > - jared
--__--__--
Message: 7
From: "James Gardiner" <asterisk at crafted.com.au>
To: <asterisk-dev at lists.digium.com>
Date: Wed, 12 May 2004 16:05:54 +1000
Subject: [Asterisk-Dev] Where to get 48 volt Power Supplies for Cisco IP
Phones
Reply-To: asterisk-dev at lists.digium.com
Hi,
I picked up some Cisco IP phones 7940, however, was foolish to not catch
the
fact that they do not come with power supplies.. Cisco power supplies
for
them are $150 (Can you believe it..) or more from a retailer I know. I
found one place that sold compatible ones for $15 aus but with a 8 week
turn
around..
Can anyone point me in the direction where I can do some Mail Order of
48volt power supplies (240 AC in Australia)
Thanks,
James Gardiner
--__--__--
Message: 8
Date: Wed, 12 May 2004 02:14:16 -0500
From: Josh Roberson <twisted at indigent-networks.com>
To: asterisk-dev at lists.digium.com
Subject: Re: [Asterisk-Dev] Where to get 48 volt Power Supplies for
Cisco
IP Phones
Reply-To: asterisk-dev at lists.digium.com
James,
I've had pretty good luck finding them on ebay for around 30 bucks or
so. Might give that a shot.
Josh
James Gardiner wrote:
>Hi,
>I picked up some Cisco IP phones 7940, however, was foolish to not
catch the
>fact that they do not come with power supplies.. Cisco power supplies
for
>them are $150 (Can you believe it..) or more from a retailer I know.
I
>found one place that sold compatible ones for $15 aus but with a 8 week
turn
>around..
>
>Can anyone point me in the direction where I can do some Mail Order of
>48volt power supplies (240 AC in Australia)
>
>Thanks,
>James Gardiner
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at 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 mailing list
Asterisk-Dev at lists.digium.com
http://lists.digium.com/mailman/listinfo/asterisk-dev
End of Asterisk-Dev Digest
More information about the asterisk-dev
mailing list