Hi there

Long time lister first time caller.

Have an RB750, connected to which I have:
- a netgear unmanaged gigabit switch
- a Cisco UC320W telephony box, and
- a SPA8000 for analogue phones

Internal extensions can make outgoing calls no problem.

External callers can call in no problem.

Internal extensions can transfer live calls internally with no issue, and call divert to an internal extension works fine too.

However, call transfers, or call divert, to *external* numbers does not work. Silence (is golden).

Would appreciate some clues as to where I should start looking for a reason why this is happening.

Thanks!

Robin

Hi,

Do the calls actually go through but you get 'dead air' or not even that? I.e. Do the 'external' phones ring on divert?

Rgds,
Mark.

Hi,

Do the calls actually go through but you get 'dead air' or not even that? I.e. Do the 'external' phones ring on divert?

Rgds,
Mark.

Hi Mark, thanks for your reply.

The external phones were ringing on divert but "dead air" from there ...

Regards

Robin

Hi Robin,

From our experience of this, you probably have a problem with your RTP stream and not the SIP part.
Are you by any chance doing more than one NAT with the voice traffic?

Rgds,
Mark.

Hi Robin,

From our experience of this, you probably have a problem with your RTP stream and not the SIP part.
Are you by any chance doing more than one NAT with the voice traffic?

Rgds,
Mark.

Hi Mark

Thanks for this. We have established that this is either an upstream issue with a failover provider to the ISP and/or a hairpinning issue with the UC320.

BUT there is a SPA9000 (supporting some analogue phones) alongside the Cisco UC320 - is that what you mean?

Cheers

Robin

In general, how do people go about configuring their Mikrotik router for SIP passthrough, assuming there is a PBX-like device on the LAN behind the router (WAN)?

I'd be very interested in hearing how people manage this. Currently, we have the firewall accepting UDP on 5060-5070 and NAT forwarding of UDP 5060-5070 to the same ports on the Cisco UC320.

Cheers

Robin

Hi Robin,

All I can tell you at this point is that the ports you have configured in the firewall are only the SIP ports i.e. just control messaging for call control, etc (usually 5060 & 5061).

RTP i.e. the actual audio, shall use random ports and if these are not going back and forth seamlessly, you get the dead air scenario.

Unless the router is REALLY SIP aware, you shall have this sort of problem if you just block all traffic except the usual ones you know about e.g. DNS, ICMP, HTTP.

It really depends on the rest of your firewall config. Try to ensure that you are letting established connections pass through.

Rgds,
Mark.

Hi Robin,

All I can tell you at this point is that the ports you have configured in the firewall are only the SIP ports i.e. just control messaging for call control, etc (usually 5060 & 5061).

RTP i.e. the actual audio, shall use random ports and if these are not going back and forth seamlessly, you get the dead air scenario.

Unless the router is REALLY SIP aware, you shall have this sort of problem if you just block all traffic except the usual ones you know about e.g. DNS, ICMP, HTTP.

It really depends on the rest of your firewall config. Try to ensure that you are letting established connections pass through.

Rgds,
Mark.

Thanks Mark for your perspectives.

The strange thing here is when the ISP reverts to their original upstream call provider, the issue goes away.

Regards

Robin

Hi Robin,

Could be that the packets are going out from one leg and coming back from another and do not know where to go at that point. From what I can imagine, you are having BGP/routing issues here and it's not the SIP server that has the problem. Do you have one or two links to your provider(s)?

Also, is the 'dead air' only one way or both?

Rgds,
Mark.

Thanks again for the ideas Mark.

What you describe is possible. The (small) ISP say that they have primary and backup call providers for their SIP trunks and the issue is that the Cisco UC320 isn't capable of hairpinning the call. Their current temporary fix is to route hairpinned calls in and out via the same provider. When the UC320 was installed, their primary was provider A and failover provider B. For cost reasons they reversed this, and all went to pot. For testing, they reverted back to the original situation (primary A, failover B) and everything worked again. Now we're back to primaryB failoverA so the problem remains.

In terms of the link to the SIP provider (the ISP), there is a single Miktroik router connecting the business to the ISP via a wireless unit. Speeds are generally 50mb down/10-20mb up.

Regards

Robin

Hi Robin,

Could be that the packets are going out from one leg and coming back from another and do not know where to go at that point. From what I can imagine, you are having BGP/routing issues here and it's not the SIP server that has the problem. Do you have one or two links to your provider(s)?

Also, is the 'dead air' only one way or both?

Rgds,
Mark.

Also, is the 'dead air' only one way or both?

Sorry, forgot to add that it's both way. The "target" phone rings, but that is all.

Regards

Robin

OK an update here: the ISP made some changes, including authentication information, and now everything works.

Interestingly - and I don't know if this was significant or not - the UC320 codec was G711 and once the ISP knew this, the configuration change at their end reflected this (not G729), that's when it appeared to start working.

Thanks for the replies to my original post.

Regards

Robin