SIP in higher education

[Renee Shuey <>]

Hi Steve,

I think you have it.  I was just thinking that we all have instances 
where we need to create guest accounts to provide internet access to 
those outside of our university community.  I was only thinking in terms 
of the SIP services at this point in time.  Shared resources is another 
good place to begin developing use cases.  It really is a matter of 
authenticating locally and then "federating" the identity so others can 
make access control decisions regarding their resources.  Again, it 
seems that integrating the SIP authentication with your enterprise authN 
system is the most important place to start.

Renee'

Steve Blair wrote:

>    I'm not sure I follow. What services would you access as a guest?
> Do you mean services offered to subscribers of Hawaii's SIP proxy
> server? If so I could see why that might be useful if Hawaii's server
> provided something that was not offered or was inaccessible via
> Penn State's proxy from your current location.
>
>    I'm not well versed on the "federating" concept but if  access to
> and agreement to offer shared resources fall into this concept then
> perhaps that is the place to address this issue.
>
> -Steve
>
> Renee Shuey wrote:
>
> > Wouldn't it be cool if when I visited Penn (or better yet Hawaii) I 
> > could logon to your network authenticating against my Penn State 
> > security server (not UPenn) and then be "authorized" as a guest to 
> > have access to certain services such as these.  Maybe this falls 
> > under the use cases for "federating" identity for sip.
> > just thinking......
> > Renee'
> >
> > Steve Blair wrote:
> >
> > > Yul:
> > >
> > >  I've tried a number of approaches. I'm not sure if Penn has settled
> > > on one method yet. Our proxy currently requires anyone who
> > > registers to authenticate, registered users must be in a specific
> > > group to use the PSTN and our PSTN gateway has ACLs to limit
> > > access on the LAN side. We also log the remote domain name for
> > > inbound IP calls. We don't do any other "filtering" on IP calls.
> > >
> > > -Steve
> > >
> > > Yul Pyun wrote:
> > >
> > > > I'm interested in finding out what other campuses are doing or what 
> > > > your thoughts are in regards to UA registration and authentication.
> > > >  
> > > > It seems to me that there are at least two distinct functions when 
> > > > it comes to authentication: 1) processing registration, and 2) 
> > > > processing INVITES.
> > > >  
> > > > My thoughts are that:
> > > > 1) You want to authenticate those UAs that belong to your domain 
> > > > when they register, regardless of where they are registering from, 
> > > > and deny registration of all other UAs.  If you don't authenticate, 
> > > > then potentially anyone can register with your Registrar, and 
> > > > basically spoof the calls as if they are part of your 
> > > > organization.  I'd rather not be in the business of providing 
> > > > registration/proxy services to the entire net.
> > > >  
> > > > 2) You want to be able to receive calls (INVITES) from anyone on 
> > > > the net, or perhaps narrow it down by use of ACL.  Analogy would be 
> > > > my pbx phone...anyone in the world can call me if they my number.
> > > >  
> > > > Thoughts/comments?
> > > >  
> > > > -Yul
> > > > ----------------------------------------------------
> > > > Yul Pyun, 
> > > >
> > > >  
> > > > <mailto:>
> > > > University of Hawaii