It is rather frustrating, as there are so many things in SIP that should work, and in practice they don't.
The latest was that we were using 302 redirects on registrations, and A, AAAA, and SRV records on DNS to steer SIP sessions and registrations to the currently active servers.
This mostly worked, but a few phones simply did not understand the 302 redirects on a register. So we created an alternative host name starting no302 for those as an exception. They would register pot-luck on any active server, and get an error if it was not currently active forcing them to re-check DNS.
Sadly we seem to have found a further stupidity where a phone does understand and follow the 302, but then will not accept calls from the IP of the target of the 302, only the IP it originally contacted. WTF?
So we have changed to not use 302s at all, except those same phones insist on registering on the previously advised temporary redirect now matter ho much we re-register, etc. Ended up power cycling the phones.
So we have :-
- Phones that do not follow 302 redirects at all
- Phones that do, but treat it as very permanent (until power cycle)
- Phones that cannot be redirected back to the configured host name
- Phones that hold DNS answers regardless of specified timeouts
At least we finally have a reasonably scalable solutions. Removing state from the call server means we can also do maintenance a lot more easily.
You seem to be trying to reimplement an SBC with an App Server bolted on the side of it. There are products out there that already do all of this and do it exceptionally well, you might want to take a look and see how they do it to give you ideas.
ReplyDeleteJust because there are other products does not mean we should not try.
DeleteThe solutions is pretty good, but it is frustrating that so many things do not work as they should. One of those protocols where ever trying to just follow the RFC simply does not work.
The result is a scalable VoIP platform on which we can base our services. The boxes are also designed to work stand-alone as a PABX.
Oh, indeed - I wasn't suggesting that you shouldn't merely that you seem to be trying to fix the same problems that have already been fixed and that you might want to take some inspiration from them.
DeleteOnce you're ready with it is be happy to have a look if you want some feedback.
While it is noble to go to all this effort, I would take the stern view that the phones do not talk SIP properly and so the owners of the faulty devices need to install the appropriate software (which may mean requesting a fix from the vendor).
ReplyDeleteI would, normally, agree, but in practice we cannot take an existing customer base, move them to a new design platform, and tell them "tough, contact phone supplier". We have to find ways to work for at least the majority of customers :-)
DeleteGrr, just had to retype this comment. I needed to submit it from a different Google account, so after submitting the comment then choosing to log in as another user, it did not post the comment or retaind the text. Anyway.
ReplyDeleteIt is noble to implement all these workarounds, however I would take the stern view that the affected devices are not SIP-compatible. The owners of the faulty devices should install an appropriate software image on the phones (which may mean requesting a fix from the vendor). It is no wonder that VOIP hasn't killed off POTS yet.
And people ask me why I use POTS and Skype instead of SIP! The answer is that they Just Work without any faffing or incompatibility problems. Can you imagine calling someone on a POTS phone and getting an "Incompatible" message, or no response for that reason?
ReplyDeleteCheers,
Howard