Failed calls - H323 box , Call Manager , PSTN

[jbichard]

Hi all , I run an AS5350 gateway which is connected to our pstn switch . A customer of ours has 2 call manager´s , we provide the PSTN connection. The customer is working on connecting 3rd party H323 CPE (allied telesyn) with his CCM net. If we call in from the PSTN to his H323 CPE all is OK. But , calls out to the PSTN from the H323 box fail through call manager 2 , but are OK if routed through call manager 1.

The call managers are parallel connected for redundancy , and our AS5350 config routes calls to the call manager´s using preference , and we also use h225 timeout tcp establish command.

When the call is made from the H323 box through CCM1 , the PSTN phone rings , but gets no audio when answered , the phone connected to the H323 box gets continued ring back tone until the call is dropped. I am thinking that the answer acknowledge signal from the PSTN phone is being routed to CCM1 , instead of CCM 2 that is setting up the call.

I would be grateful for any ideas that could shed light on this problem. Maybe the customer will always have to route outgoing calls through CCM1 ?

voice class h323 1

h225 timeout tcp establish 3

dial-peer voice 115 voip

description OFFICE via CCM1

destination-pattern 12345..

voice-class h323 1

session target ipv4:10.169.108.3

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

!

dial-peer voice 215 voip

description OFFICE via CCM2

preference 1

destination-pattern 12345..

voice-class h323 1

session target ipv4:10.169.108.4

dtmf-relay h245-alphanumeric

codec g711ulaw

no vad

Thanks

Jerry

[eyabane]

Jerry,

isn't the CCM2 the problematic one? because the beigining of your second paragraph is referring to CCM1 as the one that fails the call. Please confirm that.

now, assuming you meant CCM2 in that paragraph, there are quite a few things that could contribute to your problem, at this point, given the info you provided:

1. are the 2 CCMs identical (configuration and version wise)? something as trivial as a difference in the CallManager Service Parameter (H323FastStartInbound for exple) could lead to this result.

2. are you certain the calls from the third party device are being sent with the same elements each time; i.e., could be that you send the call FastStart when it goes out CCM1, but yet it is sent SlowStart when going to CCM2.

3. if possible (when low traffic), use the q931 debug on the AS5350 to insure that the call is also sent with the same parameters regardless of which CCM it orignated from, and that the PSTN call flow goes as far as a Connect from the PSTN. a comparison of the PSTN call flows for each type of call will yield info on any PSTN related issue, although that will be the least of my suspicions. It will at least help narrow the prblem down to the IP leg only.

You will notice i am leaning more towards a signaling problem so far, and that is because the source endpoint is still ringing, indicating it never got ( or it couldn't decode) the Connect message.

lastly, i do assume there are no ACLs anywhere along the way blocking anything valuable to these calls.

Eyabane

[jbichard]

Thanks for your reply Eyabane , you are right about my mistake - it was meant to be CCM2 in that paragraph. To answer your pointers :

1, I have been assured that the config and version etc are identical on both CCM´s.

2, I´ll have to check with the customer about the FastStart/SlowStart possibility , but I assumed that its the same when routing through either CCM.

3, I did try a debug Q931 for a couple of test calls, but there was too much traffic really , I did see though that the call is disconnected when the connect acknowledge signal comes from the PSTN side.

I follow your thoughts that the source endpoint is not receiving that connect acknowledge.

Is it a possibility perhaps that the connect ack signal is being sent to CCM1 instead of CCM2 ?

Thanks

Jerry