Monthly Archives: March 2011

Configure 3CX to use DIDforSale DIDs

If you have not checked out DIDforSale and have any need for robust and inexpensive inbound DIDs… do so now.

For those of you who have a 3CX PBX install in addition to DIDforSale DIDs and are having trouble configuring 3CX to correctly talk to the DIDforSale SIP Trunk, this blog entry will save you time and frustration.

NOTE: This entry can also be used to configure multiple DIDs for most other SIP Trunk providers.

Prerequisites

  • You have a fully functional install of 3CX version 9
  • You are not behind a firewall -OR- you have all required ports forwarded to support the SIP protocols
  • You have configured your DIDs to point to your external IP address for 3CX
  • Coffee is brewing

Step#1: Setup a new VOIP provider for DIDforSale
This step creates a generic VOID provider for DIDforSale and setups the basic parameters for the provider.

  1. Click the Add VOIP Provider Wizard button located on the toolbar of your 3CX management console
    image
  2. Give the VOIP Provider an appropriate name for your 3CX install and select Generic SIP Trunk
    image
  3. In the VOIP Provider Details screen, enter the SIP server hostname or IP as 209.216.2.211 (the IP for DIDforSale’s SIP server).  Leave all other data as the default
    image
  4. In the Account Details screen, set the value for the fields as follows:
    External Number: Your PIN number as supplied by your Trunk provider
    Authentication ID: Your login account (UserID) as supplied by your Trunk provider
    Authentication Password: Your password as supplied by your Trunk provider
    Maximum simultaneous calls: Whatever your license with 3CX allows
  5. In the Office Hours screen, select any extension you would like this to be forwarded to.�
    NOTE: Anything you set in this screen will be overridden once we setup the inbound DID rules in the next section.
  6. The next screen will attempt to create an outbound call rule for DIDforSale.  Unless you are using DIDforSale as an outbound provider, click the Skip button.

Step#2: Configure the provider’s inbound parameters
This step configures the VOIP provider to properly extract the inbound DID # from the SIP request as sent by DIDforSale.  Without this step, 3CX will not be able to determine which phone number the inbound call is targeted for.

  1. Open and edit the VOIP provider created in Step#1
    image
  2. Select the Inbound Parameters tab
  3. Select and delete the To: User Part SIP Field (see highlighted image below)
    image
  4. Add a new SIP Field
    1st: Set the SIP Field combo box to Request Line URL: User Part
    2nd: Set the variable to “CalledNum” number that has been dialed
    3rd: Click Add/Update
    (See image for selection)
    imageNOTES: DIDforSale sends the destination phone # in the DIDNumber@YourIPAddress format.  This change tells 3CX to pull the CalledNum from the URI (I.E. the inbound phone number is the DIDNumber part of DIDforSale’s inbound request)
  5. Click Apply

Step#3: Add and route your DID numbers
This step setups each DID number and the internal routing associated with that inbound DID.

  1. Open the VOIP provider created in Step#1
  2. Select the DID tab
  3. Enter your DID number and click Add
    image
  4. Click Apply
  5. Select the Source ID tab
  6. Make sure the Source identification by DID is checked
  7. Click Add DID and select the DID you added in #3 above
    NOTE: If you do not see the DID number, you forgot to click Apply in #4 above
    image
  8. Select the inbound rule which was automatically created when you entered the DID number.
    image
  9. Change the office hours and routing rules to fit your organizations needs for the DID number being configured.
  10. Repeat these steps for each DID number you need to configure

Step#4: Coffee Time!

Creating Hyper-V virtual networks and the dreaded “Cannot bind to” error message

8 Replies

Windows 2008 R2 Hyper-V server is an incredible tool in the IT pro’s test, backup, and recovery arsenal…. as long as everything meshes together nicely.

One of the more interesting errors we see in the field is the dreaded message

Error Applying New Virtual Network Changes
Binding to the external ethernet [NIC goes here] failed.
Cannot bind to [NIC goes here] because it is already bound to another virtual network.

image

 

We at AIS see this problem most often when dealing with multiple-NIC servers.  The failure scenario goes something like this:

  1. Provision and configure Hyper-V server 2008 R2
  2. Access the new Hyper-V server via Hyper-V Manager on a separate PC
  3. Provision the first NIC under a virtual network
  4. Provision the second NIC under a virtual network (At this point, something goes awry in the Hyper-V Manager due to a variety of RPC / COM issues… the list of which would fill a small book)
  5. The second NIC provisioning is partially active within Hyper-V but is not accessible via the Hyper-V Manager
  6. Any additional attempts to provision the second NIC will now be met with the dreaded “is already bound to another virtual network” error

The quick and dirty solution

  1. Remote desktop into the Hyper-V server
  2. Find the command prompt window
    This is usually located behind the blue colored Server Configuration prompt window
  3. Type the following commands to uninstall and then reinstall the Microsoft Virtual Network Switch Protocols

C:> netcfg –u vms_pp

C:> netcfg –c p –i vms_pp

 

These two commands will 1st uninstall the virtual switch protocols and then force a reinstall of the same protocols.  This simple two step process forces the invalid virtual network mapping to be cleared from the configuration.

Happy (Virtual) Mappings!