Small office phone setup
-
@ajstringham said:
I believe the average bandwidth for calls is 100kbps both up and down for each concurrent call.
100Kb/s is just above the theoretical maximum, not average. We use it as a buffered number to account for all possible overhead. Average is well below 80Kb/s for uncompressed audio and as low as like 15Kb/s for some compressed options. Using 100Kb/s gives you more than enough safety margin and is really easy to calculate. With 100Kb/s you can do high def audio even.
-
@ajstringham said:
@Dashrender said:
Something else to mention - my carrier currently forwards all calls that would overflow the two lines back to my main office. Can SIP trunks do that?
Yeah, that's doable.
Actually no, a SIP trunk does not do that. A provider may have an add on service, but a trunk does not do that.
All the providers I have worked with only send calls to the fail over number when the trunk is unreachable. Not when the trunk has reach a concurrent call limit. There may be a provider that does it, but I do not know of one.
The issue here is your call flow not the SIP trunk. You only have 2 phones available to answer a call, but what about call waiting or having multiple lines programmed on the phone to allow more than one inbound call at a time?
You need to think differently. Using a trunk from VoIP.ms has no realistic limit to concurrent calls. You send the calls in to a ring group and have the fail for that ring group be to send the call to your main office.
-
@ajstringham said:
The latency difference really isn't noticeable. NTG hosts their PBX out of Toronto and I used it both from Upstate NY and Dallas and didn't have issues either time.
We did. More recently we moved it to Chicago.
-
@scottalanmiller said:
We did. More recently we moved it to Chicago.
FYI, VoIP.ms must be in the same facility as RackSpace because my trunks to their Chicago servers have 1ms response times.
-
@JaredBusch said:
@ajstringham said:
@Dashrender said:
Something else to mention - my carrier currently forwards all calls that would overflow the two lines back to my main office. Can SIP trunks do that?
Yeah, that's doable.
Actually no, a SIP trunk does not do that. A provider may have an add on service, but a trunk does not do that.
All the providers I have worked with only send calls to the fail over number when the trunk is unreachable. Not when the trunk has reach a concurrent call limit. There may be a provider that does it, but I do not know of one.
The issue here is your call flow not the SIP trunk. You only have 2 phones available to answer a call, but what about call waiting or having multiple lines programmed on the phone to allow more than one inbound call at a time?
You need to think differently. Using a trunk from VoIP.ms has no realistic limit to concurrent calls. You send the calls in to a ring group and have the fail for that ring group be to send the call to your main office.
As long as I can 'send these calls to a traditional LEC' that's fine. Can I?
-
@JaredBusch said:
@coliver said:
Good point, just thought it would be something to be made aware of.
Also, calculating calls on 100kb per call means you have at most 10 active calls * 100 kbps = 1 mbps with QoS on your router, there should not be any problems.
And that is the maximum with every line engaged, all at once, all talking. Any silence suppression or compression brings that number down. You'd never be able to hit 1Mb/s (and that is rounded up again on top of the buffer already built in) even in a test purposefully trying to hit that. A more reasonable "you'll never hit it limit" is more like 800Kb/s. And there is a very good chance that 600Kb/s will never actually be hit even after years of use.
-
@Dashrender said:
As long as I can 'send these calls to a traditional LEC' that's fine. Can I?
Yes, you have multiple ways to handle it all once the call hits your PBX.
-
@JaredBusch said:
@ajstringham said:
@Dashrender said:
Something else to mention - my carrier currently forwards all calls that would overflow the two lines back to my main office. Can SIP trunks do that?
Yeah, that's doable.
Actually no, a SIP trunk does not do that. A provider may have an add on service, but a trunk does not do that.
All the providers I have worked with only send calls to the fail over number when the trunk is unreachable. Not when the trunk has reach a concurrent call limit. There may be a provider that does it, but I do not know of one.
The issue here is your call flow not the SIP trunk. You only have 2 phones available to answer a call, but what about call waiting or having multiple lines programmed on the phone to allow more than one inbound call at a time?
You need to think differently. Using a trunk from VoIP.ms has no realistic limit to concurrent calls. You send the calls in to a ring group and have the fail for that ring group be to send the call to your main office.
Oops. Misread that. You're right.
-
@ajstringham said:
Yeah, the up is the only potential problem. If someone is on the phone and tries sending a large email attachment, you could have issues. Is this a DSL connection at that location?
2Mb/s is easy to saturate. But QoS on the router will fix that. Just make sure that RTP traffic has priority and that's not really an issue. It is ingress (incoming) that is the issue but there is tons more of that.
-
@scottalanmiller said:
@ajstringham said:
The latency difference really isn't noticeable. NTG hosts their PBX out of Toronto and I used it both from Upstate NY and Dallas and didn't have issues either time.
We did. More recently we moved it to Chicago.
Oh, news to me.
-
@ajstringham not like we make a huge public announcement
When we first built the Toronto platform we were not doing PBX hosting. Eventually it didn't make sense to run our own PBX when we had a standard hosting platform for clients. So we moved into the same datacenter on the same platform as most of our PBX clients. Now we are identical to them just running on the most bleeding edge version of the product so that we see issues before anyone else (we hope.) -
@scottalanmiller said:
@ajstringham not like we make a huge public announcement
When we first built the Toronto platform we were not doing PBX hosting. Eventually it didn't make sense to run our own PBX when we had a standard hosting platform for clients. So we moved into the same datacenter on the same platform as most of our PBX clients. Now we are identical to them just running on the most bleeding edge version of the product so that we see issues before anyone else (we hope.)Yeah, I heard you guys moved to FreePBX a couple months ago.
-
@Dashrender said:
Something else to mention - my carrier currently forwards all calls that would overflow the two lines back to my main office. Can SIP trunks do that?
Sure, but even better is getting the ability to go over two lines. It's really easy to get unlimited lines with SIP, or at least many lines.
-
@ajstringham said:
Yeah, I heard you guys moved to FreePBX a couple months ago.
Yes we did, but the moves were separate. Elastix in Toronto to Elastix in Chicago to FreePBX in Chicago.
-
@JaredBusch said:
@coliver said:
Good point, just thought it would be something to be made aware of.
Also, calculating calls on 100kb per call means you have at most 10 active calls * 100 kbps = 1 mbps with QoS on your router, there should not be any problems.
Key in on the word "should" there. Sometimes Sonicwalls do not play nice with SIP. It depends on the model as to whether QoS is even available if I remember correctly.
-
@NetworkNerd it's always an issue that you might have a router without working QoS.
-
@NetworkNerd said:
Key in on the word "should" there. Sometimes Sonicwalls do not play nice with SIP. It depends on the model as to whether QoS is even available if I remember correctly.
Missed the fact that it is a sonicwall. simply hate them because they cause so many problems with SIP. Prior to SIP use being so common, they were a great platform that I would recommend.
-
@JaredBusch said:
@NetworkNerd said:
Key in on the word "should" there. Sometimes Sonicwalls do not play nice with SIP. It depends on the model as to whether QoS is even available if I remember correctly.
Missed the fact that it is a sonicwall. simply hate them because they cause so many problems with SIP. Prior to SIP use being so common, they were a great platform that I would recommend.
I remember having to turn on SIP inspection (or SIP transformations as they call it) on one Sonicwall in particular to avoid one-way audio. And I think there was a community post made by @DonutDetroyer about having to do that with a Fonality system as well.
-
@scottalanmiller said:
@ajstringham said:
Yeah, I heard you guys moved to FreePBX a couple months ago.
Yes we did, but the moves were separate. Elastix in Toronto to Elastix in Chicago to FreePBX in Chicago.
Which makes sense.
-
@JaredBusch said:
Missed the fact that it is a sonicwall. simply hate them because they cause so many problems with SIP. Prior to SIP use being so common, they were a great platform that I would recommend.
One of my least favourite security devices. Too expensive and too low quality.
