Echo 360 generated RSS feeds failing to stream/download in iTunes U

Question

Greetings iTunes U comrades!
We've been working with Echo 360 to isolate where the failure is on this issue and they're scratching their heads. They assure me that other institutions are successfully configuring iTunes U with Echo 360 RSS feeds, but seeing as there's no public forum for Echo 360 users, I'm hoping someone over here might be able to share their experiences with Echo feeds. This is part of our Echo 360 pilot on campus and Echo/iTunes U integration is a key area of functionality for our university. I'll try to provide a concise description of the issue:
The Echo 360 system generates the following RSS feed:
http://(EchoServer IP address:8080)/ess/feed?id=aa06ce62-7373-4070-9a3b-440a6c07dc3d&type=MP3
This feed functions perfectly well in the browser, on or off campus, and we can stream the assets in the browser without issue.
I created a course page in iTunes U, pasted the feed URL, and it accurately listed all the lectures in the course, indicating that on at least some level, the Echo server is communicating with iTunes U.
However, when I try to stream any of those lectures, iTunes hangs at 0:00 and never progresses, but conversely never times out. And if I try to 'Get' an individual lecture or try to download the entire course via the 'Get Tracks' or 'Subscribe' options, I receive the following error in the 'Status' field on the downloads page in iTunes: "stopped (err = 404)"
Additionally, I receive the following message via a pop-up window in iTunes:
"There was a problem downloading (title of lecture).
The URL "http://deimos3.apple.com/DeliverDownload/(EchoServer IP address:8080)/echocontent/0926/3/f2e2e509-af3e-4c5b-a0d8-e86305cc4c8f/audio.mp3 ?downloadKey=1246484124_d9aa3cd85bcfde6f039df5ec94361e58" could not be found on the server."
Notice the discrepancy between the Echo feed and the iTunes U generated URL. This is my main area of concern and I am requesting any insight as to how iTunes U is parsing the Echo feed and creating that download key. (Echo support seemed unfamiliar with this issue.)
Of particular interest: If I go through iTunes to Advanced>'Subscribe to Podcast' and paste in the echo feed, I have no trouble downloading the lectures.
That, in essence, is the failure. I'll post troubleshooting details below.
Thanks!
iTunes U course page settings: I left the 'security' and 'signature' fields set to 'none.' However, problem persists with security set to 'HTTP Basic' or 'Digest Authentication.'
Access settings: problem persists regardless of whether download access is given to 'all' or only to 'authenticated' for this course. I've tried toggling all these settings to troubleshoot the issue, to no avail.
I've tried using "feed" in place of "http" in the Feed URL. Same issue, regardless.
The issue is consistent with MP3, M4B, and M4V feeds.
There doesn't seem to be any way to manipulate the feed URL via the EchoSystem Server (we're on V. 2.4), and there's no additional configuration settings for manipulating the feed via iTunes U. But iTunes U is definitely producing a different feed URL, which appears to be the point of failure.
Insights?

Answer 1

Short version: issue resolved. I can now successfully stream and download the Echo assets via RSS feeds in iTunes U.
Long version: Well, I can't be sure exactly where the point of failure originally was. (@Duncan: I'm not sure if there was any active tweaking on the backend with the deimos feed parsing, I can't be sure what was or wasn't done on your end) That being said, on a support call with the Echo team, as an experiment, I set all access permissions to "download." I had done this previously (before Duncan's mysterious response), and the issue persisted. However, this time after setting all permissions to 'download,' I was /finally/ able to download and stream the assets. (Eureka!)
Of course the real test was what would happen when we re-established the original access permission set, wherein unauthenticated users had 'no access'. This time, it worked! After a bunch of head-scratching, a colleague of mine elucidated that although we had 'reset' the permission structure previously, it was before Duncan and Apple may or may not have intervened on the backend, and that what we had done by changing the permission set may have been necessary for a backend RSS parsing to take hold.
I can be sure that no modifications to the RSS XML were executed on Echo's end, but if the same is true on the iTunes U side, then I am truly perplexed. The bottom line is: I don't know why it 'works' now, but I'm not going to ask too many questions so long as it keeps working. (Thanks Duncan)