Source: snapvoip.blogspot.com

O’Reilly Media has released the Asterisk: The Future Of Telephony under under the Creative Commons license. Kudos goes to O’Reilly Media and the three authors, Jim Van Meggelen, Jared Smith, and Leif Madsen. Download links and Authors links are under the links at the bottom of the post.
Once I know the rules, I will post it in IPTELEPHONY in Google Groups.
Asterisk: FOT has received wide attention in the VoIP and IPPBX realm. It is a very well put together book that appeals to new comer to Asterisk as well as to the IPPBX pro. For information, I have listed the contents of the book below.

Contents of the Asterisk: The future of Telephony
Foreword

Preface

1. A Telephony Revolution
VoIP: Bridging the Gap Between Traditional Telephony and Network Telephony
Massive Change Requires Flexible Technology
Asterisk: The Hacker’s PBX
Asterisk: The Professional’s PBX
The Asterisk Community
The Business Case
This Book

2. Preparing a System for Asterisk
Server Hardware Selection
Environment
Telephony Hardware
Types of Phone
Linux Considerations
Conclusion

3. Installing Asterisk
What Packages Do I Need?
Obtaining the Source Code
Compiling Zaptel
Compiling libpri
Compiling Asterisk
Installing Additional Prompts
Updating Your Source Code
Common Compiling Issues
Loading Zaptel Modules
Loading libpri
Loading Asterisk
Directories Used by Asterisk
Conclusion

4. Initial Configuration of Asterisk
What Do I Really Need?
Working with Interface Configuration Files
FXO and FXS Channels
Configuring an FXO Channel
Configuring an FXS Channel
Configuring SIP
Configuring Inbound IAX Connections
Configuring Outbound IAX Connections
Debugging
Conclusion

5. Dialplan Basics
Dialplan Syntax
A Simple Dialplan
Adding Logic to the Dialplan
Conclusion

6. More Dialplan Concepts
Expressions and Variable Manipulation
Dialplan Functions
Conditional Branching
Voicemail
Macros
Using the Asterisk Database (AstDB)
Handy Asterisk Features
Conclusion

7. Understanding Telephony
Analog Telephony
Digital Telephony
The Digital Circuit-Switched Telephone Network
Packet-Switched Networks
Conclusion

8. Protocols for VoIP
The Need for VoIP Protocols
VoIP Protocols
Codecs
Quality of Service
Echo
Asterisk and VoIP
Conclusion

9. The Asterisk Gateway Interface (AGI)
Fundamentals of AGI Communication
Writing AGI Scripts in Perl
Creating AGI Scripts in PHP
Writing AGI Scripts in Python
Debugging in AGI
Conclusion

10. Asterisk for the Über-Geek
Festival
Call Detail Recording
Customizing System Prompts
Manager
Call Files
DUNDi
Conclusion

11. Asterisk: The Future of Telephony
The Problems with Traditional Telephony
Paradigm Shift
The Promise of Open Source Telephony
The Future of Asterisk

A. VoIP Channels

B. Application Reference

C. AGI Reference

D. Configuration Files

E. Asterisk Command-Line Interface Reference

Index

Links;
download book as a single entity,a PDF file.(4.5MB) USA1 USA2 UK NL
Download each chapter is a seperate PDF file (3.1MB) USA1 USA2 UK NL
O’Reilly Media
Jim Van Meggelen
Jared Smith
Leif Madsen

Source: snapvoip.blogspot.com

I was surfing the web searching for information on Skype technology and if it affects users as popular beliefs on the net and else where. Specially in the case of Supernodes and relaying nodes, mentioned in the article;
VOIP IP Telephony: How to be or not to be a skype supernode?
I did find some very good information. One of the studies (the best in my view) were done by Saikat Guha of Cornell University and Neil Daswani, Ravi Jain of Google. The study was conducted over more than four months extending from September 1, 2005 to January 14, 2006. Also one factor that they state is that, Experiments on this data were done in a black-box manner, i.e., without knowing the internals or specifics of the Skype system or messages, as Skype encrypts all user traffic and signaling traffic payloads. The results indicate that although the structure of the Skype system appears to be similar to other P2P systems, particularly KaZaA, there are several significant differences in traffic. The number of active clients shows diurnal and work-week behavior, correlating with normal working hours regardless of geography. The population of supernodes in the system tends to be relatively stable; thus node churn, a significant concern in other systems, seems less problematic in Skype. The typical bandwidth load on a supernode is relatively low, even if the supernode is relaying VoIP traffic.
So is Skype good or bad? well you have to take all the facts and decide for your self.
Despite its popularity, little is known about Skype’s encrypted protocols and proprietary network. Garfinkel (His site has a wealth of information but the related article was found on another site Perhaps why the original authors just cited the article, I have uploaded the article to iptelephony at google groups.), concludes that Skype is related to KaZaA; both the companies were founded by the same individuals, there is an overlap of technical staff, and that much of the technology in Skype was originally developed for KaZaA. Network packet level analysis of KaZaA and of Skype (and again the article was uploaded to iptelephony at google groups) support this claim by uncovering striking similarities in their connection setup, and their use of a “supernode”-based hierarchical peer-to-peer network.

Supernode-based peer-to-peer networks organize participants into two layers: supernodes, and ordinary nodes. Such networks have been the subject of recent research. Typically, supernodes maintain an overlay network among themselves, while ordinary nodes pick one (or a small number of) supernodes to associate with; supernodes also function as ordinary nodes and are elected from amongst them based on some criteria. Ordinary nodes issue queries through the supernode(s) they are associated with.

Here are the two experiments;
Experiment..1:
Basic operation. We conducted an initial experiment to examine the basic operation and design of the Skype network in some more detail. We ran two Skype clients (version 1.1.0.13 for Linux) on separate hosts, and observed the destination and source IP addresses for packets sent and received in response to various application-level tasks. We observed that in Skype, ordinary nodes send control traffic including availability information, instant messages, and requests for VoIP and file-transfer sessions over the supernode peer-to-peer network. If the VoIP or file-transfer request is accepted, the Skype clients establish a direct connection between each other. To examine this further, we repeated the experiment for a single client behind a NAT2, and both clients behind different NATs. We observed that if one client is behind a NAT, Skype uses connection reversal whereby the node behind the NAT initiates the TCP/UDP media session regardless of which end requested the VoIP or file-transfer session. If both clients are behind NATs, Skype uses STUN-like NAT traversal to establish the direct connection. In the event that the direct connection fails, Skype falls back to a TURN-like approach where the media session is relayed by a publicly reachable supernode. This latter approach is invoked when NAT traversal fails, or a firewall blocks some Skype packets. Thus the overall mechanism that Skype employs to service VoIP and file transfer requests is quite robust to NAT and firewall reachability limitations.

Experiment..2:
Promotion to supernode. We next investigated how nodes are promoted to supernodes. In an experiment we conducted, we ran several Skype nodes in various environments and waited two weeks for them to become supernodes. A Skype node behind a saturated network uplink, and one behind a NAT, did not become supernodes, while a fresh install on a public host with a 10 Mbps connection to the Internet joined the supernode network within minutes. Consequently, it appears that Skype supernodes are chosen from nodes that have plenty of spare bandwidth, and are publicly reachable. This approach clearly favors the overall availability of the system. We did not test additional criteria such as a history of long session times, or low processing load as suggested in this article, p2p supernode. As we show later, the population of supernodes selected by Skype, apparently based on reachability and spare bandwidth, tends to be relatively stable. Skype, therefore, represents an interesting point in the P2P design-space where heterogeneity is leveraged to control churn, not just cope with it.

Well the article seems to be getting too long. I will have to make a second article to finish the rest. It will be interesting as you will be able to see all Skype info in visual format, i.e. graphs. I am sure it will be interesting.