Restreaming an authenticated RTSP stream through Wowza Pro
As noted in this thread, adding a username:password to the url is simple.
rtsp://username:password@[camera-ip-address]:554/axis-media/media.amp
However is there any way to allow Wowza to use basic or (better) digest authentication instead of having the password in the URL? The reason is two-fold: better security and passwords that have characters that need encoding. The Axis camera will deny requests with urlencoded passwords as seen in the output of openRTSP. When authenticating via digest authentication and testing through openRTSP I can connect and record without an issue. Is there a way for Wowza to support digest authentication or even basic authentication where the username:password does not have to be in the url?
Thanks!
Michael
rtsp://username:password@[camera-ip-address]:554/axis-media/media.amp
However is there any way to allow Wowza to use basic or (better) digest authentication instead of having the password in the URL? The reason is two-fold: better security and passwords that have characters that need encoding. The Axis camera will deny requests with urlencoded passwords as seen in the output of openRTSP. When authenticating via digest authentication and testing through openRTSP I can connect and record without an issue. Is there a way for Wowza to support digest authentication or even basic authentication where the username:password does not have to be in the url?
Thanks!
Michael
The User:password in the url is basic authentication.
The RTP / Authentication / PublishMethod only works for streams that are initiated from the encoder so that will not work with Axis cameras.
If what you want to achieve is to hide the username & passwords from the user, you can use any of the following methods.
1. Use *.stream files. This is a simple text file on the server which contains the rtsp url. The player plays the stream file.
2. Use the StreamNameAlias plug-in.
3. Create a custom module that implements the IMediaStreamNameAliasProvider(2) interface. Use the resolveStreamAlias method to resolve the correct rtsp url. Make sure that the resolvePlayAlias method returns a valid name.
The RTP / Authentication / PublishMethod only works for streams that are initiated from the encoder so that will not work with Axis cameras.
If what you want to achieve is to hide the username & passwords from the user, you can use any of the following methods.
1. Use *.stream files. This is a simple text file on the server which contains the rtsp url. The player plays the stream file.
2. Use the StreamNameAlias plug-in.
3. Create a custom module that implements the IMediaStreamNameAliasProvider(2) interface. Use the resolveStreamAlias method to resolve the correct rtsp url. Make sure that the resolvePlayAlias method returns a valid name.
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.
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.
I have seen some issues on axis cameras to do with passwords and have normally fixed them but setting the camera to use un-encrypted passwords only.
I have seen some issues on axis cameras to do with passwords and have normally fixed them but setting the camera to use un-encrypted passwords only.
That confirms what I saw happening with Wowza although it seems that openRTSP can log in fine with Digest or Basic authentication. Thanks for the note.
Just a note for others interested in this. After some discussion with Wowza's awesome support there is a new development build, patch 8, which resolves this issue.
Note if you are using it on EC2 though you'll have to be careful to merge the existing /conf/Server.xml with the new /conf/Server.xml provided in this patch, and also merge the existing /conf/VHost.xml with the new /conf/VHost.xml. But this is a development build so it may not be completely stable and requires further testing.
http://www.wowza.com/forums/content.php?199-Development-Builds
Note if you are using it on EC2 though you'll have to be careful to merge the existing /conf/Server.xml with the new /conf/Server.xml provided in this patch, and also merge the existing /conf/VHost.xml with the new /conf/VHost.xml. But this is a development build so it may not be completely stable and requires further testing.
http://www.wowza.com/forums/content.php?199-Development-Builds
