SIP in higher education

[Steve Blair <>]

Just some thoughts.

-Steve

Abrams, Derek wrote:

> 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.
>  

While I see the point you are trying to make I'd like to add that our 
ViDe users don't use the
ViDe dialing plan. They found it cumbersome and yet another addressing 
scheme to remember.
Instead they contact the remote party and dial by IP address whenever 
possible.
Just an observation.

> My Phone Number: 541.713.3330
> My Campus Exten: 33330
> My E.164 Number: 33330 (dynamic IP)
> My Email Addres:  
> <mailto:>
>  
> 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.
>  

Very true. In our experience cross-over point seems to depend upon an 
individual's background.
If staff come from a telephony background they gravitate toward a phone 
and numeric keypad form of
addressing. If their background is data oriented they are perfectly 
happy using IP addresses, a name
from an address book or an email style of address. This is one reason 
why we have found this issue
challenging. Staff that use a soft client don't see it as a telephone 
and do not have the same service
expectations.

> 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.
>  

I think it is also an issue of momentum. I cannot help but wonder where 
we will be a few years
from now if a majority of users are sip.edu enabled. Will we have the 
"little old lady with a black
rotary phone" problem? If so at what role will her Service Provider play 
in gateway'ing between
the "12 digit" and sip.edu environments?

> 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.
Yes except the SIP address of record should fix this.

> 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".
Very good point. How do you deal with high-end user requirements today? 
If such requirements
demand additional infrastructure or services do you bundle that increase 
in price into the
service price?

> 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.
Interesting suggestions. Our take has been to buy SIP addressable boxes 
and build a modular
service. I hope "proprietary" requirements can be satisfied using this 
same approach, however,
so far we have not had such a requirement. We are still well below the 
power curve on our
deployment so our experience is probably just light reading for most people.

> 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 <http://oregonstate.edu/%7Eabramss>
>
>  

--
 
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104  


voice: 215-573-8396 

      215-746-8001

fax: 215-898-9348    

sip: