Hello !
We have a Balance 310 and we have a problem with SIP. The first time someone tries to initiate a call nothing happens, the next time they try it works fine.
We have tried to enable Service Passthrough, SIP to compability with no luck. The SIP provider replied back with the ports they use to :
SIP is on 5060 UDP,
RTP on 16000-21000 UDP
Any suggestions ?
Best regards
Stein Jacobsen
Stein,
The same thing used to happen to me. Leave SIP Passthrough enabled. Try to access your cable modems (you might need to call your ISPs for username and password) and make sure to disable SIP ALG on them, under Firewall or NAT settings. That solved my problem. Try also disabling DSL Cable Optimization under QoS on the Peplink, some say it causes more harm than good, by delaying upload bandwidth packets, and finally, enable QoS for SIP port 5060 and RTP (UDP) Ports.
Regards,
Soriam
We have replaced the Peplink unit with an ERAMAX router and then the problems dissapeard leaving me with the suspicion to the Peplink unit.
Please try the recommendations given above.
Dear Soriam !
I was able to enable the Qos for SIP, but whatabout RTP ? How do i do that ?
Stein,
For fine control of my network, and for QoS to work at its best, I assign a RTP (UDP) port range to my phones. For example. My phone uses RTP ports 10000-10019, My wife’s uses range 10020-10039, and so on.
If your phones have the ability to assign a RTP (UDP) port range, I suggest you assign it manually, then go to the PEP and assign those UDP ports, by creating a custom rule and in my case for example, I would prioritize to “High” UDP port range 10000-10039. The reason for this is because youtube and other video apps use a whole range of UDP ports, but I don’t want video traffic messing up my voip calls. This is what I mean by fine tuning QoS and it works very very well. Let me know if that makes sense. I am attaching a picture of my QoS settings for these ports.
Regards!
Stein,
Here is another pic of what QoS should look like. DSL/Cable Optimization is disabled here also, which is an important step.
Stein,
One more thing. May I ask what type of SIP phones do you have? I am a VoIP expert and could perhaps give you a few pointers as to the phone configurations. I can almost guarantee you the Pep is not the problem, it works very well with VoIP.
Hi again !
The phones used are Gigaset DE310 Pro and service delivered through a company called EMAKOM in Poland.
Stein,
Do you have access to the phone configuration page? And if so, would you feel comfortable with working in there? Just trying to know your level of understanding of networks, voip, etc.
I would really have appreciated that , but the phones are delivered from EMAKOM preconfigured, and we don’t have login to the webservice on the phone. I have a really good knowledge of VOIP. Have worked and have trained on Cisco UC520
Stein,
I see. Can you turn them off, then connect them to the Pep, then turn them back on and test? I just want to make sure they get a new and fresh connection. It might also be the case that they need the other router in order to work, if they come preconfigured (like a cable phone). Let me know.
Regards!
The phones are rebooted. They are in DHCP mode, so i can see the connections in Peplink. I have tried to adjust the DHCP scope in order to see that they are getting a new ip address as well. As i mentioned earlier, when we exchange the Pep with a lowend router everything works fine
Try it now and let me know.
Our company has over 300 Balance Series units in the field strictly used for hosted VoIP via SIP with no issues at all. I suspect you have other issues.
Stein,
If the steps indicated above did not help, then indeed it must be other issues as tjvoip45 mentioned.
As stated before I find it quite strange that when we exchange the Peplink with a cheap router/fw we experience no problems !
Sometimes what can happen in a multi-WAN environment is that the phone will register with the SIP server using WAN1 for example but then when you go to make a call it generates a new session that goes out WAN2 or WAN3. The SIP server sees the call coming from a completely different IP address and it won’t go through.
The solution for this is with a custom outbound policy rule: Source = Any, Destination = SIP server IP or Domain, Protocol = Any, Algorithm = Priority. The Priority1 WAN connection should be your primary circuit.
This will ensure your VoIP traffic is sticky to a single WAN but will also allow it to failover to the other WANs in case the primary fails.
Hope this helps.
This is what we have done. Algorithm is set to Enforced and not Priority. This has no effect. I do see under sessions that the traffic is routed correct
Can you share the screenshot of the active sessions (Status > Active Sessions > Search > Filter by IP subnet 87.204.129.0/24)?
