Is VoIP ready for the real world?

Blaster99

I've been using a few SIP services with different hardware and different ISP's and I'm using Skype quite a bit and it strikes me that the VoIP codecs are much more sensitive to connection issues where the call quality often suffers from echo, jitter, complete breakups, and lag. On the other hand, Skype-to-Skype calls are nearly without fail perfect. In my experience, it doesn't really matter how far apart the Skype users are in network terms, it's still very good. With VoIP, it's challenging to use a VoIP provider in another country.

Would it be fair to say that the VoIP codecs are designed to run on internal well managed networks as run by telcos, as opposed to the often variable quality of a retail user's internet connection? Are there moves to improve the codecs or are the telcos the industry drivers with different requirements from the independent operators?

JimmySmith

I dont think its ready for prime time yet. To use this for business where incoming calls = money is not an option. There are call break ups and the customer may not call back. Sometimes customers call you on your mobile to say they cant get through on the landline.

Tried several different providers and they all have the same problem, some morte than otheres but there are problem calls with all providers. Funnily enough Skype always seems perfect.

I'm sure its not too much of an issue for just personal calls, but its a business killer when these things happen.

For outgoing calls its ok, but you can piss off customers when your voice is breaking up. I dont know if the low outgoing call cost justifys the potential for call breakups with VOIP.

probe

I never have problems with “echo, jitter, complete breakups and lag” using SIP, though it did take a bit of experimentation with choice of CODECs with one SIP provider.

I live on the Continent and have one Irish VoIP provider and one local one. Sound quality on the Irish VoIP provider is 99.99% perfect. Sound on the other VoIP provider was awful until I played about with the CODEC list on the phone web interface, and it is fine now. I have a Snom (www.snom.de) VoIP phone which I would give 9 out of 10 to (it loses a few % on the limited choice of melodically boring Germanic ringing melodies).

Almost 10% of phone lines in France are now VoIP and one seldom hears complaints about call quality. In most cases the lines are unbundled so the VoIP provider is the same as the broadband provider which (a) eliminates the possibility of the ISP engaging in dirty tricks against VoIP traffic going to competitor VoIP service providers and (b) ensures use of standard CODECS which work best with the VoIP providers’ kit. Having said that I don’t suffer by paddling my own VoIP canoe and using a selection of independent VoIP providers unconnected with my ISP.

If I was a business user in Ireland, I would hold on to some ISDN channels for incoming calls and DDI and route outgoing traffic over VoIP having shopped around for the best combination of VoIP provider and ISP and made sure that I had the CODEC settings right. I would advertise SIP addresses (eg 0766799999@myVoIP.ie as well as regular E.164 number (eg 034 567 8900). This would allow other SIP phone users to call me directly rather than using a PSTN/ISDN number which involves two different network technologies and platforms.

Skype to Skype calls are effectively pure VoIP calls – the traffic packets are directly routed over the internet to the destination user’s IP address. I also use Skype and find it OK for most calls – the main problem being call quality on calls terminating on mobile numbers. One wonders if Skype route mobile calls half way around the world trying to save a few cents per minute!

probe

aaronc

Blaster99 wrote:

I've been using a few SIP services with different hardware and different ISP's and I'm using Skype quite a bit and it strikes me that the VoIP codecs are much more sensitive to connection issues where the call quality often suffers from echo, jitter, complete breakups, and lag. On the other hand, Skype-to-Skype calls are nearly without fail perfect. In my experience, it doesn't really matter how far apart the Skype users are in network terms, it's still very good. With VoIP, it's challenging to use a VoIP provider in another country.

Would it be fair to say that the VoIP codecs are designed to run on internal well managed networks as run by telcos, as opposed to the often variable quality of a retail user's internet connection? Are there moves to improve the codecs or are the telcos the industry drivers with different requirements from the independent operators?

Skype use ilbc as their codec and in the coding/decoding of voice signals they are no different from pretty much any other VoIP system. The main difference with Skype is their transport mechanism, seemingly a hybrid peer-to-peer network, as oppossed to your standard VoIP provider operating a centralised network.

Aaron

Blaster99

From http://www.voip-info.org/wiki-iLBC:

"Basic quality higher than G.729A, high robustness to packet loss"

I think that says it all really. What's the story with codecs like iLBC and VoIP equipment? Is it or will it be supported?

I did a quick google on Skype codecs, and it seems they might be using iSAC also, which uses more bandwidth but is also quite resistant to packet loss. I suppose nobody knows for sure because Skype aren't the sort to say much about how their stuff works. But it does work really well, and the SIP world has a lot to learn from them in terms of easily achievable quality and simplicity of installation and use.

aaronc

Blaster99 wrote:

From http://www.voip-info.org/wiki-iLBC:

"Basic quality higher than G.729A, high robustness to packet loss"

I think that says it all really. What's the story with codecs like iLBC and VoIP equipment? Is it or will it be supported?

Quality is subjective and you'll see jsut as many if not more people saying g729 sounds better than ilbc (most SIP based providers do support ilbc). The statement could be right on the packet loss front though, g729 doesn'ttend to do a great job there. The message here though is once you're trying to milk a call with low bandwidth and packet loss the results are rarely going to be great and if you find something that works you're lucky.

Blaster99 wrote:

I did a quick google on Skype codecs, and it seems they might be using iSAC also, which uses more bandwidth but is also quite resistant to packet loss. I suppose nobody knows for sure because Skype aren't the sort to say much about how their stuff works. But it does work really well, and the SIP world has a lot to learn from them in terms of easily achievable quality and simplicity of installation and use.

A lot of Phd's have been devoted to reverse engineering Skype so there is quite a lot known about it. I would agree wholeheartedly that the SIP designers could have done a lot better by using some of the Skype mechanisms in regards to NAT traversal and HTTPS tunnelling but apart from that there's probably not a lot of difference between them (Skype did come along after SIP). At it's heart SIP is fairly simple, there are only 7 different request types and of those only the INVITE one involves anything more than simple processing.

Skype has taken a highly practical and obviously highly successful approach to getting packets around the internet. SIP takes a very elegant, flexible approach but comes unstuck with NAT. The way things are looking at the moment IPv6 addresses will get into circulation before there is any widespread agreement about the best way to circumvent NAT.

If you're really trying to get a good picture of whether VoIP/Skype is ready for the mainstream you should be looking at Japan, South Korea and the US. Talking about whether a 20Kbps codec does a better job than a 32Kbps codec becomes fairly meaningless once you can count on > 1Mbps.

Aaron

jimmycrackcorm

Having NTL cable and being in a position to get rid of my phone line - then I'd say yes. The real world does not revolve totally around business use. My real world is that i'm currently paying a bill to eircom that is > 90% line rental + extras and I can get rid of it - but like most people i'm more dependent on mobiles. So what if Voip isn't 100% flawless - it's more than a good substitue for me.

The only issue I have is that unless you have a preset ATA, it is technically difficult to get set up.

Blaster99

aaronc wrote:

Quality is subjective and you'll see jsut as many if not more people saying g729 sounds better than ilbc (most SIP based providers do support ilbc). The statement could be right on the packet loss front though, g729 doesn'ttend to do a great job there. The message here though is once you're trying to milk a call with low bandwidth and packet loss the results are rarely going to be great and if you find something that works you're lucky.

The real world is not packet loss free and is not full of stable pings and packets arriving in the right order. Skype is significantly better at dealing with the internet connections I've thrown at it and that's presumably down to the codec. I will continue to maintain that stuff like G.729a is geared towards managed networks with QoS etc and Skype (iLBC/iSAC) deals with the real world.

aaronc wrote:

If you're really trying to get a good picture of whether VoIP/Skype is ready for the mainstream you should be looking at Japan, South Korea and the US. Talking about whether a 20Kbps codec does a better job than a 32Kbps codec becomes fairly meaningless once you can count on > 1Mbps.

I've used both G.729a and Skype on anything from a 128kbps ADSL connection to a 4Mbps wireless connection. Skype worked fine on anything, G.729a only worked reliably on the 128kbps connection, presumably because it was an eircom line and they do a good job once they get around to it. So bandwidth doesn't really make that much of a difference in my experience. Wireless connections tend to suffer from packet loss so that's probably why Skype worked well and G729a (or G.711) did not. I incidently deal with a guy in Germany who uses an Irish VoIP provider and he gets poor quality on an ADSL line in Germany. Skype is on the other hand perfect.

Do you support the iLBC or iSAC codecs? I would be interested in doing some tests with them to see if they are the holy grail of codecs. None of my devices support it, mind you. Is there a SIP/iLBC (or iSAC) soft phone around?

aaronc

Blaster99 wrote:

The real world is not packet loss free and is not full of stable pings and packets arriving in the right order. Skype is significantly better at dealing with the internet connections I've thrown at it and that's presumably down to the codec. I will continue to maintain that stuff like G.729a is geared towards managed networks with QoS etc and Skype (iLBC/iSAC) deals with the real world.?

Fair enough but you'd be wrong. Claiming that ilbc and isac are the only codecs that have been designed to take into account the internet/real World and that every other codec is only suitable for utopian conditions doesn't hold from a theoretical (ilbc/isac are lossy codecs and therefore cannot be better at coping with loss and jitter compared to lossless ones such as ulaw/alaw) or empricial point of view.

If you were to claim the Skype system was the only one the that worked in the real World you could then dismiss the theoretical argument and get down to the empricial one. If you then counted up the number of people happily using non-Skype VoIP systems on the public internet with no end-to-end QoS/management then about the time you went past the 5 million mark you'd probably have to agree that maybe it does work for some people. There may be as many or more people happily using Skype but that doesn't mean the non-Skype systems don't work.

As for Skype providing the best experience for you over all the VoIP systems you've tried then that is completely accepted as Skype is a very good system.

Blaster99 wrote:

I've used both G.729a and Skype on anything from a 128kbps ADSL connection to a 4Mbps wireless connection. Skype worked fine on anything, G.729a only worked reliably on the 128kbps connection, presumably because it was an eircom line and they do a good job once they get around to it. So bandwidth doesn't really make that much of a difference in my experience. Wireless connections tend to suffer from packet loss so that's probably why Skype worked well and G729a (or G.711) did not. I incidently deal with a guy in Germany who uses an Irish VoIP provider and he gets poor quality on an ADSL line in Germany. Skype is on the other hand perfect.

I've seen g729 NOT work on a 4Mbps\256kbps link and using the quoted ISP maximum speeds as a gauge of available bandwidth is very, very unreliable. ilbc does use less bandwidth than g729 so it's quite feasible it willwork in places where g729 and higher bandwidth codecs like g711 won't. Of course there will be a point where ilbc breaks down as well and I'd be suprised if your Skype calls are crystal clear over a wireless connection in Dublin between 7 to 9pm.

Blaster99 wrote:

Do you support the iLBC or iSAC codecs? I would be interested in doing some tests with them to see if they are the holy grail of codecs. None of my devices support it, mind you. Is there a SIP/iLBC (or iSAC) soft phone around?

Blue Face do support ilbc yes. I think just about every softphone, and hardware device for that matter, I've come across supports ilbc and the xlite certainly does. I'm not too familair with isac but it looks to be a completely proprietary codec that has not be widely licensed and I don't know of any softphones that support it.

Aaron

lzbones

All of the big players (Skype, Google, Yahoo, MSN, Gizmo) use iSAC from GIPS the big advantage of iSAC is that it's adaptive ie. low bandwidth line adapts codec to low bandwidth - high bandwidth line adapts to high bandwidth. This is why in places like US where large amount of bandwidth is available they get very high quality skype calls and in Ireland we get lower quality but it still works well in both.

http://www.globalipsound.com/solutions/solutions.php

Blaster99

aaronc wrote:

Fair enough but you'd be wrong. Claiming that ilbc and isac are the only codecs that have been designed to take into account the internet/real World and that every other codec is only suitable for utopian conditions doesn't hold from a theoretical (ilbc/isac are lossy codecs and therefore cannot be better at coping with loss and jitter compared to lossless ones such as ulaw/alaw) or empricial point of view.

I'm trying to understand why it is that Skype is so much better than G.729a. And that is incidently empirical "fact" based on my significant user experience and that of others that I know. If you look at the user base here, the people who are typically happy with SIP are NTL users. I would hazard a guess that NTL runs a sweet operation. VoIP works really well over eircom's ADSL in my experience, in fact I would call it perfect. Skype works well on anything I've tried within reasonable limits.

I'm incidently primarily interested in finding out why Skype works and why G.729a doesn't in many conditions, but if I were running a VoIP service in Ireland I would probably not try to dismiss this stuff and instead figure out how I can sell a service to people on networks other than NTL in a reliable fashion. Last time I looked, IBB had more customers than NTL. Digiweb is obviously expanding rapidly etc.

aaronc wrote:

If you then counted up the number of people happily using non-Skype VoIP systems on the public internet with no end-to-end QoS/management then about the time you went past the 5 million mark you'd probably have to agree that maybe it does work for some people. There may be as many or more people happily using Skype but that doesn't mean the non-Skype systems don't work.

I'm sure it works for some or most people or it wouldn't exist. I can only gauge my own experience of running Skype or SIP in various conditions, and Skype is on a different planet in terms of dependable quality. I can't imagine I'm the only one to have noticed that.

aaronc wrote:

I've seen g729 NOT work on a 4Mbps\256kbps link and using the quoted ISP maximum speeds as a gauge of available bandwidth is very, very unreliable.

We can perhaps for a moment assume that I'm not stupid. On that particular link I never got less than 1Mbps in either direction. Seeing as these codecs at most use 64Kbps, speed is not really the issue. I know you guys seem a bit hung up on this, but it's not a problem I've come across. Besides, the very low upload speeds are practically history now in any event.

aaronc wrote:

ilbc does use less bandwidth than g729 so it's quite feasible it willwork in places where g729 and higher bandwidth codecs like g711 won't. Of course there will be a point where ilbc breaks down as well and I'd be suprised if your Skype calls are crystal clear over a wireless connection in Dublin between 7 to 9pm.

I was a little unclear and perhaps have given Skype too much credit. There have certainly been times when a wireless connection with serious packet loss and 1s pings have completely bollocksed Skype too. But in normal circumstances Skype has always outperformed G.729. I've had problems with wireless connections at any time of the day, incidently. Over a typical wireless connection I couldn't hold a G.729 conversation over a five minute period that didn't have several complete drop-outs whereas with Skype there would typically be no problems at all.

aaronc wrote:

Blue Face do support ilbc yes. I think just about every softphone, and hardware device for that matter, I've come across supports ilbc and the xlite certainly does. I'm not too familair with isac but it looks to be a completely proprietary codec that has not be widely licensed and I don't know of any softphones that support it.

Great stuff, I'll give it a shot. Neither of my hardware devices support iLBC from what I can tell, but I'll give X-Lite a shot. All I need now is a crappy internet connection.

Sponge Bob

Part of the answer you seek Blaster99 ...going forward...probably lies in a QoS based INEX where the Voip is partitioned off and peered differently .

Sleipnir

JimmySmith wrote:

I dont think its ready for prime time yet. To use this for business where incoming calls = money is not an option.

Dunno about that. I'm implementing Cisco VOIP in place of the auld PABX for a company of about 200 across 3 sites. There are huge advantages e.g. calls from out london office to our dublin office won't be charged at international rates. Also, you can have to so that if I want to call a number in the U.K. from Dublin, the call will originate from the London office. Of course you have to consider downtime but the same is true for email or any other business critical system.

Blaster99

Sleipnir wrote:

I'm implementing

Maybe you can come back to us when the service has been in use for a few months. Nobody is debating that VoIP works on internal well-managed networks or on high quality internet connections with close proximity to the SIP provider.

Sponge Bob

Fire them all down a 2Mbit VPN along with the MS Network Chatter on Port 139 and then see what the users reckon

aaronc

Blaster99 wrote:

I'm incidently primarily interested in finding out why Skype works and why G.729a doesn't in many conditions, but if I were running a VoIP service in Ireland I would probably not try to dismiss this stuff and instead figure out how I can sell a service to people on networks other than NTL in a reliable fashion. Last time I looked, IBB had more customers than NTL. Digiweb is obviously expanding rapidly etc.

Personally I'm not dismissing it at all and I'd be more than interested to know more about why one VoIP system works better than another under certain conditions. The problem here though is the systems are complex enough (once you take into account the user end, the network and the provider's systems) that you could almost turn each investigation into Masters project. From a provider's point of view it's more worthwhile to pressure ISPs to provide connections with less loss and less jitter rather than try and squeeze the last bits out of bad connections.

Blaster99 wrote:

We can perhaps for a moment assume that I'm not stupid.

I did that, assume you're not stupid that is. It takes a fair bit of thought to respond to these threads and speaking for myself I wouldn't do so if I thought it was going to waste .

Aaron

Freddie59

aaronc wrote:

Personally I'm not dismissing it at all and I'd be more than interested to know more about why one VoIP system works better than another under certain conditions. The problem here though is the systems are complex enough (once you take into account the user end, the network and the provider's systems) that you could almost turn each investigation into Masters project. From a provider's point of view it's more worthwhile to pressure ISPs to provide connections with less loss and less jitter rather than try and squeeze the last bits out of bad connections.

I did that, assume you're not stupid that is. It takes a fair bit of thought to respond to these threads and speaking for myself I wouldn't do so if I thought it was going to waste .

Aaron

Speaking as a Bluface customer of almost four months I can't fault it. Some slight teething problems, and reselecting codecs, and everything is fine. Only complaint I have (and it isn't Blueface's fault) is the length of time it takes to port from Eircon. Ten days to go from UTV - Eircom. EIGHT WEEKS to port from Eircon to Blueface.:mad: Otherwise Blueface VOIP is brilliant.:D
I would definitely recomment it to any domestic consumers.:)

Blaster99

I found a pretty good piece of research on codecs: http://www.ero.dk/documentation/docs/doc98/official/pdf/ECCREP051.PDF. Section 7 is the most relevant. The graph on page 17 is particularly telling. I have a nagging suspicion that the document has been written by somebody who's associated with GlobalIPSound, the makers of iLBC, but it's interesting all the same.

In summary, the problem is that codecs like G.729 and G.711 are designed for circuit-switched networks which have bit errors. Packet networks have packet loss which these codecs are not designed to deal with. iLBC, iSAC, etc are designed for packet networks and are designed to recover from packet loss very quickly.

This is presumably why Skype is superior in less than perfect conditions. Even if G.711 and G.729 perform acceptably in situations with low packet loss, I would personally think they should be deprecated in a VoIP environment as they're not designed for it and we should move towards codecs that are designed for packet networks.

I found a site on my travels with a codec support matrix, http://compare.ozvoip.com/codecsupport.php. iLBC is poorly supported in comparison to the traditional CELP codecs and indeed neither of my boxes support it. Which is a bummer.

JimmySmith

I notice that a lot of the talk about improving your voip performance revoles around 'selecting the right codec'. All very well, but i've never seen a voip provider list the right codec for particular situations.
voip providers should post such info on their websites and save themselves a few support calls. Its not good to have the customers experimenting with codecs, because one could be fine one minute and the next rubbish.


aaronc,
As the only voip provider that tries to help out around here (pity the other providers wouldnt do the same)
for example can you tell blueface users the correct codec to use in the following situations assuming everyone has at least a 1M down /256k up connection.

Condition Codec to use
No packet loss fixed line
wireless provider (some packet loss)


Also i notice you said that blueface supports the ilbc codec, but how does a customer go about using it.

If you could answer these questions here you could save yourself some support calls. Even better if you had it on your website though.

Sleipnir

Blaster99 wrote:

Maybe you can come back to us when the service has been in use for a few months. Nobody is debating that VoIP works on internal well-managed networks or on high quality internet connections with close proximity to the SIP provider.

Well about 50 of them have been set up without a problem.

Sponge Bob

Sleipnir wrote:

Well about 50 of them have been set up without a problem.

Well Done My Man ! Especially since Cisco only announced SIP support 2 days ago

Blaster99

I should have added that those packet network optimised codecs can handle packet loss in the region of 25-30% with little quality degradation. Sounds like a dream scenario for Irish Broadband users.

Does anyone know if there's a G.711 to iLBC converter around that I can connect my IP phones to internally and then use iLBC externally? Can this be achieved with Asterisk?

Sleipnir

Sponge Bob wrote:

Well Done My Man ! Especially since Cisco only announced SIP support 2 days ago

Well as the man said "The great thing about standards is that there's thousands to choose from"

We currently have Cisco Call Manager 4.1 and SIP will be integrated into version 5.0

aaronc

JimmySmith wrote:

the correct codec to use in the following situations assuming everyone has at least a 1M down /256k up connection.

Condition Codec to use
No packet loss fixed line
wireless provider (some packet loss)

With a good connection g711 is the recommended codec. g711 comes in two flavours ulaw and alaw, alaw is what's used in Europe so is what should be selected (on the xten this is G711a), either will work fine though.

If g711 doesn't work then I would suggest g729 as that does have a reputation as being a very good low bandwidth codec.

If g729 doesn't work then I would suggest trial and error and going on Blaster's advice also try Skype. Try all the codecs your device supports and possibly different frame rates as well. It's important to realise that wireless internet technologies in particular are cutting edge and the connections can be highly variable with regards to loss and jitter while sometimes maintaining ok average data throughput.

VoIP running over wireless internet is pretty good when you think about it. Yes there are lots of issues because it's new but in 3 years time when it's issues with video over wireless at least you'll be able to ring up customer support.

JimmySmith wrote:

Also i notice you said that blueface supports the ilbc codec, but how does a customer go about using it.

If you could answer these questions here you could save yourself some support calls. Even better if you had it on your website though.

Most devices do let you specify allowed codecs or the priority of them. If your's doesn't or you just don't want to stuff around email us and we'll force your connection to use a particular codec.

Point taken about the support pages and we do have a revamp in the pipeline. The other complaint we get about our support pages is that they contain too much techno mumbo jumbo . However I'm sure we can find a way to put it off to one side with a big warning notice or something.

Aaron

aaronc

Blaster99 wrote:

I should have added that those packet network optimised codecs can handle packet loss in the region of 25-30% with little quality degradation. Sounds like a dream scenario for Irish Broadband users.

I'd be very interested to hear how you get on (ulterior motives aside). I suspect if it's a constant packet loss you've got, i.e. dropping 1 in 4 or 5 packets, it will work fine but if it's spikey with 100% drop for a second or two there will be nothing the codec can do.

Blaster99 wrote:

Does anyone know if there's a G.711 to iLBC converter around that I can connect my IP phones to internally and then use iLBC externally? Can this be achieved with Asterisk?

Yes, it's called transcoding and Asterisk will handle it for you very nicely.

Aaron

Blaster99

aaronc wrote:

If g729 doesn't work then I would suggest trial and error and going on Blaster's advice also try Skype.

My advice is to avoid G.711 and G.729 and use iLBC where supported. If it can handle 25% packet loss, that's damned good. I've never noticed much of a difference between G.711 and G.729 (either both work fine or neither work well). All G.729 does it to use less bandwidth and bandwidth is rarely an issue. Packet loss, latency, and packet order are the problems and neither G.711 and G.729 can deal with it.

Blaster99

aaronc wrote:

I'd be very interested to hear how you get on (ulterior motives aside). I suspect if it's a constant packet loss you've got, i.e. dropping 1 in 4 or 5 packets, it will work fine but if it's spikey with 100% drop for a second or two there will be nothing the codec can do.

Yes, it's called transcoding and Asterisk will handle it for you very nicely.

Aaron

The problem, if you can call it that, is that I no longer use an ISP that's prone to packet loss so I can't test it properly. But I'm still interested in setting up a G.711 -> iLBC transcoder/gateway using Asterisk and will devote some time to it the next little while, as a scientific experiment...

Assuming iLBC works as advertised, what would be really handy for all involved is if this could be packaged and installed on a Linux or Windows machine so anyone could avail of iLBC without having to get special equipment for it.

JimmySmith

Blaster99 wrote:

My advice is to avoid G.711 and G.729 and use iLBC where supported. If it can handle 25% packet loss, that's damned good. I've never noticed much of a difference between G.711 and G.729 (either both work fine or neither work well). All G.729 does it to use less bandwidth and bandwidth is rarely an issue. Packet loss, latency, and packet order are the problems and neither G.711 and G.729 can deal with it.

Question for you guys. I would like to try the iLBC codec
Is it possible to get the linsys wrtg54p2 router to use the iLBC codec though.
I dont see it in the dropdown list at all. Can i get it anywhere that the router can use it.

Blaster99

I doubt that ATA supports it. You can try it with the X-Lite soft phone. It should be downloadable from here: http://www.tucows.com/get/309984_117238. You need a headset as well. There are instructions on Blueface's support site for how to set it up. You should disable the codecs other than iLBC.

I haven't been able to find a line with packet loss, so I haven't been able to do any meaningful testing. If you have a line without packet loss, G.711 gives the best quality as it's uncompressed. G.729a and iLBC much the same.

Your Linksys probably gives call stats on ongoing calls, so you can see if you're getting packet loss during calls as a way of troubleshooting the problem.

Blaster99

Also, I think Skype sounds better than iLBC so I don't think they're using that codec. They're probably using iSAC instead.

lzbones

JimmySmith wrote:

aaronc,
As the only voip provider that tries to help out around here (pity the other providers wouldnt do the same)

I asked my provider why they did not take part in boards.ie - they said they were banned -- methinks these boards are a little biased.

JimmySmith

Blaster99 wrote:

I doubt that ATA supports it. You can try it with the X-Lite soft phone. It should be downloadable from here: http://www.tucows.com/get/309984_117238. You need a headset as well. There are instructions on Blueface's support site for how to set it up. You should disable the codecs other than iLBC.

I haven't been able to find a line with packet loss, so I haven't been able to do any meaningful testing. If you have a line without packet loss, G.711 gives the best quality as it's uncompressed. G.729a and iLBC much the same.

Your Linksys probably gives call stats on ongoing calls, so you can see if you're getting packet loss during calls as a way of troubleshooting the problem.

Thanks for that.
I'd like to be able to use the phone without the pc on though. i think i'll stivk to using voip for outgoing calls only for now.

Blaster99

I didn't mean for you to permanently switch to the soft phone. You obviously bought the PAP for a reason. But if you do some testing with the softphone and find that the iLBC codec works more reliably for you, then you at least have some data to work on. What's your ISP?

JimmySmith

Useing Netsource at the moment for voip. Its not amazing but works ok for the home phone.
I also have i have ICE comms wireless. Thats the one i want to use the VOIP on, so i dont have to pay line rental. The plan is that as soon as voip is reliable i ditch the landline. I understand that wireless has some packet loss so thats why the interest in which codec handle packet loss given that bandwidth is not a concern, 2Mb/512K up.
ICE used to be a great service but its been extremely flakey the last month or so. Massive slowdowns and huge packet loss. This has also been happening for other ICE users i know over the last month. Which reminds me i must post a thread on ICE.

Blaster99

These are my ping stats to sip.blueface.ie right now:

Statistics for sip.blueface.ie:
Packets: sent=500, rcvd=462, error=0, lost=38 (7% loss) in 49.640521 sec
RTTs of replies in ms: min/avg/max: 37.597 / 39.636 / 53.737

G.711 works poorly from my IP phone, lots of noticable dropouts. Using X-Lite with iLBC works better but it's difficult to compare them for sound quality as I'm using a phone in one case and headset in another and X-Lite always sounds a bit iffy in my opinion.

Skype-to-Skype around this time sounded amazingly good, like in the next room. SkypeOut at this time had no quality problems other than that the far end sounded like they were in a barrel. But maybe that's just the way a telephone sounds when you're comparing it with a wideband codec.

The ping stats for the Skype user:
Packets: sent=500, rcvd=480, error=0, lost=20 (4% loss) in 49.923004 sec
RTTs of replies in ms: min/avg/max: 47.125 / 115.754 / 353.109

And here are some stats for other SIP providers:

Statistics for smart076.ie:
Packets: sent=500, rcvd=498, error=0, lost=2 (0% loss) in 49.916410 sec
RTTs of replies in ms: min/avg/max: 15.194 / 17.089 / 28.458

Statistics for sip.broadtalk.ie:
Packets: sent=500, rcvd=486, error=0, lost=14 (2% loss) in 49.916176 sec
RTTs of replies in ms: min/avg/max: 15.277 / 39.933 / 258.026

Statistics for sip.voipcheap.com:
Packets: sent=500, rcvd=467, error=0, lost=33 (6% loss) in 49.326238 sec
RTTs of replies in ms: min/avg/max: 25.748 / 28.680 / 154.815

These ping tests were done with

hrping -s 100 -n 500 -l 32

I would suggest that anyone thinking of going VoIP with something like G.711 or G.729 should run a lot of ping tests to a selection of VoIP providers.

Once I have the G.711 -> iLBC transcoder setup, I'll post some more results.

WillieFlynn

Blaster99 wrote:

The real world is not packet loss free and is not full of stable pings and packets arriving in the right order. Skype is significantly better at dealing with the internet connections I've thrown at it and that's presumably down to the codec. I will continue to maintain that stuff like G.729a is geared towards managed networks with QoS etc and Skype (iLBC/iSAC) deals with the real world.

I found that VoIP providers like blueface, work much better than Skype; to the point that I no longer use skype. (BTW my ISP is netsource, my brother also uses blueface with no problems from Finland)

Also every smart broadband customer, is using VoIP for normal landline calls whether they know it or not. Then you have BT in the UK, where they are replacing all phone lines with VoIP. So the common VoIP protocols, do cut it in the real world.

It is possible that under some conditions skype works better. The main advantage which skype has, is that it can get through firewalls in companies with out having to get premission.

Blaster99

"works better", what does that mean?

Freddie59

Blaster99 wrote:

"works better", what does that mean?

I would presume it means of a higher quality. When Skype-Skype is used between two PCs it's FM quality sound. It can't be beaten. But not everyone wants to sit at, or use the phone via, a PC.

No-one's knocking Skype - merely giving Blueface the credit they deserve (take a bow lads). As I've said already, I have it and it works perfectly. As I'm a domestic customer, I presume that would be classed as the 'real world'?

aaronc

Blaster99 wrote:

These ping tests were done with

hrping -s 100 -n 500 -l 32

I would suggest that anyone thinking of going VoIP with something like G.711 or G.729 should run a lot of ping tests to a selection of VoIP providers.

Ping tests are not the best way to test a connection for VoIP except to give an idea of the latency of a connection and a very rough gauge of packet loss. If your ping reposne times are less than 150ms or 200ms then it's unlikely you will notice anything on your call. With regards loss you'll often find a connection getting 0% ping loss but if you load it up with RTP traffic you can find up to 5% loss.

I'm not familair with hrping but I assume what that line is saying is send an ICMP Ping every 100ms with a 32 byte payload 500 times. The payload is a bit small for VoIP but ignoring that the test is only 50 seconds which probably isn't enough to give a connection the workout it will typically get from a real call.

The call audio test is of course the best measure but if you want to get metrics on a connection ideally you'd send UDP packets at intervals of around 20 to 30ms with payloads of 80 to 160 bytes. If you've got a Windows machine you can test your connection using a little app we whipped up precisley for this purpose:

http://www.blueface.ie/downloads/BlueFaceNetQualityMonitor-0.3.0.msi

Aaron

Blaster99

aaronc wrote:

Ping tests are not the best way to test a connection for VoIP except to give an idea of the latency of a connection and a very rough gauge of packet loss. If your ping reposne times are less than 150ms or 200ms then it's unlikely you will notice anything on your call. With regards loss you'll often find a connection getting 0% ping loss but if you load it up with RTP traffic you can find up to 5% loss.

I would disagree about not noticing anything. Last night, when I had about 7% packet loss, I could very clearly hear it. As I was making the calls, I checked the phone status which has an absolute packet loss counter, and every time I heard a dropout, the counter went up. I have never suffered any real problems from latency, but I don't think I've ever seen it worse than 150ms. I could also tell from the pinging that the packet loss would typically occur in groups. Perhaps this is normal. On the phone, the packet loss counter always jumped by perhaps 5 packets at a time.

Tonight when I have a lot less or no packet loss, the line quality is excellent.

aaronc wrote:

I'm not familair with hrping but I assume what that line is saying is send an ICMP Ping every 100ms with a 32 byte payload 500 times. The payload is a bit small for VoIP but ignoring that the test is only 50 seconds which probably isn't enough to give a connection the workout it will typically get from a real call.

The reason hrping is much better than ping is that ping sends a packet once a blue moon. With hrping you can fire packets much more often to get a better picture of what's going on. I appreciate that ping has limitations but it's the best I had at hand. I had to set the packet size low to get Smart's SIP gateway to respond to the pings, to get the comparative numbers.

I sent 500 packets to not have to spend a lifetime gathering ping stats and I incidently ran these tests a few times and I got pretty consistent numbers back from the SIP gateways I tested with. In the case of Blueface, I'm fairly sure the problem is not with Eircom but with the transit between Eircom and Blueface. When you get the INEX stuff up and going, I would expect that to be resolved. With other networks my experience has been that the problem is typically either access contention or in internal backhaul and no INEX peering in the world is going to solve that.

aaronc wrote:

The call audio test is of course the best measure but if you want to get metrics on a connection ideally you'd send UDP packets at intervals of around 20 to 30ms with payloads of 80 to 160 bytes. If you've got a Windows machine you can test your connection using a little app we whipped up precisley for this purpose:

You da man. I ran it there and it's v cool app! It confirmed something I suspected, which is that the packet loss occurs more frequently outbound than inbound in my case. I enabled silence suppression last night and the incoming audio sounded a lot better. I'm guessing the outbound packet loss was echoed back to me as I was listening and when I switched on silence suppression, there was no traffic from me and the phone reported a lot less packet loss as well. Don't know if that makes sense or not. I incidently got less packet loss with G.729 as well, presumably because it's sending less or smaller packets, and therefore it sounded better. So using G.729 helps, but it's just a workaround and doesn't really solve the underlying issue in my opinion.

Another thing is that your app is reporting significantly higher jitter than my phone does. My phone shows jitter around 8ms, your app shows it at 30ms. I don't know what the story is there. Maybe this is the power of hardware accelerated codecs.

aaronc

Blaster99 wrote:

Another thing is that your app is reporting significantly higher jitter than my phone does. My phone shows jitter around 8ms, your app shows it at 30ms. I don't know what the story is there. Maybe this is the power of hardware accelerated codecs.

The app does not subtract the correct interarrival arrival time from the actual arrival interval so a packet that arrives correctly spaced at 20ms will show as having a jitter of 20ms. This keeps the jitter lines above 0 and makes the graphs easier to read to be more correct jitter on the graphs should be called interarrival time. The app tries to send out 20ms spaced packets so if you subtract 20ms from the jitter readings it should be more in line with what other tools will report.

The measurements should not be relied upon to be too accurate though given that the app is entirely dependent on the PC resources. The measurements should be used as a rough gauge and the most important one are packet loss and jitter discards. Generally if there's no red or orange lines showing up on the graphs the calls on a connection will be ok.

Aaron

JimmySmith

I might try that app later on.
aaron, i've tried your echo test before, which i think you get by calling 331 or somthing like that.
Its a great app, but you should really have it let you speak for about 30 seconds and then have it played back to you. Its very hard to judge the quality when its played back about 1 second after you speak because you're speaking and listening at the same time.

I'm still looking for the best voip provider, and will be checking quality often to see how the technology is going, but will be holding onto the eircom line as well for now i think.

aaronc

JimmySmith wrote:

I might try that app later on.
aaron, i've tried your echo test before, which i think you get by calling 331 or somthing like that.
Its a great app, but you should really have it let you speak for about 30 seconds and then have it played back to you. Its very hard to judge the quality when its played back about 1 second after you speak because you're speaking and listening at the same time.

I'm still looking for the best voip provider, and will be checking quality often to see how the technology is going, but will be holding onto the eircom line as well for now i think.

The echo test is on 301 (most Asterisk based providers will have it on this number). The echo test is mainly designed to measure latency not quality. When you speak if you hear your voice back almost instantaneously then you have low latency. if you wait for a few seconds and then you hear your voice you've got very high latency. You'll hear your latency shoot up if you try a donwload at the same time as the echo test.

Aaron

JimmySmith

aaronc wrote:

The echo test is on 301 (most Asterisk based providers will have it on this number). The echo test is mainly designed to measure latency not quality. When you speak if you hear your voice back almost instantaneously then you have low latency. if you wait for a few seconds and then you hear your voice you've got very high latency. You'll hear your latency shoot up if you try a donwload at the same time as the echo test.

Aaron

I see.
Wouldnt it be a good idea then to allow the user to test quality too?

Blaster99

aaronc wrote:

The measurements should not be relied upon to be too accurate though given that the app is entirely dependent on the PC resources. The measurements should be used as a rough gauge and the most important one are packet loss and jitter discards. Generally if there's no red or orange lines showing up on the graphs the calls on a connection will be ok.

When does a jitter discard occur? Is that once jitter exceeds a threshold?

aaronc

JimmySmith wrote:

I see.
Wouldnt it be a good idea then to allow the user to test quality too?

Yes, you just call somebody.

Aaron

aaronc

Blaster99 wrote:

When does a jitter discard occur? Is that once jitter exceeds a threshold?

Yes. All VoIP devices will typically operate with a jitter buffer that allow the packets to arrive out of order or with different inter-arrival spacings (jitter). If a jitter buffer is not used every packet would have to arrive exactly when the audio device is expecting it or it would be discarded. With a jitter buffer there is a window in which the packet can arrive and be put into the correct sequence to be passed to the audio device. The catch is if the jitter buffer is too large you introduce latency into the call and you get the annoying talkover where both parties pause and then start speaking at once.

In our app the jitter buffer is set at 10 x frame size, currently working out to about 2 seconds. This is very generous and most devices would typically have dynamic jitter buffer with a maximum size of 200ms.

Aaron

Blaster99

Assuming that what this test tool is telling me is correct, why is it testing against 82.195.148.216? Seeing as that is hosted by Hosting365, it's not terribly representative is it?

Freddie59

Blaster99 wrote:

Assuming that what this test tool is telling me is correct, why is it testing against 82.195.148.216? Seeing as that is hosted by Hosting365, it's not terribly representative is it?

You don't work for another VOIP outfit or Eircom by any chance, do you? You seem to be extremely knowledgable about it.:)

aaronc

Blaster99 wrote:

Assuming that what this test tool is telling me is correct, why is it testing against 82.195.148.216? Seeing as that is hosted by Hosting365, it's not terribly representative is it?

nslookup www.blueface.ie (depending on your ISP this will generally be using INEX). We don't want the tests to interfere with our real calls in anyway. The test is designed to give a rough measure of a broadband connection's suitability for VoIP and not specifically measure whether an ISP has greater contention on their internet or INEX links.

Aaron

WillieFlynn

Blaster99 wrote:

"works better", what does that mean?

When I said that blueface works better than skype, what I mean is that there is less lag, jitter, breakups, etc. In other words it has sufficient quality that you can forget that it is not a normal landline phone.

The problem I found with skype, was that it would work fine for say twenty minuits then it would breakup for 30 seconds before working again. Also found on some calls that the latency was such that you tended find you were talking across the person at the other end. Overall I found skype usable most of the time, but was constantly reminded that it wasn't a normal phone.