[cisco-voip] H.323 vs MGCP

Fri Aug 22 04:26:45 EDT 2008

This is a fairly well known work around, but the major limitation being it
only supports 5 circuits or gateways...
So it's ok for small installs.

I'd still prefer H323 for partials

I wonder if they are finally supporting this properly with MGCP in CUCM 7?

Cheers,

Tim

On 8/22/08, Darren <darren at dnsl.com> wrote:
>
> Hi, I recently got the TAC to confirm this, and after some back and forth
> the TAC DO support fraction E1's using MGCP, as long as you do below, I got
> confirmation in an email so I'm all good there.  Also of interest I'm not
> 100% sure you have do below, I had an 10channel E1 configured and used
> asscending and descending and I couldn't get it to fail, so I suspect its
> not an issue anymore, also I had the call manager config enabled and it
> never broke during testing, however TAC guy told me to do the following:
>
> Darren
>
> ****************************
> 1.
>
> From CCMAdmin pages go to System > Service Parameters > Service Parameter
> Configuration > Clusterwide Parameters (Device - PRI and MGCP Gateway) ->
> Change B-Channel Maintenance Status 1
>
> B-Channel maintenance status for PRI and CAS interfaces in real time for
> troubleshooting.
> Input Format:
> Device Name = B-channel Maintenance Status
> Example:
> S0/DS1-0 at SDA123456789ABC = 0000 1111 0000 0000 0000 0001 (24 bits for T1.
> Channel number begins with 1 to 24 from left to right.* In the case of
> PRI, the last bit specifies the D-Channel*, which does not get affected. *In
> this example, the 5th through 8th B-Channels are out of service.*)
> or,
> S1/DS1-0 at DLS2-CM136-VG200-2.SELSIUSCMLAB.CISCO.COM = 0000 0000 0000 0000
> 0000 0000 1111 1111 (32 bits for E1. B-Channel number begins with 1 to 32
> from left to right. The 16th channel specifies the D-Channel. The last bit
> does not affect any channel. In this example, the 25th through 31st channels
> are marked out of service.)
> Explanation:
> *The Device Name as specified in the Gateway Configuration page in Cisco
> CallManager Administration MUST exactly match the gateway name that this
> field specifies.* To avoid any manual inputting mistake, copy the Device
> Name from Cisco CallManager Administration and paste it into this service
> parameter. "=" is mandatory and unique to distinguish the Device Name and
> B-Channel Maintenance Status fields.
> BCHANNEL MAINTENANCE STATUS = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
> Where x can be:
> *0 -- In service
> 1 -- Graceful out of service (Change channel status until active call ends
> if an active call exists on that channel.)
> 2 -- Forceful out of service (Tear down active call first; then, change
> channel status immediately if an active call exists on that channel.) *
> Because values other than 0,1, or 2 are invalid, the system ignores them.
> Make sure that the total number of 'x' is either 24 for T1 or 32 for E1. Any
> other invalid length or mismatch (for example, 24 for E1) gets treated as
> error, and no action gets taken for that device.
> SPACE: Optional.
> The spaces between device name and "=", between '=' and BCHANNEL
> MAINTENANCE STATUS, and between x and x, are all optional. You cannot use
> any space inside the DEVICE NAME field.
> PRI Specific:
> To use this feature, the Enable status poll check box must be checked on
> the PRI Gateway Configuration window. If it is not, you need to check the
> check box, click Update, and reset the gateway for the service parameter
> change to take effect.
> Maximum length: 255
>
> 2. Make sure you will not use it with the CCM config server option as the
> call manager will reset the B channel service parameter status and
> overwrite
> the configuration on the router, so calls will then be attempted on the
> unconfigured B channels.
>
> For your interest:
> Defect CSCdw78580 describes the issue with fractional PRI and MGCP.
> ************************************
>
>
>
>
>
> On 8/22/08, Kris Seraphine <baryonyx5 at gmail.com> wrote:
>>
>> If you have any analog DID trunks or fractional PRIs you'll want to
>> stay H.323.  Those are not support as MGCP in CM.
>>
>> If you decide to convert, take into consideration your digit discard
>> settings on the route lists.  Likely you are currently passing the
>> prefix digit to the gateway.  If you convert to MGCP you'll want to
>> strip it on the route list.
>>
>> Personally, I prefer H.323 for remote site PSTN trunks when SRST is
>> involved.  It's much less buggy more flexible and easier to
>> troubleshoot.  If you use MGCP you still have to configure H.323 for
>> fallback so you gain very little.
>>
>> On Tue, Aug 19, 2008 at 12:23 PM, Matthew Loraditch
>> <MLoraditch at heliontechnologies.com> wrote:
>> > All,
>> >
>> > In the past I have had MGCP setup for my gateways but recently took over
>> a
>> > system with h.323 for the gateways. The gateways are only connected to
>> and
>> > used by CCM and I like the MGCP abilities to control the various ports
>> > directly in CM. Is there any benefit to keeping them as H.323? If not is
>> it
>> > difficult to convert between one or the other?
>> >
>> > Thanks!
>> >
>> >
>> >
>> >
>> >
>> > Matthew Loraditch
>> > 10944 Beaver Dam Road, Suite A
>> > Hunt Valley, Maryland  21030
>> > support at heliontechnologies.com
>> > (p) (410) 252-8830
>> > (F) (443) 541-1593
>> >
>> > Visit us at www.heliontechnologies.com
>> > Support Issue? Email support at heliontechnologies.com for fast
>> assistance!
>> >
>> >
>> >
>> > _______________________________________________
>> > cisco-voip mailing list
>> > cisco-voip at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >
>> >
>>
>>
>>
>> --
>> kris seraphine
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20080822/13564cc6/attachment-0001.html>