P2P-SIP Presentation
Philip Matthews
Nimcat / Avaya
Nimcat’s Product
Matthews; P2P-SIP; 64th IETF
2
Features


PBX system for small-med organization
Is P2P; no central component.


Phones cooperate to produce PBX functionality
Supports many standard PBX features:




Call forward, call transfer, conference call, etc.
Corporate directory (built automatically)
Even features like voicemail, auto attendant, call
logs, etc. are done in a distributed fashion.
See www.nimcatnetworks.com for list of features
Matthews; P2P-SIP; 64th IETF
3
Features (cont.)


Designed for resiliency - system still works if
some phones become unavailable.
Designed to be very “plug-and-play”


For basic operation, the only configuration
required is to enter your name on your phone.
Two ways to connect to outside world


Through an optional PSTN gateway box (TTI)
Though a SIP service provider
Matthews; P2P-SIP; 64th IETF
4
Implementation


Uses SIP for signaling
Uses a simple proprietary P2P layer





Uses multicast to locate peers and join overlay
Uses both multicast and unicast to distribute info
about each phone
Each phone has complete knowledge of other
phones
Uses various proprietary schemes for
distributing services in the P2P environment
Not planning to describe details unless group
is interested.
Matthews; P2P-SIP; 64th IETF
5
Status




Nimcat’s business model is to license the
software to hardware vendors (= IP phone
vendors)
One announced licensee (Aastra) is currently
shipping product (“Venture IP”).
There will be other licensee announcements
soon.
In September, Nimcat was acquired by
Avaya, and ports to various Avaya platforms
are underway.
Matthews; P2P-SIP; 64th IETF
6
Observations on a P2P Layer
for Real-Time Communication
Matthews; P2P-SIP; 64th IETF
7
Intro


Feel that the P2P layer should be a
major focus of this group.
Want to talk a bit about requirements
and observations on a P2P layer for
Real-Time Communications (RTC).
Matthews; P2P-SIP; 64th IETF
8
Basics


P2P layer = distributed database
In RTC, data items stored are mostly
information about a user




Name
IP address of phone
Etc.
Requirements for a P2P layer for Real-Time
Communication (RTC) are not the same as
the requirements for file sharing
Matthews; P2P-SIP; 64th IETF
9
RTC vs. File-sharing
P2P layer for RTC P2P layer for Filesharing
# of data items
 # of nodes
Size of data items Small
Can be >> # of nodes
Can be large
Lookups
Infrequent -- not a
Can be frequent
significant portion of a
phone’s workload
Join/Leave
frequency
Low
(especially wireline)
Can be high
Matthews; P2P-SIP; 64th IETF
10
Different Requirements (cont)


Most of the academic research into P2P
algorithms has implicitly assumed filesharing as the application.
RTC is a different (simpler?) problem.
Matthews; P2P-SIP; 64th IETF
11
Enterprise vs. Consumer




See (at least) two distinct applications of
P2P-SIP
Consumer telephony: Skype-like
Enterprise telephony: PBX systems for
enterprises
These two applications have different
requirements
Matthews; P2P-SIP; 64th IETF
12
Enterprise vs. Consumer
Enterprise
Enterprise
Hierarchy
Natural groups (office,
division, etc) that a P2P
layer should respect.
Artificial?
Trust Model
-- Authentication (“Can
this phone/group join the
network?”) is very
important.
-- Preventing rogue
behavior not so
important.
-- Authentication is not so
important
-- Preventing rogue
behavior is important.
Scale
10,000 peers is a large
network
10,000 peers is a small
network
Matthews; P2P-SIP; 64th IETF
13
Final thoughts

Are their other RTC applications with
different requirements?


E.g., Proxy server redundancy?
Perhaps a set of drafts, each outlining
the requirements on the P2P layer for a
particular RTC application is the right
place to start?
Matthews; P2P-SIP; 64th IETF
14