SIP in higher education

["Abrams, Derek" <>]

Title: Re: [sip.edu] Weekly SIP.edu Call Tomorrow - 8/11

Here's my view:

 

1) The groups prime directives are:

• Build a large base of SIP-reachable Internet2 users by making existing campus PBX, Centrex, and VoIP systems reachable via SIP.

• Facilitate the convergence of communications identities by promoting the use of email addresses for voice and multimedia communications.

While the SIP.edu prime directives provide a clear definition and support for a particular syntax, that syntax seems to limit the first prime directive of reability since not all devices use an email syntax nor is that syntax conducive or intuitive for all interactions and user interfaces. In our Video Network (granted very few are SIP-based) we use a numbering format that is conducive to the UI and the easier for the user - which is numbers.

 

My Phone Number: 541.713.3330

My Campus Exten: 33330

My E.164 Number: 33330 (dynamic IP)

My Email Addres:

 

My Polycom ISDN: 541.713.3347

My Polycom Extn: 33347

My E.164 Number: 33347 (dynamic IP)

My Polycom Email: none

 

Given the technology and the purpose (to facilitate communication) which is easier, which is available? We shorten some of these by using address books, Gatekeepers and LDAP servers - but ideally the best syntax depends on the mode of communication, the user and the UI.

 

Behind, intuitive "ease of use" is the infrastructure to carry it off, so where appropriate numbers ought to be used, or email addresses ought to be used.

 

2) In response to SIP by Numbers

 

While the first SIP.edu objective conflicts slightly with the second (reachability verses syntax restriction [i.e. email address] ) ideally what I am looking for is a resolution to the issue of IP Identity (IPID).

 

The goals of which are:

 

- Reachability - being able to connect to any telphony device including non-IP sets, via IP (presumably SIP).

 

- Basic Feature Set Support: callToStation,callFromStation, dropLastConnection, transferCallTo, conferenceWith, musicOnHold

 

Advanced Features might include:

 

- buttonActivation-awareness: Which button on the set was pressed, a differnet form of presence monitoring.

- LEDcontrol: Silent visual communication

- LEDsensing: Is the MWI, Speaker, or Mute light on?

- hookStatus: on/off (Could be used with logic of "IF hookStatus = X THEN")

 

So I am neither for or against the SIPxNumbers concept, it seems to me that it is really a matter of the interaction and the infrastrucutre required for that interaction. As the mode of interaction will dictate the required or preferred syntax.

 

For example, if numbers are easier then, I elect to use number, and while I really dislike 1-800-call4me (vanity numbers) they do make it easier to remember the number, though more difficult to dial.

Using "derek at location.x" is somewhat easier, sort of like "Derek of Loxley". The one issue with this type of routing is that there is no global registration point. So if I move, then my IP Identity changes. Then "derek at location.x" becomes "derek at location.z" even though I may still live in Loxley.

COST OF IP IDENTITY:

Seeing the success of Candace's Avaya deployment, for us was great. The price tag however, under the current options do not support scalability using a proprietary SIP-proxy. Using a TDM SIP-proxy like SER and others, might satisfy the basic goals of reachability and basic features, but they provide no growth for the advanced features, some of which are only available via a proprietary solution. We have 40K stations, and a 900K dial-plan (9 sites with 100K DP each), so the proprietary solutions end up in the millions. Most people ask at this point, but why would you want to enable all the endpoints? My answer is that I see the endpoints as part of the communication fabric rather than "just an endpoint".

IP IDENTITY INFRASTRUCTURE:

I think that there are several things requried to make IPID scalable, from provisional, administrative, progmatic (System-to-System(S2S) and Application-to-Application(A2A)integration) and economical perspectives, and I do not have all the answers, but here's what I think:

- SIP Proxy (Proprietary): To support proprietary PBX features for proprietary SIP endPts.
- SIP Proxy   (TDM-based): To support non-proprietary SIP endpoints and features.
- SIP Application Gateway: To support A2A and S2S interactions with the communication fabric.

SIP Trunking can be satisfied in multiple ways using either a proprietary or non-proprietary SIP Proxy solution depending on what you want to do with it. I prefer to make it part of the core system and use a proprietary solution for the core network, however for subscriber solutions where we are delivering a TDM circuit, the subscriber could certainly use any other solution depending on what they want to do.

 

Derek Abrams
541.713.3330
http://oregonstate.edu/~abramss