This is the response from Edgecast:
At this time I see that all the requests are being served from EC edge, however the origin / wowza is sending a response header of ‘Cache-Control:no-cache’ for smooth streaming. As a result all the requests are getting directed back to the origin.
This is not the expected behavior when it comes to smooth streaming, the default behavior from IIS is a Cache-Control:max-age=2 for Manifest and Cache-Control:max-age=30 for the fragments for any live stream. Where as wowza is setting no-cache for both resources. These TTLs allow a window for the chunks to be served from EC edge instead of all the requests forwarded back to origin.
We can work around this on our side by using override rules as a part of the rules engine. We can provide one free rule to over ride the TTL for the media / fragments resulting in media being served from our edge, but all the requests for Manifest will be directed back to your origin due to no-cache.
The second option would be to get these TTLs configured on the wowza / origin side. For these adjustments please contact wowza support.
Is there a way to configure the TTL’s in Wowza for Smooth Streaming?
I’m working with Edgecast on this. At the moment we’ve graduated from “un-cachable” to “tcp-miss” (i.e. it tried to cache but couldn’t). If we get it working I’ll post the details.
Being able to stream Smooth-streams from Wowza through a CDN would be a seriously cool thing. You guys could gain a lot of traction as an origin-server-to-anywhere; it’s not something a lot of companies offer but a lot of customers want. RTMP is dying a slow death. If you allowed us to modify the cache/no cache headers it would be a lot easier to do. Just a suggestion 
Put me down as the very first person to want to test this when you get to that point then We have a lot of experience with Smoothstreaming; however I prefer Wowza’s approach over IIS Media Services 4.0 because I can support more devices (and Expressions Encoder is a real hog on the encoding end, wheres Wirecast is both more efficient and has more features).
Edgecast says the session ID in the Wowza url is what’s throwing off their ability to cache, and they can’t re-write content with a rule.
This:
http://wpc.2315.edgecastcdn.net/802315/wowza/live/2011_05/QualityLevels(450657)/Fragments(video=194695330000)/WowzaSessions(185920760).ismv
For example, contains a unique session ID for each client, thus it doesn’t get cached by the CDN. Is there a way to work around this in Wowza? Way to set the same session id for all clients of a given stream, perhaps?
We’re still working on it. Edgecast’s support and dev team are great. I’m setting up test streams for them and they are figuring out how to use a cache rule that ignores the session id part of the filename. If they get it working I’ll post how.
I understand you don’t officially support this, and I’m not knocking you for it, but if possible it would be great if you guys would take a look at adding even an unsupported way to do it, as it seems like a fairly simple thing to do from your end, and would greatly boost the value of Wowza.
Is this for live? Are you seeing any caching on edgecast. I am attempting to do the same thing but for purposes of only having to maintain one set of tokens for token authentication (using edgecast’s token authentication). I set the Wowza up as my origin and wrote a server side module to append the tokens to the playlist segments to handle geofencing and leach prevention. However, since each playlist entry has a “sessionid” that is unique to the connection I am wondering how much caching actually occurs. I know wowza has a load testing tool, does it test HLS or only rtmp?
Looking good now! Thanks.
I am guessing this is likely not supported but I figured I will ask before I start asking our CDN to make any changes. Now that we have the option to use manifests for our flash content how would we go about getting our CDN to be able to use the variable list i.e. stream_all/manifest.f4m? We currently use a push module to send it to them so it is played as an rtmp. However the manifests are http so that mechanism doesn’t work. Is there a way for our CDN to pull the http from our server? I know with .m3u8 you can set the relative option to get this working. Is this not possible? Any advise would be appreciated.
HTTP Origin feature still near-future? Or now, near-near-future? 
Richard,
We currently use Adobe and AWS because of scalability. We are evaluating Wowza and we like a lot of what we see. The lack of ability to be a live origin for AWS is a deal breaker. We have clients who need us to integrate with their CDNs and they all want HTTP these days. Any updates on when this might be a feature?
Never mind. I found it in 3.5 here: https://www.wowza.com/docs/how-to-configure-a-wowza-server-as-an-http-caching-origin
HTTP Origin feature still near-future? Or now, near-near-future?
I am guessing this is likely not supported but I figured I will ask before I start asking our CDN to make any changes. Now that we have the option to use manifests for our flash content how would we go about getting our CDN to be able to use the variable list i.e. stream_all/manifest.f4m? We currently use a push module to send it to them so it is played as an rtmp. However the manifests are http so that mechanism doesn’t work. Is there a way for our CDN to pull the http from our server? I know with .m3u8 you can set the relative option to get this working. Is this not possible? Any advise would be appreciated.
Can someone from Wowza please help us with this matter ? It looks like we are not the only ones running into this… And if this is not possible then please let everyone know so we know…
Thanks in advance,
Mike
Any updates on this by any chance? I just started working with Edgecast to try and find a solution on the CDN side. I tested Cloudfront the other day and ran into the same caching problem as with Edgecast for smoothstreaming. If Edgecast is able to get it to work I will let you guys know.
Thanks!
Richard,
We currently use Adobe and AWS because of scalability. We are evaluating Wowza and we like a lot of what we see. The lack of ability to be a live origin for AWS is a deal breaker. We have clients who need us to integrate with their CDNs and they all want HTTP these days. Any updates on when this might be a feature?