Case-1: Analog Phone-1 call to IP-Phone1. Call received by VG, since both the phone and VG are capable to handle G.711, call should be successful.Call should also be if initiated by IP-Phone-1.
Case-2: Analog Phone-2 call to IP-Phone-3. Call received by VG, call should be successful if a Trancoder is provided, since IP Phone-3 is using a G.729. Call should also be successful if initiated by IP-Phone-3.
Case-3: Call initiated by IP-Phone-1 to Analog-Phone-1, IP-Phone-3 must be included in conversation so conference is initiated from IP-Phone-1 to include IP-Phone-2. Conference Bridge is required to successfully include IP-Phone-2.
Case-4: Analog Phone-2 call to IP-Phone-3. Call received by VG, call should be successful if a Trancoder is provided. At the same time, if IP-Phone-1 and 3 to be included in the conversation, a Conference Bridge is also required. This should hold true if call was initiated by IP-Phone-3.
Case-5: Analog Phone-2 call to IP-Phone-3. Since codec are different, Transcoder is required to successfully complete the call. Now IP-Phone-3 put Analog-Phone-2 ON-HOLD. To provide these supplementary services a Hardware based MTP is required to compensate the codec mis-match.
Case-6: IP-Phone-2 calls IP-Phone-3. The call is successful if Transcoder is provide. Now IP-Phone-2 need to transfer this call to IP-Phone-1. Hardware based MTP is required to complete the call transfer. When the transfer is successful, Transcoding resource should be alllocated to complete the call setup between IP-Phone-3 and IP-Phone-1.
I don't see an actual question anywhere in your posting so I'll just address them in turn.
A transcoding resource is not required here as the gateway should support G.729 natively if everything is properly configured. The DSP has to convert the audio from TDM or analog depending on your PSTN circuit to IP packets. If UCM just specifies the codec that it should use on the IP side.
Ok although you appear to have accidentially reference IP Phone 3 in this scenario. I'm going to presume you meant to say this was a G.711-only conference. You can use a hardware or software conferencing resource for this.
A transcoding resource is not required for the initial part of this call. When the call is turned into a conference, you will need a hardware conference bridge. IOS hardware conference bridges will support G.729 and G.711 users simultaniously. You would need a transcoding resource if you have a software conference bridge.
An MTP is not required here. The codec will be renegotiated to provide G.711-based audio from the UCM MoH server to the voice gateway. When the call is taken off hold, the codec will be reneogitated back to G.729 for IP Phone 3.
A transcoder is not likely required here. It is likely that both phones support G.729 and UCM will instruct IP Phone 1 to use that for the call. When the transfer completes to IP Phone 1, the codec will be renegotiated to G.711
Codec specifications within the region configuration of UCM only specify the maximum bandwidth, not the codec itself. UCM will use any commonly supported codec between two end points up to the bandwidth of the codec you specified. This has been so confusing that Cisco reworded the fields on the region page starting in 8.0(1).
Each call leg negotiates its own codec selection. Whenever you transfer, hold, etc UCM performs an independant determination of what codec to use.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.