Gateway 2821 fails to forward call to callmanager5

Answered Question
Feb 25th, 2008

Hi,

Topology:

[Intercom] -> fxo--[gw 2821] -> [cucm5] -- [phone 41851]

The configuration:

dial-peer voice 41851 voip

destination-pattern 41851

session target ipv4:172.26.240.10

dtmf-relay h245-signal

codec g711ulaw

voice-port 0/0/0

cptone CA

timeouts call-disconnect 5

timeouts wait-release 5

connection plar 41851

station-id name Intercom4

station-id number 00004

caller-id enable

I suspect that some configurations are missing. please help.

Please refer to the attachment for output of debug vpm signal and deb voice dialpeer.

Thanks,

Jon

Attachment: 
Correct Answer by Michael Owuor about 8 years 12 months ago

Hi Jon,

It may be necessary to shut/no shut the voice port to have the changes take effect.

If not, then it would seem that any caller-id information received from the VG224 phone overrides the station-id configs. Can you configure the VG224 phone to not send any caller-id information.

In the planned topology, the FXO port was connected to the Intercom system. Would the intercom system be sending caller-id information like the VG224 phone is doing? If not, then the station-id info would be sent.

Regards,

Michael.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Michael Owuor Mon, 02/25/2008 - 21:09

Jon,

Looks like you are getting battery reversal on the line.

*Feb 26 02:05:53.987: htsp_process_event: [0/0/0, FXOLS_OFFHOOK, E_DSP_SIG_0110]fxols_offhook_rvs_battery

Try disabling battery-reversal on this port and test it again.

router(config)# voice-port 0/0/0

router(config-voiceport)# no battery-reversal

Regards,

/mao

xiaoliangyue Tue, 02/26/2008 - 08:30

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

xiaoliangyue Tue, 02/26/2008 - 09:19

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

xiaoliangyue Tue, 02/26/2008 - 09:24

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

Michael Owuor Tue, 02/26/2008 - 09:50

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.

xiaoliangyue Tue, 02/26/2008 - 10:04

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.

Attachment: 
Michael Owuor Tue, 02/26/2008 - 10:58

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.

Michael Owuor Tue, 02/26/2008 - 12:11

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.

xiaoliangyue Tue, 02/26/2008 - 13:10

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

Michael Owuor Tue, 02/26/2008 - 13:37

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.

xiaoliangyue Tue, 02/26/2008 - 14:47

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.

Attachment: 
Michael Owuor Tue, 02/26/2008 - 15:38

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.

xiaoliangyue Tue, 02/26/2008 - 16:10

Michael, you're amazing! Vg224 did have routing problem. resovlving the routing issue, now vg224 can reach phone 41851, and I got 2-way audio now.

At the beginning, the h323 gateway was configured on a router with IP 172.26.240.244. However this box was used for other purpose, I got another router 2821, which has IP 172.26.240.243. This change happened just since last test.

Now the call goes thru. More than that, I was hoping that the caller id (station-id name IntercomTest) configured on voice-port 0/1/0 could be passed to the called party (phone 41851).

voice-port 0/1/0

no battery-reversal

cptone CA

timeouts call-disconnect 5

timeouts wait-release 5

connection plar 41851

station-id name IntercomTest

caller-id enable

This is actually the real purpose why I deploy the H.323 gw. Now on phone 41851, caller id shows 41896 with caller name XXXX. which is not I expect :(

Thanks,

Jon

Michael Owuor Tue, 02/26/2008 - 17:00

Good to hear that you're almost there Jon!

It sounds like the caller-id information being received on 41851 is the information about the VG224 phone which is originating the call.

Check out the following document that explains the relevant commands:

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_configuration_example09186a00800a9a49.shtml#req

Specifically, note that:

1. When the 'caller-id enable' command is used, this enables the transmission of caller-id on an FXO port. In our case, we don't want to have the caller-id information from the VG224 phone transmitted. So lets use the command 'no caller-id enable' instead.

2. The 'station-id number' and 'station-id name' commands only apply if no caller id is received on an FXO voice port. In our previous test we were indeed receiving caller-id because of the presence of the 'caller-id enable' command. So now that we have disabled inbound caller-id, lets add a 'station-id number' command to the voice-port.

The anticipation here here is that by disabling caller-id on the port through the 'no caller-id enable' command, the two 'station-id' commands would then take effect, and what is configured via those commands is what will be transmitted to the destination phone. Lets try this and see what happens.

!

voice-port 0/1/0

station-id number 12345

station-id name IntercomTest

no caller-id enable

!

Regards,

Michael.

xiaoliangyue Wed, 02/27/2008 - 09:00

Michael,

I agree with your analysis. I disabled the caller id on port 0/1/0, and made a test call. the weird thing is, the h323 gw still gets caller id and name:

001874: *Feb 27 16:52:39.671 UTC: [0/1/0] get_fxo_caller_id calling num=41833 calling name=Jon Test calling time=02/26 19:01

and the caller id and name show up on the phone 41851.

The values the gw has now are actually what it remembered from last caller id it got. station-id name/number are not used at all.

Thanks,

Jon

Attachment: 
Correct Answer
Michael Owuor Wed, 02/27/2008 - 10:47

Hi Jon,

It may be necessary to shut/no shut the voice port to have the changes take effect.

If not, then it would seem that any caller-id information received from the VG224 phone overrides the station-id configs. Can you configure the VG224 phone to not send any caller-id information.

In the planned topology, the FXO port was connected to the Intercom system. Would the intercom system be sending caller-id information like the VG224 phone is doing? If not, then the station-id info would be sent.

Regards,

Michael.

xiaoliangyue Wed, 02/27/2008 - 11:33

Hi, Michael,

I think the h323 is using cache. shut/no shut doesn't remove it. I finally rebooted the router. It works just like it is supposed to.

Thank you so much!!!

Jon

Michael Owuor Wed, 02/27/2008 - 11:56

That's good news Jon. Thanks for the update, and the opportunity to assist :-)

Regards,

Michael.

Actions

This Discussion