Hosted PBX use case for Service Providers

Size: px

Start display at page:

Download "Hosted PBX use case for Service Providers"

Dennis Chase
5 years ago
Views:

Hosted PBX use case for Service Providers This use case will show how to implement Hosted PBX Services for Service providers using an Access SBC in Front of the Hosted PBX platform and an SMB SBC at

1 Hosted PBX use case for Service Providers This use case will show how to implement Hosted PBX Services for Service providers using an Access SBC in Front of the Hosted PBX platform and an SMB SBC at customer premises to provide Security, Transcoding and Local Survivability to existing endpoints (IP Phones). The case can be used also as a sample for Large enterprises with Centralized IPPBX (Data center) and remote branch offices. We will also explain how to enable remote users roaming on Public Networks in a secure manner (Smart Phones, Home Offices, Employees on the field...) The following diagram shows the scenario: As we can see: All external Voice traffic is secure and encrypted (TLS/SRTP) All Internal Voice traffic is standard (SIP/UDP) We will show transcoding between GSM and G711 for Smartphone users Users in Branch office / Customer office will have local survivability, using the local SMB-SBC as a secondary registrar. In more detail here are the specifications of what we will configure in the Access SBC:

Let's Start!!!!! First we will create 2 Sip Profiles in our Access SBC, one internal, in the Private Subnet, facing the IPPBX/Softswitch located at 10.

2 Let's Start!!!!! First we will create 2 Sip Profiles in our Access SBC, one internal, in the Private Subnet, facing the IPPBX/Softswitch located at The External Sip ( ) profile will be used to receive upper registrations for end points coming from branch offices, via the local SMB-SBC. Note the following attributes: We are going to use a non standard listening port for UDP and TCP (15060). We will see also that we will use for TLS. The only reason we are enabling TCP and UDP in addition to TLS is for testing purposes. We recommend to change to TLS only once everything has been tested and we are going on production. The Internal Sip ( ) profile, listening on standard port will face the Softswicth/IPPBX Now, lest see what is needed in the External Sip Profile: First we need to associate a domain ( mypbx.ddns.net) for upper registration:

.0.1.252 on the private network We have enforced 60 seconds expires to be able to quickly detect

3 As we can see: Forward registration is enabled to be able to forward registrar requests to the IPPBX/Softswitch. IPPBX is in standar listening port at on the private network We have enforced 60 seconds expires to be able to quickly detect lost of service Transport between SBC and IPPBX on the internal network will be UDP Now our External SIP Profile nedds to bind the new domain:

Please note: Note we are using host: for external IP address for signaling and RTP mydemopbx.ddns.

4 At this point is importnt to note that the domaing is a full FQDN alse which resolves the public IP of the SBC in the internet. We will autodiscover that IP by using the prefix "host:" in the Sip Profile. Please note: Note we are using host: for external IP address for signaling and RTP mydemopbx.ddns.net Interop section will have default values, as well as timing section For TLS we will use previously loaded self signed certificates We will enable also SRTP Encryption and enforce it for any inbound invite in this profile.

5 Notice that all authentications are disabled, as it is being delegated to the IPPBX. We are also enabling all Far End NAT Transversal techniques and will aneable Full Idenification in session routing:

6 Notice we have associated a Routing plan called Inbound_to_PBX. Here it is:

7 So any inbound call coming in the External Profile will be routed to the IPPBX ( ) in the Private network via the Internal Profile (Internal_SIP_Interface) Now, we need to configure the Internal Profile, which will deliver calls to the PBX coming from Extensions at customer's premises, and receive calls from the IPPBX going out to those extensions.

8 This profile is alocated at the eth1 interface IP No need to reference any external IP address for translation Transport is UDP Standard port is used Now profiles with non default values:

Will accept blind authentication as this interface is never exposed and is in a secure Data center private network Will associated a Routing Plan that we will describe later (Outbound_All_Extensions)

9 Will accept blind authentication as this interface is never exposed and is in a secure Data center private network Will associated a Routing Plan that we will describe later (Outbound_All_Extensions) Will do a header manipulation previous to routing on calls landing on this profile (Domain_Routing_Header) Now, let look at the Header Manipulation rules: In thie manipulation, as an FQDN is used as the domin, and call will be routed to the external network to the customer on premise SMB-SBC, we need to asure the domain is properly passed. So, we will capture the domain name in a variable to be used on the Routing plan. We will use in this case Basic technique:

We will capture in kdomain the value " mydemopbx.ddns.net" if the call is coming from the host at 10

domain_name We are enforcing SRTP on the b leg when the call will be bridged We are enforcing TLS on the bridge application In case you

are only using PCMA and PCMU at this point.

10 We will capture in kdomain the value " mydemopbx.ddns.net" if the call is coming from the host at (IPPBX) Now let's see the Routing Plan "Outbound_All_Extensions": Notice: We are assiging kdomain to the channel variable domain_name We are enforcing SRTP on the b leg when the call will be bridged We are enforcing TLS on the bridge application In case you are doing test with UDP or TCP you can comment the current bridge sentence and uncomment the one not enforcing TLS In terms of coec we are only using PCMA and PCMU at this point. So Default media profile is as follows: At this point we have finished configuring the Access SBC at the Data Center or Enterprise central Site. Let's now do the configuration for the local SBC at customer premises. The setup for the Branch office will like like this:

Internal_Phones_Survival: to receive secondary registrar and process Sip requests as a secondary proxy for all local SIP end

11 As we can see we will be using a local domain in addition to the domain form upper registration to the data center. A total of 3 Sip Profiles will be needed: Internal_Phones: used to upper register extension to the central IPPBX Internal_Phones_Survival: to receive secondary registrar and process Sip requests as a secondary proxy for all local SIP end points. External_to_Carrier: to be used to snd and receive SIP to and from the Central IPPBX (via Access SBC) A Local Domain with local authentication is needed:

12 We will also create the USer Credential Information. In this case, just for two extensions (505 and 506)

13 Now we will show configuration for each sip profile: Internal_Phones Profile:

14 Notice: We will do a header manipulation to grant the domain name is passed correctly (Domain_Name_Pass) This internal profile will be associated with a Routing Plan called Outbound_to_Carrier Listening port will be standard Profile will be associated to internal interfce Header Manipulation:

$*"> <action application="export" data="dialed_extension=$1"/> <action application="export" data="sip_secure_media=true"/> <action application="export" data="domain_name=${kdomain}"/> <action$ $application="bridge" data="{sip_invite_domain=${domain_name}}sofia/external_to_carrier/${dialed_extension}@${domain_name}: 15061;transport=tls"/> </condition> </condition> </extension> Will look like$

15 Routing Rules: <extension name="from_local_to_pbx"> <condition field="caller_id_number" expression="^5.."> <condition field="destination_number" <action application="export" data="dialed_extension=$1"/> <action application="export" data="sip_secure_media=true"/> <action application="export" data="domain_name=${kdomain}"/> <action application="bridge" 15061;transport=tls"/> </condition> </condition> </extension> Will look like this: Notice: We are enforcing SRTP via the "sip_secure_media=true" We are checking call is coming from an extension via caller_id_number="^5.." <-- this could be just deleted to make it more generic We are enforcing sip domain name in the bridge as well as TLS in Leg B via Externa_to_Carrier profile Now, let's present what to do with the external profile:

16 Transport protocol will be TLS Associated to external interface External public IP address will be announced for signaling and RTP

17 TLS will use a selfsigned certificate SRTP is enabled and enforced for all inbound trafic on this profile

Branch Office should be able to register in the central IPPBX and also be able to make calls between extensions.

18 NAT is not eneabled except for RTP Adjust to avoid certain cases where audio in one side will not wait for the other side. A Dial plan as been associated for incoming calls to the profile (Inbound_Dialplan) Here we are showing the Inbound dial plan associated to this external profile: At this point Any Endpoint at the Branch Office should be able to register in the central IPPBX and also be able to make calls between extensions. Any VoIP Trafic in the Internet will be tatlly secure with TLS/SRTP TLS and SRTP functionalities are jept at the SBC's levels and no need for any considertion at the IPPBX level or endpoint is needed. Now, we will add one more level of complexity by implementing dual registration at the endpoints in the Branch Office On this excercise we will use SNOM 870 SIP Phones, but it can be implemented in any phone supporting Dual Registration (Polycom, Yealink, AASTRA and Grandstream has been tested. Call for details if needed) So, we will use the secondary domain ( mydemopbxbkp.ddns.net) for the prupose of secondary registrar for the End Points. The way SNOM implements Dual Registration, is by using what they call "Failover identity". So, for example for extension 505 we will create an identity to upper register on the PBX via the local SBC as follows:

19 Notice: Domain in SNOM is communicated in the SIP header via the registrar FQDN, and corresponds to the domain used with the IPPBX /Softswitch We are using the local SBC internal profile as the outbound proxy to be used by the phone. This is identity 1, but we are assigning Identity 2 as the Failover (or secondary registrar) The Failover Identity will look like this:

20 Notice: Domain used is the local domain we created for survivability purposes (mydemopbxbkp.ddns.net Outbound proxy corresponds to a new internal sip profile called (Internal_Phones_Survival) using the listening port associated to this profile (6060) This new profile will have the following configuration:

Even so, you can still test calls between the two extensions as the SNOM will start using automatically Identity 2 for the failed Identities.

22 Routing rules associated to this profile is the ona named Local_Calls, which will look like this: At this point, you can test by blocking connectivity to the central site and you will notice on the phone that Identity 1 (Extensions 505 and 506) become red to make clear registration have failed. Even so, you can still test calls between the two extensions as the SNOM will start using automatically Identity 2 for the failed Identities. Now are are going to enable users to directly register on the PBX via the access SBC on the central site. This is a typical situation for employees traveling with Softphones on their Laptops or SmartPhones, or even very small braches or home offices, with a few extensions. So, what we will need, as we don't have in this situation an SMB-SMB on premise, is to configure the endpoint to support TLS/SRTP and we will point them directly to the corporate/central SBC for upper registration and SIP requests.

23 No need to make any changes at any of the SBC's as we are going to take advantage of the same domain " mydemopbx.ddns.net" and the External SIP Profile we created for Branch offices. Conceptually this is because from the perspective of the Access SBC there is no difference between and end point coming from a branch (As the local SBC takes the personality of all endpoint behind him), and an isolated end point in the public internet. In both cases the Access SBC will only accept TLS/SRTP traffic. So, let's show how an extension confiuration on the pubic internet will look like, using a SNOM 870, extension 506:

24 Notice: We are using the mydemopbx.ddns.net domain outbound proxy is " mydemopbx.ddns.net:15061;transport=tls", as this FQDN will resolve to the IP Public address for the Access SBC. There is no failover identity defined.

25 Notice: Enabled RTP Encryption At this point you can test between Branch Office extensions and Extension on the Internet. We have acomplished the goals for the use case. Any question, suggestions or comments feel free to me: Enjoy!!!!

Configuration Guide IP-to-IP Application

Multi-Service Business Gateways Enterprise Session Border Controllers VoIP Media Gateways Configuration Guide IP-to-IP Application Version 6.8 November 2013 Document # LTRT-40004 Configuration Guide Contents