Warning: Cannot modify header information - headers already sent by (output started at /home/phonecar/public_html/index.php:1) in /home/phonecar/public_html/wp-includes/feed-rss2.php on line 8
Phone Cards Digest » VoIP http://www.phonecardsdigest.com Phone cards in a nutshell Mon, 02 May 2011 16:27:02 +0000 en hourly 1 http://wordpress.org/?v=3.0.4 Proprietary VoIP Traffic Monitoring http://www.phonecardsdigest.com/2009/08/proprietary-voip-traffic-monitoring_104.html http://www.phonecardsdigest.com/2009/08/proprietary-voip-traffic-monitoring_104.html#comments Mon, 31 Aug 2009 12:27:40 +0000 admin http://www.phonecardsdigest.com/?p=104 The main VoIP protocol that falls into this category is Skype. As the protocol
implementation is currently unknown and the packet payload encrypted, the best way to monitor this protocol is to threat it as special eDonkey protocol communication.

Typically Skype is detected as follows:

• The underlying protocol must be eDonkey. This can be detected by dissecting the initial session payload as described in [karagiannis], and partially relying on the default port being used. Patterns searching for Skype detection has been implemented using the popular PCRE [pcre] library. This library that allows patterns to be efficiently searched into into a data buffer, has been used to search for Skype pattern into the packet payload. The protocol pattern definition has been borrowed by the popular l7-filter [l7-filter] tool that includes several patters not limited only to P2P/ VoIP protocols. Thanks to this solution, it is possible to detect not only Skype in general, but also the conversation type (skype2skype or skype-in/out call).

• As Skype traffic looks similar to the original eDonkey traffic, it is necessary to further characterize the traffic in order to distinguish eDonkey from Skype. As protocol payload is encrypted, the only choice left is the analysis of traffic conversations. In particular the main differences between a P2P and Skype conversation are:

• During a Skype conversation, traffic is bidirectional, packet frequency is high (in general around 64 packets/sec regardless of peers speaking or not) with limited jitter, packet size is limited (usually below 250 bytes).

• A eDonkey P2P session instead is mostly unidirectional (from the source of data to the host where data is directed), packet rate is not constant and packet size is much larger.

In a nutshell the only thing that a monitoring application can do with respect to Skype traffic, is to provide evidence of calls without furnishing any other information such the nickname of the people who held the conversation. For this reason Skype detection has been implemented only inside ntop and not on nProbe as there are almost no metrics to export while analyzing Skype traffic.

Source: Luca Deri (ntop.org)

]]> http://www.phonecardsdigest.com/2009/08/proprietary-voip-traffic-monitoring_104.html/feed 0 VoIP Regulatory Issues http://www.phonecardsdigest.com/2009/08/voip-regulatory-issues_101.html http://www.phonecardsdigest.com/2009/08/voip-regulatory-issues_101.html#comments Mon, 24 Aug 2009 13:47:08 +0000 admin http://www.phonecardsdigest.com/?p=101 LDC DILEMMA
• Political constraints in more developed areas of “bypassing” the incumbent with VoIP and thus regulatory or even criminal restraints of development. Control/loss of intl traffic.
• Tension between graduation of urban areas and commerce to next higher level of global market access and deploying basic access to rural areas—the universal access challenge

REGULATORY CHALLENGE
• Getting the courage to regulate creatively and around the traditional formats
• Encouraging private-municipality partnerships
• Exempting certain regions out of restrictive regulation
• Balancing true consumer needs with investment realities

REGULATORY CHALLENGE AND OPPORTUNITY

Consider opening telecoms market to VoIP to licensed competitors at least in urban environments and require them to contribute to universal service fund. Good concept with political, technical and economic issues.
- Balancing of interests to access charge regulation, should broadband be outside the regulatory realm?
- Regulatory creativity: partnerships between private enterprise and municipalities; “regions with disability” regulation, etc.
- Provision of Emergency Services: 911 and E911

Source: Greenberg Trauring

]]> http://www.phonecardsdigest.com/2009/08/voip-regulatory-issues_101.html/feed 0 Supporting VoIP Services with a Best-Effort Network http://www.phonecardsdigest.com/2009/08/supporting-voip-services-besteffort-network_95.html http://www.phonecardsdigest.com/2009/08/supporting-voip-services-besteffort-network_95.html#comments Mon, 10 Aug 2009 14:35:30 +0000 admin http://www.phonecardsdigest.com/?p=95 A best-effort network provides just what its name describes – a network that does its best to deliver packets in a timely manner. It is the least complex and costly network approach and is the design most networks use today. Best-effort networks work well for non-sensitive traffic types such as Web browsing and e-mail since delays in these services generally do not significantly impact the user experience.

Best-effort networks leverage Interior Gateway Protocol (IGP) technologies such as Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (IS-IS) to determine paths for routing packets between hosts. IGP protocols use a Shortest Path First (SPF) algorithm to build routing tables. The routing engine references these routing tables at each router hop traversed by the packets.

Architects for these networks provide QoS by over-provisioning the links and routers so that network congestion does not introduce unwanted levels of latency, jitter, and packet loss. Overprovisioning a network would appear to be a simple way to provide the necessary level of QoS. However, while this approach requires a significant amount of added bandwidth, it still cannot guarantee service levels in an operational environment. Historically, to provide toll-grade services during predictable periods of network usage, service providers must over-provision bandwidth resources by a factor of between 10:1 and 20:1.

Best-effort networks are not ideal in dealing with temporary or permanent outages. IGP will advertise the outage and initiate a route table reconstruction based on the modified topology. This process is called route re-convergence, and if not designed carefully or optimized, can take seconds to stabilize. Web browsing or e-mail users do not typically notice these seconds. However, route re-convergence can be detrimental to VoIP users in the middle of a conversation, as it impacts both latency and jitter.

Source: Juniper Networks, Inc. White Paper

]]> http://www.phonecardsdigest.com/2009/08/supporting-voip-services-besteffort-network_95.html/feed 0