How To Build A Voip Network

Reply from tangle on Jan 16, 2007 - 12:46 PM

What you've got when Dean's built your VoIP platform v1.0, and walked away with the knowledge of job well done, is a good start – particularly if you'd done it 4-5 years ago.
You now have to turn it into a business. Unfortunately your network can only make IP-IP calls and inbound and outbound PSTN and offer a few basic functions like three way calls and call transfer.

Your competitors - now and future - are Skype, BT, Yahoo, Google, AOL, Vonage, Carphone Warehouse, NTL/Virgin, Betamax and pretty much every ISP and CPS service. Everyone one of which spend more on their hospitality budget than you just did on your entire network. And they’re all competing on price, functionality, reliability and service and most are packaging them with for free to sell IP TV, mobiles or Internet.

You have no price edge because you can't negotiate a volume PSTN deal until you have volume, you have no unique features because you haven't yet built them, you have no billing advantage because all you've got is a basic system and you have no customer service because, well, you have no-one to answer the phones.

You have no marketing budget either so you can forget a London Underground poster campaign or a TV add so you spend your money on google ads and SEO. Ever tried typing VoIP into google? (162,000,000 results) Or Cheap calls? (10,300,000 results)

Luckily (?) most of Africa, the new European Eastern block and USA will find you very quickly and start pushing bent credit card payments through your system which get charged back to you by your card merchant 3 months later.

Your finance department will then leave when the bank gets in touch . Oh didn’t anybody mention finance?

Reply from VernonRazon on Mar 21, 2007 - 04:15 AM

Hi Dean,

Your article on how to build a VoIP network was great. Hope you don't mind some more questions, though.

All a SIP Proxy server does is to point the caller to the callee's address, and once they're connected, the proxy disconnects, right? This means that the caller's and the callee's SIP device (whether an IP phone or ATA) are connected to each other without any other intervening device. However, this connection traverses the Internet and thus its quality is dependent on whether the Internet is congested or not at the time of the call.

Question:
1. Is there any way this "call peering" can be routed to a T1 or E1 line instead of the internet? How?
2. Is this also the way H323 VoIP calls are routed - through peering?
3. How do you route an H323 VoIP call through a T1 or E1 line?

Thank you very much in advance, Dean.

Vernon

Reply from dean on Mar 21, 2007 - 10:08 AM

Hi Vernon, welcome to VoIP User.

Quote:

All a SIP Proxy server does is to point the caller to the callee's address, and once they're connected, the proxy disconnects, right?

Up to you. You could build it like that. You may need to keep a proxy in place where you have two users behind NAT though.

You could also proxy nothing and just live with some of the NAT issues that may occur (one way audio is a common one) and lack of accurate call timing. Or you could proxy everything as many ISP's do, to retain control over the session and get accurate timing data.

Quote:

1. Is there any way this "call peering" can be routed to a T1 or E1 line instead of the internet?

Sure.

Quote:

How?

Basic networking principles apply. A VoIP network is just a network. Interconnects are the same as for data. You can go all the way down to Layer 1 and run a CAT V cable. Or T1 or E1 or whatever. WiFi if you like.

Quote:

2. Is this also the way H323 VoIP calls are routed - through peering?

H323 is just a protocol. It is only concerned with Layer 5. Peering could happen at Layer 5. Equally peering could happen at Layer 1. But so far you have only mentioned signalling, for which QoS is less of a problem. I would worry more about the QoS on the RTP media.

Quote:

3. How do you route an H323 VoIP call through a T1 or E1 line?

H323 is just a protocol. You can route it over anything, any which way you like, as long as you have some means of making it communicate with Layer 4.

You could, theoretically, run H323 over smoke signals, or a mechanical connection - code sent by switching a light on and off for example.

You need a more thorough understanding of the OSI networking model. I suggest you read the Wikipedia article on it I linked to in my original post.

Going back to some of the proxying concepts, to give you an example, VoIP User takes a "proxy nothing" approach. We do that specifically because proxying costs money (by way of bandwidth and server usage etc) and we don't really have any, or very much anyway. So we live with the issues and we just say to people "look, it is what it is. We do it on a budget!". We get the occasional user behind NAT having one way audio issues as a result. If you look through the Outbound Service Support forum you'll see that.

You couldn't get away with that running a commercial (paid for) service.

There is a happy medium. You proxy the RTP media only where it is absolutely required and there is no other way as P2P would fail. And then you proxy all the SIP/H323 signalling traffic anyway as it's only a few bytes and not a big deal traffic wise.

Such a configuration gives you the best of both Worlds - you're proxying, but only when you absolutely need to (which would be perhaps 2% of calls or less based on data I have), and you always proxy the signalling traffic from which, theoretically, you can get accurate call data records.

It's not that easy to do. You need some call intelligence to determine when you need to proxy and when you don't need to.

That's what the Ditech SBC does that I mention in my first post. That's why they cost $10k. That's why commercial VoSP's will need one.

I keep trying to hammer home the importance of SBC's to people. To be honest, if you're thinking of starting up a VoSP and have a development budget, don't do it! Hire a team of developers instead and go design a NAT traversing, B2BUA Session Border Controller with Anti-DDoS measures etc etc in built. You'll make a fortune.

SBC's are where the money is right now, and they're really not that hard to build. There's loads of open-source GPL SIP stacks out there you could base one on.

Dean

Reply from VernonRazon on May 03, 2007 - 07:35 AM

Hi Dean,

Hope you don't mind a bunch of basic SIP questions.

1. How is the bandwidth consumption for SIP signalling calculated? How much bandwidth is needed per call?

2. It has been contended that the "last mile" is usually the section of the Internet that's most vulnerable to congestion and so is usually the cause of degradation of voice quality in VoIP. Is this true? My opinion is that the public portion of the Internet is shared, so it must be all subject to congestion.

3. If it's true that the last mile is the usual culprit causing degradation of VoIP quality, can a home enduser QoS device like broadband booster (which maintains QoS on the home user's LAN) help?

4. Is there a scalable method of interfacing bandwidth to the VoIP server to bypass the limited number of T1 cards you can put in the server?

Thank you very much. I really appreciate the time you spend helping people with your expertise.

Vernon

Reply from dean on May 03, 2007 - 09:02 AM

Your last question implies you're using Asterisk, so I'm not sure whether you mean to ask about SIP or something else? What do you mean by "VoIP Server" exactly?

Perhaps you can let us know what you're trying to do.

Reply from VernonRazon on May 03, 2007 - 09:17 AM

Dean,

What I meant was a SIP Proxy Server.
Thanks.

Vernon

Reply from VernonRazon on May 03, 2007 - 09:43 AM

Hi Dean,

Sorry. Regarding my 4th question, it's a SIP Proxy setup. I was just wondering what's the best scalable solution to interface megabytes of bandwidth to the server from the provider, since T1 cards would limit the bandwidth to the number of slots in the server.

Thank you.

Verno

Reply from dean on May 03, 2007 - 10:41 AM

This is a getting a little too complex I think Vernon. I recommend you take some advice from a networks specialist. Not necessarily a VoIP networks specialist. Might be an idea to try and find yourself a Cisco Certified engineer?

If you want to use a T1 line as a trunk that's one thing, future load-balancing and multiple T1's is another. These are pretty much too completely different projects.

You definitely don't want to be putting T1 cards into a SIP proxy server if you want to expand. Why would you when you can put a 100mb or even 1gb NIC in there? The T1's would be terminated by a router backing on to a 100mb or 1gb LAN. Then you can bolt in additional T1's at any time, without changing a thing.

I have no idea what bandwidth SIP signalling uses - I've never bothered to measure it as it's such a small number of bytes. But it would be measurable.

How about building a test rig? Create a fake T1 line (a few feet would do) using twisted pair and a router at each end and actually test it and make whatever measurements you need. You can buy some of the older Cisco kit for a few pounds now on eBay.

As for QoS - you're trying to find a single point where in fact there are multiple points for bandwidth to get "shaped", either inadvertently or deliberately. Get QoS in at as many points as possible.

Dean

Reply from VernonRazon on May 03, 2007 - 10:49 AM

Thanks Dean. As usual - you deliver! More power to you and the VoipUSer.org!

Vernon

Reply from robertlam on Nov 17, 2007 - 12:34 AM

Hi

Can anyone explain how get this open source SBC (opensipstack.org) to function with openSER?

Also is sipfoundry.org's sipXecs a sip server in the same context as openSER?

Reply from dean on Nov 17, 2007 - 12:56 PM

Hi Robert,

opensipstack is not an SBC, it's just an open source SIP stack.

openSBC is an SBC which is based on it (mentioned above).

You're better off posting in our openSER forum for help on setting it up. I'm not sure if anyone here has done it before, but it'll be something like:-

client->openSBC->openSER

The job of the SBC is only to marshall the registrations coming in, and if all is well, send it straight on to the SIP registrar/proxy.

I suggest you take this one into the openSER forum.

Reply from philipj on Jul 12, 2008 - 12:14 AM

Hi VoIP Gurus
Nice post, thanks for the detailed information, I am totally a software guy ,very poor in techinical, intersted in making a service like JAJAH, confident of good marketing. My question is these information all I need to start the VoIP system. My aim is to concentrate on Asian countries.
please help.
thanks
philip

Reply from dean on Jan 08, 2009 - 11:50 AM

I just want to highlight to readers of this thread a couple of products (both from the same company and both open-source) that we've been experimenting with at VoIP User recently and are likely to become a part of the VoIP User core network.

Sippy B2BUA

http://www.b2bua.org/

This is a SIP back to back user-agent. Part of what you might call an edge controller, or more loosely call a Session Border Controller.

It's written in Python and you can read the specs on the link above. We've been playing with it for the last week and really like its ease of configuration and scalability. It can be used to assist with NAT traversal and if you're currently running openSER/Kamailio in a proxy mode it will take a little load off that for you but keep you in the middle of the signalling path (so you always get BYE messages, or a timeout).

It will interface to a Billing/Rating engine via RADIUS. A RADIUS server can also of course be used to authenticate and this again will take a little load off the SIP Registrar if needed. It can also be used to time calls in both pre-pay (through a RADIUS credit-time attribute) or post-pay (CDR collection).

VoIP User of course has very unique and particular requirements with rating/billing, as we work in global minutes rather than cash. But really it's just a case of making our existing system talk RADIUS and has proved quite straightforward.

It also is designed to work in conjunction with:-

Sippy RTP Proxy

http://www.b2bua.org/wiki/RTPproxy

Again, this will help with NAT traversal and also allows recording of calls and copying of RTP streams (useful for lawful intercept). It's designed to scale simply by having multiple instances so if you need more you just add more.

With a bit of configuration work you can also add another one in a different country to create a POP access point there for QoS and use geo-targetting to tell connecting clients which POP to use.

The company that produces these is SippySoft:-

http://www.sippysoft.com/company/

They also offer consultancy services. I don't know them as I haven't got in touch with them yet, but I like what they've developed so they get an initial thumbs up from me.

Incidentally, when looking at integrating these products to the VoIP User Core (for some additional features to deal with Ofcom regulation and for NAT traversal) we had to take a decision on supporting a new development environment. Both of these applications are written in Python, and the rest of our SIP core is all C (for applications) and PHP (for scripts and webapps) based. We know C and PHP but we don't know Python, so it's a bit of a punt and if we need something customised we might not have the skill-set to do it.

We took a view on that for a couple of reasons. First, there are a lot of Python developers out there and if we really got stuck we can probably get some help. Secondly, both applications use standard protocols (SIP and RADIUS) which means that, if necessary, we should be able to switch out either unit for another brand.

Reply from Charl on Apr 29, 2009 - 08:50 AM

Hi I'm Charl and new to the community.

Been looking into building a VoIP network for some time, though the one that is most clear to me is Dean's tutorial, (this one.)

Iv'e read the good, the bad and the ugly regarding VoIP and its future. Im in a country that has one main telecom provider and they basically run a monopoly here, having not touched VoIP as they have no need to, making more money on fixed lines and cellular networks.

The tutorial is over 2 years old now and was woundering if there have been any revolutions in the area or a updated tut?

It is a great tut and I take my hat off to Dean but in 2 years im sure there's some new soft/hardware that could play a vital role in more efficient system.

Look forward to a responce and take in mind im a newb here so if there's a area Iv'e overlooked on the forum feel free to direct me in the right direction though I do think a remake of the tut is due.

*crap, over looked deans last post. soz but some of the above still reagrds the topic

*and would any admins/mods be intrested in aiding me in making of a new network, it would all be recorded, have write up's and photo's for a 'complete' tut from start to end, from buying the hardware/configuring the software, to the end product?

For instance say i bought everything in Dean's post, did everything he says, and conifugered it with abit of help, whilst document every set with visual aid and all the script...

Reply from gray on Apr 29, 2009 - 09:21 AM

Quote:

and would any admins/mods be intrested in aiding me in making of a new network

Are you sure you could afford us

Goto page Previous  1, 2, 3  Next

Voip User Forum Index » The World of VoIP » VoIP General