Transcoders, Regions, and MTP

[calmichael]

I am trying to digest some information presented in

"Troubleshooting IP Telephony" (Hallmark/Smith) with

regard to Codec Selection and Transcoder Resources

(pg.569-571).

It seems that the text (and the supporting graphic)

is implying that Transcoders should be configured

into their own CCM Regions; which is especially

important for centralized multisite style installations.

I have seen many centralized multisite style

installations where XCODE resources are "lumped"

into the CCM Region for a particular site. These

type of installations normally seem to use Device

Pools which have a provisioned MRGL which used

XCODE resources local to that site; etc, etc.

These installations seem to work just fine. . .

Is seperating Transcoder resources into their own

Region a new "best practice"? The current SRNDs

don't seem to reflect this, unless I have missed it.

I had a quick discussion with a local Cisco SE and

he seemed to know that if you don't configure a

Transcoder in it's own CCM Region that certain

calling situations fail or do not work as expected;

though he could not recall one of these situations

for illustration.

Lastly, if Hardware Transcoders are present at a site,

should Software Based MTP resources be left out, or

"deprioritized" in a MRGL as a Transcoder provides

the capabilities of an MTP; as Software MTP is supposed

to be pretty CPU intensive?

--- Thanks ---

[thomas.chen]

You can also use MRGs and MRGLs to separate resources based on geographical location, thereby conserving WAN bandwidth whenever possible.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_implementation_design_guide_chapter09186a00802c37fa.html

[calmichael]

Thomas,

Can you help me understand how the use of MRG/MRGLs

(or with the lack of definitions, the default MRGL)

provides guidance on if Transcoder (XCODE) recources

should be part of the primary Region for a site

versus being defined an independant Region? Or are

you suggesting that Region settings are irrelevant

with the use of MRG/MRGLs in this situation?

[calmichael]

Expanding on the original question:

A follow-up conversation with the SE of the example

that causes was:

"Calls initiated from remote "Region 2" to the

central location "Region 1" where IPCC (configured

as G.711) was located. Calls would immediately drop

when IPCC accepted the contact and played a message

file as the Region-to-Region required a G.729 (or

lower) codec. Debugs showed ‘media mismatch’ and

failure to invoke an available transcoder which was

part of an MRG/MRGL and Region 1 associated with the

central location.

Region 1 - Region 1 (G711) Region 1 to Region 2 (G729)

Region 2 - Region 2 (G711) Region 2 to Region 1 (G729)

By creating a Region 3 and placing only the XCODE

resource for the central location into it, the

call from Region 2 to Region 1 based IPCC was

successful.

Region 1 - Region 1 (G711) Region 1 to Region 2 (G729) Region 1 - Region 3 (G711)

Region 2 - Region 2 (G711) Region 2 to Region 1 (G729) Region 2 - Region 3 (G729)"

When I first heard this, I though that this may have

been a successful workaround for a bug, er, feature

for that CCM release. But then when this concept

appeared in the Cisco Press book (Troubleshooting

Cisco IP Telephony) recently, I though that having

XCODE resources in a separate Region might be a

new best practice; thus the original question.

[palves]

I had a similar issue.

I had a remote site that was trying to communicate with the central site which had IPCC Express there (more specifically a call centre-ICD).

IPCC Express was installed with G.711 and the remote sites were configured with G.729 (for inter-office calls).

The main site's device pool\MRGL\MRG required a transcoder to work. This transcoder needed to be bound to the MRG\MRGL\DEVICEPOOL\REGION for the CTI ports that IPCC Express used.

Calls would NOT work if I placed a transcoder in the DEVICEPOOL\MRGL\MRG\REGION of the REMOTE SITE even though calls were initiated from the remote site.

Paul