p2p-sip presentation philip matthews nimcat / avaya

P2P-SIP Presentation

Philip MatthewsNimcat / Avaya

Matthews; P2P-SIP; 64th IETF 2

Nimcat’s Product


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


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


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.


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.


Observations on a P2P Layer for Real-Time Communication


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


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


RTC vs. File-sharingP2P layer for RTC P2P layer for File-

sharing

# of data items # of nodes Can be >> # of nodes

Size of data items Small Can be large

Lookups Infrequent -- not a significant portion of a phone’s workload

Can be frequent

Join/Leave frequency

Low (especially wireline)

Can be high


Different Requirements (cont) Most of the academic research into P2P

algorithms has implicitly assumed file-sharing as the application.

RTC is a different (simpler?) problem.


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


Enterprise vs. ConsumerEnterprise 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


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?

p2p-sip presentation philip matthews nimcat / avaya

Documents