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?
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?
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.
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.
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)?
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.
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.