Basic Business Model

thats quite a list...

A single t1 isn't a lot of bandwidth by our current appetites. It should be fine for 5 phones. But, as this customer 'grows rapidly', adding phones connected to a hosted platform is going to cut deep into your bandwidth doing things like internal calls, conferencing, and checking voicemail. I would say that as this customer grows to say 15-20 handsets, have a plan to step into single-tenant edition of thirdlane. this will limit your voice traffic over the t1 to that of to/from the PSTN. Using a compressed codec like g729 along with traffic shaping on your cisco router should be fine. (example: their provider issued a /29 for your ethernet interface on your cisco router. After assigning one ip to your PBX, take the remaining usable ips and make them part of an ACL that is used by the traffic shaper to limit their bandwidth to [1536 - 256] 1280kbps leaving 256 untouched for use by your pbx).

as far as BYOB; it really depends on the network they're on and the networks you're on. If they're using some crappy cogent connection, you can expect problems because they're notorious for oversubscribing their networks and high latency between peering points. However I've seen AT&T connections be just as good as if their layer2 was pulled straight into my facility (once I created traffic shaping rules to keep them from maximizing the full t1).

Hi Erik,

Thank you so much for taking the trouble to help me.

OK, so I understand there is not a fundamental problem with BYOB...but I should be careful about the quality of the circuit and the path/latency from the customer site to the ITSP servers. I probably won't be asking Cogent for any quotes...

I admit I'm still unsure of what constitutes a good Internet connection to use with VoIP. My experience to date leaves me amazed at how well it all works, even on crappy connections. However we're moving into a whole new level of responsibility and risk to our reputation moving our client's primary voice onto the Internet. Where do you draw the line as to what you consider an acceptable connection? That would be _very_ helpful for me to know.

I have been assured by my wholesale provider that my customer can start out with a single T1 and expand to a 2xT1 when they are ready. Have you had experience with that sort of upgrade? How much trouble was it?

While we are looking into hosting voice services for our customers, that is not our immediate plan. If we do move that way, we'll consider co-locating our server(s) in Vitelity's rack. For the foreseeable future, we'll be installing iPBX's at the customer premises.

I understand that traffic shaping is very important. Am I correct in assuming that all I have control over is the outbound queue of my client's own router? In your experience, does ToS/DiffServ tagging have any positive effect at all across the Internet?

I understand that G.729 uses much less bandwidth than G.711 and it sounds pretty good in my previous limited testing. Do you use G.729 for primary business voice? Always? Sometimes?

Do you always put the client PBX in the DMZ? Or just when possible? In the past, I've always placed the iPBX behind NAT, then used port-forwarding and IAX2 phones for remote extensions...which is a little bit of a pain.

Thank you again for your time and trouble,

G

usually the QoS tags have no impact over the internet, but obviously they're important for when the packets finally reach your network or your customer's network.

I use g729 when I need to conserve bandwidth. It sounds pretty good but it does add load to my gateway so by using it only when I need to I can work toward my goal of 5000 concurrent calls on a single gateway. Obviously every time I transcode I cut into this so I dont want to transcode on every call.

I never put it in the DMZ of a firewall, I put it on public IP and use the firewall rules of iptables. Most firewalls suck for voice, even on a DMZ segment. You never want to put your PBX behind NAT. SIP hates NAT. Even when you think you're in the clear something stupid come along that the firewall tried to perform and suddenly you realize you cant conduct that 3rd simultaneous call, or you randomly get 1-way audio, or you can't do attended transfers etc. That usually means having the customer to get a static subnet, even if its just a /29. I usually just take 3 ports on my switch and make them a port-based vlan for the wan segment. Hook one to the firewall, one to the pbx and one to the router.

Hello again,

Thank you for your comments on QoS tagging. I had not considered the other end of the route before. That makes sense. For some reason, I had assumed the tags would be stripped/manipulated somewhere along the line.

Your comments about transcoding CPU utilization with G.729 also make perfect sense.

I also appreciate your comments about NAT. I have previously experienced most of the issues you mentioned, at one time or another, so I know you are correct. I'll take this advice to heart.

Perhaps my usage of the term DMZ is not the most common one. I have always used the term for an actual subnet of statically assigned IPs with a NAT router as the LAN gateway. I have never actually used the 'DMZ' feature built into many cheap NAT boxes...though I have often used port forwarding in those same boxes. I like your idea of using a VLAN for the DMZ switch...I had never thought of doing that before.

We have made a detailed proposal to our customer that includes a DIA T1 that terminates in the same building as the SIP provider (less than 10 hops total). Their respective networks just happen to overlay at that point. Further, our T1 provider has promised that bonding a second T1 with MLPPP is trivial and that prioritizing VoIP traffic in both directions will be done over the T1. Our provider also suggested it might be possible to create an even more direct (BGP) route to the SIP provider to improve things further.

Thanks again. You have been very helpful.

G

p.s. Your web site looks great!

Hello Erik,

>> I put it on public IP and use the firewall rules of iptables. Most firewalls suck for voice, even on a DMZ segment. You never want to put your PBX behind NAT. SIP hates NAT.

We noticed some big issues with Thirdlane under NAT. So we want to build Thirdlane server with public static IP; And we are planning to implement HA as well. Does that mean I have to get 3 public IPs (one for master node, another one for slave, and the third one for floating)? I think we need HA with MAC address floating as well (not quite sure if the floating public IP goes to eth0:0 on slave node, it is working or not). I am wondering the HA + public IP is doable here? Or not possible (e.g. one have to go to NAT if using HA).

I also read one article here: http://kb.smartvox.co.uk/index.php/asterisk/how-it-works/high-availabil… ; And it seems no perfect solution. Which solution (NAT or without NAT) you suggested for HA of Thirdlane servers?

Thanks,
Rocky

yes, you need 3 ip's per cluster. the heartbeat tool will bring up eth0:0 on the slave node when it has to acquire resources.

Thanks for quick response. I am little worried about that even the floating public IP switch to eth0:0 on slave node, it is still not accessable from outside (maybe ISP need time to refresh to make the floating IP moved on another node); I'll use floating Mac address as well here. So is there any successful stories regrading HA + 3 public static IPs? Do I have to use Mac address floating? Anyway, I'll make a test in our test environment soon.

Thanks,
Rocky