No audio when moving YeaLink phones between domains

[TheJTrain]

We have 2 completely separate domains running FusionPBX that we register phones to (Domain1 and Domain2 for the purposes of this forum). This is not a multi-tenant domain running off of the same instance, but 2 separate instances.

I ran into an issue recently where I'll register a Yealink phone (T54W) on Domain1 and it'll work just fine, but when I delete the phone's MAC address out of Domain1 and factory reset the phone from the web interface and then add it/register it to Domain2, the phone will register and call out/receive calls, but there's no inbound or outbound audio on the phone. Also have this issue with the wireless phones (W60B/W56H). Other phones are currently registered on Domain2 and are working just fine in production, so it's not an issue with all phones, just the ones I've previously registered to a different domain.

I've tried creating new extensions on Domain2 and assigning them to different lines on the phone, but still not getting any audio. I've tried the different advanced settings on the extension (SIP force contact and SIP force expire) but that didn't seem to help either. I've dug around on the Debian base server looking through the freeswitch/fusion files trying to find if somewhere this phone's mac address is still registered on Domain1 but haven't been able to find anything. I've also tried looking through the logs on Fusion but don't see where it's trying to send the audio to a different IP address or something, but it could also be a case of not knowing what to look for.

I assume it's the phone's mac address tied to a registration to Domain1 that's hung up somewhere or something like that but don't know where to look.

Any help would be appreciated.

 

[Adrian Fretwell]

It is unlikely to be an issue with the phones unless any configuration has been written to any of the static fields. You can check this by exporting all the configuration from the phone(s) and looking at it with a text editor. Look out for items that would not get overwritten by the provision template.

I think it is also unlikely to be a Fusion/FreeSWITCH issue if both servers have been set up in the same way, the only difference being the IP addresses.

You do not describe your network topology, maybe there are some significant differences there? If SIP signalling works but audio does not, it is often a network related issue. The IP and port pairs to send/receive audio are defined in the SDP body, most commonly associated with the initial INVITE and it's associated 200OK.

 

[TheJTrain]

Understood. Thanks for your reply.

In this case, we have it set up to where Domain1 has a public IP address and Domain2 has a private IP address that NATs out to the internet. That probably sounds like a NAT issue, but I'm still curious as to why we've been able to set up so many phones successfully on Domain2 with the NAT-ed private IP address and only some have had this issue - especially ones that have been registered on Domain1 previously.

Forgive me but I'm not sure where to look to find out. I've scanned over the log viewer in Fusion but am not sure I'm seeing what I need to. Do I need to run a packet capture on the Debian base to see that information?

 

[Adrian Fretwell]

Yes, I often recommend packet captures when diagnosing SIP, so much so that I begin to sound like a broken record! (Reference for those who remember scratches on vinyl that made the needle jump).

ngrep, sngrep, tcpdump and Wireshark are the tools to help you. Look closely at the Contact headers and the IP addresses in the SDP bodies.

 

[TheJTrain]

And sage advice, it appears! Running sngrep on Domain2 behind NAT, I noticed that calls were going from the public IP on a test router the phone was connected to to the private IP of Domain2, which was apparently not allowing sound to pass through NAT. Placing calls from phones on Domain1 which has a public IP was going straight from a public to a public, so nothing for NAT to mess up at the destination and therefore sound was working just fine.

I moved the phone to a router on the same internal network as Domain2 (so it wouldn't have to traverse NAT at the destination) and sound is going through no problem. The test router setup wasn't analogous to what our production environment would look like using Domain2, so probably not worth diving into why NAT wasn't allowing sound on those calls just yet. Might be something to look into another day, but for now, this fixed my issue.

Thanks for the help.