DNS Question - Remote Phones and SBCs

[pmkr...@gmail.com]

Know there is some deep DNS expertise on this forum – hopefully there is a quick answer to a question I have been trying to answer unsuccessfully for a few days around remote phones.

I have been working with remote phones registering to an SBC who in turn will forward the registration to Sipxcom.  With one remote phone registered on the network, everything works fine. The problem is when two or more remote phones are deployed – each remote phone needs its own SIP domain name defined in the SBC (SBC limitation).

Is there a way within Sipxcom to do the following (assume Sipxcom has SIP domain name of example.com):

• ·  Remote phone 1 has fqdn of rphone1.example.com – this gets provisioned in the SIP line server address field of the first remote phone
• ·  Remote phone 2 has fqdn of rphone2.example.com – this gets provisioned in the SIP line server address field of the second remote phone
• · Through use of DNS alias records or custom DNS (e.g. A or SRV) records within Sipxcom, there is a way to make call routing work between local phones (who have example.com provisioned in the SIP line server address field) and remote phones.

Any insights are greatly appreciated.

All the best

Peter

[Joe Micciche]

On 04/13/2016 11:21 AM, pmkr...@gmail.com wrote:
> I have been working with remote phones registering to an SBC who in turn
> will forward the registration to Sipxcom. With one remote phone registered
> on the network, everything works fine. The problem is when two or more
> remote phones are deployed – each remote phone needs its own SIP domain
> name defined in the SBC (SBC limitation).

In this case, would it simply not be better to just use sbc as a
firewall and disable registrations on it? Have the sbc pass all SIP
traffic to sipXcom, after applying the various
rules/filters/manipulations/etc.

What you're suggesting seems a nightmare to support + much extra work.

--
==================================================================
Joe Micciche | Red Hat, Inc. | www.redhat.com
Senior Communications Engineer | +1.919.754.4554 | X81 44554
==================================================================

[pmkr...@gmail.com]

Thanks Joe for the response - I agree. I'm in the last stages of compiling an interoperability document for the Wiki describing Sipxcom / Skype for Business integration with the Sangoma SBC. I want to cover the upper registration issue as part of the document; hence the reason for this post.

Under the covers the Sangoma SBC is Freeswitch with a GUI. In their implementation, registrations are not passed transparently from one side of the "B2BUA" to the other; so a feature called upper registration was created. Because of the question I asked combined with maintenance of firewall rules for provisioning, the upper registration capability (my view) has limited utility with Sipxcom. For remote phones, a much simpler approach from an operational perspective is to establish a VPN tunnel.

I'd be interested in alternative perspectives, and will capture in the Wiki submission.

All the best
Peter

[Nathan Baker]

Peter,

You didn't mention Sangoma in your original post so I wasn't sure which SBC you were referring to.  Did Sangoma tell you it was a limitation of their SBC, and the phones needed to be on unique domains?  Are these remote phones all at the same location (getting NATd to the same public IP)?  We have upper registration working with several phones all on one domain, we only ran into issues when trying to register the same extension/user more than once through the SBC.  Sangoma support did help me get past that issue (which won't affect everybody anyway) with a custom configuration.

Upper registration was developed by Sangoma, and although they said they were going to contribute it back to FreeSWITCH, I'm not sure if they ever did.  See this for reference: http://lists.freeswitch.org/pipermail/freeswitch-dev/2013-June/006576.html

Are you looking for a solution for several remote phones at one location (not connected with VPN or private connection), or one remote phone per location (employees working from home, etc)?  

-Nate

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/c2ca6753-78aa-4e11-95e5-4d629c8fbe57%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pmkr...@gmail.com]

Hi Nate,

Many thanks for the response - it is the Sangoma SBC I am trying to capture in a wiki document. I was reluctant to mention them by name as I was hoping to test possible workarounds to ascertain the issues are not on my side.

Attached is the reference architecture I'm trying to document - with one remote phone, all local-remote call features work with the exception of shared lines, intercom. and MOH when the remote phone is put on hold. With two remote phones behind a remote router, I have not been able to calls working consistently. I have not been able to find a way with the latest SBC release to take a common SIP SIP domain and map it to unique ports on the Sipx side of the B2BUA. My intuition is that the SBC will be able to handle call flows properly between the remote phones if unique port numbers are defined on either side of the SBC B2BUA.

ISTP to Sipxcom local phones work without issue, as do Skype for Business to Sipxcom call via the SBC - it's the remote phones with upper registration that would be good to capture in the wiki (including remote phone scalability).

Any insights are appreciated.

All the best
Peter


 

Many thanks for the response.

[Nathan Baker]

Peter,

I have a few questions if you don't mind, hoping to clear up some stuff:

1) Do you have separate profiles on the Sangoma SBC for SIP trunking and remote phones?

2) Are you doing a static NAT for the remote phones, or otherwise why are you listing a port number for each of them?

3) Did Sangoma tell you this was a limitation, and that a separate domain was needed for each remote phone?

4) Why are you trying to map one domain to several unique ports on the SIPX side of the SBC?

Thanks,

Nate

--

You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To post to this group, send email to sipxco...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/cdb51691-6977-4ff7-8461-ac6156a60211%40googlegroups.com.

[pmkr...@gmail.com]

Hi Nate, My previous submission from this morning did not get posted, so you may see this twice. Good questions and understand why you're asking - my responses are in-line.

On Monday, April 18, 2016 at 8:04:06 AM UTC-4, Nate Baker wrote:

Peter,

I have a few questions if you don't mind, hoping to clear up some stuff:

1) Do you have separate profiles on the Sangoma SBC for SIP trunking and remote phones?

Yes - in fact to ascertain there are no conflicts, this test SBC only have profiles for the remote phones. Once this capability has been validated, I intend to add in additional trunking profiles and dialplans.

2) Are you doing a static NAT for the remote phones, or otherwise why are you listing a port number for each of them?

Static port forwarding for the two remote phones to allow incoming SIP messages to be forwarded to the correct phone regardless of firewall state. As I think of this question, I should have the SBC ping the remote router every 20 seconds or so see whether it keeps the firewall states active after the lines register. If so, this may eliminate the need for separate ports on each phone.  

3) Did Sangoma tell you this was a limitation, and that a separate domain was needed for each remote phone?

In parallel to this query, a ticket was opened with Sangoma. They did confirm for me on Friday that with upper registration, there is a 1-1 mapping between the domain name and SIP profile used between the SBC and Sipx.
 

4) Why are you trying to map one domain to several unique ports on the SIPX side of the SBC?

 By specifying the IP address of the voice server in the remote phone rather than the sip domain in the line->server field when the phone registers as well as the call routing dialplan, I've been able to place  calls between the remote phones as well as remote<-> local phones - it's essentially a workaround to the 1-1 mapping restriction between the domain and SIP profile (previous point). When the same port number is used to Sipx, the SBC rejects some incoming calls from local phones to remote phones due to 'user registration not found' issues. The SBC internally appears to prefer unique port number across all profiles - at the least the way I have configured the SBC. 

[pmkr...@gmail.com]

I've made some progress. By having the SBC issue the options command to the remote router every 30 seconds, there is no longer any need for static port forwards being defined on the remote router. As well, the same port can be used between the SBC and Sipxcom.

The current issue is the remote and local routers. They keep track of firewall states on the WAN interfaces using the local WAN address, remote WAN address, and port numbers. When it sees two remote phones behind the router, it will map the state of the last remote phone registered to the SBC, and override the state information of the other remote phone(s). Using different signaling port numbers to the SBC resolves this issue. The attached image shows the firewall states for one of the remote phones - you can either get one phone working consistently, or the other, but not both at the same time.

When the remote phone is given a public IP address, this is not an issue with upper registration. It is also not an issue with 1 remote phone behind a router. I can work around this using some SBC dialplan magic and provisioning of the remote phone in a slightly different manner to complete this section of testing.

Peter

[Joegen Baclor]

Forcing tcp transport on your remote phones should fix your nat port issues - joegen

To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/72cb841d-5160-41f0-8ad1-c4436e4a8a03%40googlegroups.com.