Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Mitel Collaboration Advanced (AWC) - Web Conferencing
- Thread starter kwbMitel
- Start date
I have heard you can get it to work this way although I have never done it. You need to put it in a DMZ on a separate firewall network interface and set it up as a one-to-one NAT policy for that public IP to be statically routed to the private IP on the LAN. So I guess it would depend on the firewalls capability. I have our MBG on a separate server on a different subnet to keep things simple and separate and have a static route setup in the firewall so that subnet0 can talk to subnet1. I think it is more secure this way. Mitel doesn't recommend using the same server (so I've been told) so depending on how many teleworkers you have you do not need a very high profile server, so it shouldn't be to expensive to keep the servers independent. What kind of firewall are you using if you don't mind posting?
And by separate public IP I imagine you mean different then the public IP that the computer network uses to reach out to the internet then yes. The port forwarding would compete with and other services required that use the same ports as the Mitel MBG and the regular services for things other than Mitel wouldn't be able to communicate properly with each other. For a DMZ to properly work you need a separate public IP so that all ports can be forwarded to a dedicated specific destination.
And by separate public IP I imagine you mean different then the public IP that the computer network uses to reach out to the internet then yes. The port forwarding would compete with and other services required that use the same ports as the Mitel MBG and the regular services for things other than Mitel wouldn't be able to communicate properly with each other. For a DMZ to properly work you need a separate public IP so that all ports can be forwarded to a dedicated specific destination.
- Thread starter
- #4
I have 2 sites where I need to get this working.
Both are running on the network edge in server and gateway mode.
Because AWC uses different ports than TW I thought it might be possible to share the same IP as TW.
I can't find anything in the docs one way or the other.
**********************************************
What's most important is that you realise ... There is no spoon.
Both are running on the network edge in server and gateway mode.
Because AWC uses different ports than TW I thought it might be possible to share the same IP as TW.
I can't find anything in the docs one way or the other.
**********************************************
What's most important is that you realise ... There is no spoon.
The MBG also contains the AWC via MAS?
Your logic is sound as you are correct the AWC hopefully uses completly different ports then TW sets. The question then becomes how to route traffic to the correct application. I guess you would need to setup port forwarding in the MSL so that if the MBG sees a call to a particular port then it knows to forward it to the proper application. I have no idea how to do that.
Was wondering if a seperate MBG and using its embedded Webproxy would work?
I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
Your logic is sound as you are correct the AWC hopefully uses completly different ports then TW sets. The question then becomes how to route traffic to the correct application. I guess you would need to setup port forwarding in the MSL so that if the MBG sees a call to a particular port then it knows to forward it to the proper application. I have no idea how to do that.
Was wondering if a seperate MBG and using its embedded Webproxy would work?
I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
Yes you can
A mas server if running as a physical server in server gateway mode can share the main IP with TW and MCA
MCA still requires a secondary Ip for the MCA client to use.
If I never did anything I'd never done before , I'd never do anything.....
A mas server if running as a physical server in server gateway mode can share the main IP with TW and MCA
MCA still requires a secondary Ip for the MCA client to use.
If I never did anything I'd never done before , I'd never do anything.....
- Thread starter
- #7
@Billz66, I keep seeing the second IP in the Docs but I don't understand the purpose. Can you elaborate for me?
I have a customer that has Collaboration working with just 1 IP. What is the other for exactly?
**********************************************
What's most important is that you realise ... There is no spoon.
I have a customer that has Collaboration working with just 1 IP. What is the other for exactly?
**********************************************
What's most important is that you realise ... There is no spoon.
Think the first is for external access to the admin portion and the second for collaboration. I find this in the Web Proxy course.
AWC: Audio and Web Conferencing (AWC) provides an integrated application to create Audio and Web conferences using corporate directories and personal address books from Microsoft Outlook. AWC is packaged on the Mitel Applications Suite (MAS) server, which is linked by an Ethernet connection to the IP network. The “My Unified Communications portal” on the MAS server allows the administrator to configure AWC, schedule conferences, view conference calls, and administer collaboration controls. Internet Clients wanting to connect with this interface for administration will reference a FQDN on an External DNS that will connect them with the Firewall (HTTPS). The Firewall will forward the traffic to the Web Proxy which in turn will analyze the packets and send the AWC traffic to the correct MAS server, assuming that AWCis enabled in Web Proxy as shown below. Examples are provided later in this module.
The second address is for the listen port.
AWC Listen Port: In addition to the My Unified Communications portal used for AWC administration support, a AWC Listen port is defined to allow AWC Collaboration (i.e. Web conference) traffic to flow from the AWC client to the MAS server via the firewall and Web Proxy. A separate network interface is required at the firewall (you cannot use the same IP Address as the My Unified Communications portal). The firewall takes the Web Conference traffic and converts the port from 443 to a predefined setting. The traffic will be sent to the Web Proxy assuming that the predefined port setting on the Firewall matches the AWC Listen port setting on the Web Proxy (default setting is 4443 to match the AWC defaults). Web Proxy in turn will send it to the MAS server. Examples are provided later in this module
I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
AWC: Audio and Web Conferencing (AWC) provides an integrated application to create Audio and Web conferences using corporate directories and personal address books from Microsoft Outlook. AWC is packaged on the Mitel Applications Suite (MAS) server, which is linked by an Ethernet connection to the IP network. The “My Unified Communications portal” on the MAS server allows the administrator to configure AWC, schedule conferences, view conference calls, and administer collaboration controls. Internet Clients wanting to connect with this interface for administration will reference a FQDN on an External DNS that will connect them with the Firewall (HTTPS). The Firewall will forward the traffic to the Web Proxy which in turn will analyze the packets and send the AWC traffic to the correct MAS server, assuming that AWCis enabled in Web Proxy as shown below. Examples are provided later in this module.
The second address is for the listen port.
AWC Listen Port: In addition to the My Unified Communications portal used for AWC administration support, a AWC Listen port is defined to allow AWC Collaboration (i.e. Web conference) traffic to flow from the AWC client to the MAS server via the firewall and Web Proxy. A separate network interface is required at the firewall (you cannot use the same IP Address as the My Unified Communications portal). The firewall takes the Web Conference traffic and converts the port from 443 to a predefined setting. The traffic will be sent to the Web Proxy assuming that the predefined port setting on the Firewall matches the AWC Listen port setting on the Web Proxy (default setting is 4443 to match the AWC defaults). Web Proxy in turn will send it to the MAS server. Examples are provided later in this module
I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.
- Status