Skype
Page 2.
Discuss Skype, on the Communication & Internet forum of FrequentFlyer.com.au, the home of frequent flyers.
Welcome to Australia's leading independent Frequent Flyers resource! We hope you find the information useful and decide to join our online community. Its free to join, simply click on the register link. To start viewing messages, select the forum that you want to visit from the selection below.
I feel right at home on this thread
But i am at home beer in hand, brain dead from to much work on a monday.
Anybody done the maths on the power requirements for POE to run all those alternate to skype VIOP handsets ? scary !
I think std PABX's and lines will be around a while yet.
Evan
Sponsored Links
Registered Users have the option of
removing this and all other advertisements.
More
Member of: AA Exec Plat; QF LTG; PC Plat; HHonors Gold
Posts: 9,844
Re: Skype
Quote:
Originally Posted by Evan
Anybody done the maths on the power requirements for POE to run all those alternate to skype VIOP handsets ? scary !
The one here on my desk at home is around 5 watts. But since I don't have POE at home (not supported on my Cisco 877W router) it is supplied from a plug-pack power supply.
No extra power requirements when using one my 3 IP Softphone clients (two SIP clients and a H.323 client).
I have had three concurrent active calls using SIP out over my ADSL service via a USA-based IP-PBX, one from my desk phone, one softphone on my laptop and one softphone on my PocketPC.
The real challenge is getting the QoS configured right so I can still surf and replicate my email etc without killing the call quality. Outbound queuing is easy (low latency queuing), but controlling the inbound is the tricky bit .
Actually, the IEEE 802.3AF standard says that each POE port should be able to deliver 15.4Watts. Now that is one heck of a power requirement for a chassis with lot of ports. Currently nobody is shipping a 48 port IEEE802.3AF compliant blade.
One of the big problem is in the provision of UPS power and cooling in the distribution layer of the network. People expect their phones to keep working during a power outage, so a corporate/enterprise VoIP solution needs to provide UPS power to the distribution layer switches that are delivering the POE. And those POE switches now have big power appetites and lots of heat dissipation to match, meaning the floor distribution wiring closets now need more power, UPS capabilities and air 24x7 air conditioning. So better calculate that in the ROI spreadsheet.
Consider that the Cisco 6500 chassis now supports up to 6000 Watts of power supply in order to deliver high density POE capabilities.
Not many phones that need 15.4 Watts, but some Wireless APs and VC units do come close.
Quote:
Originally Posted by Evan
Why 3 calls at once, were you billing 3 customers at the same time as well
I had two conflicting conference calls, so was listening to both at the same time. Then someone called my SIP address so I answered it on my PocketPC. Unfortunately I rarely get to bill anyone for my time, especially my conference calls.
Quote:
Originally Posted by Evan
Do you use the IPsec on that router or your VPN is software off your workstation ?
E
Both. I have a permanent PISec tunnel from my router to a location in the USA. The depending on which wireless SSID/VLAN my PC is connected to, it either routes down that IPSec tunnel or is NATed direct to the Internet via my ISP and I can then use a PC VPN client to connect to our Australian VPN gateway (also IPSec).
So if using the Softphone from the USA IP-PBX, I switch to the appropriate wireless SSID/VLAN and route down the IPSec tunnel. If using one of the Australian IP-PBX systems I use the PC VPN client routed to the Australian VPN gateway.
I am yet to find a usable PocketPC IPSec client, so it always connects to the secure SSID/VLAN and routes down the tunnel to the USA IP-PBX.
So when you add the POTS phone attached to my ADSL line, the home POTS line and my Mobile phone, I have quite a few options for making calls! The IP phone via the USA is very handy for calling AA since it is then litterally a local call .
Ahh, yes. That makes more sense. Making it 24-120kbps.
But with VoIP, the most common cause of quality issues are dropped packets and jitter. Unfortunately there is no way to control those things on a public network like the Internet.
Agreed. If we could get all the parties involved to properly use the TOS or Diffserv flags, we could rectify this to a degree. But given the war going on over net neutrality and the requirement that everyone in the chain agree to the rules - I can't see it happening anytime soon. For now, just good old overprovision of BW and hope that the terminating ISPs have few hops to the SONET backbone is the way to go.
Quote:
I believe it is neither. Their direct POTS connection in most cases will be T1/E1 (ISDN in most cases) which use a 64kbps PCM which is similar to G.711. The connection from the Skype client to the POTS gateway uses the Skype proprietary CODEC which is neither G.711 or G.729 (not that it really matters, so long as it works).
<overview snipped>
You have to wonder why they didn't just use G.729. I guess by keeping it proprietary they have to maintain control of the product/service??
After a little digging - I can claim this is work related research - I found that Skype uses an implementation of Internet Low Bit Rate Codec (iLBC)
for the voice codec. RFC is here: http://www.ietf.org/rfc/rfc3951.txt
This seems to degrade more gracefully with dropped packets then either G.711 or G.729. Other VoIP products can use it, so it's not Skype specific.
Quote:
Its amazing what snippets of trivia can be find in a community like this .
You're not kidding. I never thought I would ever see ANY references to 802.3 standards on a FF forum.
Sponsored Links
Registered Users have the option of
removing this and all other advertisements.
More
The real challenge is getting the QoS configured right so I can still surf and replicate my email etc without killing the call quality. Outbound queuing is easy (low latency queuing), but controlling the inbound is the tricky bit .
There are a few ethernet controllers coming onto the market now that allow pre-classification of incoming traffic into separate receive queues. Some of these parts will be cheap enough to go into the sub $200 routers that you find from Netgear and the like. I am not yet aware of how the stack software will interface to these 'smart' ethernet controllers, but the capability is there to do a poor man's NBAR on receive traffic. In theory the same capability can be added to 802.11 controllers, but I have yet to see one.
Member of: AA Exec Plat; QF LTG; PC Plat; HHonors Gold
Posts: 9,844
Re: Skype
Quote:
Originally Posted by mainly tailfirst
You're not kidding. I never thought I would ever see ANY references to 802.3 standards on a FF forum.
So the logical extension is now to discuss the signalling used by Skype . Again I assume its proprietary, but is it some manifestation of H.323, SIP, Q.931 or similar?
Quote:
Originally Posted by mainly tailfirst
There are a few ethernet controllers coming onto the market now that allow pre-classification of incoming traffic into separate receive queues. Some of these parts will be cheap enough to go into the sub $200 routers that you find from Netgear and the like. I am not yet aware of how the stack software will interface to these 'smart' ethernet controllers, but the capability is there to do a poor man's NBAR on receive traffic. In theory the same capability can be added to 802.11 controllers, but I have yet to see one.
The problem is that the point of congestion is way before your receive queues. So unless you start playing with window sizes and delayed flow control (delayed ACKs) there is not much you can do to manage the inbound congestion successfully. And those things only work for TCP streams anyway. But it could be used for classification and marking purposes.
I could never go back to a basic home router after using my Cisco 877W. I have it running three separate SSIDs using VLANs (2 with WPA-PSK and one WEP which is my guest VLAN and only provides rate limited Internet access), outbound Diffserve marking and LLQ, policy-based routing to send some traffic down the IPSec tunnel and other is NATed and sent to the Internet with wo different NAT policies.Its my DHCP server, running IP-Helper between VLANs and makes a pretty good cup of coffee. No Netgear, Linksys, D-Link etc "router" is going to do that! Now if only Cisco made an 800-series router with POE .
But getting back on-topic. I do find using VoIP with a Sotfphone is a very valuable tool when travelling. And its always fun confusing people as to where I am. Making calls when in the USA that have a Caller-ID of 02xxxxxxxx confuses people, as does making calls with a US 817 area code when I am at home in Brisbane. Skype is a means for anyone to be able to take advantage of network bandwidth without the investment in the back-end infrastructure.
So the logical extension is now to discuss the signalling used by Skype . Again I assume its proprietary, but is it some manifestation of H.323, SIP, Q.931 or similar?
Doesn't appear to be based on any previous signalling standard. Given the extraordinary lengths that Skype has gone to in obfuscating it's operation, most of the information I have learnt is based on reverse-engineering papers. The use of the super-node is key and there is a far bit of speculation as to what happens after the supernode is reached. Since everything is encrypted if v.hard to work out what exactly is being exchanged.
Quote:
The problem is that the point of congestion is way before your receive queues. So unless you start playing with window sizes and delayed flow control (delayed ACKs) there is not much you can do to manage the inbound congestion successfully. And those things only work for TCP streams anyway. But it could be used for classification and marking purposes.
Aah, the 'inbound' problem on the WAN side. I assumed you were referring to the 'outbound' from your internal network. I.e. some of your precious upload link was getting clobbered by non-RT traffic. Pre-Classification and hardware support for RED can help with that. Agreed, that not much can be done once it is mixed into a single link (yet).
Quote:
I could never go back to a basic home router after using my Cisco 877W. I have it running three separate SSIDs using VLANs (2 with WPA-PSK and one WEP which is my guest VLAN and only provides rate limited Internet access), outbound Diffserve marking and LLQ, policy-based routing to send some traffic down the IPSec tunnel and other is NATed and sent to the Internet with wo different NAT policies.Its my DHCP server, running IP-Helper between VLANs and makes a pretty good cup of coffee. No Netgear, Linksys, D-Link etc "router" is going to do that! Now if only Cisco made an 800-series router with POE .
True. I run a hacked firmware on my Linksys that does give me some of that functionality, though the rather pokey CPU in it means that the more features I turn on (e.g. VPN tunnel) things like wireless video streaming to my Myth box drop dead. The SW is willing, but the HW is weak...
A lot of what make Cisco routers great is the fact that they run IOS and have great support for their custom HW that they run it on. IMO, as more HW features make it into the low end parts and get supported by Linux, the difference will narrow.
The coffee feature is a new one though. Is it just filter or can it do espresso as well?
Quote:
Skype is a means for anyone to be able to take advantage of network bandwidth without the investment in the back-end infrastructure.
Or more efficiently use that which has already been provisioned.
.
.
. Again I assume its proprietary, but is it some manifestation of H.323, SIP, Q.931 or similar?
Linear Mode
