Moving-on: Recommendations for a simply-installed (on-premise) and configured SIP Proxy/Server

Greetings,

Reviewing #billsimon’s guidance to the OP, #grosen in point of Cisco DX-80 and SIP URI Dialing issue cisco-dx-80-and-sip-uri-dialing-issue/72362/7:

The issue is that any calls that FreePBX receives are going to be processed
by its routing rules/dial plan… you will need to use a server that can route a
SIP URI as-is without processing it like a PBX.
Another way would be to set up an open-source SIP proxy like opensips,
which is a true proxy and not a PBX.

Today, needs are for a SIP proxy/server with impeccable registration robustness, TLS support and videocalling assumption than a telephony PBX. (PSTN and dialplans is well down the list).

ObCisco: I’ve found their TelePresence CODECs handle SIP URI dialling better un-registered, If going to register to one’s own SIP (for inbound call handling and other benefits), it had better offer impeccable registration robustness, TLS support and assume video-by-default.

TTBOMK, the usual-suspect SIP servers are not packaged for easy install and configuration like FreePBX and likely that one would need to engage consultants rather than thinking one can get going by relying on community support.

So my question: Given 2024 needs and without going-down the custom route which SIP proxy/server should I be looking at? Or, if SIP proxying (to the Internet using DNS-NAPTR etc.) is the primary need and not PSTN, should I be thinking more in terms of dispense with an on-premise SIP proxyserver/PBX and use SBC upper registration (with all external SIP accounts maintained on the SBC and SIP endpoints registered via a single account on the endpoint to the SBC)?

Choosing a SBC (standalone on-premise, software on-premise, SaaS) is no-less uncomplicated. At least my experience is that the feature list is similarly backward-looking to telephony and associated transcoding, and MS Teams stuff useful before the advent of CVI etc.).

Look forward to reading your take!

Thanks

I suggest you look at kamailio, if you want an easy gooey, add DSipRouter.

1 Like

Thanks #dicko, appreciated, and will investigate both.

Given my observation that anything that proxy’s for the DX likely makes interoperability worse, I wondered what you thought of having fewer things between the “phones” and the outside world and so accomplishing it all with just the (off-the-shelf) SBC.

K/R

Thanks #dicko, good recommendations. Tried the dsiprouter demo and had expected more (didn’t see much there there) – likely unfair as I had only skimmed the documentation.

I’d have more confidence if the various gifted free SIP proxy/servers had impeccable registration robustness and yielded universal interoperability. The gifted free servers (run by experts) don’t manage it, so a little hesitant to jump on-board. As oxymoronic as it sounds, with the yardstick for comparison wotsapp-like “inter-operability”, seems there might be a fair number of risks and complexities that might not become apparent before one has put one’s hand in one’s pocket and spent quite a bit.

About as robust as it gets and building a cluster of them for redundancy quite easy, (SIP is more than just phone calls) , price is also right

About Kamailio – The Open Source SIP Server Project | The Kamailio SIP Server Project.

If you don’t like RTFM

Thanks, but no, I had previously seen and priced-in the 1-day training.

Re easy to use GUI, I did come across SIREMIS the screenshots of which looked more promising.

Don’t doubt stability and ruggedness. However, I do see flashing line keys from time to time on various SIP accounts. So my reference to robustness was solely in relation to registration.

Clustering, load balancing, fail-over etc. are hygiene factors – not order-winning ones if the usp is five nines interoperability. Maybe I’ve just been unlucky. Those services, run by experts, paid and commercial, don’t give me confidence that ubiquitous heterogenous interoperability is there out of the box or at least realistically within grasp. Freely admit to saying this without any evidence, but I get the impression they’ll take your money then tell you it’s hard to achieve.

There’s always Cisco, they are ‘unified’ :wink:

Nice company, but their product set is perplexing with names that don’t tell you what the thing is.

Start here

But reading TFM’s is well over 20000 pages, they have sales engineers in suits for interpreting them

How big of a deployment of DX80s do you have? I am puzzled by the desire to use expensive Cisco endpoints but not also invest in the core.

Sorry if I misled you Bill. This has nothing specifically to do with the DX – they’re just another SIP phone with a large screen, like the HiHi, if only a little less proprietary…

Dicko didn’t contradict my impression that getting a SIP proxy/server to initiate calls between videophones beyond one’s own domain is a hit-and-miss affair and even commercial/free services run by the experts struggle to overcome the complexities: There’s a strong whiff of “buyer beware”. I’d like to start modestly but seems like there’s a “quantum leap” between the knowledge required to get FreePBX installed and up running and getting a SIP proxy/server installed and up and running if the need is primarily SIP proxying for videocalls rather than PBX.

Thanks.

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.