Need of SIP proxy manager

Discussion in '3CX Phone System - General' started by Basheerpt, Sep 16, 2017.

Thread Status:
Not open for further replies.
  1. Basheerpt

    Joined:
    Feb 15, 2017
    Messages:
    49
    Likes Received:
    7
    Hi,
    I was wondering do I need a SIP proxy manager for the below scenario:
    We have multiple locations in different geographical area. On HQ there is 3cx server installed. All other locations are connected MPLS network and reachable. My concerns are:

    - In order to introduce phones in remote locations, do I need separate PBX systems (3cx or other and bridge them) or can I just add a phone and provision them as we do in the HQ?
    - Is it necessary to use the SIP proxy manager in each locations other than HQ? If yes, what is the advantage?
    - How much bandwidth I can expect per call if initiated from the above remote locations? What is the best codec to use that consume less bandwidth and no compromise audio quality?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  2. leejor

    leejor Well-Known Member

    Joined:
    Jan 22, 2008
    Messages:
    10,586
    Likes Received:
    252
    If you have more than a couple of sets in each location, unless you are using VPN, then it is highly recommended that you use a 3CX SBC https://www.3cx.com/docs/3cx-tunnel-session-border-controller/ at each remote location. Failure to do so can cause audio issues and can impair auto provisioning.. It also means that any remote in-office call will have to route back through the PBX, rather than direct set to set.

    Here is some information on bandwidth and Codecs.

    https://www.3cx.com/blog/docs/bandwidth-utilised-for-voip/

    As to whether you are better off with a local PBX at each location...that all depends. If you plan on having local trunk access, then perhaps. If you use a VoIP provider for each location, then trunks can probably be registered at the host, but that will vary. If you plan on using a gateway at a location, then you will probably run into problems, unless a PBX is in the same location as the gateway. If you utilize VPN then it may not be an issue. There are a number of considerations, it's not a simple yes, or no. It may be that some sites can be hosted while other are better off with a PBX on site.
     
    #2 leejor, Sep 16, 2017
    Last edited: Sep 16, 2017
  3. cobaltit

    cobaltit Active Member

    Joined:
    Mar 22, 2012
    Messages:
    833
    Likes Received:
    127
    @Basheerpt
    You don't need multiple PBXs regardless of topology. Multiple PBXs is a financial/business/technical/admin decision, but certainly not a requirement simply because you have multiple locations. As long as you have routed subnets over your MPLS and no NAT, you can just provision all of your phones as local phones to the PBX in HQ. Other factors may come into play since you mention different geographic locations such as the desire to have local dial tone, bandwidth between locations, etc that may make putting local PBXs at some or all locations more practical.

    Regarding bandwidth, G.729 is the codec you would want to use to saving bandwidth with minimal effect on call quality.

    https://www.voip-info.org/wiki/view/Bandwidth+consumption
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
    YiannisH_3CX likes this.
  4. Basheerpt

    Joined:
    Feb 15, 2017
    Messages:
    49
    Likes Received:
    7
    Hi, Thanks for the inputs.
    I think I am better to go with the SBC. One thing I will loose, the ability to have PSTN failover. (I don't want to use a spate gateway, to avoid additional cost and complexity). However let me ask, SBC can be run on Virtual machine?

    Please advise.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. sip.bg

    sip.bg Active Member

    Joined:
    Nov 7, 2016
    Messages:
    704
    Likes Received:
    219

    You don't need neither 3CX PBXs in your locations nor 3CX SBCs for your remote extensions. All your locations are connected into a MPLS network, so you can treat all extensions as local ones. With 3CX SBCs you will introduce only limitations like 5 or 10 extensions per site, depending what hardware you are using for SBCs, and you will complicate unnecessary your setup.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. Basheerpt

    Joined:
    Feb 15, 2017
    Messages:
    49
    Likes Received:
    7
    Hi sip.big,
    Thanks for the reply. The reason I chose to use SBC is to avoid unnecessary traffic and bandwidth consumption for the internal calls in the remote site. What I understood is , if I don't use SBC, any internal calling in the remote site with use the bandwidth between the HO and remote site. It will affect my other applications uses the WAN.

    Please share your thoughts.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. sip.bg

    sip.bg Active Member

    Joined:
    Nov 7, 2016
    Messages:
    704
    Likes Received:
    219
    Hmmm,

    I don't think you can save on bandwidth using SBC, it only encapsulates the traffic into one port (which helps with NAT issues), 3CX tunnel is a kind of GRE tunnel. You need to test. To ensure RTP traffic (i.e. voice) between remote extensions will remain in the same remote network, you need to use same codec (e.g. G.711a or µ), for bandwidth save you may use only G.729; you should not record calls and should not force 'PBX delivers audio' for these extensions.
    Check it with Wireshark on the PBX site for a call between two remote extensions, if RTP remains in the remote LAN, you should capture only SIP traffic (signalization). You may apply filter like 'SIP or RTP' in Wireshark.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. Basheerpt

    Joined:
    Feb 15, 2017
    Messages:
    49
    Likes Received:
    7
    Hi
    The purpose of the SBC what i understood was to avoid the remote extensions contacting the pbx site for each time the user talk internal extensions. This would definitely save bandwidth, as leejor explained above.

    I dont want to affect the voice traffic to my primary network applications between Pbx site and remote site. by the way, i have many sites and once all started working, it may kill my HO bandwidth!
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  9. sip.bg

    sip.bg Active Member

    Joined:
    Nov 7, 2016
    Messages:
    704
    Likes Received:
    219
    OK, if SBC closes the RTP traffic inside the remote LAN.

    I'm not sure this is a feature of the SBC, you still need both remote extensions in a call to use the same codec (otherwise the PBX should transcode the voice), you should also not record calls nor forcing 'PBX delivers audio'.

    My opinion is that RTP traffic will not leave the remote LAN, if above conditions are fulfilled, regardless of using or not a 3CX SBC in the remote LAN. This can be verified easily with Wireshark or similar tool.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  10. Basheerpt

    Joined:
    Feb 15, 2017
    Messages:
    49
    Likes Received:
    7
    Dear 3Cx Expert team, Would you please confirm the point 'sip.big' pointed out? 3cx SBC closes the RTP traffic in the LAN where it is installed?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  11. GiannosC_3CX

    GiannosC_3CX Guest

    Hi Basheerpt,

    Please see the following link: https://www.3cx.com/docs/3cx-sbc-windows/#h.ifh2rew1q40u
    The SBC keeps the RTP streaming locally if :
    - the extensions are in the same lan as the SBC
    - the extensions are provisioned via SBC not manually.
    - configured with the same codec (means common codec) as the other extensions at the remote site.
    - the option "PBX delivers audio" is not enabled
    - the "Record all calls" option is not enabled.
     
Thread Status:
Not open for further replies.