We have a situation where our phone system will deliver voice-mail as email attachments to the phone. The problem is the format (while wav) uses a proprietary codec that most mobile device users cannot playback. I need for our Exchange server (Exchange 2003) to parse the incoming file, convert it to a usable format and then deliver the attachment.
Can someone point me in the right direction?
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)
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.
I am using Spring JavaMail API to generate automatic emails to the customers.I am using SMTP server to send this emails.As soon as email goes out to the customer the outgoing email should be stored to some physical location in .MSG format.Is there any java API to do this?
I believe .MSG is the Microsoft-proprietary file format used by Outlook. I'm not aware of any Java software that will write that format, but the Apache POI project can read that format. Better to store the messages in .EMI format, which is just MIME format. Or, use your own mail server and store the messages in a folder supported by that mail server.
I have a proprietary library that generates JPEG images at 10-20Hz. I'd like to stream the images as a video stream over the network, so that a remote client (VLC for example) will be able to view it.
The clients are all in a LAN and there are no restrictions on the streaming protocol and the video format. The environment is Windows 7/XP and the library DLL exports a C-only API.
Is there a recommended library that allows streaming image frames, injected in real-time? the streaming libraries I know (VLC and Live555) do not allow this AFAIK.
M-JPEG defines streaming over HTTP by sending individual images. This protocol is understood by VLC.
From Wikipedia:
M-JPEG over HTTP
HTTP streaming
separates each image into individual
HTTP replies on a specified marker.
RTP streaming creates packets of a
sequence of JPEG images that can be
received by clients such as QuickTime
or VLC. The server software mentioned
above streams the sequence of JPEGs
over HTTP. A special mime-type content
type
multipart/x-mixed-replace;boundary=
informs the browser to expect several
parts as answer separated by a special
boundary. This boundary is defined
within the MIME-type. For M-JPEG
streams the JPEG data is sent to the
client with a correct HTTP-header. The
TCP connection is not closed as long
as the client wants to receive new
frames and the server wants to provide
new frames. Two basic implementations
of such a server are test-server
"cambozola" and webcam server
"MJPG-Streamer".
Client software
Browsers such as Safari, Google Chrome
and Opera stream M-JPEG natively.
See: http://en.wikipedia.org/wiki/Motion_JPEG#M-JPEG_over_HTTP
Take this scenario:
I send an HTML email with images embedded in it - such as a newsletter with images placed inside using an tag.
I open the email
An image is requested
During that image request, what is the full set of information sent to the server? Can someone paste it in?
Would love to see the full request & header when the email is opened in a client like Outlook and at least one webmail platform like Gmail.
As to the comment about which server -- I guess HTTP? If I'm viewing an email in Gmail, and an tag is served, that is being served over HTTP, right?
Thanks!
As far as the client computer is concerned, mail client applications are completely different from a web-based mail front-end.
Typically, mail client applications (formally Mail User Agents or MUAs) use a mail-specific protocol such as POP3 or IMAP to access a mailbox on a remote server.
Depending on the capabilities of the protocol, the MUA may have to download a whole message before displaying anything (POP3) or it may be able to request each MIME attachment separately (IMAP). Usually images are included as MIME attachments and are encoded in a printable form (i.e. restricted to 7-bit ASCII) using something like Base64, in order to ensure delivery without corruption.
Web-based mail front-ends, on the other hand, are accessed through the generic HTTP protocol - the message decoding happens at the remote server. Images are retrieved through normal GET requests like every other image.
A few years back, you might have been able to see both cases at work using a network sniffer tool such as Wireshark. These days most decent mail providers prefer the encrypted versions of these protocols (POP3S, IMAPS and HTTPS) which cannot be usefully studied using a network sniffer.
If you really wish to have a look at the protocols, you might still be able to find a POP3/IMAP service that allows unencrypted connections, although it's probably not going to be a big provider. You could also set-up your own server for experimentation.
If you use Firefox, on the other hand, there is at least one add-on that allows you to see the requests made by the browser, by intercepting the requests before they are encrypted. It will allow you to see what happens as you use e.g. Gmail.