Thanks for reply, Mao. disabling battery reversal doesn't resolve it. Do I have to add a H.323 gateway on CallManager to make this work? I haven't done that yet.

Thanks,

Jon

Hi Jon,

Yes, the H.323 gateway needs to be added in CCM.

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080094636.shtml

Once added, test once again and let us know what happens.

Regards,

Michael.

Hi, Michael,

The h323 gw was added with default configurations in ccm now. the router's config is like this:

voice-port 0/0/0

no battery-reversal

cptone CA

timeouts call-disconnect 5

timeouts wait-release 5

connection plar 41851

station-id name Intercom4

caller-id enable

dial-peer voice 41851 voip

destination-pattern 41851

session target ipv4:172.26.240.10

dtmf-relay h245-alphanumeric

codec g711ulaw

Good news is the phone 41851 now rings, however, I hear busy tone once the call is answered.

Thanks,

Jon

I haven't configured the route pattern using the h323 gw in ccm. 'Cause this is gonna be one-way calling, from an intercom device to IP Phone. Do I need to configure it?

Thanks

If it is only one-way calling to the IP phone, then the route pattern is not required in the CallManager.

Could you please attach the output of these debugs while testing?

- debug cch323 h225

- debug cch323 h245

- debug voip ccapi inout

Thanks,

Michael.

Michael, please refer to the attached file for the debug output.

Currently I use an fxs port of vg224 plus phone 41896 to simulate the Intercom. phone 41896 dials fxs 41740, call goes to gw 2821, then to phone 41851.

It seems CCM is disconnecting the call, I think after waiting in vain for the gwy to begin H.245 negotiation.

*Feb 26 18:45:06.471: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type RELEASEIND_CHOSEN

*Feb 26 18:45:06.471: //46/C5B3BAA78044/H323/release_ind: Disconnect cause 47 location code 0

One more request Jon. There is a checkbox on the gateway configuration page in CCM called 'Wait for Far End H.245 Terminal Capability Set'. If this is checked, could you please uncheck it, then reset the gateway within CCM.

After making that change and before testing again, please add the following debugs on the gateway:

debug h225 asn1

debug h245 asn1

Also if you could include the detailed CCM traces from the CCM side to your attachment that would be great!

Regards,

Michael.

here you are, Michael.

Jon,

We are getting closer, so bear with me a little. Here's the analysis of the last debugs from the gateways perspective.

When an H.323 call is being established, the H.245 negotiation allows the endpoints to agree on the properties of the call being established. One of the properties that must be agreed upon is the codec that will be used for the duration of the call. In this negotiation, each party specifies which codec it can support, and as long as they have at least one codec in common, then the call may proceed.

In this particular case, here is what the gateway sends to CCM as it advertises its capabilities.

*Feb 26 19:51:17.235: H245 MSC OUTGOING PDU ::=

value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :

capability receiveAudioCapability : g711Ulaw64k : 20

Notice that the gateway indicates that it only supports G.711, which is the codec you have configured on the outbound voip dial-peer that is used to send the call to CCM.

And below is what the CCM advertises as the codecs that it phone in question is allowed to use.

*Feb 26 19:51:17.247: H245 MSC INCOMING PDU ::=

value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :

capabilityTableEntryNumber 1

capability receiveAudioCapability : g729wAnnexB : 6

},

{

capabilityTableEntryNumber 2

capability receiveAudioCapability : g729AnnexAwAnnexB : 6

},

{

capabilityTableEntryNumber 3

capability receiveAudioCapability : g729 : 6

},

{

capabilityTableEntryNumber 4

capability receiveAudioCapability : g729AnnexA : 6

},

{

capabilityTableEntryNumber 5

capability receiveAudioCapability : g729AnnexA : 6

},

Notice also that phone is only allowed to use variants of G.729 codec.

So essentially the issue is one of a codec mismatch between the gateway and the called phone.

Shortly after the exchange above, the gateway released the call because none of the capabilities that were exchanged matched and no transcoder resource was available.

*Feb 26 19:51:17.255: H245 MSC OUTGOING PDU ::=

value MultimediaSystemControlMessage ::= response : terminalCapabilitySetReject :

One option that may resolve the issue to so configure the gateway to support G.729 as well. You could do this by modifying the configuration so that it looks like this:

!

voice class codec 1

codec preference 1 g729br8

codec preference 2 g729r8

codec preference 3 g711ulaw

!

dial-peer voice 41851 voip

destination-pattern 41851

session target ipv4:172.26.240.10

dtmf-relay h245-signal

voice-class codec 1

!

Other alternative options to fix the issue include configuring the Regions within CCM so that the codec used between the Region that the gateway is in and the one that the phone is in is G.711. Alternatively, providing access to a transcoder resource would allow the two endpoints to speak their different languages while the transcoder would act as a translator.

Lets try the modification to the gateway as above and lets see if that makes a difference.

Regards,

Michael.

Hi, Michael, we're getting closer now. I applied the voice class codec you posted. now call is established. however, only one way audio exists, which is from dialer to receiver 41851.

Thanks,

Jon

Thanks for the update, Jon. A couple of questions for you:

1. When the H.323 gateway was added in CCM, what is the IP address that was used for this?

2. Would you please depict the topology here once again? You mentioned previously that there was a VG2xx device involved as well, so I'd like to make sure we understand the full topology.

3. For clarification of the current issue, the IP phone user hears the calling party but that calling party does not hear the IP phone user - Is this correct?

4. Please recreate the current issue, and collect CCM traces once again from the CCM. In order to make sure we have the correct set of CCM traces, if you can, please set the trace level to detail, stop logging, delete existing trace log files, then start logging again before doing the test.

5. While the call is up, execute the following command on the gateway twice. Wait about 15 seconds before executing it the second time.

Thanks,

Michael.

Thanks a lot for diving into this, Michael.

1. When the H.323 gateway was added in CCM, IP address that was used is 172.26.240.243(this change since this test)

2. The final topology will be like this:

[Intercom] -> [fxo 0/1/0 on gw 2821(172.26.240.243)] -> [cucm5(172.26.240.10)] -- [phone 41851]

For the purpose of proving the configurations, I use this topology now:

[phone 41896] -> [ext 41740 of vg224] -> [fxo 0/1/0 on gw 2821(172.26.240.243)] -> [cucm5(172.26.240.10)] -- [phone 41851]

3. The receiver hears the calling party but that calling party does not hear the receiver - This is correct

4. Please see the newest trace and gw debug output from attachment.

Jon,

Do you have both 172.26.240.244 and 172.26.240.243 on the H.323 gateway?

* In previous traces, the H.323 gateway specified .244 as its address in the H.225 setup, but in the latest one, while performing capabilities exchange, it used .243. Was this as a result of a recent change?

* To remove any ambiguity, on the interface that has the .243, add the command h323-voip gateway bind' command so that all h.323 communication may use that address.

* From the traces:

- CCM tells the VG224 phone to startMediaTransmission with VG224 gateway while specifying the address to use for the VG224 gateway as 172.26.240.245

- CCM tells Destination IP phone (172.26.241.197) to startMediaTransmission with H.323 gateway while specifying the address to use for the gateway as 172.26.240.243

Can we verify that the subnet masks and default gateways of these devices are all correct, and also perform ping or other tests to confirm reachability between the 240 and 241 subnets?

Regards,

Michael.