0

One way audio

Kris Vandewiele

April 17, 2018 09:44

None

Follow

Hi 

I guess there are multiple posts about audio but even after days/weeks/... of browsing knowledge bases etc.. and trying a lot of different things I cannot get it working.

I have a Yeastar S50, latest firmware.
There is one hardware phone connected (tiptel) and there are multiple remote extensions with a softphone app.
When I call from hardware phone to softphone I get sound, the other way around it does not work, one can not hear sound in the hardware phone.
The hardware setup is as follows:
provider with dynamic IP -> modem (no routing functionality) -> Mikrotik -> S50.
For NAT I tried with a hostname (DDNS) or the dynamic IP.
Forwarded ports are 5060UDP and 10000->12000UDP.

Fyi;
I also tried with a cloud voip provider and there I got audio working however, when the call was abandoned my phone kept ringing, quite annoying.

Thanks

• Facebook
• Twitter
• LinkedIn

12 comments

• 
  Jonathan E April 18, 2018 22:35 Official comment

  Kris;
  
  SIP ALG is often suggested off, not on. So if the only change you made last go around was to Enable SIP ALG then I'm not confident your problems are gone, if they are then your issue is 100% related to port forwarding not being set up correctly.
  
  You say you did the 10000-12000 RTP forward, but I'm curious if your firewall actually allowed ranges or if you tried to input the range creatively to work.
  
  SIP ALG tries to do some packet inspection and adds routing to clearly identified SIP packets including RTP packets; if you're using it your firmware on your router should be all the way updated to whatever they last released. I personally make it a troubleshooting step to disable SIP ALG entirely because I can't be responsible from a Yeastar perspective if some other device has logic set to help route packets and things aren't working correctly.
  
  To bisect correctly and resolve this issue, you should have SIP ALG disabled, if you want to use it, get it working without first and then transition your settings over (if you're confident your microtik's alg implementation is solid). But turning it on is never a troubleshooting step for me.
  
  Show me a screenshot of your port forwarding you have set up.

• 0
  
  Larry Neblett April 17, 2018 12:05

  There are a number of things that can cause this. 

  1. Is SIP ALG disabled in the MikroTik?

  2. What is the softphone in use at the remote sites?

  3. Do you have access to the remote routers? Is their SIP ALG disabled?

  4. How many remote softphones are behind any one remote router?

  5. Is NAT checked in the extension settings for those remote phones?

  From the description it sounds like the softphone is initiating a call. The register and INVITE reach the PBX and the TipTel rings. When the Tiptel answers, the softphone can hear the audio coming from the TipTel, but the TipTel is not able to hear the audio from the softphone. 

  The bottom line is that the RTP audio stream from the softphone is not making it to the TipTel. 

  Check the SIP settings in the UCM and the NAT settings page. If needed, post a screen shot of same, but obscure the public IP settings. 

  If none of the above is successful, then a capture of such a call may be in order so we can see what the messaging indicates. 

   

   

   

• 0
  
  Oscar Colka April 18, 2018 02:48

  Agree with Larry, if after checking what Larry suggested and still no luck, a capture of such a call(pcap logs) would be the best way to diagnose this issue.

• 0
  
  Kris Vandewiele April 18, 2018 09:31

  Hi
  Thanks for the valuable input.
  Strangely enough I see that SIP ALG was not turned off in the Mikrotik.
  I assume it is due to testing multiple parameters at once, not a good approach I know now..

  Still testing but I assume it will be working now.

  Brgds

• 0
  
  Jonathan November 16, 2018 23:27

  You need to set stun in general >sip > nat on the yeastar and define the local network.

  Tick register remotely and nat on each extension.Sip service port on mikrotik is perfectly acceptable.

  Sip transformations or sip alg on sonicwall or system for example are not and need to be switched off.

   

   

• 0
  
  Michael Rautenbach October 22, 2019 15:11

  Kris Vandewiele - long shot from my side. I am having the identical problem. Did you eventually get rid of the one-way speech problem? I have a Mikrotik router as well. Have enable disable SIP ALG - no difference. Have set NAT on - no difference. Tearing my hear out

• 0
  
  Kris Vandewiele October 28, 2019 13:23

  Hi

  My apologies for the somewhat late response.
  SIP ALG disable in combination with local network settings did the trick for me.
  
  Do you have a provider's router in between?
  I used to have one one and replaced it for a modem, this was an important thing to do as it tends to mix up packet contents.

  In my experience, it's best to investigate the SIP traffic as it can give you an insight of what is sent to the other side. For instance it is possible that the return IP mentioned in the packets is the local IP making it rather difficult to work... You could try Wireshark
  Audio problems most of the time have to do with packet contents. (in my opinion)
  
  

  Brgds

• 0
  
  Larry Neblett October 28, 2019 14:04

  So, you have a S PBX with remote devices running softphones and NAT via a MikroTik?

• 0
  
  Kris Vandewiele October 28, 2019 14:09

  S50 / Mikrotik Hex / Bria

• 0
  
  Larry Neblett October 28, 2019 14:13

  OK, so which device can hear or not the other? My assumption is the Bria can hear the S PBX, but the S cannot hear the Bria.

   

  Also make a call and despite the absence of audio, see if the call will last for longer than 40 seconds. See if it drops at around 32 seconds.

• 0
  
  Kris Vandewiele October 28, 2019 14:15

  My problem is solved, it's a question for mr Michael Rautenbach.

  I see why you ask the question about the 40s audio.. Codecs??

• 0
  
  Larry Neblett October 28, 2019 14:31

  No, if codecs are incompatible the SIP response will be a 488, not acceptable here and the call will not establish.

  If NAT is incorrect, then generally once the call is established, then the devices will start to use the IP addresses contained in the contact and connect headers of the SIP message, rather than the IP seen when the INVITE was sent.

  Typically, the NAT settings in the S PBX will be incorrect and the messaging will tell the remote device to use the private IP instead of the S PBX public IP. When this occurs the 200OK will not be seen by the PBX and the call timer will time out at 32 seconds (or less) and the call will drop.

  The bottom line is depending on how the PBX is setup with regard to the NAT settings and its physical setting in relation to interface settings and if the local lans are know, both sides need to know how to contact the other correctly. Because the PBX is also the media server, the IP is the same for both the contact header (SIP) and the connect header (RTP).