One Way Voice Issue

[config t]

Please forgive my terrible VoIP lingo and if this is confusing I completely understand 

Long story short - we are landing three networks via SATCOM onto our backside internal infrastructure. Two were previously existing and working and one (the new one) of the networks can not make external VoIP calls. I have verified reachability of this particular network (two-way voice) within our WAN. I made some test calls with the network to external numbers and all I heard when they picked up was dead silence. So, I had dial tone and could dial out  but I couldn't hear anything when they picked up. After calling them from a working net I verified they could hear me just fine. So classic one-way voice.

Possibly important is the fact that we are also using a Session Border Controller for these particular networks.

Any ideas on what could be causing the issue? The traffic is definitely getting out and to them, but doesn't appear to be coming back.

[deanwebb]

Is there some kind of fancy dialing rule that they need for outbound calls to complete? Are there config options set in the other voice networks that aren't set for this one?

Otherwise, I'd want to look at the session border controller, check for different settings there, as well.

[icecream-guy]

need some packet captures on both ends...

[config t]

need some packet captures on both ends...

Agree. Unfortunately the other end is an external agency and for some god awful reason my customer refuses to admit the issue could be someone else's routing or firewall. They also refuse to look at the SBC.
Why is it so hard for some people to just say they don't know, or ask for help?

I'm thinking this now belongs in the current frustrations thread Headed back to Bahrain today and I'm fixin to start crackin whips. I hate it when people get in the way of my troubleshoot.

[config t]

Is there some kind of fancy dialing rule that they need for outbound calls to complete? Are there config options set in the other voice networks that aren't set for this one?

Otherwise, I'd want to look at the session border controller, check for different settings there, as well.

I'm getting access to that SBC come hell or high water. I think the competent voice engineer is working the day I return as well so I will hit him up for a sanity check.

[deanwebb]

Is there some kind of fancy dialing rule that they need for outbound calls to complete? Are there config options set in the other voice networks that aren't set for this one?

Otherwise, I'd want to look at the session border controller, check for different settings there, as well.

I'm getting access to that SBC come hell or high water. I think the competent voice engineer is working the day I return as well so I will hit him up for a sanity check.

That is the strategy you want. Get the *competent* engineer!

[Dieselboy]

Sorry I missed this, I am in Sri Lanka now. Delayed flights etc etc. .


If you had control over the registration of the phone at the remote site, then you could enable packet capture output to the PC port of the phone and use wireshark on a laptop to capture the call set up.

1 way voice is lost packets in one way. As you can't hear them, their voice packets are not getting to your phone. Does the media flow through or flow around the SBC? Is this all Cisco?

During the SIP setup, the endpoints IP addresses / ports are sent so they know how to send media to the othet side. It could be something simple like there is NAT and there is no inspection of the SIP packets and so the private IP is getting sent instead of the NAT public IP. Or it could be something else simple like the RTP ports are not getting opened in the firewall/nat because of no SIP inspection. Or it could be something like the voice vlan subnet is not getting advertised within the routing protocol, so the phones cant route to each other.

Can you ping each phone from the SBC? And can you ping each remote phone from the local subnet where each phone resides? For example, if phone 1 is on 192.168.1.x/24 and phone 2 is on 10.0.2.x/24 then can you ping 192.168.1.x from 10.0.2.x.

As the phones ring when dialed, this is a network issue with media flow.

[config t]

Okie dokie..

The *competent* engineer also turned out to be the lazy engineer because I had to push from the top and get someone to actually order him to look at the SBC. Not my prefered route for reasons but I'm pretty sure my hand in it was masked 

As I now understand it, the SBC in our network is a separate router specific for that purpose and acts a proxy for voice traffic. So *if* it is working all VoIP traffic traversing external transport does so through the SBC network.

While investigating it was discovered the route had been added to the SBC but was not being utilized. I wasn't there to see it myself but I'm told all he did was delete the configuration and re-add it. After that we were able to successfully make external calls.

On a side note.. we came up with a new Super Hero name.. Captain Troubleshot. His super power is only troubleshooting when someone makes him do it.

[icecream-guy]

I'm told all he did was delete the configuration and re-add it. After that we were able to successfully make external calls.

Sounds like a Cisco solution.

[Otanx]

I'm told all he did was delete the configuration and re-add it. After that we were able to successfully make external calls.

Sounds like a Cisco solution.

The step you do right before the Windows solution.

-Otanx

[deanwebb]

I'm told all he did was delete the configuration and re-add it. After that we were able to successfully make external calls.

Sounds like a Cisco solution.

The step you do right before the Windows solution.

-Otanx

[Dieselboy]

10 years ago I would have said that engineer was outright lying - he found his problem and fixed it.

However, now I would say he's 100% correct and the router had a bug.

[config t]

Definitely Cisco and definitely a bug.

I don't think he was being lazy. He just knew the config was there and was being stubborn. Unfortunately that cost us several weeks.

I made some assumptions on my end for sure, I thought it was a WAN routing issue and didn't fully understand what role the SBC was playing. It was bugging me (pun) that nobody looked at the SBC though, so I had to push for it and I'm glad I did.

If anything now I am looking at what I could have done to speed up the process on my end. Now that I know the device exists and what it does I won't have this problem in the future.

[deanwebb]

We can't really speed up the process all that much because of... dunn dunn DUNNN



CHANGE CONTROL!

[config t]

We can't really speed up the process all that much because of... dunn dunn DUNNN



CHANGE CONTROL!

I wish this organization had change control..