I know SMS is possible using Azure Comm. Service, but what about sending/receiving MMS images and videos?
Is this possible?
If not, are there other options besides ACS to use MMS in Azure?
As of now (2022/09) Azure Communication Services doesn't yet support MMS, but it is in the works.
Related
I need to relay the incoming RTMP stream to several external RTMP endpoints (facebook, twitch, ...). Does anyone know if it is possible with Azure Media Services? I can't seem to find any documentation regarding supported outputs.
Thanks for any help
Not possible currently with Azure Media Services. We do not have an RTMP relay broadcast feature at this time. We have several customers using external services like Restream.io though to achieve that flow.
This request has been on our backlog for a while and we will be looking at it in the future.
We've been writing services to access our on-premises databases through Azure Service Bus Relay for awhile now. That means that we've had to deploy them as WCF services. Our web site development is moving to node.js and I would like to begin deploying our API services on node as well. However, while the Azure NPM package has good support for queues/topics on Azure Service Bus, I can find no mention of the relaying capabilities. I've had a look at the code for the Azure SDK on github, but again, relay seems to be conspicuously absent.
Is it possible to use Azure Service Bus Relay with a node.js backend?
Now Azure support Node.js. You can find the infomration from here. This link is the samples for Node.js.
Right now, Relay only supports a WCF service. You can try to use Clemens Vasters' post on Port Bridge to get your scenario working. In his post, he describes creating a WCF client / service that will forward requests to a specific port.
I have a virtual machine on Azure which will listen to messages over the servicebus of Azure. And another developer needs to connect to this servicebus to send messages to my service. To do so, we need to come up with some protocol for this communication system. And I was thinking about using WSDL to make the server something webservice-like, but instead of listening to the standard HTTP ports it would connect to the service bus and within it a topic with subscription, or whatever. I'm still not sure what would be best.
So, is it possible? Has anyone done something similar before? Are there some examples?
Service Bus provides both Brokered and Relayed messaging models. With using Topics/Queues you are essentially sending and receiving message to/from the broker. So you can use APIs/protocols that the broker supports. As an example you can use the NetMessagingBinding from your service/client to send and receive messages through the queue. There is no contract here other than what you put in the BrokeredMessage body and properties values. The application on either end can decode/decipher that info as needed.
In the case of Relayed messaging however you are making a end-to-end connection between the client and the service with Service Bus serving as the proxy in-between for auth, location-transparency and even load-balancing. So here you can use from a variety of RelayBindings such as NetTcpRelayBinding or webHttpRelayBinding but then both the client and the service need to be available at the same time. Here you need the service and clients to be using the same contract.
I currently designing a solution for communication between a Charge Point for Electrical Vehicles and the backoffice. the ChargePoint are connected to the Network of the Telephone company and the backoffice is hosted on Azure. The Chargepoint don't have a public IP-address. In order to send messagese from the backoffice to the ChargePoint we want to implement Azure Service Bus (ASB) Relay. The ChargePoint OS is embeded Linux and Azure is Microsoft. The ASB Relay only works with WCF bindings. I found out that mono supports WCF but cann't find if it supports httpRelayBinding?
what kind of communication are you looking for between the device and service? If you need Relay like two-way or one-way synchronous RPC communication then you could use a simple http client to call into the service, a sample for this is here: http://code.msdn.microsoft.com/windowsazure/Relayed-Messaging-Bindings-a6477ba0
Also if you are looking for different patterns of communication such a brokered messaging where you can send/receive messages w/ data then you can consider using Service Bus Queues and Topics. I recently covered some of these usage scenarios in my session at TechEd: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B336
I am working on a Windows Phone 8 app which is connected to Azure Service Bus Relay. Since i cant add Microsoft.ServiceBus.dll to the WP8 project, I had to go with BasicHttpBinding which works fine.
Now I want to use the service bus relay with topics in WP8. Is this even possible? I cant use NamespaceManager which is discussed here: http://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-topics/ , because its not supported by WP8.
My question is simply, is this possible to do? And what approach should i choose?
We do not have any libraries that target Windows Phone at this point but are working on producing these. You can make direct http calls to the REST APIs and send/receive messages etc. Samples for these are available:
http://code.msdn.microsoft.com/windowsazure/Brokered-Messaging-569cff88
https://github.com/WindowsAzure/azure-sdk-for-java/tree/master/microsoft-azure-api/src/main/java/com/microsoft/windowsazure/services/ServiceBus
http://msdn.microsoft.com/en-us/library/hh780762.aspx
Zeezer,
"Now I want to use the service bus relay with topics in WP8"
Not sure if you are conflating two separate issues...
We do not have an SDK for Service Bus Relay for the Windows Phone. However, if your service is using any of the *HttpRelayBinding's, you can use a regular HTTP client from the Windows Phone app to communicate with the Relay endpoint for your service. You will need to include the ACS token for authenticating to Service Bus Relay in a custom HTTP header called ServiceBusAuthorization.