SIP telephony issues: suggested solutions? (e.g., Siproxd?)

Seems like interest in SIP telephony has waned over the past few years, I guess owing to the fact that everyone +dog has one or more cellphones with accompanying phone/data plan that doubles as their personal computing device. Me, I still haven't made my way fully into the cellular era--largely for economic reasons. And those reasons include the fact that SIP telephony is--at least for my circumstances--light years more economical than cellular service.

To be honest, SIP telephony has never worked for me anywhere near as reliably as POTS ever did, but I did manage to get it operational within acceptable limits some years ago. That's been the case until recently, after having put LEDE on my gateway/router (previously used DD-WRT for about 9 years, under which I had only occassional SIP telephony problems).

My latest iteration of SIP telephony, which worked acceptably under DD-WRT, involves a mobile phone with no cellular plan but with a SIP app (Csip-simple) installed and with wifi connectivity. It connects to my home network and is supposed to handle incoming and outgoing SIP calls. I would sometimes miss incoming calls under DD-WRT but under LEDE I'm missing a lot more. Even worse, though I rarely had problems dialing out under the DD-WRT router, now dialing out fails perhaps 30% of the time. I suppose it's worth mentioning that "dialing out" for me usually involves entering the number I'm calling into the google voice interface, which is then supposed to route the call to me (via the DID supplied by my SIP provider). So that actually probably qualifies as an incoming call. I should also mention that, apart from reading about the popular internet telephony utility asterisk, I have no experience with it and am not now considering it as an option for addressing my SIP telephony issues.

So, I'm looking for solutions. I've tried forwarding some port ranges, which hasn't made much of a difference. Additionally, I don't like the idea of forwarding such a large range of ports--sort of defeats the purpose of a firewall. And it's well known how vulnerable to hacking attempts Android phones are anyway. So I hope to find some other more effective and less insecure solution.

I've been reading up on Siproxd as a possible solution--a package available for LEDE/OpenWRT. I wanted to ask here on the forum whether any other LEDE users are using it and, if so, whether it's worked well for them? Also, if there are any other suggestions for addressing SIP issues under LEDE I'd be interested in learning about those. Thanks

Some Siproxd links: http://heavyjoost.ca/?p=66 https://www.dd-wrt.com/wiki/index.php/Siproxd https://www.linux.com/news/using-siproxd-allow-voip-through-firewall http://www.enterprisenetworkingplanet.com/unified_communications/VoIPowering-Your-Office-Siproxd-Trumps-NAT-3749196.htm http://siproxd.sourceforge.net/siproxd_guide/siproxd_guide.html

SIP is still extremely popular, but almost exclusively as a business service, not individuals. I think the reason is that it requires setting up your network with some sophistication to get it to work properly, and it's just not possible to do that at scale for individual consumers, also, most people's internet service just sucks, packet loss, latency, ISP controlled routers with SIP ALG, carrier grade NAT, etc etc and most consumers don't really have the slightest idea what an IP address is much less an ability to get into their ISP router and turn off problematic features.

I do use SIP for phones at my home and my small business. I have had to do a lot to get it to be reliable, and I have not been able to get it to be reliable for other family members who have DSL via ATT...

If you want reliable SIP service, what seems to work well is to have a dedicated box on the internet that provides a PBX, and to connect to that box over IPv6 thereby bypassing all the crap that ISPs are doing these days with carrier grade NAT and soforth.

I also find that Android phones via wifi seem to be relatively unreliable at picking up calls, they are too aggressive about wifi power saving and detecting "no internet" conditions and thereby disconnecting.

Finally, CSipSimple was abandoned about 3 or 4 years ago, and has not undergone any development since then. I switched to Bria and it's less than perfect, but is at least still in development.

I guess that also depends massively on your location, at least in germany all ISP are actively cancelling PSTN and ISDN contracts in favour of "all-ip" (at least Deutsche Telekom wants to discontinue ISDN/ PSTN completely[1] in 2018, so within the next few months). Unfortunately they usually push all-in-one routers with proprietary firmware for that, covering all aspects (including the necessary QoS) in one device (modem, router, pbx, analogue FXS ports, DECT), so there is little interest in free software handling SIP among 'normal' consumers.

[1] ISDN will vanish completely, existing contracts cacelled. All contracts bundling ISDN/ PSTN with ADSL or VDSL are force-migrated to all-ip (ADSL Annex J or VDSL, both migrating from BRAS to BGN/ NGN infrastructure and SIP). Pure PSTN contracts without any kind of xDSL will emulate PSTN by pushing SIP ATAs into the local DSLAM cabinet.

I guess I'd classify that under "business" since the end user doesn't configure a sip service it's all within the control of the Telecom co. Same thing is going on here, and typically the ISP equipment interferes with 3rd party services...

Thanks for the replies so far. I consider myself to have just enough technical acumen to manage a basic SIP set-up.

Like I said, I've had a fairly reliable working SIP set-up in my home for a few years now. I've always had problems with a certain, fairly low (maybe less than 10%?), percentage of calls being missed and going to voice mail instead of ringing my phone here in the home. Placing outgoing calls has been more reliable, though it could happen from time to time that I'd have one-way audio (either the caller or callee could hear the other, but not both). The most annoying part for me has been the lag that is noticeably present whenever I speak with someone who is using a cellular phone. When I speak with other users of my SIP provider, on the other hand, the experience is usually just as good as any PSTN connection ever was--actually much better than PSTN connections when it comes to international calls (which, in addition, are even free between users of the same SIP provider). My ISP is currently a cable provider, btw, and I have a fairly high tier of service. FIOS was recently introduced in my neighborhood and I may wind up trying it out.

In the past I'd used an ATA. More recently, I decided to go with a softphone app. I do know that development on Csipsimple has ceased and I tried recently to migrate to linphone because of that. Linphone was so inferior to Csipsimple that I wound up abandoning the former and going back to the latter. Despite it's being so long in the tooth, Csipsimple still performs far better than any other softphone app I've tried. But I have yet to take a look at Bria, which I'll check out now.

I take it what you're alluding to when you speak of a reliable SIP service using a PBX may involve something like setting up a VPS dedicated to running a PBX, correct? I do currently have a VPS that sees very limited load, so that could be an option: it's only real load currently is running an XMPP server that has only 2 clients connected. Setting up an asterisk pbx looks like a fairly daunting task, but it was something I had, a few years ago, been planning to do.

So, no input on Siproxd? I've seen posts on the openwrt forum discussing it. Should I take input offered to this point as insinuating that Siproxd is unlikely to resolve my issues?

I don't really know much about siproxd, it could help, but it might be just another point of failure. In my set-up I have opensips and asterisk running on a VPS and then my ATA + Bria inside my network.

I mostly do ok, but find that the android phone is the flakiest part, but this is in part because my android phone regularly bounces up and down on the wifi, and has been getting worse and worse that way, something about it thinking I have no internet connection when I actually do. It's android specific as all other devices on my network are fine. Possibly a new phone would eliminate those problems as I think my wife's phone is better in this respect.

My impression is siproxd is a lightweight proxy specifically for dealing with NAT issues, so running it on your router might help, but then, how well will your softphone work when it's not on your home wifi? For me that's a non-starter as I need it to work on cell data as well as wifi as well as wifi at other locations...

I've actually got 3 cellular phones that all have a SIP client installed, but only 2 of which have a cellular plan. Those 2 are prepaid phones & travel with the wife and I--their cellular service being reserved for emergency calling/texting (they see sufficiently limited use such that we're only spending about $5/yr. on cellular service for each). The 3rd phone has no cellular service and stays at home, and that's the one with which I do the bulk of my SIP telephony.

The other 2 can, while traveling and if a wifi connection is present, make SIP calls as well. So while using Siproxyd is unlikely to cause me any issues with the stay-at-home phone, it would pose problems, should I ever want to dial using one of the "travel phones," a SIP call while at home. In that case, I'd need to go into settings on the travel phone(s) app and enable the proxy, then disable it again after placing the call. Something to take into account.

PS I tried to set up the K9Mail app on my home SIP phone so as to receive, when I get an SMS via google voice, an alert from the phone. But I discovered that the app was getting put to sleep no matter what I tried (I don't care about battery usage on this phone since it is almost always sitting right next to a charger). Further sleuthing turned up some discussion on the K9 mailing list about some recent changes to Android 7 that were overriding the application's attempts to stay awake. Could those sorts of changes be likewise affecting your phone's wifi/SIP connectivity? Are Android versions on your 2 phones the same? Just a thought.

my phone is android 6.0 my wife's is a year or so newer, probably 7.something mine is the one with the issues staying connected to wifi.

in general I have been unimpressed with android phones, they are consumer level crap because consumers don't care about things like running sip phones and working in an ipv6 only network or the like. They compete on pixels and battery life, and exist to make google rich with spying data, not as computers that consumers control with correctly working software or security or features.

:frowning:

I'm using a cisco phone at home and never had a missed call or a callout failure, must be something with the phone app or standby wifi, can you test if the app is on a computer it fails ?

I take it you mean to say that, despite not having done any special configuration on your LEDE-flashed router, and without adding any sort of SIP-oriented packages onto it, you nonetheless have had none of the internet telephony problems discussed thus far in this thread? I've had at least minor problems with every SIP configuration I've ever tried over the last 8 or 9 years, and the problems have persisted under various router firmwares and varying softphones and hardware (as mentioned above, my SIP telephony career has also involved use of an ATA rather than a softphone). The problems have worsened a bit now under a stock LEDE install. All I can say on the basis of what has been said thus far is that your experience with SIP telephony has been quite different from mine.

I'm using, only for testing an ATA for fax and didn't had any problems, and fax machines are very very picky about network. my provider is using fiber to the home, you could try some qos profile on the router, but after that, all depend on the ISP, delay, jitter, etc

@wayover13 generally speaking you need to look at the server logs to figure out why you're missing the calls.

Last I've looked at them, neither of the free SIP apps for Android worked well with the versions of Android newer than Lollipop. Also, with more drastic battery saving features introduced in the newer versions of Android things might only get worse for the apps which don't support PUSH notifications.

If you have no access to the server logs, I would try:

  1. Native Android SIP client rather than the 3rd party client without PUSH support.
  2. A SIP client with the PUSH support (you should be aware tho, that your SIP credentials will be sent to a 3rd party server), like something from Acrobits.
  3. A proprietary solution like 3cx server/client combo.

Like others said, specifics of your internet connection matter. Double-NAT used to be a known SIP-killer, but other things can make SIP unreliable as well.

Sorry i have not experimence with siproxd too, but i think it is not a security solution.
As i understand an outproxy is normaly used for overcome NAT, it makes the "SIP-Server" if you can not open a port on your Router.
For this reason it is required that the proxy are inside the Internet.

Normally is it not required because all SIP Provider that i have seen have and Outproxy for the people behind the CGNAT.
I think it makes sense only, if you want to give other people which behind a NAT, SIP access.
For example if you want to phone without a provider and you or friends want to call each other by knowing the IP (DDNS) and if one of them are behind a CGNAT,
then make siproxd sense.
But i have not understand how is RTP opened? STUN ?
But i know that it work in generall (tested with asterisk behind a NAT)

The other Problems: Do not hear only on side or do not hear any voice but ringing or voice like a Mickymouse.
Is normally the result of lack/wrong of prioritization and or not working code.

I at the moment solved 99 % of all my problems with the konsequent use of G.711 (alaw and ulaw).
The other reason is why it works very stable by me, is a relativ fast Internet connection (100/20 Mbit/s) and less data use of them.
And of cource each kind of Radio connection make it less stable.

####################################################################################
OT:
I am a great fan of old (from before 1990) rotary phones, because they do what they should do, they are relativ cheap (if you buy them as untestet basement found),
the Technik a very simple, they are extrem durable, they looks fine and the best the circuit a so that noone can hack them and hearing inside the room because it have a mechanical switch that prevent them.
(the last point does not apply to phones from later 70er and 80er from DDR)

Of course i know that the modern VoIP degrade this phones to an microphone/speaker and keyboard or better frontend.
And these frontend is nothing without a good ATA, but these ATAs exist with LEDE. The most Router with LEDE support and lantiq / xx200 or lantiq / xway chipsets + FXS ports are very good ATAs
And this is actually a total understatement, because it works with Asterisk and give so much possibilities for Telephon, LEDE give so much possibilities for Networking, and the next best:
these Router in many countrys extrem cheap (my 8 EUR (3 EUR + 5 EUR transport)) because they are OEM Router from a provider, with scary original firmware.
And last but not least they works very well with old Rotary phones becauce the pulse times are tollerant, you can regular some voice parameter (volume echo supression etc.) and important you can change the interdigit time.
These Routers are a (ATAs) are VERY VERY GREAT solution !!!:smiley:
And i want to say big thanks to all developer that make this device working and special thanks too Stefan Koch they make the Asterisk channel lantiq working for LEDE.
And thanks too for Quallenauge and the others they makes the Vodafon Easybox 904xDSL working (i think the only router with an display).
And thanks to Arcadyan they produce great Router with a nice small detail: they have pins for the serial connections, it can be used without soldering.

The disadvantage of the whole it is very complex and error-prone, so that i am glad that the telephones works now stable, but without extras.

While not quite on topic for this thread, I'm pretty curious how the ringtone of your rotary phones attached to a modern pbx/ SIP ATA works for you?

So far I haven't gotten the electromagnetic ringers (FeTAp 611, FeTAp 792) to work at full volume nor their original sound with any (consumer) digital (ISDN or SIP) pbx/ ATA (that includes ISDN pbx solutions from AVM or Eumex/ Funkwerk, just like lantiq based routers with SIP/ pbx functionality (AVM, O2 box 6431 with LEDE/ asterisk)). The cause of this is rather obvious, given that those electromagnetic ringers were made for 60-90 V at 25 Hz, while pretty much all digital products only provide 12-24 V at 50 Hz for the ringer.

Post deleted. I realized later I had unplugged the phone from the second SIP device, so of course it wasn't ringing or giving me a dial tone! I need a breath of fresh air or something, sheesh.

Will post further as to whether further port forwarding tweaks will have addressed the issues described above.

@wayover13
Have you try to use outproxy of your provider and do you use STUN service ?

##########################################################################
OT:
I hear the Originalsound from a trunk 2005 last time.

I think in this modern time upconverter are no problem.
I am not 100% shure but i think the Lantiq SLIC have 25Hz and 40V. And i think 40V are normal too for PBX in past. I can not measuring the AC voltage but:
I remember on LEDE menuconfig in past (2016) you can choice between 25Hz 40V and 20Hz 45V or so.
The Open circuit voltage on O2Box 6431 is 40V on Easybox 803 is 45V.
The Open circuit voltage on a PBX from 1952 is 38V. But the Frequenz and voltage are not the only thing it is important how much power i get from the PBX.
My personal impression too equal modern Router with early PBX is: FeTAp's are equal, W28 minimal quieter, W48 quieter and a littlebit borderline but works for me.

I am interesting if is possible to get more power on the code of drv_tapi-4.7.3.6 you can find lines like:
in drv_tapi_io.h

/** Read out the analog line battery voltage configuration. This configuration
    can be set by BBD coefficient download or
    by \ref IFX_TAPI_LINE_BATTERY_VOLTAGE_SET. Note that this command returns a
    given configuration instead of any measured value.
    This command applies to ALM modules.

   \param IFX_TAPI_LINE_BATTERY_VOLTAGE_t* Pointer to an \ref IFX_TAPI_LINE_BATTERY_VOLTAGE_t structure.

   \return Returns the following values:
      - IFX_SUCCESS: if successful
      - IFX_ERROR: in case of an error
*/
#define IFX_TAPI_LINE_BATTERY_VOLTAGE_GET    _IOWR (IFX_TAPI_IOC_MAGIC, IFX_TAPI_LINE_BATTERY_VOLTAGE_GET_IDX, IFX_TAPI_LINE_BATTERY_VOLTAGE_t)

/** Set the current battery voltage of the analog line.
   The voltage can be read out by \ref IFX_TAPI_LINE_BATTERY_VOLTAGE_GET.
   This command applies to ALM modules.

   \param IFX_TAPI_LINE_BATTERY_VOLTAGE_t* Pointer to an \ref IFX_TAPI_LINE_BATTERY_VOLTAGE_t structure.

   \return Returns the following values:
      - IFX_SUCCESS: if successful
      - IFX_ERROR: in case of an error
*/
#define IFX_TAPI_LINE_BATTERY_VOLTAGE_SET    _IOW  (IFX_TAPI_IOC_MAGIC, IFX_TAPI_LINE_BATTERY_VOLTAGE_SET_IDX, IFX_TAPI_LINE_BATTERY_VOLTAGE_t)

/*@}*/ /* TAPI_INTERFACE_CONTMEASUREMENT */

If you're still considering dipping your toes into asterisk, please take a look at the Freeswitch-stable package instead. I've been running problem free on a Raspberry Pi 2 for awhile now.

Big thanks to the maintainers of the package! I really hope some binary packages make it into the 18.03/04 release.

freeswitch is definitely how I would go if I were setting up a new system. I've got a running asterisk and haven't gotten around to writing freeswitch config files to do similar stuff to what I've got asterisk doing, but every fiber of my being says "asterisk is a horrible hack and freeswitch was written by an actual software architect"

I've had endless annoyances from asterisk.