How to Implement Cisco Call Manager Express at Home, part five

Session Initiation Protocol

In 2020, as previously mentioned SIP is replacing most of the desktop phones. SIP stands for Session Initiation Protocol.  H323 or SIP is neither better or worse of standards, it only differs how the phones connect and disconnect calls. Cisco’s SCCP uses H323 standard, even though the protocol itself is proprietary. Your routers IP address handles the configuration (buttons and lines, sometimes for the user like backdrops and ring tones), the time clock (the time of day and day of the year), the signaling (the tones), and the transmission (the human conversation). SIP could do any of the four things and could be separate devices on separate networks.

The basis of the SIP “stack”/protocol/extension supports

  • Video chats
  • Audio calls (err the traditional telephony)
  • Instant Messaging (known as “texting”, “messaging” or “chat” if someone has been born after 1994
  • The basic SIP telephony stack supports essentially all standard 19 Custom Calling Features that the phone company used to provide separately, that many broadband phone companies provide for free or is included at a much lower price rate.
  • The protocol literally revolves around Caller ID. “Display Name” and “SIP Alias” is equivalent to the “station-id name” and “station-id number” in the FXO ports respectively  in the IOS configuration if you wanted to do ethical caller ID spoofing.)

As of mid 2020, the consumer equivalent or analogy  to SIP is Zoom, that actually uses some or most of the SIP standards; while Skype is similar in nature, the difference is Skype is proprietary. Also after the acquisition by Microsoft, they turned Skype’s signature P2P or Peer to Peer Protocol into a centralized protocol, basically Skinny for consumers and some businesses. (And a way for Microsoft to spy on their users…)

It’s a blessing because Any Brand Company (ABC) SIP phones that adhere to the SIP specifications could work, but may work better on an ABC softswitch, or ABC could produce it’s own SIP phones designed to work on any system (basically a glorified landline phone with an IP stack.) Likewise, Cisco, Avaya, Mitel, and others have added their own “stuff” in the SIP stack, albeit travels along the same pipe as SIP; mostly to replicate the traditional phone-system-type features that the standard SIP does not support.

Nerds behind the invention basically didn’t just think you could go to a Radio Shack and buy a $40 SIP phone to tie into your office’s VOIP network (in fact an Avaya executive in 2005 had made such prediction… just that Radio Shack closed, and SIP phones started to make their appearances in some consumer fronts after) that it could also go the other way around. You could turn a Cisco SIP phone into a modern day landline; or any other set, with some expert configuration, this is where “flexibility” of the stack is touted for.

The nerds felt SIP would be the future as they felt, phones, wouldn’t be around forever, and that apps would replace the hardware devices. Also the believers felt that telephony should adapt the web standards… because for an example when a user picks up a SIP phone and dials an extension or telephone number, what the backend does is it basically pulls up a URL that “resolves” a telephone number instead of a web page when using the omni bar.

Related to the CME:  for all intensive purposes, the rest will assume you’re using an IP connected phone that’s “standard” to that 2500-type telephone. The similar conventions of assigning a ol 2500 type set to a Voice Gateway should be the way think in this setup. Can you make your SIP set work more like a Skinny? This is where SIP gets a bit complex, you would have to go on the device side to make that possible.

As previously posted, the Cisco 7900s can do SIP, but it doesn’t gel well CME; but newer 8900, 9900 and 8800 and 7800s could work a bit better though unverified by me. 

At the lowest config level mode, you  want to enter the following commands (similar to telephony-service; you need to do this to get the SIP sets to work)

CORE1 (config)# voice register global

(config-voice-reg#) mode cme

 (config-voice-reg#) source-address 172.18.2.2 port 5060

Port 5060 is the default SIP port, ensure you have binded SIP as well as well as you did in H323

 (config-voice-reg#) max-dn 52

 (config-voice-reg#) max-pool 24

 (config-voice-reg#) timezone 21

21 answers to US Eastern Time, RTFM if you’re not on the East Coast!

(config-voice-reg#) ntp-server 172.18.1.2 mode multicast

Like with IP Phone (ephone) prompts; you want to do the same for the SIP phones, this time it’s called voice register dn. To create the first extension, use the following example in config mode

(config #)voice register dn  40

(voice-reg-dn#) session-server 1 

(voice-reg-dn#) number 200

(voice-reg-dn#) allow-watch

allow-watch means the BLF can monitor off/on hook statues.

To setup the physical telsets; instead of ephone, it’s called voice register pool (I know in Cisco’s DHCP “pool” means devices, perhaps this is why it’s called such.)

voice-register pool  1
 id mac 0000.0000.0000

 type P600

 number 1 dn 1

 username 200 password 6030000200

In this instance, I zero’d out the MAC address, supposedly the way the SIP sets authenticate, doesn’t need MAC addresses (that is from the H323 days), it doesn’t hurt. P600 is the defined model for Polycom’s IP 600 line, and the model I used was the SoundPoint IP VVX 310, and nothing had changed for a number of years, what could hurt?

If the SIP set isn’t exposed to the WAN or the wider Internet, there isn’t a real concern for strict passwords, I treat it as PIN. And for this instance; my VOIP network is not exposed; so PINs are OK, the example mimics ISDN, such as the full “phone number”. If there is WAN exposure, there should be firewall or proxy to begin with and using a proxy –  this is where on the server side, could have the random password, then for the user side (or user-agents) you could use a PIN, especially for cube hoppers.

The following is unrelated to Cisco: but if you subscribe to “cloud phone service” and your router/firewall is not used to proxy VOIP calls, to strongly take a second look; particularly in the Polycom installs. 

At this point you may need to at your SIP phone’s documentation on how the set should register into the Cisco. Most SIP-compliant phones should work, it’s at the unique model and vendor where things have to be specific. That’s outside the scope of this note. Things to look for is the “proxy” address should be IP of the router; the “register” address should be the same. NTP or the time server should be the same as well. The username and password should meet what is set up in voice register pool [tag #] In other systems, some of the settings in the dn and pool would be reversed (username would go along with the extension, rather than the hardware.)

*