Bowser (IOS browser)

[Tom Chandler]

I have installed bowser (ios browser) on my IPAD.  Trying to run echo-test.  Local video works ok, but never get a remote window.

Comparing logs from a firefox session vs IOS session, everything looks ok until the browser is to send back
a payload to the janus-gateway.  This payload appears to never returned to janus-gateway.

So, is there any interest in IOS via bowser to process janus gateway, and anyone have
any suggestions on where to go.  I am looking at the .js file to see if there are changes
that need to be made there, based on the type of browser being used?

Any comments/suggestions will be appreciated.

Cheers
Tom c

[Lorenzo Miniero]

Most likely something needs to be changed in adapter.js, where currently only Chrome and Firefox (and Opera) are "detected" in order to wrap the right getUserMedia and PeerConnection stuff. I don't own any iPhone/iPad so I can't check what Bowser uses, not sure if there's any public documentation available somewhere.

In case someone gets it to work, I'd be glad to integrate the required changes.

L.

[Gatecrasher777]

Bowser is open source.

https://github.com/EricssonResearch/bowser

Ability to use Janus via Bowser would be a very nice feature. 

[Warren McDonald]

Bowser useragent string is 

"Mozilla/5.0 (iOS; like Mac OS X) AppleWebKit/536.36 (KHTML, like Gecko) not Chrome/27.0.1500.95 Mobile/10B141 Safari/537.36 Bowser/0.2.3"

it uses webkitGetUserMedia and webkitRTCPeerConnection 

Cheers,

Warren

[Lorenzo Miniero]

Then it should work already. The adapter.js code looks for navigator.webkitGetUserMedia and webkitRTCPeerConnection to make it handle JSEP stuff as it were Chrome. The issue may then be somewhere else but, as I anticipated, without a device to test this on I wouldn't know where to start.

[Warren McDonald]

Hi Lorenzo,

I'm getting set up to do some Bowser debugging for other projects, so I'll see if I can tell what's happening.

Cheers,

Warren

[Lorenzo Miniero]

Thank you Warren!

L.

[Gatecrasher777]

Any further updates on this?  I did try briefly a few months ago when I had access to an iPad, but without any success.  Bowser seems to have been updated again quite recently. So I'm wondering if anyone has succeeded yet.  One thought I had on this was that Bowser on an ios device might only be negotiating H264 and not VP8, which might be a problem in itself, but might be even more of a problem if Janus recognizes it as Chrome, which doesn't support H264 at all. 

Which leads to another question. In the videoroom plugin is H264 supported? It doesn't look like it from the code, at least from the preparation of the SDP. Given that other participants might be on Chrome that is understandable. And I expect the recordings require VP8/OPUS too. Doubtless there is no transcoding going on.

I guess this kind of dilemma is going to be ongoing until a mandatory codec is agreed upon and implemented by all webrtc platforms. 

[Lorenzo Miniero]

I don't own any Apple device so I can't check anything.

The videoroom plugin needs the same codecs to be shared among all participants, since no transcoding is involved. You can modify the way the SDP is generated to force H.264 for everybody: it's not configurable anywhere as the streaming mountpoints are, as of now.

Lorenzo

[Gatecrasher777]

I can envision a near future where VP8 and H264 decoding will be available to almost all listener end points, whereas encoding might be still be limited to one or the other and/or hardware capabilities on the originating device might dictate which codec a publisher uses. Rather than enforcing a single codec, would it not make sense to have Janus gateway and its plugins capable of negotiating either/any codec "out of the box"? Relaying to listeners whichever codec the publisher adopts? Given that Janus itself is an endpoint, perhaps a codec supported/preference list should be a configuration option for the preparation of the SDP. Some time in the future, we may also see VP9, VP10, H265, Daala, etc. 

Of course, if a listener's app/browser does not support a published feed it will fail. But that would seem to be a problem for the developer using Janus, than Janus itself. Rather keep Janus flexible/neutral and let developers worry about the encoding/decoding capabilities of their clients. 

[Nicholas Wylie]

You're correct, it's best to keep Janus neutral with regards to media formats. As Lorenzo said you can modify the generated SDP to force the use of H264 for everybody as opposed to VP8.

I think the problem is the SDP generation. I was trying to finish writing my plugin over the weekend and figured I would write a simple SDP parser to make it more configurable. It took most of the weekend just to find/comprehend all the arcane lines in the different SDP's generated. I must have read some 10+ different RFC's to get there and I was ignoring any ICE related lines.

It would be nice if we could come up with one SDP parsing engine for the entire gateway, and some other format that would be easy for plugins to interpret/generate internally. Then the SDP stuff happens in one place, and it takes a load off the plugins. This would be difficult though.