We use BotFramework to contact our clients using Skype. We expect to get attachments as a part of Activity's Attachment property, and this is the case when client sends 'jpeg', 'gif' or other image type. However, when client sends audio file '.m4a' or similar, we get something like:
<URIObject uri="https://api.asm.skype.com/v1/objects/0-neu-d11-f5e80525b1cae4f19957707afbb44006" url_thumbnail="https://api.asm.skype.com/v1/objects/0-neu-d11-f5e80525b1cae4f19957707afbb44006/views/audio" type="Audio.1" doc_id="0-neu-d11-f5e80525b1cae4f19957707afbb44006">To hear this audio file, go to: <a href="https://login.skype.com/login/sso?go=webclient.xmm&docid=0-neu-d11-f5e80525b1cae4f19957707afbb44006">https://login.skype.com/login/sso?go=webclient.xmm&docid=0-neu-d11-f5e80525b1cae4f19957707afbb44006</a>
<OriginalName v="Recording.m4a"></OriginalName>
<FileSize v="66912"></FileSize>
</URIObject>
Should we parse it by ourselves (we were supposed to get this as attachment, aren't we?) and if yes - are there any parsers to handle this kind of stuff? Only thing i can find is related to SkPy (https://skpy.t.allofti.me/protocol/chat.html) or MSNP(https://github.com/msndevs/protocol-docs/wiki/Messaging) which is outdated.
So, this is due to how/what Skype is allowing through as attachments to the bot framework. I ran a quick test with .wma and .m4a and the .m4a are blocked (aren't surfaced to the bot framework). I swapped the file extensions and again; .wma worked an .m4a was blocked. I'm guessing it is a simple whitelist for extensions. Perhaps there is a Skype feedback avenue somewhere to have this changed/added.
It appears that the first attribute (uri) is the resource itself. But you would definitely need to authenticate via Skype API to retrieve that, if that is the case.