Posts tagged "edge"

Telephony conference fails to start when we have an edge server in front of Connect Origin server.

Issue:

Telephony conference fails to start when we have an edge server in front of Connect Origin server.

Reason:

Licensed customers who use telephony that makes call-back to Connect (Intercall, for example) must open port 9080 on their firewall so that the call-back can be made. If the Intercall bridge cannot make the call-back to this URL on port 9080 the conference will not launch. It uses the call-back URL for anything you do in the conference call – mute a user, hang-up etc. The call-back URL must provide Intercall with a direct route to the origin running the meeting room.

When we have an edge server between the telephony provider and Origin server, we need to ensure that edge listens on port 9080 (in addition to 80,443,1935) and forwards 9080 traffic to Origin server. Additionally, if the origin server is clustered, we need to ensure that the response of call-back requests is sent back to the origin server who initiated the request. We cannot let edge server send these request to load balancer and have latter load balance this traffic between the origin nodes. If we do so, half of the call-back (round robin) requests will fail.


Solution:

To ensure call back is successful:

1) Make the Edge listen on ports 9080 and 9081 (in addition to current 80, 443, 1935).

2) Add redirects for each of these ports in adaptor.xml file such that

Port 9080 is redirected to origin1:9080

Port 9081 is redirected to origin2:9080

3) Change call-back URLs on both origin servers such that

Call-back URL on origin1 is connect.example.com:9080

Call-back URL on origin2 is connect.example.com:9081

4) Open TCP ports 9080 and 9081 to the Edge servers on the firewall.

 

The Connect configuration:

1) In \edgeserver\win32\conf\_defaultRoot_\adaptor.xml, add entries to map edge:ports to origins:ports as follows

origin1 IP Address:9080

origin2 IP Address:9080

2) In \edgeserver\conf\config.ini add entries to for ports on which the  Edge listens as follows:

FCS.HOST_PORT=:1935,80,443,9080,9081

3) On origin 1:

connect.example.com:9080/services/CCAPICallbackSOAP

4) On origin 2:

connect.example.com:9081/services/CCAPICallbackSOAP

Now if a meeting is launched on Origin server 2 and an Intercall conference is started, that Origin server will make a connection to the Intercall conference bridge. The call-back URL that Intercall receives will contain the port number 9081. Intercall will hit the Edge server on port:9081 and the Edge server will redirect the request to Origin server 2 because of the redirect we placed in its Adaptor.xml.

Encrypting traffic between Edge and Origin Server on 8506.

Issue:

Encrypting traffic between Edge and Origin Server on 8506.

Solution:

By default, the traffic between external edge and origin server is in clear. To encrypt that, follow the steps below:

Step 1:

On the remote Edge servers, edit: /breeze/edgeserver/win32/conf/_defaultRoot_/_defaultVhost_/vHost.xml:

replace:
<RouteTable protocol=""> with
<RouteTable protocol="rtmps">
replace:
<RouteEntry></RouteEntry> with
<RouteEntry protocol="rtmps">*:*;*:*</RouteEntry>

Step 2:

Secure the 8506 traffic at the Origin server on 8506 exactly as though it were client traffic inbound to port 1935 except using port 8506 instead.

On the origin servers (or on the origin’s SSL accelerator), encrypt the inbound Edge to origin traffic on port 8506. The example below shows an stunnel.conf file on origin server, add for the IP receiving rtmp traffic on the meeting server VIP:

#[rtmps-vip for Origin]

accept = 10.40.2.54:8506

connect =InternalIP02:8506

 

Note:

One caveat with this technique of doing SSL, is that when you view the RTMP sequence from within a test meeting (Help>Shift>About Adobe Connect) the second leg of the RTMP sequence will read RTMP even though it is actually RTMPS. We are testing for a means to adjust that output, but it is very trivial as the first leg does read RTMPS and adjudicates both legs.