From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Fri Aug 13 2004 - 12:04:59 GMT-3
Call Manager Express.
A Cisco Call Manager (CCM) like call control system that is a feature
for some routers and some IOSs. I.e. an all in one solution for your
branch if you also go with UnityExpress (also a Unity inside a NM, i.e.
Network Module).
Joseph D. Phillips wrote:
> What's "CME"?
>
> ----- Original Message -----
> From: "Carlos G Mendioroz" <tron@huapi.ba.ar>
> To: <swm@emanon.com>
> Cc: "'Richard Dumoulin'" <richard.dumoulin@vanco.es>; "'lab'"
> <ccielab@groupstudy.com>
> Sent: Friday, August 13, 2004 06:53
> Subject: Re: qos for voice
>
>
>
>>If that's the case, CME's implementation of RTP is non conformant...
>>
>>Scott Morris wrote:
>>
>>>Very true. But again, the RFC for RTP operations specifies that RTCP
>>
> must
>
>>>also be used. So regardless of the initiating protocol (although I
>>
> believe
>
>>>we started talking H.323, hence the reference), the end result for what
>>>appears SHOULD be the same...
>>>
>>>Scott
>>>
>>>-----Original Message-----
>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>>>Carlos G Mendioroz
>>>Sent: Friday, August 13, 2004 9:29 AM
>>>To: swm@emanon.com
>>>Cc: 'Richard Dumoulin'; 'lab'
>>>Subject: Re: qos for voice
>>>
>>>Scott,
>>>the part of your "insanity" comes from associating Voip to H323 :-) Voip
>>
> can
>
>>>also use SIP, MGCP, SCCP, etc as call control.
>>>All of them use RTP for voice transport.
>>>CCM and CME both use SCCP (aka skinny) to do call control to Voip
>>
> phones...
>
>>>Scott Morris wrote:
>>>
>>>
>>>>According to RFC 3550, all participants in an H.323 conversation
>>>>(which is your two endpoints, being IP phones or routers with FXS
>>>>ports) MUST send RTCP. Therefore, H.323 voice ALWAYS works in pairs
>>>>of ports (which is good to know that I am not going insane, at least
>>>>not for this part!)
>>>>
>>>>:)
>>>>
>>>>HTH,
>>>>
>>>>
>>>>Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
>>>>CISSP, JNCIP, et al.
>>>>IPExpert CCIE Program Manager
>>>>IPExpert Sr. Technical Instructor
>>>>swm@emanon.com/smorris@ipexpert.net
>>>>http://www.ipexpert.net <http://www.ipexpert.net/>
>>>>
>>>>
>>>>----------------------------------------------------------------------
>>>>--
>>>>From: Richard Dumoulin [mailto:richard.dumoulin@vanco.es]
>>>>Sent: Friday, August 13, 2004 6:06 AM
>>>>To: Carlos G Mendioroz; Scott Morris
>>>>Cc: 'lab'
>>>>Subject: RE: qos for voice
>>>>
>>>>There's no RTCP between the ephones and CME but there is between the
>>>>Voice gateways I think, no ?
>>>>
>>>>--Richard
>>>>
>>>>-----Original Message-----
>>>>From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
>>>>Sent: viernes, 13 de agosto de 2004 11:35
>>>>To: Scott Morris
>>>>Cc: 'Steven A Ridder'; 'John Matus'; 'lab'
>>>>Subject: Re: qos for voice
>>>>
>>>>
>>>>Scott Morris wrote:
>>>>
>>>>
>>>>>Actually, voice streams use a pair of ports (even and odd) for RTP
>>>>
>>>>and > RTCP stuff (voice data and control).
>>>>
>>>>This depends on what the endpoints are.
>>>>Although true for CCM, this does not hold, e.g., for CME to Voip phone
>>>>AFAIK. No RTCP there.
>>>>
>>>>
>>>>>The rtp priority command with "16384 16383" numbers isn't a range.
>>>>
>>>>In > that command, it's the starting port and number of ports >
>>>>(16384+16383=32767) whereas the other command actually is a range with
>>>>
>>>>
>>>>>start and stop information.
>>>>
>>>>>HTH,
>>>>>
>>>>>Scott
>>>>>
>>>>>-----Original Message-----
>>>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
>>>>
>>>>Behalf > Of Steven A Ridder > Sent: Thursday, August 12, 2004 8:57
>>>>PM > To: 'John Matus'; swm@emanon.com; 'lab'
>>>>
>>>>>Subject: RE: qos for voice
>>>>>
>>>>>The difference between the 1st and 2nd statement is as follows:
>>>>>
>>>>>The first statement (the udp 16384...) matched the payload and >
>>>>
>>>>signal/control traffic where the "IP RTP" statement captures the data
>>>>
>>>>
>>>>>packets only. The first statement ensures that ALL RTP traffic >
>>>>
>>>>(payload and > signal) packets get matched. If I remember correctly,
>>>>each RTP stream uses > 4 consecutive ports, starting with the first
>>>>even port above 16384, so the > first stream uses 16384-16387. It's
>>>>been a while, but I think that's > correct.
>>>>
>>>>>Steve Ridder
>>>>>
>>>>>
>>>>>-- RFC 1049 Compliant
>>>>>
>>>>>-----Original Message-----
>>>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
>>>>
>>>>Behalf > Of John Matus > Sent: Thursday, August 12, 2004 8:08 PM >
>>>>To: swm@emanon.com; 'lab'
>>>>
>>>>>Subject: Re: qos for voice
>>>>>
>>>>>i have no idea if it is working........it's a lab scenario >
>>>>>i wasn't sure if the 'match rtp' somehow included the tcp 1720. i
>>>>
>>>>really
>>>>
>>>>>don't understand the difference between the two statements or why
>>>>
>>>>or > why not they would be used. any insite you could give would be
>>>>most > helpful!
>>>>
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Scott Morris" <swm@emanon.com> > To: "'John Matus'"
>>>>
>>>><jmatus@pacbell.net>; "'lab'"
>>>>
>>>>><ccielab@groupstudy.com>
>>>>>Sent: Thursday, August 12, 2004 4:36 PM > Subject: RE: qos for
>>>>
>>>>voice > > > >>Well, off the cuff, it would appear that you aren't
>>>>matching the H225 >>call setup (tcp/1720) in your second class.
>>>>Otherwise, you are either >>matching on the RTP header or the UDP
>>>>header information.
>>>>
>>>>>>Do they both work for you? ;)
>>>>>>
>>>>>>
>>>>>>Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713,
>>>>>
>>>>>>CISSP, JNCIP, et al. IPExpert CCIE Program Manager >>IPExpert Sr.
>>>>>
>>>>Technical Instructor >>swm@emanon.com/smorris@ipexpert.net
>>>>
>>>>>>http://www.ipexpert.net
>>>>>>
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
>>>>>
>>>>Behalf >>Of > > John > >>Matus
>>>>
>>>>>>Sent: Thursday, August 12, 2004 6:29 PM
>>>>>>To: lab
>>>>>>Subject: qos for voice
>>>>>>
>>>>>>is there a difference between the following??
>>>>>>
>>>>>>class-map match-all voip
>>>>>>match access-group 101
>>>>>>
>>>>>>access-list 101 permit tcp any any 1720 >>access-list 101 permit
>>>>>
>>>>udp any any range 16384 32787 >> >>AND >> >>class-map match-all
>>>>voip >>match ip rtp 16384 16383 >> >> >>do they perform the same
>>>>function or are they completely different.
>>>>
>>>>>>i'm confused :)
>>>>>>
>>>>>>
>>>>>>
>>>>>>John D. Matus
>>>>>>MCSE, CCNP
>>>>>>Office: 818-782-2061
>>>>>>Cell: 818-430-8372
>>>>>>jmatus@pacbell.net
>>>>>>
>>>>>
>>>>
>>>>>>____________________________________________________________________
>>>>>
>>>>__
>>>>
>>>>>>_
>>>>>>Please help support GroupStudy by purchasing your study materials
>>>>>
> from:
>
>>>>>>http://shop.groupstudy.com
>>>>>>
>>>>>>Subscription information may be found at:
>>>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>>
>>>>>
>>>>______________________________________________________________________
>>>>
>>>>>_
>>>>>Please help support GroupStudy by purchasing your study materials
>>>>
> from:
>
>>>>>http://shop.groupstudy.com
>>>>>
>>>>>Subscription information may be found at:
>>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>>
>>>>
>>>>______________________________________________________________________
>>>>
>>>>>_
>>>>>Please help support GroupStudy by purchasing your study materials
>>>>
> from:
>
>>>>>http://shop.groupstudy.com
>>>>>
>>>>>Subscription information may be found at:
>>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>>
>>>>
>>>>______________________________________________________________________
>>>>
>>>>>_
>>>>>Please help support GroupStudy by purchasing your study materials
>>>>
> from:
>
>>>>>http://shop.groupstudy.com
>>>>>
>>>>>Subscription information may be found at:
>>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>>
>>>>
>>>>--
>>>>Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>>>>
>>>>______________________________________________________________________
>>>>_ Please help support GroupStudy by purchasing your study materials
>>>>from:
>>>>http://shop.groupstudy.com
>>>>
>>>>Subscription information may be found at:
>>>>http://www.groupstudy.com/list/CCIELab.html
>>>>
>>>>
>>>>
>>>>**********************************************************************
>>>>Any opinions expressed in the email are those of the individual and
>>>>not necessarily the company. This email and any files transmitted with
>>>>it are confidential and solely for the use of the intended recipient.
>>>>If you are not the intended recipient or the person responsible for
>>>>delivering it to the intended recipient, be advised that you have
>>>>received this email in error and that any dissemination, distribution,
>>>>copying or use is strictly prohibited.
>>>>
>>>>If you have received this email in error, or if you are concerned with
>>>>the content of this email please e-mail to:
>>>>e-security.support@vanco.info
>>>>
>>>>The contents of an attachment to this e-mail may contain software
>>>>viruses which could damage your own computer system. While the sender
>>>>has taken every reasonable precaution to minimise this risk, we cannot
>>>>accept liability for any damage which you sustain as a result of
>>>>software viruses. You should carry out your own virus checks before
>>>>opening any attachments to this e-mail.
>>>>**********************************************************************
>>>
>>>
>>>
>>>--
>>>Carlos G Mendioroz <tron@huapi.ba.ar>
>>>
>>>_______________________________________________________________________
>>>Please help support GroupStudy by purchasing your study materials from:
>>>http://shop.groupstudy.com
>>>
>>>Subscription information may be found at:
>>>http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>
>>
>>--
>>Carlos G Mendioroz <tron@huapi.ba.ar>
>>
>>_______________________________________________________________________
>>Please help support GroupStudy by purchasing your study materials from:
>>http://shop.groupstudy.com
>>
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>>
>
>
>
-- Carlos G Mendioroz <tron@huapi.ba.ar>
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:43 GMT-3