Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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