The phone rings but it hangs up automatically

[haininghuang3185]

The networking topology is as follows

Site A and Site B are connected through an SDWAN dedicated line. The current problem is that the phone at Site A rings when calling Site B, but it will automatically hang up when connected.
1. For the CUCM address, we have done NAT on the SDWAN router at station B, and mapped the 192.168.0.28 address to the 172.25.150.58 address.
2. Site A: voice gateway CME（ip:10.10.210.1） >>> >>>> H323 >>>> Site B: CUCM（ip:172.25.150.58);
3. We captured packets on the SDWAN routers at Site A and Site B respectively, and found only H225 packets but no H245 packets. Does this mean that the call has not been established?
4. In addition, we found that the IP address carried in the Connect package is the CUCM intranet address 192.168.0.28. Should the address carried here be 172.25.150.58 after CUCM NAT?

[b.winter]

Check the CUCM logs of the call via RTMT.
Your problem sounds like a codec issue and therefore has nothing to do with any network related stuff.

[Nithin Eluvathingal]

I agree with @b.winter , your issues it looks like codec  issues.

Also make sure to disable SIP inspection if the traffic flow through any firewall.

[haininghuang3185]

The attachment is the collected CUCM log, can you help me to see where the problem occurs? The fault reappearance time is from 9:00 to 10:00 on August 2, the phone number of site A is 8141053, and the phone number of site B is 8149411

[b.winter]

Every call in the logs look good.

Make a new call and write down the exact time, calling and called number.

And IMHO you should be able to at least identify and read the CUCM logs by yourself.
You cannot make changes in the system and be unable to troubleshoot problems when they happen.

[haininghuang3185]

We checked and found that it is not codec  issues, but that the SDWAN router does not support the NAT ALG function, so the ip address carried in the Connect packet is the intranet address instead of the address after NAT.

[b.winter]

The main question here is: why on earth are you NAT-ing the CUCM's IP-Address? Which reason does this have, NAT inside your network?
Seeing your network, there is no reason at all. I would never do such a weird thing. This WILL lead to failures.

IMHO, instead of fixing any "voice" problems, you should fix your network setup.

And to your packet capture pic: This is so small, when I zoom in, I can't see anything.
In the H.323 you will always see the original IP, because NAT only works on Layer 2 and 3 --> this should be basic NAT knowledge.
H.323 is a protocol above Layer 3

[haininghuang3185]

Site A and Site B are two sites. If NAT is not implemented, the intranet addresses of the two sites will conflict.

The attachment is the result of our packet capture and analysis on the A Site router, and we found that the address carried in Connect is an intranet address and not an address after NAT.
In addition, after we enable the NAT ALG function of the router, the communication between Site A and Site B is normal.

[b.winter]

Picking up @Roger Kallberg's comment: If you really have the same subnet twice internally, then you have / your company has a very very bad network design.
If I would be the voice engineer of this company, I wouldn't do anything to fix such voice issues, if the network below is just crap.
You are currently not troubleshooting a voice / collaboration related problem, you are troubleshooting a networking problem.

What do you mean now with "normal"? Are the calls working now or not?

[Roger Kallberg]

Why did you create a new post on the same topic as this post? https://community.cisco.com/t5/ip-telephony-and-phones/cisco-voice-failure/m-p/4896475

[haininghuang3185]

Attached is the network topology diagram.

[Roger Kallberg]

What do you mean by that the intranet addresses would conflict?

 

By the topology that you shared your using all together different IP networks at the two sites. A private C-class network at one site and a private A-class network at the other. How would these conflict?