[cisco-voip] H.323 MTP Usage

[Peter Slow]

If you're going to do this you miht as well use RSVP for your CAC, and
get some sort of operational improvement out of the added complexity.

-Peter

On Thu, Apr 29, 2010 at 11:08 AM, Nick Matthews <matthnick at gmail.com> wrote:
> For what it's worth - you can use CPU cycles on your router instead of
> PVDM hardware for MTPs.  This works great when you have a few one-off
> cases you need some MTPs for and say a 3845 that's not using all of
> it's CPU.  It will do both G729 and G711 in software on the router.
>
> -nick
>
> On Tue, Apr 27, 2010 at 8:50 PM, Tom Mc <tomdmc at gmail.com> wrote:
>> Thanks Jason,
>>
>> The purpose of the MTP is purely from a perspective of controlling the
>> path that the rtp stream takes through the network.
>> I'm getting push backs from the guys managing the core routing, but
>> I'm managed to convince them to import the /32 h323 source loopback
>> addresses for the international gateways into the domestic vrf which
>> is the best solution.
>> I'm now waiting to find out if they are in a contiguous block
>> (something that I'm hoping is the case)
>>
>> Cheers,
>> Tom
>>
>> On Wed, Apr 28, 2010 at 6:42 AM, Jason Aarons (US)
>> <jason.aarons at us.didata.com> wrote:
>>> 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.
>>>
>>
>> _______________________________________________
>> 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
>