Driftwood

Items discussed:

Core topology with redundant, private-IP machines, both of which are behind
the SBC. SIP service psu.edu points to the SBC (firewall).

A plan for a second SBC to provide failover in the event of a single
firewall failure.

Phase 1 is PSU IB-wide,
userID to userID and all users will expect service continuity
when compared to UP. Or do we strictly adhere to the written Phase 1
definition.

We are at the point where we need to re-create the voip.psu.edu server front end to
provide AAA of the SoftPhone user. The next steps of the process is to
generate a strong SIP password to be cut and pasted by the authenticated
user into their soft client.

Complete the 15 steps for a new service creation.

Review Asterisk clustering as an option for this or the second phase.

Future meetings:

Review timelines found on \NPI\SoftPhone Versions\Soft Phone Version Control
Document

Help desk involvement -- would we consider a wiki-based support function for
Phase 1.

SNMP logging and developing maintenance / support functionality

SBC configuration overview

SIP trunk for Phase 2 reviewed

A group got together yesterday with a couple of pizzas for a two hour discussion regarding the LAN topology to be put in place for the SoftPhone project. SoftPhone is the current title of the voice portion of the SIP communications project, coined to indicate a SIP client on a personal computing device used to call PSU IB-wide by providing the UserID of the person with whom you wish to communicate.

The concept is not new and much collective experience exists with SIP. The high level of the project includes several phases, the first phase actually takes a step back from an ongoing field trial where complex customization tied the open system SIP to the legacy VoIP system. I'll provide further details in a next set of posts on this topic.

The meeting -- Mark Linton, Scott Reed, Sven Schulz and I explored some really interesting LAN and some Layer 3 ideas to help move forward with completion of phase one. At the end we had a couple of questions -- one regarding how our edge security plays into the LAN topology -- is answered but we have some further work prior to moving forward. The quick take is we will architect a pair of SBCs to act as firewalls, positioned front and center of the traffic from the rest of the world. We have some design questions for the SBC vendor (Ingate) before deciding on how to best proceed.

These first steps sound important and they are for several reasons -- the phase one time line looms close (don't they all?), our next steps are equally critical -- completing AAA and a front end which needs reworked from the original trial, then some opportunities to talk, listen, sell, and provide additional knowledge transfer.