This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firewall voip SIP settings for provider callwithus

Having issues with audio with voip provider callwithus. Also have callcentric configured which works fine because there's a defined set of servers for media.

The call is initiated successfully, but the issue is with the audio/rtp media.  Callwithus doesn't have a specific server or servers it uses, but rather the media can come from a any number of different servers (and ports). 

I've found two solutions to make it work.

1) Allow the pbx full access to all external (internet) ports (1:65535) by way of a firewall rule.  While this works, I'm not comfortable giving the box full wide open access.

2) Use "Internet IPv4" as a network in the voip/Sip Server networks.  Call audio works both ways, firewall shows SIP call (as expected).  I'm not 100% comfortable with this solution but it does block the pbx from trying to access other ips/ports unless a sip session has been initiated.  What I'm unclear about is what ramifications does this have in terms of unsolicited inbound traffic?

For now the pbx is strictly used locally and does not accept external (from the internet via sip uri) sip calls directly unless they come through one of the configured voip provider trunks (which also works properly).

Thoughts?



This thread was automatically locked due to age.
  • Hi Jay Jay,

    SIP is 2 functions

    SIP (Port UDP 5060) is the control line, and the Voice side is the RTP port, this can be anywhere from 3000-65535 (UDP), the PBX documentation will provide this.

    The RTP ports are only opened (on the PBX) after negotiation, SIP 5060 port is the port you need to protect against problems, Like "ghost calls", this is where people use the application "SIP Vicious" to probe 5060-5062 for weak spots.

     

    I was thinking about this, and I have an alternative way to accomplish what you need.

    1. Create the "SIP Server Group", and a "RTP Server Group", add in the relevant servers into the Groups. 

    2. Create a Rule going from internal PBX to external Provider using SIP port only. (you may need to create a second rule in reverse of this rule from Ext SIP Provider to PBX, depends on your PBX)

    3. Here is where it becomes a little more complicated, and it all depends on how RTP is handled - it is either Direct (not via the PBX), or it is a VoIP Proxy (it uses the PBX for RTP).

    3.a. Direct - Create another rule from the Phone(s) to the RTP Server group using the RTP ports (noted in the PBX documentation).

    3.b. VoIP Proxy - Create a Rule from PBX to the RTP Server Group using the RTP ports (noted in the PBX documentation).

    4. Add you PBX into the Network Protection/VoIP/SIP Client Networks, then add bot the Groups (created in Point 1) to the SIP Server networks.

    I have set many systems up this way and have had no issues.

    you may need to add QoS for this, but I have found that this is only required if there is a lot of traffic across the network/UTM.

    I hope this helps you out with your requirements.

    XG & UTM Architect (Systems: XG v18 & UTM 9.7 - Virtual, HW & SW)
    Curious enough to take it apart, skilled enough to put it back together, Clever enough to hide the extra parts when I'm Done!

  • Jason,

    Thanks for the reply.  Your comments are absolutely correct and working IF the ITSP RTP server group is known.

    As I mentioned in the OP, callwithus uses a number of different servers in numerous geographic areas.  They don't disclose specific FQDN's, IP's, or any other way to identify their servers so I can create a specific host or dns group.

    Without this detail, the rest of the instructions don't work.

    FWIW, my configuration for callcentric is exactly as you describe.  They even have a faq entry for this exact information - https://www.callcentric.com/faq/9/254 .  Not so with callwithus.

    I've enabled full logging on the firewall for the pbx since adding cwu and implementing #2 in the OP.  So far the only traffic I see coincides with actual calls being made/received (based on CDR time stamps).  I'll leave the logging on for another week or so and if nothing unusual, turn it off.

    Also, with respect to pbx ports.  Yes, there's a specific range of rtp ports defined in the sip settings, but these don't seem to get applied or respected by the ITSP.

    Pbx in question is freepbx14/asterisk 15.