SIP Passthrough

[RR-texas]

Until recently, I had an RT-AC87u with merlin on it. Recently I updated my router and replaced it with RT-AC86U. (The Asus numbering scheme is weird - the 86 is way newer than the 87. Go figure.)

The new router AC86U is running Merlin 384.4_2.

For quite a while I've used Onsip as my VOIP provider for home and office. With the AC87U the voip service was rock solid.

Since replacing the 87U with the 86U, we've been having a little trouble with call completion and call transfers.

Can someone point me in the direction of an explanation (or a readme I've missed) on how I should set the WAN / Passthrough options for the best results for cloud based VOIP services.

I just looked and realized that SIP Passthrough is currently set to ENABLE.

I'm looking for info on the difference between ENABLE, DISABLE, and ENABLE with NAT Helper.

I have this vague (very vague) recollection that there was a change in the way the Asus code handled SIP a while back, and SIP Passthrough was supposed to now work properly.

But with the current version - what is the collective wisdom?

Thanks in advance

Robert

 

[OzarkEdge]

Until recently, I had an RT-AC87u with merlin on it. Recently I updated my router and replaced it with RT-AC86U. (The Asus numbering scheme is weird - the 86 is way newer than the 87. Go figure.)

The new router AC86U is running Merlin 384.4_2.

For quite a while I've used Onsip as my VOIP provider for home and office. With the AC87U the voip service was rock solid.

Since replacing the 87U with the 86U, we've been having a little trouble with call completion and call transfers.

Can someone point me in the direction of an explanation (or a readme I've missed) on how I should set the WAN / Passthrough options for the best results for cloud based VOIP services.

I just looked and realized that SIP Passthrough is currently set to ENABLE.

I'm looking for info on the difference between ENABLE, DISABLE, and ENABLE with NAT Helper.

I have this vague (very vague) recollection that there was a change in the way the Asus code handled SIP a while back, and SIP Passthrough was supposed to now work properly.

But with the current version - what is the collective wisdom?

Thanks in advance

Robert

The N66U and AC68U caused one-way audio with an OBi ata and VoIP.ms. Disabling SIP Passthrough fixed this, so I automatically did same on the AC86U. I have not seen the setting ENABLE with NAT Helper here on stock firmware.

I say disable it and see how it works for you. If the problem persists, you may find more advice here.

OE

 

[Vexira]

Leave the nat pass through set to helper, make sure in the voip phone or ATA that nat traversal is set to keep alive.

 

[JDB]

Personally I prefer to disable any router based pass through/helper.

What it does is attempts to manipulate the SIP Contact header and Media IP in the SDP to be your WAN IP. However, your SIP Client and SIP Provider should be configured (via STUN and other mechanisms) for this not to be required, and often the router just makes a hash of it.

If NAT is the issue you would see one way audio (you would hear nothing, other party would hear you) and/or you would miss incoming calls. What you describe doesn’t sound like a NAT issue to me.

(Previous Technical Director at a VoIP specialist telecom equipment manufacturer and now run my own telecoms consultancy, often fixing SIP issues like this!)


Sent from my iPhone using Tapatalk

 

[JDB]

To answer your question on the modes;

Enabled - Will use WAN_IP:5060 for the NAT mapped external port for SIP packets sourced in your network. Only really works properly if you have 1 SIP device

Enabled with NAT helper - As above plus the SIP/SDP manipulations I described

Disabled - SIP packets will be mapped to a random WAN side port as with any other packet

If you have only 1 SIP device having it enabled would do no harm. If you have more than 1 it may cause the issues you describe if trying to transfer a call between devices (as only one will work at a time in my experience, and they’ll effectively fight over the 5060 port). The router should allocate 5061, 5062... for further devices in this case but not sure if it does, plus according to the SIP spec it would be better doing even ports only (so skip 5061 as it technically can be used by the original 5060 user in some scenarios).

It gets very complicated, hence, turn it off and let the dedicated SIP devices at either end sort it out themselves!


Sent from my iPhone using Tapatalk

 

[CollinChaffin]

To answer your question on the modes;

Enabled - Will use WAN_IP:5060 for the NAT mapped external port for SIP packets sourced in your network. Only really works properly if you have 1 SIP device

Enabled with NAT helper - As above plus the SIP/SDP manipulations I described

Disabled - SIP packets will be mapped to a random WAN side port as with any other packet

If you have only 1 SIP device having it enabled would do no harm. If you have more than 1 it may cause the issues you describe if trying to transfer a call between devices (as only one will work at a time in my experience, and they’ll effectively fight over the 5060 port). The router should allocate 5061, 5062... for further devices in this case but not sure if it does, plus according to the SIP spec it would be better doing even ports only (so skip 5061 as it technically can be used by the original 5060 user in some scenarios).

It gets very complicated, hence, turn it off and let the dedicated SIP devices at either end sort it out themselves!


Sent from my iPhone using Tapatalk

This is dangerously incorrect. Not only does the actual description of each correctly state the behavior, but I can report as we speak I have 2 pbx's and over a dozen ACTIVE SIP registrations/trunks on different providers/devices heck I even have a couple ATAs in the mix, and can pick up ANY and call ANY other, routing first to one SIP provider (callcentric) through one PBX or ATA and dial not only folks outside my network, but back in to another device on voip.ms and a totally different registered pbx/ata.

The point being, the ONLY scenario in which this works is to actually drop the helper but REMAIN ENABLED. Disabled, as everyone else out there has also reported, simply blocks SIP from working under usual configs as the ports are kept closed, and the helper is simply broken for more than one device in my experience.

So, I will give the advice that if you have MORE THAN ONE sip registration needed out of your ASUS, drop from the default of "enabled with helper" down to just "enabled", reboot and see if that helps.

Per the Merlin description of each:

DISABLED==Actively BLOCK the port used by the protocol.
ENABLED==Allow NAT through the protocol's port <----IF YOU HAVE MORE THAN ONE SIP DEVICE

SCREENSHOT:

 

[JDB]

I strongly recommend you don’t turn up with your 3 posts of experience and respect on this forum and start calling people’s input “dangerous”. That insinuation is absurd.

As you say, turning it off completely has the effect of blocking the ports on the firewall, but I also have a fleet of SIP devices working in my network and so know how it works and it doesn’t outright stop the protocol from working in all cases!

Keep your advice moderated and realise that there is no one size fits all answer to a problem if you don’t mind!


Sent from my iPhone using Tapatalk