[cisco-voip] H.323 MTP Usage

[Jason Aarons (US)]

>From a design standpoint it's always best to avoid using MTPs.  Is the reason you need a MTP because the PBX doesn't support H.323v2 and Empty Capabilities Set?  

My past experience is that MTPs are undesireable due to scalability (unless you got money to burn on PVDMs), and that checking MTP is usually a workaround for a bug, etc.

________________________________________
From: cisco-voip-bounces at puck.nether.net [cisco-voip-bounces at puck.nether.net] On Behalf Of Tom Mc [tomdmc at gmail.com]
Sent: Tuesday, April 27, 2010 4:19 PM
To: Ryan Ratliff
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] H.323 MTP Usage

Thanks guys,

I'm using g.729. 'Software MTP only supports g.711', that would
explain it. I'm using dynamips in my test lab so I cannot test with a
xcode resource but it might be a possible solution.
The other option being using an IP-to-IP GW to terminate the call at
the cluster site, I was leaning this way myself but I adds a layer of
complexity that I may not get though by the weekend (wheels turn
slowly in this project).

Cheers,
Tom



On Tue, Apr 27, 2010 at 11:42 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
> What codec is getting used for the calls through the MTP?  The software MTP only supports g.711 and if you are using any other codec CUCM will try to allocate a transcoder and this part sounds like it is failing based on your description.
>
> -Ryan
>
> On Apr 27, 2010, at 7:58 AM, Tom Mc wrote:
>
>> Hi guys,
>>
>> I have a query about how mtp can be implemented with h.323 gateways.
>>
>> We are going through a migration for a customer replacing a LCR solution.
>> Topology looks something like this:
>> PBX --> QSig --> 3845 --> H.323 --> CUCM 7.1 --> H.323 --> 3845 --> QSig --> PBX
>> CUCM has been configured for call routing using route patterns with
>> h.323 gateway destinations
>>
>> This solution has been implemented internationally for about 40 sites
>> all with 'any to any' connectivity which has not been a problem.
>> We now need to cutover Australia, and I have just been told that
>> routing to the other 40 sites at this point in time is not possible
>> and that media traffic will need to be routed via the CUCM cluster.
>>
>> I've tried to lab up this solution (replacing the pbx with ip phones)
>> trying to get the gateways to use an MTP (which is registered) and
>> thus forcing the media stream out to the internationally hosted CUCM
>> cluster.
>>
>> Ticking the box "Media Termination Point Required" in the gateway
>> config and assigning a MRGL with the CUCM software MTP's does not seem
>> to work.
>> Wireshark shows the media stream from GW to GW not GW to CUCM to GW as expected.
>> Setting the service parameter  "Fail Call If MTP Allocation Fails" to
>> true, predictably ends the call on answer attempt.
>>
>> Is what I am attempting to do possible with the CUCM software MTP's?
>> Do I need hardware resources to do this?
>>
>> The "Help, this page" on the gateway config page tells me the
>> following (which sort of tells me that this is not the purpose of the
>> MTP):
>>
>> "If you want a Media Termination Point to implement features that
>> H.323 does not support (such as hold and transfer), check the check
>> box.
>>
>> Use this check box only for H.323 clients and H.323 devices that do
>> not support the H.245 Empty Capabilities Set message.
>>
>> If you check this check box to require an MTP and this device becomes
>> the endpoint of a video call, the call will be audio only."
>>
>>
>> Cheers,
>> Tom
>> _______________________________________________
>> 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

-----------------------------------------
Disclaimer:

This e-mail communication and any attachments may contain
confidential and privileged information and is for use by the
designated addressee(s) named above only.  If you are not the
intended addressee, you are hereby notified that you have received
this communication in error and that any use or reproduction of
this email or its contents is strictly prohibited and may be
unlawful.  If you have received this communication in error, please
notify us immediately by replying to this message and deleting it
from your computer. Thank you.