Session Initiation Protocol – The Secrets, part two

Clickford, Steven M.

For the end user level, SIP telephones can do cool stuff that couldn’t be done on “office phones” prior to.

One for the first time since ISDN, office grade sets can interconnect without the expense of a large PBX  system. Some can work in Peer to Peer fashion.  BUT, don’t believe in this entirely just yet.

They work in basic modes when it’s off the H323 network, if the Avayas, the Mitels and the Ciscos have “dual modes”. You have to toggle this in it’s basic configuration.

Again H323 is an open Internet Standard for handling the traditional, but proprietary  hardwired telephone systems over the IP stack, or drivers or something that can allow these devices to talk to each other on an Ethernet network. One of the reasons is that SIP has standard messages to troubleshoot similar the Error 404 on a web browser when a page can’t be found because reading an error message  from a Mitel or an Avaya may be more accurate if you make the time to read a 200page error documentation that’s more effective.

In short, if anyone older than 30 remember “dumb terminals”, H323 was the equivalent to that, while  SIP is more like PCs, mobile, less manageable if management tools are scarce.

Because SIP can be interoperable between different vendors; this can cause issues if you are in a serious production environment. Many of the diehard SIP phone manufactures, Snom, Polycom and Mitel (visavis Aastra) have apps for management machines to standardize the “config files”. For SIP phones, config files are the telephony equivalent to those ol BATCH files in the PC world. For hard phones, it’s more complex, because the SIP phone and telephone number and user information is often hard coded to that device, which this “mobility” would be a theory.

Traditional Office VOIP Phones on SIP networks?

Before I start, I want to share a YouTube video of this experience I found online

https://www.youtube.com/watch?v=nZvo7n128Vg

This is called officially an 8434DX Voice Terminal. People say a “voice terminal” was to seperate a “data terminal” by AT&T marketing, but I also describe why the word “telephone” should not be used formally when referring to these devices. They are essentially a large electronic device that connects to the “brain” or control unit to then “extend” the telephony features and calls, and everything  else. According to the eyes of the FCC, the PBX or Key systems are really the “telephone” when it connects to the outside world, governed by the Part 68 rules. So essentially a site with 2,000 stations only has one or several “telephones” that look like “computers” that are connecting that enterprise to the world. This is one of the reasons why I use “telset” so liberally, short for a “telephone set”, take out phone and the wording is very accurate.

Looking in the mind of scale and perspective is key. But SIP is truly infinite in theory.

Now I’ve mentioned early on with the Avaya, Cisco and Mitel. Sets made after the early 2000s can run SIP just fine. But these act as simple POTS phones perhaps with some multi line abilities. Here is the catches

  • Most devices such as extension selectors, DSS, adjuncts such as analog adaptors will most likely not work on SIP. In fact these drivers work exclusively in their native proprietary systems, tied at that “brain”, “control unit” part
  • Some sets like the ol Nortel/Avaya Blue, and Cisco have been reversed engineered by the open source community to retain the H323 compatibility so you can use additional modules, etc. Avaya is hated by the world because they are just plain bad and sucky and given their simplicity, they should be damned.
  • If you do want to look very professional, just follow this idea. Keep it Simple. Don’t get a large screen, do not get a large set with multiple buttons. In the PBX/SIP sets, the buttons cannot be programmed.  Those empty keys are pretty useless. Mitels are a bit better, you can program speed dial keys so you could make the phones more functional.
  • Feature keys are not often supported (so remember those star-6-9 like services, because Feature Access Codes will be required in these setups)
  • Remember this: Any color or GUI set that requires some Java app to function, I would recommend to avoid. The color GUIs tend to lean to a H323 bias.
  • There is one little catch: All major vendors have moved to SIP  for the most part, however programming features, paging, and even addons can work, only IF the server on the far end has some extra magic in the SIP packets. Some vendors use the “open” app to put in closed features, to make that H323 look like an H323 set, but due some differences in the deployment model the phone will work like a traditional office phone. However, it is very software dependent in the data center for that ability, with additional virtual or physical appliances need to do so.
  • Remember, SIP is open, but with many catches.

It’s perfectly OK to say that you want to have a SIP phone that’s used in enterprise setups for basic phone  at home, just be responsible and understand it’s functioning  more to an analog house phone without the worries of high voltage electricity to power and make it function.

Peer to Peer SIP

There has been a movement to go support Peer to Peer SIP telephony. Avaya and Aastra did this years ago, however to reproduce it for me was a bit complicated last winter. Some vendors work better, some don’t. Because SIP is very Caller ID based in the nature, in theory for P2P to work properly, the SIP Proxy has to be clear and no register information. For inbound calls to work, assumably and FXO, one idea I had played with was to fuse a Grandstream FXO gateway to ring as an FXS extension and program a line for it to ring as if that FXS extensions was a bridged line appearance. But for that to work properly, the FXO gateway had to register somewhere.

This would be ideal for the home to have that multi line, intercom, and really basic telephone handling; and this practice if was exposed to the outside world would be caller ID spoofing because there is no authentication.

It’s not to say it can, just it requires time on your hands.

Hybrid SIP…will it be a thing?

In the transition of IP Telephony (early 2000s) the goal was to replace 2 or 4 wire proprietary sets to IP, and all it was in the H323 world was moving that 2 wire virtually in the H323 methodology I had explained throughout. Hybrid IP systems enabled users to have 2 wire sets and IP sets together and work seamlessly, except that the network had to be stable for the IP sets to work properly. 2 wire sets still exist in many locations where IP may not be ready for primetime ether by wiring or the network infrastructure.

VOIP was and is very common to connect to remote sites. Still is with SIP. Now with all these silly features like Salesforce and other social interaction apps mixing with telephony, could you theoretically have your traditional hardwired, to the PBX 2 wire telephone be able to communicate modernly? Sure, in the 2010s, the move from IP Telephony moved to Unified Communications to eliminate that theoretical issue of H323’s lack of transparent connectivity across systems. But given SIP being an app, that’s not to say a user can have a softphone and still have ability to communicate with their 2 wire phone or an H323 phone. If you understand the specific non voice app, understand the domain, login/LDAP and the  SIP networking, this would be a great addition instead being Mr. Cost Cutter and replace fine functioning phones with more expensive (per telset that is) and less functioning telephones that barely do just that 80% of the time.

There is so much e-waste as time goes along due to the political differences between warm phone guys and gals and anti social sysadmins in the IT department. It is what it is.

*