Results 1 to 9 of 9

Thread: Fail-over ORIGIN located on an active EDGE

  1. #1
    Join Date
    Dec 2010
    Posts
    24

    Default Fail-over ORIGIN located on an active EDGE

    We're testing multiple edge servers with a single dedicated origin but trying to create a fail-over origin config on one of the edge machines.

    Our source content is IP camera RTSP streams described by [camera].stream files in the content folder of the origin.

    We're experimenting with the OriginURL method of specifying the fail-over origin server e.g. in application.xml in the liveedge app on the edge servers ...

    <OriginURL>wowz://[primary origin]:1935/liveorigin|wowz://[fail-over origin+edge]:1935/liveorigin</OriginURL>

    The edge server that's acting as a host for the fail-over origin now has two applications configured... liveedge and liveorigin.

    On the primary origin, we use startupstreams.xml to start all our camera streams. On the fail-over origin, we changed the liveorigin application type to rtp-live to trigger automatic on-demand acquisition of the camera streams in the event that fail-over happens.

    Amazingly, this all works. If you shutdown the primary origin, ~12 second delay and the fail-over origin has acquired the streams and a client playing video from an edge pauses but then continues automatically.

    Problem: For the above to work, we also placed the .stream files that describe our source streams in the content folder of the edge acting as a fail-over origin. When we do that and then try a connection to that edge (normal mode, no fail-over), the liveedge application appears to give precedence to resolving the stream via the .stream file in [content] as opposed to redirecting through OriginURL to the desired origin hierarchy.

    Connections to the edge then fail because the camera stream is not started and a liverepeater-edge stream type won't autostart it ... which is good because we don't want edge activity to start streams intended solely for fail-over origin use! We really want the edge application activity to completely ignore the [content] folder contents and always use OriginURL.

    Is there a simple way around this???

    We've thought of ...

    a) Using a VHOST config on the edge acting as a fail-over origin to give the origin app it's own separate content folder.

    b) Using another layer of .stream file redirection e.g. every edge has a .stream file for every stream and in it we specify the pipe concatenated origin URLs that point to origin .stream files that abstract the RTSP URLs. Effectively making a lot more config files and completely bypassing the single OriginURL config in the edge application.xml . Note: We use something like this today in our production cluster (without fail-over) but are trying to simplify the edge configs and have no .stream files on them.

    Any help or suggestions appreciated.

    Many thanks,
    David.

  2. #2
    Join Date
    Dec 2010
    Posts
    24

    Default

    2013-08-29	18:39:39	EDT	connect	session	INFO	200	[client IP]	-	_defaultVHost_	liveedge	_definst_	0.461	[any]	1935	rtmp://[edge domain]/liveedge	[client IP]	rtmp	http://mywebsite.com/flowplayer/flow...ial-3.2.14.swf	WIN 11,8,800,94	542674703	3471	3073	-	-	-	-	-	-	-	-	-	-	-	-	-	rtmp://[edge domain]/liveedge	-
    2013-08-29	18:39:40	EDT	create	stream	INFO	200	-	-	_defaultVHost_	liveedge	_definst_	0.024	[any]	1935	rtmp://[edge domain]/liveedge	[client IP]	rtmp	http://mywebsite.com/flowplayer/flow...ial-3.2.14.swf	WIN 11,8,800,94	542674703	3539	3413	1	-	0	0	-	-	-	-	-	-	rtmp://[edge domain]/liveedge	rtmp://[edge domain]/liveedge	-	rtmp://[edge domain]/liveedge	-
    2013-08-29	18:39:40	EDT	comment	server	INFO	200	-	MediaStreamMediaCasterPlay: startPlay	-	-	-	13.499	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-29	18:39:40	EDT	create	stream	INFO	200	-	-	_defaultVHost_	liveedge	_definst_	0.014	[any]	1935	rtmp://[edge domain]/liveedge	[client IP]	rtmp	http://mywebsite.com/flowplayer/flow...ial-3.2.14.swf	WIN 11,8,800,94	542674703	3607	3455	1	0	0	0	-	-	-	-	-	-	-	-	-	rtmp://[edge domain]/liveedge	-
    2013-08-29	18:39:40	EDT	comment	server	INFO	200	-	LiveMediaStreamReceiver.connect[rtsp://user:pass@[cam IP]:554/axis-media/media.amp?videocodec=h264&streamprofile=Test]:rtsp://[cam IP]:554/axis-media/_definst_[media.amp]	_defaultVHost_	liveedge	_definst_	13.561	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-29	18:39:52	EDT	comment	server	WARN	200	-	LiveMediaStreamReceiver.doWatchdog: streamTimeout[axis-media/_definst_/media.amp]: Resetting connection: rtsp://[cam IP]:554/axis-media/_definst_/media.amp	-	-	-	25.846	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-29	18:39:52	EDT	comment	server	INFO	200	-	LiveMediaStreamReceiver.resetConnection: (SOCKET, R: /[cam IP]:554, L: /[edge IP]:50445, S: /[cam IP]:554)	-	-	-	25.849	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-29	18:40:05	EDT	comment	server	WARN	200	-	LiveMediaStreamReceiver.doWatchdog: streamTimeout[axis-media/_definst_/media.amp]: Resetting connection: rtsp://[cam IP]:554/axis-media/_definst_/media.amp	-	-	-	38.368	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-29	18:40:05	EDT	comment	server	INFO	200	-	LiveMediaStreamReceiver.resetConnection: (SOCKET, R: /[cam IP]:554, L: /[edge IP]:50450, S: /[cam IP]:554)	-	-	-	38.37	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    For extra context, above is a log extract from when a client connects to the edge that's hosting the fail-over origin config.

    Looks like the edge is trying to directly connect to the camera stream via the contents of the .stream file but the URLs are getting mangled. For example, I see a Wowza "_definst_" inserted in the middle of an Axis camera URL e.g. "axis-media/_definst_/media.amp" . Something is getting confused.

    The camera .stream file looks like this (but we don't want it to be used by the edge app to resolve an incoming stream request... only the fail-over origin app) :

    rtsp://user:pass@[cam IP]:554/axis-media/media.amp?videocodec=h264&streamprofile=Test

  3. #3
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    David,

    You can do the same fail-over per stream in the .stream file. On the edge:

    file: /content/origin.stream
    contents: rtmp://[wowza-origin_1]:1935/liveorigin/myStream|rtmp://[wowza-origin_2]:1935/liveorigin/myStream

    Richard

  4. #4
    Join Date
    Dec 2010
    Posts
    24

    Default

    Quote Originally Posted by rrlanham View Post
    David,

    You can do the same fail-over per stream in the .stream file. On the edge:

    file: /content/origin.stream
    contents: rtmp://[wowza-origin_1]:1935/liveorigin/myStream|rtmp://[wowza-origin_2]:1935/liveorigin/myStream

    Richard
    That's what we do right now but without the fail-over origin spec.

    I was hoping to achieve a content-free edge config and rely solely on OriginURL with all .stream files on the origin(s).

  5. #5
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    No, it's one or the other. The .stream files take precedence.

    Richard

  6. #6
    Join Date
    Dec 2010
    Posts
    24

    Default

    Okay. I guess we can work-around with numerous .stream files including fail-over origin specs.

    However... I claim it's a "bug" that .stream files pointing to an IP camera and located in a content folder shared between an origin and edge app are mistreated by the edge app.

  7. #7
    Join Date
    Dec 2010
    Posts
    24

    Default

    Quote Originally Posted by rrlanham View Post
    No, it's one or the other. The .stream files take precedence.

    Richard
    Feature request: a config variable we can add to application.xml to tell a liverepeater-edge app (for example) to ignore .stream files in the [content] folder, or maybe everything in the [content] folder and rely solely on OriginURL.

    Alternatively, maybe it's just a switch to reverse the precedence order while searching to resolve an incoming stream request.... OriginURL first, [content] folder second and if not found on origin(s)

  8. #8
    Join Date
    Aug 2012
    Posts
    4

    Default

    Quote Originally Posted by rainman View Post
    2013-08-29	18:39:39	EDT	connect	session	INFO	200	[client IP]	-	_defaultVHost_	liveedge	_definst_	0.461	[any]	1935	rtmp://[edge domain]/liveedge	[client IP]	rtmp	http://mywebsite.com/flowplayer/flow...ial-3.2.14.swf	WIN 11,8,800,94	542674703	3471	3073	-	-	-	-	-	-	-	-	-	-	-	-	-	rtmp://[edge domain]/liveedge	-
    2013-08-29	18:39:40	EDT	create	stream	INFO	200	-	-	_defaultVHost_	liveedge	_definst_	0.024	[any]	1935	rtmp://[edge domain]/liveedge	[client IP]	rtmp	http://mywebsite.com/flowplayer/flow...ial-3.2.14.swf	WIN 11,8,800,94	542674703	3539	3413	1	-	0	0	-	-	-	-	-	-	rtmp://[edge domain]/liveedge	rtmp://[edge domain]/liveedge	-	rtmp://[edge domain]/liveedge	-
    2013-08-29	18:39:40	EDT	comment	server	INFO	200	-	MediaStreamMediaCasterPlay: startPlay	-	-	-	13.499	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-29	18:39:40	EDT	create	stream	INFO	200	-	-	_defaultVHost_	liveedge	_definst_	0.014	[any]	1935	rtmp://[edge domain]/liveedge	[client IP]	rtmp	http://mywebsite.com/flowplayer/flow...ial-3.2.14.swf	WIN 11,8,800,94	542674703	3607	3455	1	0	0	0	-	-	-	-	-	-	-	-	-	rtmp://[edge domain]/liveedge	-
    2013-08-29	18:39:40	EDT	comment	server	INFO	200	-	LiveMediaStreamReceiver.connect[rtsp://user:pass@[cam IP]:554/axis-media/media.amp?videocodec=h264&streamprofile=Test]:rtsp://[cam IP]:554/axis-media/_definst_[media.amp]	_defaultVHost_	liveedge	_definst_	13.561	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-29	18:39:52	EDT	comment	server	WARN	200	-	LiveMediaStreamReceiver.doWatchdog: streamTimeout[axis-media/_definst_/media.amp]: Resetting connection: rtsp://[cam IP]:554/axis-media/_definst_/media.amp	-	-	-	25.846	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-29	18:39:52	EDT	comment	server	INFO	200	-	LiveMediaStreamReceiver.resetConnection: (SOCKET, R: /[cam IP]:554, L: /[edge IP]:50445, S: /[cam IP]:554)	-	-	-	25.849	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-29	18:40:05	EDT	comment	server	WARN	200	-	LiveMediaStreamReceiver.doWatchdog: streamTimeout[axis-media/_definst_/media.amp]: Resetting connection: rtsp://[cam IP]:554/axis-media/_definst_/media.amp	-	-	-	38.368	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-29	18:40:05	EDT	comment	server	INFO	200	-	LiveMediaStreamReceiver.resetConnection: (SOCKET, R: /[cam IP]:554, L: /[edge IP]:50450, S: /[cam IP]:554)	-	-	-	38.37	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    For extra context, above is a log extract from when a client connects to the edge that's hosting the fail-over origin config.

    Looks like the edge is trying to directly connect to the camera stream via the contents of the .stream file but the URLs are getting mangled. For example, I see a Wowza "_definst_" inserted in the middle of an Axis camera URL e.g. "axis-media/_definst_/media.amp" . Something is getting confused.

    The camera .stream file looks like this (but we don't want it to be used by the edge app to resolve an incoming stream request... only the fail-over origin app) :

    rtsp://user:pass@[cam IP]:554/axis-media/media.amp?videocodec=h264&streamprofile=Test

    I am having the same issue where Wowza is mangling our URL. My .stream file contains the same line above, and in the error logs, the URL shows up with everything after the "?" removed and "_definst_" is inserted after axis-media. Is this a bug? Anyone with the same issue? Any fix?

  9. #9
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    URLS that include "_definst_" would be playback urls, not the source.

    What client are you testing playback with? Does it work?

    This is the basic IP camera guide

    Richard

Similar Threads

  1. High-availability cluster Active/Active for video-chat application
    By mmaron@mikogo.com in forum General Forum
    Replies: 1
    Last Post: 09-19-2014, 08:03 AM
  2. Amazon EC2 system in wowza origin-edge streaming fail
    By oxidecircle in forum Wowza Media Server 3 for Amazon EC2 Discussion
    Replies: 0
    Last Post: 02-19-2014, 09:25 AM
  3. Detect Active Origin
    By Tome Nedanovski in forum General Forum
    Replies: 1
    Last Post: 06-04-2012, 01:19 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •