Hi Roger,
Basic authentication has been approved so far for this application so that is fine and I currently have it set up using a *.stream file. The issue seems to be how Wowza parses and passes the authentication data on to the Axis camera. The password contains a character that is not url safe and so must be url encoded in order to be able to resolve the host correctly. The *.stream file has the correct URL to the camera with the password urlencoded and this works within VLC. The Wowza log shows that it can’t connect at all and the log shows the connection string with the password urlDEcoded. I’m not sure where it breaks down in the connection attempt.
So if the connection string without any url encoding would be
rtsp://username:p@ssword@[ip-address]/axis-media/media.amp
the url encoded one of course would be
rtsp://username:p%40ssword@[ip-address]/axis-media/media.amp
and this works in VLC. If I use this url encoded one in Wowza it says it can’t connect and the logs show the non-url encoded version.
In openRTSP this results in an 401 unauthorized access. For openRTSP I have to do
openRTSP -u username p@ssword rtsp://[ip-address]/axis-media/media.amp
and that works fine. In QuickTime I can only use
rtsp://[ip-address]/axis-media/media.amp
and get the login prompt and that works. If I remove the offending character from the password Wowza correctly connects and also correctly gets a 401 unauthorized. My guess at this point is that if the password were changed to not have any characters that needed to be urlencoded, it may work correctly with Wowza. That would be the simplest solution. I can’t see justifying going into custom code if it doesn’t though.