<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Calling Cards Digest &#187; VoIP telephony</title>
	<atom:link href="http://callingcardsdigest.com/tag/voip-telephony/feed/" rel="self" type="application/rss+xml" />
	<link>http://callingcardsdigest.com</link>
	<description>Your resource for calling card news!</description>
	<lastBuildDate>Fri, 27 Aug 2010 16:01:26 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>VoIP &#8211; Open Issues and Future Work</title>
		<link>http://callingcardsdigest.com/uncategorized/voip-open-issues-future-work/</link>
		<comments>http://callingcardsdigest.com/uncategorized/voip-open-issues-future-work/#comments</comments>
		<pubDate>Mon, 31 Aug 2009 12:40:46 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[international calls]]></category>
		<category><![CDATA[IP telephony]]></category>
		<category><![CDATA[phone cards]]></category>
		<category><![CDATA[prepaid phone cards]]></category>
		<category><![CDATA[VoIP]]></category>
		<category><![CDATA[VoIP telephony]]></category>

		<guid isPermaLink="false">http://callingcardsdigest.com/?p=84</guid>
		<description><![CDATA[The main open issue is the inability to properly handle Skype, to date probably the most widespread VoIP protocol. As explained before, this is due to the lack of documentation about the protocol, and the use of payload encryption. This is not only a limitation of ntop and nProbe but of any other VoIP analysis [...]]]></description>
			<content:encoded><![CDATA[<p><strong>The main open issue is the inability to properly handle Skype, to date probably the most widespread VoIP protocol. </strong>As explained before, this is due to the lack of documentation about the protocol, and the use of payload encryption. This is not only a limitation of ntop and nProbe but of any other VoIP analysis tool.</p>
<p><strong>VoIP support is relatively new into ntop/nProbe hence several extensions can be added to their implementation.</strong> The current measurements focus mainly on high-level metrics such as jitter or packet loss, and are independent of the codecs being used. However as new codecs such as H.264 [h264] are becoming increasingly popular, a planned enhancement is the ability to decode some of these codec formats in order to also provide precise information about the RTP payload (e.g. voice quality), as well provide support for RTP XS reports.</p>
<p><strong>The implementation of these voice analysis metrics has been delayed with respect to the original plan, as they are described in ITU documents</strong> (e.g. ITU E.411 recommendation) that are not freely available on the Internet, that is usually a problem for the open source community. Nevertheless in the next release two new common metrics such as MOS score and r-factor will be implemented thanks to bits and pieces found googling on the Internet.</p>
<p><em><strong>Source: Luca Deri (ntop.org)</strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://callingcardsdigest.com/uncategorized/voip-open-issues-future-work/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Handling VoIP Service Requirements &#8211; Minimizing Latency</title>
		<link>http://callingcardsdigest.com/voip/handling-voip-service-requirements-minimizing-latency/</link>
		<comments>http://callingcardsdigest.com/voip/handling-voip-service-requirements-minimizing-latency/#comments</comments>
		<pubDate>Mon, 10 Aug 2009 14:42:27 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[VoIP]]></category>
		<category><![CDATA[calling cards]]></category>
		<category><![CDATA[international calls]]></category>
		<category><![CDATA[internet telephony]]></category>
		<category><![CDATA[IP telephony]]></category>
		<category><![CDATA[phone cards]]></category>
		<category><![CDATA[VoIP calling cards]]></category>
		<category><![CDATA[VoIP phone cards]]></category>
		<category><![CDATA[VoIP telephony]]></category>

		<guid isPermaLink="false">http://callingcardsdigest.com/?p=76</guid>
		<description><![CDATA[As with most real-time services, VoIP demands that the network provide predictable performance within a constrained boundary of transport parameters. This section surveys the key networking issues that an organization or service provider must carefully consider when deploying a VoIP solution. Latency (also referred to as delay) is the time that it takes a packet [...]]]></description>
			<content:encoded><![CDATA[<p><strong>As with most real-time services, VoIP demands that the network provide predictable performance within a constrained boundary of transport parameters. </strong>This section surveys the key networking issues that an organization or service provider must carefully consider when deploying a VoIP solution.</p>
<p>Latency (also referred to as delay) is the time that it takes a packet to make its way through the network to the terminating device.<strong> In other words, latency is the time it takes the speaker’s voice to reach the listener’s ear. </strong>While large latency values do not necessarily degrade the sound quality of a phone call, they can disrupt the rhythm of conversation, making it difficult to interact.</p>
<p><strong>Several factors contribute to latency in a multiservice network, including:</strong></p>
<p>• The time it takes for the endpoints to create the packets used in voice services, known as packet creation latency<br />
• The time it takes to serialize the digital data onto the physical links of the interconnecting equipment<span id="more-76"></span><br />
• The time it takes an electrical (or photonic) signal to travel the length of a conductor, known as propagation delay<br />
• The time that a packet remains buffered in a network element while it awaits transmission, referred to as the queuing delay<br />
• The time it takes a network device (router, switch, firewall, etc.) to buffer a packet and make the forwarding decision, known as packet forwarding delay.</p>
<p><strong>When designing a multiservice network, the total delay that a signal or packet exhibits is the sum of all the latency contributors. </strong>Generally, it is accepted that the end-to-end latency should be less than 150 ms for toll quality phone calls. The remainder of this section describes some basic steps network managers can take to assess and mitigate the impact of each latency contributor in a multiservice network.</p>
<p><strong><em>Source: Juniper Networks, Inc. White Paper</em></strong></p>
]]></content:encoded>
			<wfw:commentRss>http://callingcardsdigest.com/voip/handling-voip-service-requirements-minimizing-latency/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
