0

No audio on remote extension

Drazen Arsenic

July 20, 2020 13:42

None

Follow

Hello,

I have Yeastar U100 (I know it is obsolete but client is still using it) at client's site, and he have a remote branch. I have extension in remote office which is registered via DDNS in router. 

Extension register correctly but when I make call and session started there is no audio, on both sides. 

This is SIP settings in U100

Also NAT settings are as follow

As  you can see from screenshot below extension 101 is connected

And I am able to make calls which you can clearly see in CDR

But when they start session we  there is no audio. you can see there has been billing time but we couldn't talk.

In Huawei router we have set port forwarding as follows

And SIP ALG is set as follows:

I tried turning firewall of (on U100 and router both), tried to use DMZ and still no result, I tried buch of other things too and still no result.

Does anyone know how to solve this mistery?

Thanks in advance for all of the help.

Drazen

• Facebook
• Twitter
• LinkedIn

5 comments

• 1
  
  Larry Neblett July 21, 2020 10:15

  Take a capture of a call and post.

• 0
  
  Drazen Arsenic July 27, 2020 14:05

  Sorry for my late reply, I couldn't do capture sooner. Here is capture I made after making a call from extension 101 (registered remotely) to extension 200.

  

  and  next one

  

  and last one

  

  Hope you can see something here that can help me.

  Thanks

  Drazen

• 0
  
  Larry Neblett July 27, 2020 15:26

  I would have preferred to read the pcap file as this is very small and hard to read. 

   

  This is an options request from 192.168.1.50 to 192.168.1.80. Has nothing to do with a call and does not involve a remote device. 

• 0
  
  Drazen Arsenic July 27, 2020 17:19

  Here is entire pcap file

  https://www.dropbox.com/sh/inthqvpngmrp37h/AACpaGI7793ZbUqMyzyZ8l4za?dl=0

   

• 0
  
  Larry Neblett July 28, 2020 12:44

  The NAT is incorrect. 

  

  When you get to the 200OK, the system is telling the remote device at 32.223.X.X to reply (contact) to the 192.168.1.50 IP address. As this is a private IP it is not possible and as a result the ACK is never seen and as a result the system does a number of retries in an effort to get the ACK, but then times-out and ends the call (as it should). The system should  be telling the remote device to use the IP associated to the DDNS host name you have. You need to insure that the hostname resolves to your Public IP. 

   

  Additionally, the Eyebeam device at the remote site has a somewhat similar issue in that the RTP connection info is not correct. It too is telling the system that it should use the Private IP of the Eyebeam rather than what I think should be the 32.223.X.X address.