P2P-SIP Presentation Philip Matthews Nimcat / Avaya

Matthews; P2P-SIP; 64th IETF2 Nimcat’s Product

Matthews; P2P-SIP; 64th IETF3 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 voic , auto attendant, call logs, etc. are done in a distributed fashion. See for list of featureswww.nimcatnetworks.com

Matthews; P2P-SIP; 64th IETF4 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 IETF5 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 IETF6 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 IETF7 Observations on a P2P Layer for Real-Time Communication

Matthews; P2P-SIP; 64th IETF8 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 IETF9 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 IETF10 RTC vs. File-sharing P2P layer for RTCP2P layer for File- sharing # of data items  # of nodes Can be >> # of nodes Size of data itemsSmallCan be large LookupsInfrequent -- not a significant portion of a phone’s workload Can be frequent Join/Leave frequency Low (especially wireline) Can be high

Matthews; P2P-SIP; 64th IETF11 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.

Matthews; P2P-SIP; 64th IETF12 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 IETF13 Enterprise vs. Consumer 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 IETF14 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?