39 Peers

  • Increase font size
  • Default font size
  • Decrease font size
Home

What is the 39 Peers project?

The 39 Peers project aims to create an open source repository of light weight implementations of real-time communication (RTC) protocols. In a nutshell, it contains reference implementations, prototypes and sample applications, mostly written in Python, of various RTC standards defined in IETF, W3C and elsewhere, e.g., RFC 3261 (SIP), RFC 3550 (RTP), RFC 3920 (XMPP), WebRTC, RTMP, etc. This is a Free Software released under GNU LGPL license. Contact our business unit for an alternate commercial license if you like.

One of the root causes of non-interoperable implementations is the misinterpretation of the specification. A number of people have claimed that SIP has become complicated and has failed to deliver its promise of mix-and-match interoperability. There are two main reasons: (a) the number of SIP related RFCs and drafts has grown faster than what a developer or a product life-cycle can catch up with, and (b) many of the RFCs and drafts are not supported by an open implementation which results in misinterpretation of some aspects of the specification by a programmer. The job of a SIP programmer is to (1) read the RFC of SIP or its extensions, (2) understand the logic and figure out how it fits in the big picture or how it relates to the other existing SIP related source code, (3) come up with some object-oriented class diagram, classes' properties and pseudo-code for their methods, and finally (4) implement the classes and methods. With more number of emerging RTC standards such as WebRTC and ICE, this trend of specifications without implementations and consecutively the problem of non-interoperability have increased.

Clearly the text in RFCs and drafts cannot be as unambiguous as real source code of a computer program. So many programmers may read and implement some features differently, resulting in non-interoperable implementations. Having a readily available pseudo-code for RTC specifications relieves the programmer of error-prone step (2) above, and resolves any misinterpretation at an early stage, instead of expensive interop testing. There is a huge cost paid by the vendor or provider for this programmer's misinterpretation of the specification.

An earlier version of this issue appeared in a blog article, a proposal for reference implementation repository for SIP-related RFCs.

This project aims to keep an open and public repository of reference implementation of RTC specification including RFC 3261 and other SIP and RTC related extensions. The goal of this effort will be to encourage submission of reference implementations by RFC and Internet Draft authors. In case of any ambiguity, the clarification will not only be applied to specification but also to the reference implementation.

If we use a very high level language such as Python then the reference implementation essentially also doubles as pseudo code, which can be ported to other programming languages. The goal is not to get involved in the syntax of a particular programming language, but just express the ideas more formally to prevent misinterpretation of the specification.

This project will likely and greatly simplify the job of a programmer dealing with real-time communication protocols and specifications, and in the long term, will result in more interoperable and robust user products seamlessly supporting new RTC extensions and features. The programmers will have fewer things to worry about; hence can write more accurate code in the short time. From an specification author's point of view, it will encourage him/her to write more solid and implementable specification without ambiguity, and encourage him/her to provide the pseudo-code in the draft. From a reviewer's point of view, one can easily judge the complexity of various alternatives or features, e.g., one can say that adding the extension 'foo' is just 10 lines of pseudo-code to the base SIP reference implementation.

This project contains source code of various RTC specifications found in IETF RFCs and W3C documents. The source code is annotated with text snippets from the relevant specification to clearly show (a) how the code fragment implements the specification, (b) which part of the specification is relevant to the code fragment, and vice-versa, and (c) the implicit documentation of code fragment borrowed from the specification. The project includes such an annotation tool to help developers implementing more specifications in our repository
 

Main Menu