please write to the list this way others can help or can search screen-sharing is still broken https://issues.apache.org/jira/browse/OPENMEETINGS-1358 I'm working on it with red5 devs this is currently our only show-stopper for 3.1.2 release
On Fri, May 27, 2016 at 2:36 PM, Jason Romo <[email protected]> wrote: > Rooms work fine, but screen share doesn’t. logs show this: > > DEBUG 05-27 03:28:33.834 StartSharingEventBehavior.java 173901 153 > org.apache.openmeetings.web.room.StartSharingEventBehavior > [http-nio-0.0.0.0-443-exec-2] - RTMP Sharer Keystore :: start > [INFO] [http-nio-0.0.0.0-443-exec-10] > org.apache.coyote.http11.Http11NioProcessor - Error parsing HTTP request > header > Note: further occurrences of HTTP header parsing errors will be logged at > DEBUG level. > > looks like screen share is still trying to use HTTP. I wonder if reason > is because Java doesn’t have the trusted root cert in the cacerts. I can’t > add it. It has a password on it. My guess is the password is in a config > someplace. I could then add the root cert to it. Does screen share work > for you? > > Jason > > On May 27, 2016, at 12:36 AM, Maxim Solodovnik <[email protected]> > wrote: > > try to change config.xml to be > > <rtmpport>1935</rtmpport> > <rtmpsslport>443</rtmpsslport> > <useSSL>yes</useSSL> > <red5httpport>443</red5httpport> > <protocol>https</protocol> > <proxyType>none</proxyType> > works as expected for me (version 3.1.2-SNAPSHOT) > > On Fri, May 27, 2016 at 11:33 AM, Manohar Kotapati < > [email protected]> wrote: > >> Hi Jason, >> A similar issue was logged in Jira - openmeetings. Please go through the >> below link. It may help you. >> https://issues.apache.org/jira/browse/OPENMEETINGS-1358 >> >> >> On Thu, May 26, 2016 at 6:25 PM, Jason Romo <[email protected]> >> wrote: >> >>> Okay I am still getting the same error. When I enter the room it can’t >>> connect to RTMPS(5443). I must be missing something. >>> >>> lsof -n | grep LISTEN >>> >>> java 6427 root 77u IPv6 539404719 0t0 >>> TCP *:9999 (LISTEN) >>> java 6427 root 78u IPv6 539445410 0t0 >>> TCP *:9998 (LISTEN) >>> java 6427 root 135u IPv6 539419851 0t0 >>> TCP *:1935 (LISTEN) >>> java 6427 root 136u IPv6 539222895 0t0 >>> TCP *:http (LISTEN) >>> java 6427 root 140u IPv6 539301873 0t0 >>> TCP *:https (LISTEN) >>> java 6427 root 199u IPv6 539544198 0t0 >>> TCP *:tproxy (LISTEN) >>> >>> >>> from red5.properties >>> http.port=80 >>> https.port=443 >>> rtmp.port=1935 >>> rtmps.port=5443 >>> rtmpt.port=8088 >>> >>> from control.xml >>> <rtmpport>1935</rtmpport> >>> <rtmpsslport>5443</rtmpsslport> >>> <useSSL>yes</useSSL> >>> <red5httpport>443</red5httpport> >>> <protocol>https</protocol> >>> <proxyType>best</proxyType> >>> >>> >>> My keystone checks out fine on SSL labs. I don’t get any error on the >>> client. I did see other people think maybe java cacerts keystone might >>> need to have lets encrypt cross-sign key. But would that cause RTMPS to >>> not start? >>> >>> I don’t see any errors in the logs. Even put in debug all with >>> development. Nothing about the keystone, certs or RTMPS in the logs other >>> than the client can’t connect which I can understand RTMPS is not listening >>> on port 5443. >>> >>> Thanks, >>> Jason >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > > > -- > WBR > Maxim aka solomax > > > -- WBR Maxim aka solomax
