<fmt> = 96 => seems to be a common format. => Actually not :)
96 means its a dynamic format, and defined in later sections of the sdpOffer document. So those successful and unsuccessful could be quite different video format options. Even both say 96. Thx Seb Sebastian Wagner Director Arrakeen Solutions, OM-Hosting.com http://arrakeen-solutions.co.nz/ https://om-hosting.com - Cloud & Server Hosting for HTML5 Video-Conferencing OpenMeetings <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> On Tue, 5 Oct 2021 at 18:30, seba.wag...@gmail.com <seba.wag...@gmail.com> wrote: > The sdpOffer that is presented by iOS when sharing video is > > m=video 64261 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 127 104 125 106 > 107 108 > > Which is: m=<media> <port>/<number of ports> <proto> <fmt> > > <proto> == RTP/SAVPF > => denotes the Secure Real-time Transport Protocol running over UDP. > => That seems fine > > <fmt> = 96 > => seems to be a common format. > > If using chrome on macOS desktop (And successfully publishing + watching > the stream) the sdpOffer looks like this: > > m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 > 108 109 35 36 124 119 123 118 114 115 116 > > Not really much different. And this one seems to work fine. > > I don't really expect KMS to struggle with iOS accepting and re-publishing > the streams based on that sdpOffer. > > Are there any other events or debugging that could help isolate this > problem ? > > Above example / error AMR/8000 => that is actually a group of audio codecs > (https://en.wikipedia.org/wiki/Adaptive_Multi-Rate_audio_codec). So I > don't think it has something to do with publishing video. > > Thanks > Seb > > Sebastian Wagner > Director Arrakeen Solutions, OM-Hosting.com > http://arrakeen-solutions.co.nz/ > https://om-hosting.com - Cloud & Server Hosting for HTML5 > Video-Conferencing OpenMeetings > > <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> > <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> > > > On Tue, 5 Oct 2021 at 17:11, seba.wag...@gmail.com <seba.wag...@gmail.com> > wrote: > >> Opening a new thread here about publishing video issues on iOS >> >> I tried disabling the notification API to trial. The JS error is gone now >> on iOS >> => So https://issues.apache.org/jira/browse/OPENMEETINGS-2678 basically >> notifications are not working but it does not throw any errors anymore. >> >> But the video still doesn't show up on the remote screens when publishing >> via iOS. >> Same as described in here: >> https://issues.apache.org/jira/browse/OPENMEETINGS-2679 >> => iOS shows video and KMS claims "Media Conenction established" >> => On receiving participants the video pod just stains empty (see >> screenshots in OPENMEETINGS-2679) >> >> There is only another JS error left in iOS: >> Unhandled Promise Rejection: NotAllowedError: The request is not allowed >> by the user agent or the platform in the current context, possibly because >> the user denied permission. >> (As described in https://issues.apache.org/jira/browse/OPENMEETINGS-2677) >> >> I can also try fixing OPENMEETINGS-2677, but I doubt it has an impact on >> the ability to share successfully your video (and more even to see it on >> the receiving end) >> >> Are there any other pointers ? >> There is no JS error on the receiving end. >> I can see: >> room-ver-F5422CD81838B3A9C3207DE3749ACB49.js:1 !!RTCPeerConnection state >> changed: connecting, user: firstname lastname, uid: >> b862a3d0-a1f0-4483-9eeb-8f8d18d7405b >> e.onconnectionstatechange @ room-ver-F5422CD81838B3A9C3207DE3749ACB49.js:1 >> room-ver-F5422CD81838B3A9C3207DE3749ACB49.js:1 !!RTCPeerConnection state >> changed: connected, user: firstname lastname, uid: >> b862a3d0-a1f0-4483-9eeb-8f8d18d7405b >> >> But that just seems normal debug/info log. I can see the same logs >> produced when using with another client and successfully sharing my video. >> >> >> >> However in the Kurento KMS log I can see and entry when it fails >> publishing in iOS that I do not see in case of a successful publishing of >> streaming: >> 0:19:46.504315443 1 0x7fe4f4017550 INFO KurentoWebRtcEndpointImpl >> WebRtcEndpointImpl.cpp:110:remove_not_supported_codecs_from_array:<kmswebrtcendpoint17> >> Removing not supported codec 'AMR/8000' >> >> There seems to be a ticket in the KMS backlog that has been closed some >> time ago, but not sure what the state is: >> https://github.com/Kurento/bugtracker/issues/274 >> >> But I can see the same error in audio-only publishing. And audio-only >> works fine.But it seems strange the video streaming doesn't work but >> audio-only works. And there is no other error in OpenMeetings. Could it be >> a KMS problem ? >> >> I am obviously testing with the latest KMS 6.16 >> >> Thanks >> Sebastian >> >> Sebastian Wagner >> Director Arrakeen Solutions, OM-Hosting.com >> http://arrakeen-solutions.co.nz/ >> https://om-hosting.com - Cloud & Server Hosting for HTML5 >> Video-Conferencing OpenMeetings >> >> <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> >> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url> >> >
