Jump to content

Recommended Posts

Posted

Okay, TT&T tells me that CAT issues them with private IP addresses. Because of this, they don't think (but they don't know) that TSpeed is compatible with Internet phones like Vonage.

Here's what they say exactly:

I think it will not work on Hinet because it provide private IP by CAT....

TT&T is not ISP but TRUE and Samart is ISP both of them can provide real IP to the customer. Hinet is provide DSL by TT&T by port opening policy is configurated by CAT. ...You can try on new ISP such as CSLoxinfo or KSC ADSL package.I think it may be better.CSLoxinfo 053-400340,053-400354,053-225345 KSC 053-892600.The package is not so expensive and maybe solve yours ploblem.

As you can see, they're basically just telling me to go to their competitors... He mentions TRUE and Samart because I know people who use Vonage with these ISP's without any problems.

Can anyone out there actually confirm or deny whether or not private IP addresses are compatible with Internet phones and what this means in terms of anyone with TSpeed who wishes to use an Internet phone.

Posted
You mean NAT address, correct ? It's easy, just open the ports and setup your router for port forwarding.

Port forwarding does not work when it is the ISP who is applying NAT to your traffic. Unfortunately, some ISPs have the mistaken idea that the Internet is nothing more than a service for your web browser.

There are some standards for "NAT traversal" in order to get traffic such as VPNs and real-time data (including IP phones) to pass through NATs, but you can rarely determine whether it will work in your case without experimentation or very knowledgeable support staff in the network(s) applying the NAT.

Posted

What is a NAT?

How do I open the ports and set up the router for port forwarding?

How do I find out if the ISP is applying the NAT?

Basically, I'm trying to discern if my problem lies with TT&T in which case I don't know what to do OR if I just need someone smarter than me to come in here and tweak things because the standard settings definetly don't work.

What do you think?

Posted

NAT is Network Address Translation. This is why they say you have a "private address".

The problem is that you do not have a normal public address to which the UDP traffic can be sent from the other end of the VOIP phone connection. An earlier post was suggesting that you could solve this by adjusting the router in your house, but the information from TT&T is stating that it is CAT and not your own router that is doing this translation from some CAT address to the private address your modem sees. You would be able to solve the problem if your modem had a public address but your own equipment was performing NAT (as many home routers do).

Think of the address as a street address and the port number is a room number. However, because of address translation, nobody outside CAT knows what your street address is. When you send normal TCP traffic, like with your web browser asking for a webpage, there is a return address consisting of your street address and the room number where you'll be waiting for a reply. When CAT handles your letter, they rip off this return address and put a different one on that gives one of CAT's street addresses and some unique "room number" where they want the reply sent. In that room, some guy knows that when a reply gets there he is to forward it on to your address and room inside the realm of CAT.

The problem is that the internet phone uses UDP rather than TCP. This is like sending a bunch of postcards with snippets of conversation instead of a big envelope full of letters. The phone system in the US wants to send postcards to a special room in your house (the phonebooth?) where these postcards will be understood. However, no postman knows how to get these cards to your building. Even worse, if someone tries to forward them to a phonebooth at CAT, there are none that are smart enough to send it on to your phonebooth!

Given that the TT&T representative is suggesting you go elsewhere, that is probably what you need to do to make this work. Changes would have to be made at CAT to provide some address that would always forward the SIP data to your own equipment.

Posted
NAT is Network Address Translation. This is why they say you have a "private address".

The problem is that you do not have a normal public address to which the UDP traffic can be sent from the other end of the VOIP phone connection. An earlier post was suggesting that you could solve this by adjusting the router in your house, but the information from TT&T is stating that it is CAT and not your own router that is doing this translation from some CAT address to the private address your modem sees. You would be able to solve the problem if your modem had a public address but your own equipment was performing NAT (as many home routers do).

Think of the address as a street address and the port number is a room number. However, because of address translation, nobody outside CAT knows what your street address is. When you send normal TCP traffic, like with your web browser asking for a webpage, there is a return address consisting of your street address and the room number where you'll be waiting for a reply. When CAT handles your letter, they rip off this return address and put a different one on that gives one of CAT's street addresses and some unique "room number" where they want the reply sent. In that room, some guy knows that when a reply gets there he is to forward it on to your address and room inside the realm of CAT.

The problem is that the internet phone uses UDP rather than TCP. This is like sending a bunch of postcards with snippets of conversation instead of a big envelope full of letters. The phone system in the US wants to send postcards to a special room in your house (the phonebooth?) where these postcards will be understood. However, no postman knows how to get these cards to your building. Even worse, if someone tries to forward them to a phonebooth at CAT, there are none that are smart enough to send it on to your phonebooth!

Given that the TT&T representative is suggesting you go elsewhere, that is probably what you need to do to make this work. Changes would have to be made at CAT to provide some address that would always forward the SIP data to your own equipment.

Thanks very much for the good explanation. Am I right to assume that CAT could fix the problem and make it work for me if they were very motivated to do so? If I am right about this, any idea how to motivate them?

I'm in Chiang Mai where the options for ADSL are very slim. I'm quite content with TT&T at 1000 baht a month. If I was in Bangkok, I would just switch to TRUE and that would be that.

What do you make of the fact that I can use voiceglo (voiceglo.com) to make and receive calls on my computer? Why does that work and Vonage doesn't?

Regarding skype, its ok for calling out, but you don't get a dedicated phone number in the US to receive calls. Also, I've found glophone to be far better quality. Vonage is superior, because once its set up, you don't even need a computer. Just ADSL line, modem, the Motorolla device and a phone.

Posted

In a quick follow up, does the configuration of CAT and TT&T mean quite simple that anyone using TSpeed simply can't use these phones that let you make and receive calls over the internet? (I'm still confused because I can use glophone --voiceglo.com)

Surely, CAT can rearrange some settings to make it possible for some customers to use Vonage. Or am I dreaming here?

Posted

The short answer is that without a change in CAT's network, the only thing you can really do is form outbound TCP connections, which happens to be the normal behavior of your web browser. If voiceglo forms a TCP connection to a voiceglo server when you start it, and all further call information flows over this connection, then I can understand how that works despite the NAT obstacles. This is similar to how instant-messenger clients work for everyone over NAT, e.g. when I "sign on" to MSN I basically keep a connection open and messages all flow through the MSN servers. There are serious drawbacks to trying to shove real-time audio data (like a telephone conversation) down a TCP connection; I assume this may exhibit a quality problem that has motivated you to want a different solution...

I'm not really familiar with these different internet phone providers or what technologies they are using. I suspect some of them may be using strange proprietary solutions, particularly the ones you say are working right now with your NAT problem.

The two well respected voice over internet protocols, namely SIP and the H.323 protocol suite, both use something called RTP or the real-time transport procotol to avoid these performance problems with TCP. Unfortunately NAT, as is usually deployed to reuse IP addresses at an ISP, really destroys the functionality of the Internet to support these more general applications. There are many people around the world who are trying to figure out how to resolve this problem, but after my own hair-pulling I have decided to wait for a real public IP address before attempting any of these nice internet applications in BKK.

I cannot say I really know whether CAT _could_ help you if they wanted to... only someone knowledgeable in their systems could make that judgement. Also, I am not sure how to motivate them to or whether you would want to try. Remember that few telecom providers are really interested in helping you deploy a solution that takes away from their own business (long-distance voice communications)! You would probably need a friendly individual in the organization, rather than hoping the organizational policies are set to help you.

Posted

CMT,

I'm using a Claritel handset and make PC to phone calls on a TTT hinet connection. I'm using dialpad; I have tried the PC to phone from skype but no sucess so far. Have not tried PC to PC yet.

Cheers, Holm

Posted
The short answer is that without a change in CAT's network, the only thing you can really do is form outbound TCP connections, which happens to be the normal behavior of your web browser. If voiceglo forms a TCP connection to a voiceglo server when you start it, and all further call information flows over this connection, then I can understand how that works despite the NAT obstacles. This is similar to how instant-messenger clients work for everyone over NAT, e.g. when I "sign on" to MSN I basically keep a connection open and messages all flow through the MSN servers. There are serious drawbacks to trying to shove real-time audio data (like a telephone conversation) down a TCP connection; I assume this may exhibit a quality problem that has motivated you to want a different solution...

I'm not really familiar with these different internet phone providers or what technologies they are using. I suspect some of them may be using strange proprietary solutions, particularly the ones you say are working right now with your NAT problem.

The two well respected voice over internet protocols, namely SIP and the H.323 protocol suite, both use something called RTP or the real-time transport procotol to avoid these performance problems with TCP.  Unfortunately NAT, as is usually deployed to reuse IP addresses at an ISP, really destroys the functionality of the Internet to support these more general applications.  There are many people around the world who are trying to figure out how to resolve this problem, but after my own hair-pulling I have decided to wait for a real public IP address before attempting any of these nice internet applications in BKK.

I cannot say I really know whether CAT _could_ help you if they wanted to... only someone knowledgeable in their systems could make that judgement. Also, I am not sure how to motivate them to or whether you would want to try. Remember that few telecom providers are really interested in helping you deploy a solution that takes away from their own business (long-distance voice communications)! You would probably need a friendly individual in the organization, rather than hoping the organizational policies are set to help you.

Thanks again. Needless to say, it is extremely frustrating to pay for 'high speed internet', but not actually have access to all that it offers. I've sent an e-mail to CAT, but I'd be surprised if they respond, let alone fix the problem. All I can say is that if Chiang Mai is supposed to be this very important hub of the region, its got a long way to go in many, many areas.

There is the option of CSLoxinfo and KSC, but they are very much more expensive and the former has gotten terrible reviews in another thread. So that leaves KSC. I'll let the board know what happens, but for now, be aware that it seems Vonage and Hinet from TT&T are not compatible.

Also, you say that you are waiting for real public IP addresses to become available, but isn't that what you get with TRUE and Samart and KSC among others?

Posted
CMT,

I'm using a Claritel handset and make PC to phone calls on a TTT hinet connection. I'm using dialpad; I have tried the PC to phone from skype but no sucess so far. Have not tried PC to PC yet.

Cheers, Holm

I think that voiceglo and dial pad and skype all use a TCP connection. I think the whole problem is that Vonage is higher quality and so does not use TCP, but TT&T is not compatible with high quality.

Skype works fine for me, but have to turn off the firewall. Sound quality was not great so I will stick with voiceglo for now.

Posted
...

Also, you say that you are waiting for real public IP addresses to become available, but isn't that what you get with TRUE and Samart and KSC among others?

Sure, TRUE will give us a public address right after TOT finishes looking under rocks and actually provides an unassigned wire into our building from the central office. BKK isn't the panacea either it would seem. :o

I completely understand the frustration. The problem is that the world should have upgraded to IPv6 long ago instead of using NAT to limp along without enough IPv4 addresses to go around. However, too many pundits can still use their web browsers to post messages about how NAT works just fine and stop rocking the boat...

By the way, one convoluted solution for you might be to try to find a VPN provider somewhere out there who will give you a public address. This could be a company or a good geek friend with a fast and reliable broadband connection (with multiple public addresses of course). The acid test is whether they support the current "IPsec tunneling NAT-traversal mode". You would have to run a VPN client from your PC and then use a PC-based vonage solution (do they offer those?) unless you either want to shell out for a SOHO router with built-in VPN client support or get truly bent and use your PC as a VPN router for the hardware phone adapter that you've got.

Of course, given the problems so far, I wouldn't start buying services like that unless they will let you do a free trial first.

Posted
...

Also, you say that you are waiting for real public IP addresses to become available, but isn't that what you get with TRUE and Samart and KSC among others?

Sure, TRUE will give us a public address right after TOT finishes looking under rocks and actually provides an unassigned wire into our building from the central office. BKK isn't the panacea either it would seem. :o

I completely understand the frustration. The problem is that the world should have upgraded to IPv6 long ago instead of using NAT to limp along without enough IPv4 addresses to go around. However, too many pundits can still use their web browsers to post messages about how NAT works just fine and stop rocking the boat...

By the way, one convoluted solution for you might be to try to find a VPN provider somewhere out there who will give you a public address. This could be a company or a good geek friend with a fast and reliable broadband connection (with multiple public addresses of course). The acid test is whether they support the current "IPsec tunneling NAT-traversal mode". You would have to run a VPN client from your PC and then use a PC-based vonage solution (do they offer those?) unless you either want to shell out for a SOHO router with built-in VPN client support or get truly bent and use your PC as a VPN router for the hardware phone adapter that you've got.

Of course, given the problems so far, I wouldn't start buying services like that unless they will let you do a free trial first.

It sounds like I need to hire you to solve this problem, although looks like you're in BKK. That, or bribe someone over at CAT.

Vonage makes it look so simple. ADSL line to router. Router to free Motorolla device. Free M device to phone.

I guess it might be that simple with other ISP's. I have a friend in BKK on TRUE who plugged it in and was making calls 3 minutes later. I'm coming up on 2 weeks later and its just getting more confusing...

Thanks for your ideas. If I hire someone to try to work this out, I will use the information you have provided. Thanks again.

Posted

Thanks Bob.

Here's the latest from Vonage:

'In response to your e-mail, since your ISP uses a private IP address,

Vonage will work if you can get the IP address, subnet mask, default

gateway and the DNS servers from your ISP. They should be able to

provide you with this information. Once you are able to get this

information, you can enter it in the Motorola Phone Adapter.'

So is there hope or did I relay the wrong info to them regarding my ISP (TT&T) using private IP addresses? TT&T did inform me that 'CAT provides them with private IP addresse'.

Of course, I forwarded this info onto TT&T and CAT, but after a few days, there's been no response. Maybe I should just go straight to their office and refuse to leave until they give me the info I need? Not exactly Thai style, but at the end of the day, if that what it takes to get anything done, then you gotta do what you gotta do...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.



×
×
  • Create New...