[cisco-voip] Intercluster trunks and H323 outbound faststart

Blenkarn, Gary Gary.Blenkarn at fmglobal.com
Sun Sep 20 05:27:34 EDT 2009


Hi Wes

Thank you for the information.  Ok it looks like the MTP has to be in the MRGL of the trunk at each end.  If I put it here it stops the clipping.  if it is only at the remote site device it makes no difference.  Though with the MTP and faststart in place I have introduced a new problem!

I am using g729 as the outbound codec for the faststart on both clusters.  All calls work very well apart from when they hit their unity express VM box.  Strangely a call from the European Cluster to the Asia cluster works and drops into the CUE VM nicely invoking the MTP and then doing the transcoding on the Asia side remote voice gateway.  Though a call the opposite way from Asia to Europe gets a fast busy when it tries to goto Voice mail.

I have performed various debugs on the gateway, please see attached.  Traffic is getting to the gateway but the debug does not contain much to aid as to why.  I have tried other debugs but not been able to find any useful information.  What other useful traces can I run?

I have spent the weekend going through all configs on gateways and on both Clusters and all is the same.   The only difference is that Europe is on version CCM 6.1.2 and Asia on 6.1.4.

Regards

Gary

From: Wes Sisk [mailto:wsisk at cisco.com]
Sent: 16 September 2009 15:35
To: Blenkarn, Gary
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Intercluster trunks and H323 outbound faststart

Gary,

Yes. need hardware mtp in the MRGL.  I do not recall offhand if it needs to be in the ICT MRGL or in the device's MRGL.  My first guess would be the device's MRGL.  A quick test will verify.

For your MTP's remember that round trip to them can add additional delay in signaling.  Just something to keep in mind when planning the design and considering impacts.

The only downside to bundling outbound messages is potential additional delay.  ccm.exe must hold up SCCP messages in order to bundle them into a single outbound message.  Holding the messages will introduce slight delay.  the goal is to have the hold be less time than the latency cased by TCP RTT.


Have you reviewed CM traces or packet captures for a specific instance of delay to confirm the specific problem?  Just to make sure we're chasing the correct problem.

/wes

On Wednesday, September 16, 2009 10:23:01 AM, Blenkarn, Gary <Gary.Blenkarn at fmglobal.com><mailto:Gary.Blenkarn at fmglobal.com> wrote:

Hi Wes

Thank you very much for your reply.  Answers to your questions:


Clipping - losing the first 2 seconds from the receiver like their hello.

2 Clusters are 200ms apart.

LBR rate codec G729 is used across trunk.

Therefore I am assuming that I need to do a hardware MTP on the gateways that my CCM's cluster is at and add it the MRGL that is on the trunks each side.  A question from your article, are there any negatives in using the 'Bundle Outbound Messages Timer' parameter?

Regards

Gary

From: Wes Sisk [mailto:wsisk at cisco.com]
Sent: 16 September 2009 14:35
To: Blenkarn, Gary
Cc: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Intercluster trunks and H323 outbound faststart

Let's take a step back for clarification please.
can you elaborate on what you mean by 'clipping'?
how far apart are your 2 clusters in terms of msec round trip time?
also, do you use low bit rate (LBR) codecs (729, iLBC) over the intercluster trunks?

CM's software MTP does not support LBR codecs only G.711.  If you are attempting to invoke an MTP and there is no capabilities match CM will default to connecting the call anyway but disabling supplementary services. This could also lead to additional delay.

In general inbound faststart will not help without the remote peer supporting outbound faststart.  If you noted any difference with only inbound fast start enabled it is either a fluke or there is something else going on in the network that needs clarification.  The only item I can think of that would trigger this is some type of SBC or CUBE anchoring calls between 2 clusters.  Do you have any such device between the clusters?

with 150msec RTT to remote sites you may want to review this previous conversation on cisco-voip:
http://www.gossamer-threads.com/lists/cisco/voip/114051


/Wes


On Wednesday, September 16, 2009 3:07:45 AM, Blenkarn, Gary <Gary.Blenkarn at fmglobal.com><mailto:Gary.Blenkarn at fmglobal.com> wrote:


Hi

We have 2 CCM 6.1 clusters.  They are connected via a non gatekeeper controlled trunk.  In terms of latency some of the phones are one way 150ms.  We have been getting instances of voice clipping.  Therefore as the SRND states we have implemented Fast start.  Inbound fast start is configured both ends and makes a small difference.  Though outbound Fast start makes the voice clipping worse?  The outbound fast start requires the use of an MTP.  It is currently using the software MTP of the Call Managers in each cluster.

Can anybody provide any information how best practice wise outbound fast start should be setup please?  Should we be using a hardware MTP for instance on each Cluster?

Thank you

Gary Blenkarn
Senior Data Networking Analyst


________________________________
Registered No. 755780 England
Registered Office: FM Insurance Company Limited
1 Windsor Dials, Windsor,
Berkshire, UK, SL4 1RS
Regulated by the Financial Services Authority.
VAT No. G.B.: 792 4276 02










________________________________












_______________________________________________

cisco-voip mailing list

cisco-voip at puck.nether.net<mailto: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/20090920/450b7bba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: troubleshooting.rtf
Type: application/rtf
Size: 36933 bytes
Desc: troubleshooting.rtf
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20090920/450b7bba/attachment.rtf>


More information about the cisco-voip mailing list