Gateway 2821 fails to forward call to callmanager5

[xiaoliangyue]

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

[xiaoliangyue]

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]

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]

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

[Michael Owuor · Accepted solution]

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]

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]

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

Regards,

Michael.