[asterisk-biz] SIP providers

[Trixter aka Bret McDanel]

On Sun, 2008-06-08 at 00:44 -0600, Lane Sullivan wrote:
> On the other topic. Can I just say implementing VOIP can be easy but doing
> it RIGHT requires some insight and planning. I am planning my first
> implementation so any advise would be great. Sometimes learning what people
> would do differently is easier than reinventing the wheel!


well you asked about SIP trunking, and my advice on that particular
subject is dont do it.  Most products dont support it (asterisk doesnt)
which does not preclude using a proxy to handle the mux/demux, but that
becomes more complex.  If its a bandwidth issue, and the traffic is
going over the internet (or another network without bandwidth
guarantees) if you need the savings from trunking to make room for the
quantity of channels you need, then you are going to have a horrible
experience.  

What you save from trunking isnt enough to reliably squeeze in more
calls when you may have less than the required bandwidth once it goes
out on the public part.  You will save about 28 bytes per packet (ip
+udp), there will be some overhead to indicate how things are trunked
(the SSRC is not good enough for multiple rtp packets in a single udp
packet since length is not specified in the rtp header).  It is likely
that you would loose 10-15 bytes for this overhead, but I wont count
them for this example.  The are usually 50 packets per second per call
for RTP.  This means that 28*50=1400 bytes per call.  If you had 100
calls, yes you could cave 140kBs, enough for a couple more channels
(based on codec 1-17 or so), giving you effectively 1-17% savings.  

Given the reduced capacity, combined with a more complex system, lack of
interoperability with most providers out there, jitter/loss for one is
jitter/loss for all, and the fact that unless you are doing more than 20
calls at the same time it doesnt make sense, you may want to rethink
trunking a bit :)

Oh I almost forgot that I didnt subtract the overhead that would be
required to make this pay off, that would probably remove half of the
benefits, thus requiring more than 40 concurrent calls before a benefit
is realized, and that on low concurrent call counts it would increase
bandwidth usage, there are even more reasons to avoid sip trunking.

Unless you meant something else by trunking, I still dont know if you
meant it some other way than aggregating multiple RTP sessions into one
UDP stream instead of one per channel.

-- 
Trixter http://www.0xdecafbad.com     Bret McDanel
Belfast +44 28 9099 6461        US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!