[Asterisk-Dev] Asterisk crashes when receiving malformed RTP packets

Claus Futtrup cf at internetit.dk
Wed May 12 02:03:14 MST 2004


Hi there,

Latest CVX of Asterisk crashes when receiving malformed RTP packets
I've included an ethereal trace of the packets sent in libpcap format.
Please add this to bug tracker

Regards,

Claus


This message is for the designated recipient only and may contain privileged
or confidential information.  If you have received it in error, please
notify the sender immediately and delete the original.  Any other use of the
email by you is prohibited.
----- Original Message ----- 
From: <asterisk-dev-request at lists.digium.com>
To: <asterisk-dev at lists.digium.com>
Sent: Wednesday, May 12, 2004 10:19 AM
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_note091
86a00801d1d80.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_note091
86a00801d1d80.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,RxPackets,Rx
Octets,RxLatePackets,RxLost,RxAverageJitter,RxMaximumJitter,RxStandardDeviat
ionJitter,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","1234567890123456789012345
6789012","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","123456789012345678901234
56789012","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","1234567890123456789012
3456789012","SIP","ALAW",9654,13893011,1,6,6,"UNKNOWN","UNKNOWN",9830,139993
3
>
> 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_note091
86a00801d1d80.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
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.681 / Virus Database: 443 - Release Date: 10-05-2004




More information about the asterisk-dev mailing list