SIP Experiences

Today’s writings is the memories I’ve forgotten without regrets (or whatever party animal line is) about personal runins with the Session Initiation Protocol better known as SIP.

These runins were not done when I was drunk, nor were these done professionally, and if I had a LAN party related to telephony maybe these stories would be more funny.

Anyways, I felt it was important to discuss SIP and any caveats made by amateurs. Let’s discuss them one by one

  • SIP is an Internet port on 5060 (secure SIP on 5061.) An Internet port is basically a coded valve to open or close piping in a cyber world.
  • To access a SIP server, typically in most cases a telephone (basically a PC that appears to be a telephone) “phones home” to for an example ( for secure setups.) It’s best SIP talks to domains so another example is CW-PRO1.CLICKFORD.NET:5060 or CW-PRO1.CLICKFORD.NET:5061 in secure setups.
  • It’s purpose was originally to provide instant messaging, video and voice secure or insecure over an IP network, whether its private or public.

    An Avaya 4602 which outside of Avaya's SIP Enablement Services (now as Session Manager) is basically TRoIP. You get 2 call appearances as typically expected, but configuring buttons or adding feature rich things may be a crapshoot for non SES systems.

    An Avaya 4602 which outside of Avaya’s SIP Enablement Services (now as Session Manager) is basically TRoIP. You get 2 call appearances as typically expected, but configuring buttons or adding feature rich things may be a crapshoot for non SES systems.

  • Like an app, it’s a bite-sized equivalent to a “fat client” application on the PC; SIP is telephony’s version of apps or appetizers – just in this case thing of it as smaller drinks – if you get the acronym.
  • Apple’s iChat, Microsoft’s Messenger in Windows XP and other clients had supported the IM/video side of SIP for years.
  • Telephony manufacturers started to be warm of SIP once the technology matured and by about 2006 most manufacturers  had supported SIP as a dual boot option including proprietary protocols
  • Basic support of SIP in the telephony sense is basically the POTS in the VOIP space.  On basic SIP systems like the Asterisk family SIP is basically  tip-and-ring over IP or TRoIP*. Why? Because a lot of the Ciscos, Mitels and Avayas of the world give users basic telephony features, proprietary features or “stuff” may carry over these alleged “open” protocols if you have a proprietary “session” server.
  • TRoIP is basically a plain ol telephone capable of a couple extra line appearances, and some basic things like call appearances, message waiting and possibly rollover appearances/call waiting and can be connected to any SIP network.
  • SIP identities similar to emails. The user login is not the extension in most setups, but something similar to an email address. Behind the scenes when a digit number is placed, it redirects it to a SIP address.
  • While proprietary protocols are slowly eroding, the it’s on the server side whether your phone will be TRoIP or feature rich. I guess this would be easier to provision instead of switching protocols to do whatever is in the needs of customers.
  • Despite its application centric protocol; one needs to know networking and telephony – you can’t just be an app guy.
  • SIP can have a lot of downsides if a) you still have a flakey DNS environment – static IP can work, but many would say DNS is

    A Mitel IP 5330 IP set using the MiNet protocol. When flipped over to SIP it could do things like show dual LED colors whereas MiNet couldn’t.

    better; b)  SIP needs on the technical side be treated as if its a web server. Lot of web-terminology is applied into SIP; c) make sure you have a consistent deployment plan and deployment schedules. These phones work much differently than traditional IP sets, and if you’re in a TROIP setup, these sets are even worse to configure.

  • Another problem with SIP is how a user will get a dial tone even if its not “registered” to the system. This has been consistent across all of the 3 major vendors I’ve used. If its not “registered” typically sets will alert you but if you take the handset off hook, you will most likely get a “dial tone” regardless. This is just noise to give the customers an illusion it’s working as if it was a landline telephone. (Like the senior citizen friendly cell phones?)
  • This may give users like senior citizen a false sense of security if the phone is not properly routing to a landline gateway to dial emergency if the main system goes down.)

UPDATE: This was based on using Mitel SIP sets. It turns out I had the timeouts maxed out. If you lower it to under a minute, it will loose it’s connection. (September 2016)

  • Bootup times may be slower on SIP as it has to load the application that runs on such sets. SIP is basically the operating system to the phone, or maybe the “file shell” if you think quickly from an engineer sense. Proprietary sets always retrieves new files over the LAN (or WAN if you’re remotely located) and the applications and operating system always lives in the phone system. (Think of this as “thin clients” that run “images” from a management system in secure PC setups, like retail.)

About SIP and servers

  • SIP should really be rebranded as TRoIP because in order to build a healthy system one has to actually go back to those dreaded days of the electromechanical X-Y or Step by Step switching. You don’t believe me? Despite SIP’s latte sized bandwidth, when SIP is measured in computing, it may or may not function well.
  • Electomechnical switching in processing telephone calls was measured in how many SXS switches were in a central office. If you had 500, well only 500 calls could be handled concurrently. The ESS switching systems of the 90s spoiled us with the 10,000 BCCH (Busy Completed Calls an Hour) metric. SIP made the users go a step backwards.
  • SIP should be running on virtual machines or dedicated servers handling SIP traffic. SIP works best if it’s setup to be x/number of “concurrent telephone calls”. (like XY or SXS switching)
  • Some SIP setups will dial and process calls over the server and then handoff when the call is answered or in some setups the server is taking control of the entire call (again in my runins.) Depending on what systems you use like TRoIP based Asterisk (not a feature rich system) or a feature rich system like a proprietary system, placing and receiving SIP calls may differ.
  • Some SIP servers are really bad in the resource department, some are better. The best way to know is in voicemail and if your greeting is garbled up. If it’s garbled, add some more RAM – chances are the computer doesn’t have enough resources to “buffer” the data since on the server side it isn’t “traffic” like jitters on a network not designed for both voice and data.
  • SIP is a pretty cool technology, and it doesn’t need to be a progressive, cutting edge, solution evangelized by that Prokop guy I’ve written up in the past. WebRTC is far from a secure standard and will take time just as SIP is now becoming standard for “mum and pop shops.” SIP can be used for voicemail services in legacy VOIP environments; SIP can be used to handle VOIP calls if say you still use a legacy phone system. You can convert SIP to analog or TDM lines and keep the system. One other thing I’ve simulated was the idea of using SIP accounts (also known as extensions) for those people that so want a softphone but still have a TDM set on their desktops in the way of having an internet based SIP account then replicate it through a local SIP gateway that in turn can be routed as a DID like extension. I haven’t practiced this personally, but I’ve heard this can be a possibility when all ducks are in the row – since Personal Computing doesn’t have that same ring of reliability unlike closed, hardwired PBX or CO switching systems.

My analogies of SIP is like a PC, it’s a great technology. It’s like “I wanna have a computer on my desk but I dunno what I really want out of it”. As the 1990s came along, these little things became a nightmare for network administrators. Not only that but PCs had too much power for what many people didn’t need. What I am talking about is enterprises not consumers.

SIP is in fact can be very much like a PC.

In my first installment, I referred that SIP is much like a PBX at your desk. Unlike digital telephones, SIP can be setup to extend the PBX OR make “PBX” the dumb device. In the latter setup some would see this as the phones using peer to peer, point to point, etc.; that if a call is placed on a SIP telset to another SIP set, then the communication is between the two devices once someone answers.

The only great thing is how “open” the phones are. Well it depends on what type of SIP phone you have. If you use Avaya or Cisco it’s much a TROIP set, but Avaya, Mitel, Polycom and Cisco’s SPA series sets are easier than a Selius/7900 series sets. So don’t expect to get these sets as “SIP” and realize the several hundred features to not show up on the set and insist it will work hunkey dorie on an open source telephony server. I don’t blame them. They have to make money somehow. But regardless, if you buy a session server, any set could theoretically replicate features like Send All Calls on a Cisco set if it’s tied up to an Avaya Aura Session Manager.

SIP can be in fact inferior to H323 from my runins. H323 is an open standard to carry proprietary protocols over the open IP network. All major vendors did this until SIP got its act together a decade ago, while the protocol itself celebrates it’s 20th anniversary this year. H323 mimicked all the traditional PBX features, such as if the phone not phoning home it won’t work. SIP is extremely skeptical protocol as many sets require not only set authentication but user authentication. It’s not just PINs but handles too SIP runs slower than H323 as the “applications” for an IP phone is loaded at the set level, H323 mimics the dummy terminal/mainframe approach (if you are a phone person, you know this is the traditional PBX mindset) where the app travels through the wire, which means the set can take calls immediately with lesser bootup times. I think it’s safe to say SIP is a resource hog to hardware sets especially if SIP was designed to be secondary protocol and not a primary protocol. If you own older Avaya, Mitel, Cisco or Nortel, etc., it’s one of those “just because it can, doesn’t mean you should run it”

More annoyingly is setting up dialing plans and making sure that every set is setup to dial out properly. Kids, this is what you signed up for by supporting “open” standards. You can “open” yourselves to trouble. H323 automatically provides this information as it lives in it’s “brain”, the PBX, the Key system, or what have you. If you have sets over four hundred, imagine the labor to make sure it all gets the right information, especially if you do the open source way. Automation is a hit or miss, just like how someone can improperly set up a Group Policy Object to PCs.

SIP does have it’s pluses, I hope I gave you an objective side showing it’s weaknesses. Just like a decade ago; when the transition from TDM to VOIP occurred – H323 to SIP is the rage today. I feel comparing SIP to PCs and H323 to VT terminals is the best analogy.

My dealings with SIP is, please know what the hell you’re doing before you make the big cutova’. Just like buying an IBM (or a Cisco), you won’t get fired, just some people will hate you instead.🙂

*Registered Trademark of S Clickford in the virtual world of Miniland hahaha! I can’t help to resist sarcasm.