(1) Checked the configuration of AR, since the outgoing call started working, so the outgoing call configuration is OK.
(2) If the customer replaced AR with an IP Phone, then the call works right, no one-way call issue. packet and found that the peer address was 10.8.19.97, which is same as that configured on AR.
(3) packet in the outgoing call, we can see that the AR had sent the voice from local, but we didn’t know why the other end couldn’t hear it.
(4) So we asked the customer packet from IP Phone side. From the result we can find that AR didn’t send voice traffic to IP Phone. Compare to step(3), it seems that it’s IMS network problem, it dropped the voice traffic sent from AR(172.16.27.2) to IP Phone(172.16.21.5) .
(5) We asked the customer to ping from AR(172.16.27.2) to IP Phone(172.16.21.5) to test if the route is reachable, and it turned out that the route is not reachable.
Check the configuration again, we found there were two static routes.
dot1q termination vid 20
ip address 172.16.26.2 255.255.255.0
dot1q termination vid 30
ip address 172.16.27.2 255.255.255.0
ip route-static 0.0.0.0 0.0.0.0 172.16.26.1
ip route-static 10.8.19.0 255.255.255.0 172.16.27.1 //for SBC in IMS network
From the above configuration, we can see the next hop to SBC from AR is 172.16.27.1, but the next hop to IP Phone(172.16.21.5) is 172.16.26.1. We had asked the customer many times to provide the detail topology of the network, but had no result.
For test, we asked the customer to add one more static
ip route-static 172.16.21.0 255.255.255.0 172.16.27.1 //for IP Phone
Then the other end can hear local end. The problem was resolved.
In this situation, we don’t know exactly the detail network topology. But we can try some solution to test it.