<?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>Dane DeValcourt &#187; VoIP</title>
	<atom:link href="http://www.devalcourt.com/category/voip/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.devalcourt.com</link>
	<description>Ramblings about tech / geek stuff. Just collecting my thoughts.</description>
	<lastBuildDate>Tue, 20 Jul 2010 00:14:40 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Calculating Bandwidth &#8211; VoIP</title>
		<link>http://www.devalcourt.com/2009/04/calculating-bandwidth-voip/</link>
		<comments>http://www.devalcourt.com/2009/04/calculating-bandwidth-voip/#comments</comments>
		<pubDate>Thu, 23 Apr 2009 02:00:55 +0000</pubDate>
		<dc:creator>Dane</dc:creator>
				<category><![CDATA[CCIE]]></category>
		<category><![CDATA[VoIP]]></category>

		<guid isPermaLink="false">http://www.pktloss.net/?p=159</guid>
		<description><![CDATA[Typically when deploying VoIP in the enterprise your going to be dealing with G.711 and/or G.729 codecs. Â Both of these codecs sample at 10ms intervals. Â The default is to usually send packets every 20ms, however in some situations one might see this set to every 30ms. If your doing packets every 20ms this creates about [...]]]></description>
			<content:encoded><![CDATA[<div class="tweetmeme_button" style="float: right; margin-left: 10px;">
			<a href="http://api.tweetmeme.com/share?url=http%3A%2F%2Fwww.devalcourt.com%2F2009%2F04%2Fcalculating-bandwidth-voip%2F"><br />
				<img src="http://api.tweetmeme.com/imagebutton.gif?url=http%3A%2F%2Fwww.devalcourt.com%2F2009%2F04%2Fcalculating-bandwidth-voip%2F&amp;source=danedevalcourt&amp;style=normal&amp;service=bit.ly&amp;service_api=R_82fc7bfa1dab277796ee3829bc77fa94" height="61" width="50" /><br />
			</a>
		</div>
<p>Typically when deploying VoIP in the enterprise your going to be dealing with G.711 and/or G.729 codecs. Â Both of these codecs sample at 10ms intervals. Â The default is to usually send packets every 20ms, however in some situations one might see this set to every 30ms.</p>
<p>If your doing packets every 20ms this creates about 50 packets per second. Â If your set to 30ms you will be creating 33.3 packets per second.</p>
<p>Lets focus on G.711 for a second. Â G.711 has a sample size of 80 bytes. Â So if we are set to use the default voice payload freq. of 20ms and we know that samples are taken every 10ms then our G.711 voice payload will be two samples of 80bytes = 160bytes of voice in every packet.</p>
<p>Thats only part of the equation though, you can&#8217;t forget about headers!</p>
<p>You will need to know what headers your going to be dealing with such as Layer 2, Layer 3 or both combined? And possibly WAN headers also.</p>
<p>In a typical ethernet packet your looking at about 58 bytes of header overhead. Â 18 bytes of ethernet (Layer 2) and 40 bytes of IP, UDP and RTP (Layer 3). Â So with your 160 bytes of voice and 58 bytes of header overhead your dealing with 218 byte packets.</p>
<p>In this example we are using the default 20ms voice payload freq. which we said corresponds to about 50 packets per second right? Â So we take our total packet size of 218bytes x 8bits x 50 packets per seconds = 87.2 Kb/s for every voice call.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.devalcourt.com/2009/04/calculating-bandwidth-voip/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>CCIE Voice Lab &#8211; Version 3</title>
		<link>http://www.devalcourt.com/2009/04/ccie-voice-lab-version-3/</link>
		<comments>http://www.devalcourt.com/2009/04/ccie-voice-lab-version-3/#comments</comments>
		<pubDate>Tue, 07 Apr 2009 18:03:25 +0000</pubDate>
		<dc:creator>Dane</dc:creator>
				<category><![CDATA[CCIE]]></category>
		<category><![CDATA[CallManager]]></category>
		<category><![CDATA[VoIP]]></category>
		<category><![CDATA[CCIE Voice]]></category>
		<category><![CDATA[Lab]]></category>
		<category><![CDATA[Voice]]></category>

		<guid isPermaLink="false">http://www.pktloss.net/?p=142</guid>
		<description><![CDATA[Cisco has refreshed / updated the CCIE voice lab. Â Listed below is the new equipment and software it will cover. Â  Lab Equipment: Cisco MCS-7845 Media Convergence Servers Cisco 3825 Series Integrated Services Routers (ISR) Cisco 2821 Series Integrated Services Routers (ISR) ISR Modules and Interface Cards Â Â  Â  Â  Â  Â  Â  VWIC2-1MFT-T1/E1Â  Â Â  [...]]]></description>
			<content:encoded><![CDATA[<div class="tweetmeme_button" style="float: right; margin-left: 10px;">
			<a href="http://api.tweetmeme.com/share?url=http%3A%2F%2Fwww.devalcourt.com%2F2009%2F04%2Fccie-voice-lab-version-3%2F"><br />
				<img src="http://api.tweetmeme.com/imagebutton.gif?url=http%3A%2F%2Fwww.devalcourt.com%2F2009%2F04%2Fccie-voice-lab-version-3%2F&amp;source=danedevalcourt&amp;style=normal&amp;service=bit.ly&amp;service_api=R_82fc7bfa1dab277796ee3829bc77fa94" height="61" width="50" /><br />
			</a>
		</div>
<p>Cisco has refreshed / updated the CCIE voice lab. Â Listed below is the new equipment and software it will cover.</p>
<p>Â </p>
<h3><strong>Lab Equipment:</strong></h3>
<ul>
<li>Cisco MCS-7845 Media Convergence Servers</li>
<li>Cisco 3825 Series Integrated Services Routers (ISR)</li>
<li>Cisco 2821 Series Integrated Services Routers (ISR)</li>
<li>ISR Modules and Interface Cards</li>
</ul>
<p>Â Â  Â  Â  Â  Â  Â  VWIC2-1MFT-T1/E1Â <br />
Â Â  Â  Â  Â  Â  Â  PVDM2Â <br />
Â Â  Â  Â  Â  Â  Â  HWIC-4ESW-POEÂ <br />
Â Â  Â  Â  Â  Â  Â  NME-CUE</p>
<ul>
<li>Cisco Catalyst 3750 Series Switches</li>
<li>IP Phones and Soft Clients</li>
</ul>
<h3><strong>Software Versions</strong></h3>
<p>Any major software release which has been generally available for six months is eligible for testing in the CCIE Voice Lab Exam.Â </p>
<ul>
<li>Cisco Unified Communications Manager 7.0</li>
<li>Cisco Unified Communications Manager Express 7.0</li>
<li>Cisco Unified Contact Center Express 7.0</li>
<li>Cisco Unified Presence 7.0</li>
<li>Cisco Unity Connection 7.0</li>
<li>All routers use IOS version 12.4T Train.</li>
<li>Cisco Catalyst 3750 Series Switches uses 12.2 Main Train</li>
</ul>
<h3><strong>Network Interfaces</strong></h3>
<ul>
<li>Fast Ethernet</li>
<li>Frame Relay</li>
</ul>
<h3><strong>Telephony Interfaces</strong></h3>
<ul>
<li>T1</li>
<li>E1</li>
</ul>
<p>Â </p>
<p>Source: Â <a href="https://cisco.hosted.jivesoftware.com/docs/DOC-3641" target="_blank">Cisco Learning Network</a></p>
<p>Some of the major changes are:</p>
<p>1) Remove analog devices (such as VG248, ATA)<br />
2) Remove CatOS (Catalyst 65xx)<br />
3) Replace CCM with CUCM 7 (Linux Appliance)<br />
4) Replace Unity with Unity Connection 7 (Linux Appliance)<br />
5) Add CUPS 7 (Linux Appliance)<br />
6) Add SIP phones</p>
<p>Basic topology:</p>
<p><img class="alignnone size-medium wp-image-143" title="ccie_voice_v3_topo" src="http://www.pktloss.net/wp-content/uploads/2009/04/ccie_voice_v3_topo-300x215.png" alt="ccie_voice_v3_topo" width="300" height="215" /></p>
<p>Â </p>
<p>Source: Â http://htluo.blogspot.com</p>
]]></content:encoded>
			<wfw:commentRss>http://www.devalcourt.com/2009/04/ccie-voice-lab-version-3/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Future of Cable Providers?</title>
		<link>http://www.devalcourt.com/2009/04/future-of-cable-providers/</link>
		<comments>http://www.devalcourt.com/2009/04/future-of-cable-providers/#comments</comments>
		<pubDate>Tue, 07 Apr 2009 01:58:08 +0000</pubDate>
		<dc:creator>Dane</dc:creator>
				<category><![CDATA[Cable]]></category>
		<category><![CDATA[IPTV]]></category>
		<category><![CDATA[VoIP]]></category>
		<category><![CDATA[Future]]></category>

		<guid isPermaLink="false">http://www.pktloss.net/?p=139</guid>
		<description><![CDATA[What does the future hold for cable providers? Â I don&#8217;t know, but I do have some ideas. Â I don&#8217;t claim to be an expert on any thing related to cable companies and I am not speaking for any one provider in particular. I am personally very new to the cable industry, especially compared to just [...]]]></description>
			<content:encoded><![CDATA[<div class="tweetmeme_button" style="float: right; margin-left: 10px;">
			<a href="http://api.tweetmeme.com/share?url=http%3A%2F%2Fwww.devalcourt.com%2F2009%2F04%2Ffuture-of-cable-providers%2F"><br />
				<img src="http://api.tweetmeme.com/imagebutton.gif?url=http%3A%2F%2Fwww.devalcourt.com%2F2009%2F04%2Ffuture-of-cable-providers%2F&amp;source=danedevalcourt&amp;style=normal&amp;service=bit.ly&amp;service_api=R_82fc7bfa1dab277796ee3829bc77fa94" height="61" width="50" /><br />
			</a>
		</div>
<p>What does the future hold for cable providers? Â I don&#8217;t know, but I do have some ideas. Â I don&#8217;t claim to be an expert on any thing related to cable companies and I am not speaking for any one provider in particular.</p>
<p>I am personally very new to the cable industry, especially compared to just about everyone I have met since going to work for a provider. Â However I am not new to technology and keeping up with the latest and greatest in tech trends. Â One thing I have noticed over the years is the often we &#8216;geeks&#8217; are lucky in that we often get a glimpse into the future without always knowing it.</p>
<p>What do I mean by that? Â Well basically we tend to get our hands on or read about the latest technologies before they ever go mainstream. Â And during this time its sort of like a glimpse into the future when you consider how few overall know about or have experience with these things.</p>
<p>Cable providers in general have sort of had it made in the past. Â Competition was weak at best and cable for the longest time was the future. Â So much has been done and so much remains to be done over that single piece of coax, but I think everyone can agree that its future is limited in the traditional sense. Â How far out is a question that is highly debateable and I surely don&#8217;t want to get into.</p>
<p>Locally people are going to associate what I am saying with fiber, but thats not at all where I want to go with this. Â  Nope I am thinking a little broader in scope to be honest. Â Why? Â Because I am not concerned with the physical layer of things. Â I know the physical layer can and will likely change over time. Â  And regardless of the physical layer cable providers still have to some how differentiate themselves and the services they offer.</p>
<p>The physical layer is not where one makes money. Â Anyone can provide that. Â Where you make money is in how you use that physical layer and what services are offered over it.</p>
<p>I think everyone can agree that the future boils down to two letters. Â IP</p>
<p>Everything you can do over the traditional cable plant can be done over any type of physical layer as long as IP is involved.</p>
<p>What I find to be the most significant point about all of this is the fact that you can do this technically with no regard to whose providing the physical layer which also means you can provide your service to those outside of the typical cable providers physical plant.</p>
<p>The cable industry is always looking for ways to reach more homes, and always talk about &#8220;homes passed&#8221; and &#8220;RGU &#8211; revenue generating unit&#8221;.Â </p>
<p>I am very surprised that the cable providers aren&#8217;t pushing themselves a little harder to become more of a &#8220;service provider&#8221; rather then just a &#8220;cable provider&#8221;. Â Seems the focus should be on transitioning their services to be more IP based with the goal of providing the service to anyone who wishes to subscribe regardless of where or with whom the customer gets their physical connectivity with.</p>
<p>The cable industry more so then any other should be able to do this quickly and effectively. Â Most have the backbone and pipes to provide this sort of service. Â They already have the headends and MTC&#8217;s for obtaining the content from the content providers. Â They have been working with and dealing with the hassle of negotiating contracts for content for years. Â They typically have data engineers and experience on that side of things, including knowledge of switched digital or IPTV. Â They have all these building blocks or pieces of the puzzle but they just don&#8217;t seem to be putting it together with the same end goal.</p>
<p>They seem to focus on doing all of this but stuck on doing it over their physical plant. Â I personally think this might have a lot to do with the fact the industry is aging, including all of the experts and leadership. Â What I love the most about the industry (the fact that their are so many people who have been in it longer than I have been alive) I fear is also what holds it back often.</p>
<p>A couple of years ago I shared with some friends my idea that I eventually blogged about as well regarding the creation of a media device that was easily configured to the individual users IP services (VoIP, Video and so on) that would not care about who provide the data pipe. Â I liken it to a cross between your current cable box, Xbox or Apple TV, SIP phone and so on. Â You can read a little about that here: Â http://bit.ly/19WjKZ</p>
<p>This idea falls right into line with what I am talking about now and where I think the cable providers need to focus on heading to sooner then later.Â </p>
<p>Here is a quick recap and what I personally think should be happening:</p>
<ol>
<li>Become an IPTV provider. Â Example is to partner with someone like Microsoft where users can subscribe to an IPTV service through their XBox or PC.</li>
<li>Become a VoIP provider. Â Look at Vonage as example. Â Offer a SIP service offering where anyone can signup to get a local phone number and VoIP service which could be tied to a SIP phone of SIP softphone client.</li>
<li>Keep improving your customers data side. Â DOCSIS 3 sooner than later. Â Realize that this (big bandwidth) is the future and the foundation for which all things will be based on including your own service offerings (see items #1 and #2 above).</li>
<li>Let go of these &#8220;walled gardens&#8221;. Â Mr. Cable Provider, tear down this wall! Â Seriously, its time to let go. Â You have the potential to be so much more and your &#8220;homes passed&#8221; can become anyone with high speed internet and not just those directly connected to your plant.</li>
<li>Push the device manufactures and the CableLabs to start working on that dream device I mentioned. Â It needs to be something based on a standard (like SIP). Â See my post here for more details: Â http://bit.ly/19WjKZ</li>
</ol>
<p>Sorry for the long dissertation. Â I write too much I know in my poor attempt at trying to get these ideas out of my head in a way for anyone to understand. Â I am not talking about anything new here or revolutionary, but as many would say this is all evolutionary.</p>
<p>I hope in a few years I can look back on this and know that others in the industry were way ahead of what I give them credit for and already were working on all these things.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.devalcourt.com/2009/04/future-of-cable-providers/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CallManager / MGCP Gateways &#8211; Stop new calls?</title>
		<link>http://www.devalcourt.com/2009/03/callmanager-mgcp-gateways-stop-new-calls/</link>
		<comments>http://www.devalcourt.com/2009/03/callmanager-mgcp-gateways-stop-new-calls/#comments</comments>
		<pubDate>Tue, 31 Mar 2009 18:50:21 +0000</pubDate>
		<dc:creator>Dane</dc:creator>
				<category><![CDATA[CCIE]]></category>
		<category><![CDATA[CallManager]]></category>
		<category><![CDATA[VoIP]]></category>
		<category><![CDATA[Gateway]]></category>
		<category><![CDATA[MGCP]]></category>

		<guid isPermaLink="false">http://www.pktloss.net/?p=133</guid>
		<description><![CDATA[So I was doing some upgrades this past week adding some CMM-ACT adapters to existing Cisco CMM modules that had active PRI&#8217;s on the modules. Â I had one CMM module per Catalyst 6509.Â  All my PRI&#8217;s are split between these two 6509&#8242;s, and the various PRI&#8217;s belong to trunk groups (hope I got the term [...]]]></description>
			<content:encoded><![CDATA[<div class="tweetmeme_button" style="float: right; margin-left: 10px;">
			<a href="http://api.tweetmeme.com/share?url=http%3A%2F%2Fwww.devalcourt.com%2F2009%2F03%2Fcallmanager-mgcp-gateways-stop-new-calls%2F"><br />
				<img src="http://api.tweetmeme.com/imagebutton.gif?url=http%3A%2F%2Fwww.devalcourt.com%2F2009%2F03%2Fcallmanager-mgcp-gateways-stop-new-calls%2F&amp;source=danedevalcourt&amp;style=normal&amp;service=bit.ly&amp;service_api=R_82fc7bfa1dab277796ee3829bc77fa94" height="61" width="50" /><br />
			</a>
		</div>
<p>So I was doing some upgrades this past week adding some CMM-ACT adapters to existing Cisco CMM modules that had active PRI&#8217;s on the modules. Â I had one CMM module per Catalyst 6509.Â </p>
<p>All my PRI&#8217;s are split between these two 6509&#8242;s, and the various PRI&#8217;s belong to trunk groups (hope I got the term right) from the telco. Â So, basically I can unplug any given PRI from one 6509 and the other PRI on another 6509 will still be able to take calls.</p>
<p>With that said I can technically take down one CMM module from one 6509 and still make and recieve calls.</p>
<p>So that was the plan, take down a module, install the CMM-ACT put the module back in and check make sure everything is working and repeat on the other module.</p>
<p>The catch of course is that if their were any calls on a PRI attached to the particular CMM well they would go down when I unplugged the PRI. Â So I started researching a way to &#8216;busy out&#8217; my PRI&#8217;s on the CMM I was going to work on so that it would preserve existing calls but not accept any new calls forcing them to move to the other PRI&#8217;s on the other CMM. Â Doing something like this should allow me to get all calls off the PRI&#8217;s so that I can do maintenance and not incur any downtime.</p>
<p>I didn&#8217;t get my answers in time for my maintenance. Â But I did eventually find various sources of info related to this that I look forward to try at a later time.</p>
<p>In CallManager it seems there is a service parameter that would help accomplish what I was trying to do. Â The service parameter is: Â &#8221;Change B-Channel Maintenance Status 1 &#8211; 5&#8243;<br />
Apparently this should allow you to take the B-channels out of serviceÂ for up to five MGCP gateways without disrupting calls.</p>
<p>Source: Cisco CallManager Best Practices<br />
Google Book Search Preview: Â <a href="http://tinyurl.com/c5lop7" target="_blank">http://tinyurl.com/c5lop7</a></p>
<p>Catch is the PRI&#8217;s have to be pre-configured with &#8220;unchecking theÂ inhibit restarts at PRI intialization&#8221; and &#8220;check enable status poll&#8221;Â then restart the gateway.</p>
<p>This Cisco doc seems to explain it fairly well.</p>
<p>Busy-Out ISDN B-Channels in Cisco CallManager Configuration Example<br />
Source Cisco Website: Â <a href="http://tinyurl.com/2675fo" target="_blank">http://tinyurl.com/2675fo</a></p>
<p>Â </p>
<p>Someone else also suggested, actually they asked, if the &#8220;mgcp block-newcalls&#8221; gateway config command could possibly be used in this situation. Â I don&#8217;t know myself but its worth trying one day. Â Still waiting to see if anyone comments on his question in which case I will add that info here as well.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.devalcourt.com/2009/03/callmanager-mgcp-gateways-stop-new-calls/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
