I have the following scenario:

We run our own IVR. The IVR is a Windows service (or it can be run that way anyhow) that we wrote using UCMA. Of course Microsoft doesn't support SIP over UDP so we have to convert our incoming SIP UDP to SIP TCP. To do this we put Freeswitch in-front of it and translate. (it can also be run as a windows service)

This works fine on a VM because I can install these and maintain them myself, but I'd rather do this with better management at the Azure level using (presumably, correct me if I'm wrong) Cloud Services.

Now I can update our IVR Windows Service to use Azure Cloud Services and will do so once I have this fully flushed out but I'm having difficulty understanding all of the moving pieces. So presuming that I can do this all in Cloud Services I would like to know the following:

1. How do I package up Freeswitch and get it installed as a service and copy in all of our configuration options? (xcopy will work with Freeswitch, it has no dependencies, so I can create a zip or something that has our configuration files already setup)

2. How do I get it a dedicated public IP address and open up the right ports for Freeswitch?

3. Once I convert our IVR to an Azure cloud service, how do I get it to have an internal IP address that Freeswitch forwards from and receives data from as well? (i.e. I need to get Freeswitch to have both internal and external ips and the IVR service to have an internal one that Freeswitch knows about to forward.) 

3b. How do I get the UCMA Runtime V 5 installed

4. We also have an internal mvc.net app that receives a rest request from our SMS api and uses that to make a call out. I'd like to re-write this as part of the IVR service if I could. I was thinking about using self-host with Katana within the IVR instead of using IIS to host it and still getting the simple REST compatibility to do it all from the same service, which seems straight forward to me. However the difficult part for me to understand is how to get an internal IP address that our web app running under IIS can access and call to the Katana REST service as an HTTPPOST and wait for a response. It seems to me that I should be able to setup an shared internal network stack for this stuff but I can't understand how.

My issue is that while setting up websites and a database has been pretty straight forward and obvious, hooking up these more complex services is daunting and understanding how everything hooks together is a non-trivial learning curve so any advise would be greatly appreciated.

(and if this isn't possible and requires a VM that's ok too.)

Thanks!

• Edited by JohnGalt1717 Friday, July 31, 2015 3:54 PM

Hello,

We are researching on the query and would get back to you soon on this. I apologize for the inconvenience and appreciate your time and patience in this matter.

Best Regards,
Prasandhi Kumar

Hi John,

Sounds like an exciting project, I was in the same spot about 6 months ago, so many different options in Azure.

Cloud Services can deploy a web role or worker role. The worker role is what is the closest to a more traditional windows service. It is very straight forward to migrate an existing service over to a worker role. The advantage of Cloud Services over VMs  is you do not have to worry about patching the OS and they are very easy to auto scale.

1) I cannot give a confident answer on deploying a 3rd party service to a worker role, I would recommend researching this for a solid answer

2) As part of the cloud service configuration you set public end points (ports), which allow you to map public ports to internal ports similar to a NAT configuration in a firewall. You cloud service will also have a virtual ip address, which is the public address on the Azure load balancer, this is the address your customers will connect to. The end points will be listening on this virtual ip address and the load balancer will route the traffic across all of your worker role instances configured under your cloud service. 

I highly recommend that you create a reserved virtual ip address (via cli) so that it does not accidentally get swapped out during some update. If you shutdown all instances in your cloud services its virtual ip will be released.

3) You want to create a vnet in azure. The VNET will be your internal network (10.*.*.*) which all your cloud services and VMs can communicate over privately. When you configure your cloud services you assign them all to the same vnet. You can also create connections between multiple vnets and even create a vpn wan to your on premise servers / office if need be.

4) if you are moving towards cloud services for ivr via worker roles, maybe just use web roles to run your mvc app. You do not need to configure a public end point if it is internal only service and by making it part of the vnet I mentioned above your other worker roles can talk to it on the vnet 10.*.*.* subnet.

On a side note, I would not rule out running VM if need be for the freeswitch services, they can be provisioned on the same VNET as well under their own cloud services container and scale them independently.

I hope I provided a bit of guidance to get you going in the right direction! I have found Azure to be a very flexible platform. Also consider building your infrastructure via a powershell script, worth the effort. 

• Proposed as answer by Nithin.RathnakarMicrosoft contingent staff, Moderator 20 hours 6 minutes ago
• Marked as answer by Nithin.RathnakarMicrosoft contingent staff, Moderator 11 hours 44 minutes ago

Hi John,

Sounds like an exciting project, I was in the same spot about 6 months ago, so many different options in Azure.

Cloud Services can deploy a web role or worker role. The worker role is what is the closest to a more traditional windows service. It is very straight forward to migrate an existing service over to a worker role. The advantage of Cloud Services over VMs  is you do not have to worry about patching the OS and they are very easy to auto scale.

1) I cannot give a confident answer on deploying a 3rd party service to a worker role, I would recommend researching this for a solid answer

2) As part of the cloud service configuration you set public end points (ports), which allow you to map public ports to internal ports similar to a NAT configuration in a firewall. You cloud service will also have a virtual ip address, which is the public address on the Azure load balancer, this is the address your customers will connect to. The end points will be listening on this virtual ip address and the load balancer will route the traffic across all of your worker role instances configured under your cloud service. 

I highly recommend that you create a reserved virtual ip address (via cli) so that it does not accidentally get swapped out during some update. If you shutdown all instances in your cloud services its virtual ip will be released.

3) You want to create a vnet in azure. The VNET will be your internal network (10.*.*.*) which all your cloud services and VMs can communicate over privately. When you configure your cloud services you assign them all to the same vnet. You can also create connections between multiple vnets and even create a vpn wan to your on premise servers / office if need be.

4) if you are moving towards cloud services for ivr via worker roles, maybe just use web roles to run your mvc app. You do not need to configure a public end point if it is internal only service and by making it part of the vnet I mentioned above your other worker roles can talk to it on the vnet 10.*.*.* subnet.

On a side note, I would not rule out running VM if need be for the freeswitch services, they can be provisioned on the same VNET as well under their own cloud services container and scale them independently.

I hope I provided a bit of guidance to get you going in the right direction! I have found Azure to be a very flexible platform. Also consider building your infrastructure via a powershell script, worth the effort. 

• Proposed as answer by Nithin.RathnakarMicrosoft contingent staff, Moderator Wednesday, August 05, 2015 11:13 AM
• Marked as answer by Nithin.RathnakarMicrosoft contingent staff, Moderator Wednesday, August 05, 2015 7:35 PM