I need to stream audio over Windows sockets to a bluetooth headset.
I am able to make socket connection to the Bluetooth headset using RFCOMM and A2DP / Headset profile / Hands-free profile.
My requirement is to stream audio (WAV or MP3) over the socket.
Is it possible by simply writing audio data to the socket (using send())?
OR any other ways to do it?
I am required to use the same socket connection to stream. If I use Media Control Interface APIs, they will make a separate connection and then stream.
The A2DP profile is layered on top of L2CAP and SDP; moreover SDP shall function
while using L2CAP as its transport protocol.
So if you want to implement the communication with send(s) through a socket, you need to implement SPD also, and you should realize the communication as specified in
https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=8236
after you have connected serially to your A2DP capable device, like i. e. using:
http://SimpleBluetooth4Win.Sourceforge.net
(small library that uses the windows bluetooth networking API)
Related
I'm developing an application that receives an audio stream over a WebSocket and needs to forward the audio to a SIP server.
Currently, I've managed to connect to the audio source using a Websocket and receive the media stream (encoded u-law) using Node-Red, but I'm struggling to figure out how to send the media stream to the SIP server. Any advice would be much appreciated.
I looked into this for a similar question a while back, can't find where it was now.
As you probably know the media part of SIP is RTP, so its a fairly separate stack to the call signalling.
I didn't find any nodes that supported it and the few node.js libraries for RTP were all very incomplete and out of date.
In theory it might be possible to craft your own RTP streams using the UDP nodes and then create the relevant SDP in the SIP response but I'm not sure how robust or scalable this would be.
The other option is that there are a couple of Programmable Comms platforms out there that support both SIP and Web sockets so you could possible utilise one of those and connect from Node-RED via websocket letting them do the SIP work.
I've done SIP|<>Websocket stuff with both the Vonage API (Previously Nexmo) and Jambonz (open source)
Could anybody give me tip how to stream from main aircraft camera to remote server? We have our own app runing on RASPI 4 build on Matrice and can get live view from camera, can download h264 file to SD card, but havent't found any description/sample how to stream outside.
Is it possibe to use aircraft-RemoteController connection and then RemoteController to WiFi? Or rather use RASPI WiFi (that will cut range I assume).
Setup a RTMP server.
Stream to a RTMP-server from the MSDK (which running on the remote).
See the MSDK example project.
Anyway if you search for the class "LiveStreamManager" in the msdk example app on github.
method getLiveStreamManager
LiveStreamManager getLiveStreamManager()
Provides access to getLiveStreamManager. It can be used to stream the video to a RTMP server to do live streaming with DJI products.
It is possible to do so as shown in the figure below. The RTMP streaming is done by using FFMEPG we stream the section of the desktop to a webRTC server. We use opencv to control the XT2 image box on the desktop and then perform the live streaming. But the normal 4G based point-to-point connection may have 30sec latency, we use a webRTC video server to make the stream realtime.
I know that for audio streaming and video streaming RTSP protocol is used (However i am not aware of what is used in bluetooth).
However my question is little different.I would like to explain it with an example(Actually it is not an example i am trying to build something similar).
When we connect our device(a mobile running on android) using bluetooth to our PC(Operating System-Windows) the
control panel shows an option for streaming audio.
As many of you would be aware in this when i play a song on my device it is played on my PC speakers.
So my question is
1)Who is the server
2)Who is the client
Probably i think that my PC is the client.If PC is the client then it would open a connection for audio streaming with the device.
As it opens a connection with the server, the server should have a specific application through which the transfer of packets must take place with the client.
But to my surprise i was able to use any media player on my device to play songs on my laptop speaker.
How is this possible?? Is it possible to do the same thing using RTSP protocol.
Sip (session initiation protocol) does not understand websocket so we need sip proxy which is basically a translator between sip and websocket.
i am following this architecture for sip handshaking with web socket. I have few questions
which sip proxy must be used to make audio and video call. and in the Gateway to SIP module i am using ASTERISK. how asterisk can be used for video call is there any codec available for video call? Please share some useful links.
Your kind answers will be highly appreciated.
Check out http://jssip.net. They provide a javascript API which uses SIP over WebSocket for client-side and they also have a SIP proxy and server (also works with Asterisk,Kamailio). They are the authors of RFC7118 "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)".
that s only one way to do it. There are many ways.
you have to distinguish between the signaling path and the media path
on the signaling path, you have to choose a signalling protocol and corresponding transport protocol. A browser can use web socket for transport and sip for the protocol as far as signaling is concerned. On the legacy SIP side, you need SID over UDP, there is a need to change the transport of the signaling, not the protocol of the signaling.
On the media path, you have two problems, the encryption and the codec. The encryption is mandatory in webrtc and not in SIP. You need a B2BUA to make the transition between both words.
on the codec side, you either choose an overlapping codec between both words, or you have to transcode. The use of a media server seems mandatory here. If you have multiple parties in a conference, you will need to mix the audio and compose the video to send it to legacy SIP, in which case your media server should be an MCU.
Eventually, you also have a discovery and identity problem. During the original handshake, SIP is expecting a user ID and a domain (which is either a DNS entry or a fixed IP) while webRTC is using ICE. Here again, it is very likely that you need to use a B2BUA to bridge both world.
Asterisk/kamailio/freeswitch are likely to handle most of the above for the simple cases (1 to 1, audio). For anything complicated, you're on your own. You might want to look at respoke.io that was made by digium, the company behind asterisk.
There is device connected to PC via 1Gbit Ethernet. WinXP/7
I want to capture data in the following way:
PC sends command to devices (initiate data acquisition)
Device is sending data to PC
User application waits for acquisition
Driver saves data in the memory
Device sends command to notify that it finished acquisition
Driver generates interrupt and user application starts reading data from driver
I have no idea how to implement that.
There is NIC driver. There is NDIS. Can user application communicate with NDIS?
Do i need to write additional driver to communicate with NDIS?
Your problem really has two parts:
How to send commands to the device
How to capture data sent from the device
The first problem has two possible solutions, depending on whether your device accepts commands encapsulated in IPv4/IPv6, or whether it requires some other low-level protocol. If the device accepts commands encapsulated in IPv4/IPv6, then just use the sockets API in your favorite programming language.
If the device requires its own non-IP protocol, then you need to add an NDIS protocol driver. There is a sample protocol driver that is included with the Windows Driver Kit; this driver essentially opens a channel that allows a usermode application to send any kind of packet. (This would be a security issue if it were deployed widely, which is why it's not a built-in feature of the operating system.) You may need to modify the protocol driver to selectively listen only for control messages from your device.
The second problem — packet capture — is already solved. You should be able to pull existing software off the shelf and integrate it in your solution. Microsoft Network Monitor has an API that you can use to easily start/stop packet capture, and iterate through the captured results. Alternatively, some people use WinPcap.