Author Archive: Ashwani Gupta

Can’t remote controll Win8 screen through share pod if task manager window is there on desktop

Method:

  1. Launch a meeting in add-in on win 8 machine.
  2. Have another user join this meeting.
  3. Share screen from win 8 machine.
  4. User2 click on request control and verify the behaviour when user accepts the request.
  5. Bring task manager on screen and verify.

Observed:

User is not able to control the screen being shared after the task manager if brought in.

Reason:

This is expected. Windows 8 Task Manager runs on a separate desktop and as such any keyboard or mouse event that is sent while it is on can not be sent across to remote machine. This can be viewed similar to UAC dialogs on Windows 7.

While screen sharing Powerpoint application if user clicks on Import Video/SWF button of Adobe Presenter, other users dont see Import Video/SWF modal dialog box.

Method:
1. Enter in a meeting as a host and as a participant.
2. Open Powerpoint which has Adobe Presenter addin installed.
3. Now select share my share button in meeting’s share pod.
4.Select application radio button in the screen sharing dialog box that comes up.
5. Select Powerpoint application and start sharing.
6. Now click on Adobe Presenter tab in Powerpoint.
7. Click on import Video button in the Adobe Presenter tab.
8. The Import Video modal dialog box will appear.
9. Observe the screen from participant’s meeting client.

Observed:
Other users see hashed area instead of the modal dialog box.

This is expected. Import dialog of presenter is a separate process and thus can not be shared while doing application sharing. Only the parent process’ screen is shared.

Learners can’t view training correctly if a recording has been added as a training content.

STEPS TO REPRODUCE:

  1. Create a meeting recording that has at least one presentation shared in it in a share pod
  2. Now move that recording anywhere in the content folder
  3. Now create a training curriculum
  4. Add an item to that curriculum and select that created recording as a content for that.
  5. Enroll the learners group for that curriculum, so that it can be viewed by all learners.
  6. Login with a learner’s username/password and try to open the content in the curriculum.

RESULT:

When trying to view the training content, while being logged in with a learner’s account, the share pod in the recording stay stuck at loading and doesn’t render the actual presentation. It works fine when logged in as an administrator.

REASON:

When recordings are moved to a content folder

  • the recordings are, by default, set to inherit their permissions from the parent (content folder they were moved to)
  • the parent folder is protected (either explicitly, or because it inherits permissions from its parent, and so on).

 

WORAROUND:

The easiest way around is:

  • a) Under the “Shared Content” folder, create a new “Shared Recordings” folder
  • b) Set the permissions of this folder to “Allow Public Viewing”

Can’t add GlobalMeet PGi telephony profiles to Connect 7.5 or earlier. PGi Readyconference accounts gets added fine.

Issue:

Can’t add PGi GlobalMeet telephony profiles to Connect 7.5 or earlier. PGi Readyconference accounts gets added fine.

 

Error in debug.log:

[09-13 10:04:31] web-24 (d) <status code=”invalid”><invalid field=”number-toll-free” type=”unavailable” subcode=”missing”/></status>
[09-13 10:04:31] web-24 (d) com.macromedia.airspeed.StatusException$Invalid$Missing: <status code=”invalid”><invalid field=”number-toll-free” type=”unavailable” subcode=”missing”/></status>

 

Solution:

Contact PGi TECHNICAL SUPPORT and get dial in number-set re-ordered to list the toll-free number ranked as #1. Please refer to screenshot below:

OR

Update your Connect server to Connect 7.5 SP2 or later. The new telephony adaptor available in this version should take care of the issue.

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&nbsp; 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.