Are there existing practices / XMPP extensions to send a file to several contact's online resources via relay (SOCKS5) server?
Use-case explanation:
Alice (alice#example.com) wants to send a file to Bob (bob#example.com). Alice is behind NAT and Firewall. Bob has two XMPP clients, both online (each with different resource - bob#example.com/first and bob#example.com/second). Both support xep-0065 (for instance). Alice sends file transfer request to Bob, Bob accepts it on one of his devices, the file is being transferred through relay (relay.example.com) to both Bob's clients.
alice#example.com
\/
relay.example.com
\/ \/
bob#example.com/first bob#example.com/second
There are no such XMPP extensions for this use case.
I'd recommend you store the file on an http server (Amazon S3 comes to mind) and send the download link to all connected resources of the recipient. Upon successful reception acknowledged by the resources, the sender can delete the file.
There will be additional negociation between the recipient resources (1 resource would say to the other: "I have accepted the file transfer, please download it too")
Related
I'm in somewhat of an odd situation here. I'm looking to send SMTP e-mails from a remote embedded system which is directly connected to an iridium modem into a local server. The current system sends files in chunks of data and I don't know exactly how this would work with e-mail. I was thinking of using mutt to send attachments (.wav or .jpeg files), but again I don't know if this works without direct internet access. If anyone has any idea if this is possible, please let me know.
Edit: I'm using RUDICS communication, not a SBD modem
Thanks
The Iridium Short Burst Data (SBD) service sends burst of less that 2Kb at a time and the revenue model for Iridium service might make sending audio and image data very expensive.
Nonetheless messages are converted by the Iridium network to be delivered in email format or over HTTP to a pre-configured address. The address to which data is sent is assigned to your Iridium service subscription, not stored or configurable by the sender. You can of course forward the received data to any desired destination.
You can get a direct Internet connection using an Iridium phone (https://www.iridium.com/services/details/iridium-direct-internet); but that is an expensive and bulky solution.
It's possible but somewhat complex. You would need to setup a PPP connection with the modem and then email would be able to flow across the serial line to the other server.
In this SuperUser.com question and elsewhere, I've read that Skype doesn't store your historical chat messages on their servers in a way that's user-accessible. (Of course, what they do for internal archival and analytical purposes is a different story -- as reflected by their privacy policy).
But the user experience for group chats is: when you've been offline and you sign back into Skype... all the messages you missed appear. Even if it's been a while and there are a lot of messages. (I don't know if there are limits on how long or how many.)
So: how is this UX implemented if the messages don't come from Skype servers?
I've read this offhand description which states:
Syncing of group chats ("More than 2 people in a chat") is done by chat sync partners in those chats, and not provided by Skype servers.
If that's correct, I'd love more details about how this works, like:
Has the protocol been specified or reverse-engineered?
Is it available through an API?
Are requests routed through Skype, or is it direcly peer-to-peer?
If peer-to-peer, how are requests authenticated?
My experience is I can only "see" history back to the time when I joined a chat; can a client request or receive messages farther back in the history?
I understand some of of the protocols are currently in flux -- so, bonus points if you can explain whether/how these details are changing.
When you login your client has the last recieved id of that conversation.
Sends it to the other clients. The client who recieves the id looks up all messages after that one, and then sends it back to you.
That way they don't have to store the messages on their servers.
I have seen many of the posts relating to sending email under linux but they do not address my particular need.
I want to implement code (C/C++) in my linux application that will send me back some kind of notification (in a stealthy way) under a certain program condition. All it needs to send me is less than 50 bytes of status data. The only thing I am guarenteed is that the box will be on a local network which will have access to the Internet via the usual gateway.
One possibility would be to send me a text to my wireless carrier like this:
mynumber#verizon_gateway.com. But that assumes that I have a mail client available on the linux box which is not a guarantee. If I programmed this at the socket layer directly using SMTP I would have to manage a TCP connection which is not what I prefer to do.
Any suggestions of what would be a possible way to send me a notification from my linux app?
Thanks,
-Andres
For email you could use something like SendGrid, specifically their WebAPI - this will allow you to send email with only a HTTP request.
For SMS you could use something like Nexmo, which will allow you to send an SMS with a HTTP request.
Note that you'll have to include your API credentials in the compiled code - a potental security issue (for your credentials).
Disclaimer: I do a bit of developer evangelism for Nexmo.
I understand many of the fine details of NAT hole punching, ICE, and SIP VOIP calls. I've answered quite a few questions on SO on these topics. Now I have a question.
I am trying to understand the need for the RE-INVITE message that is documented for SIP+ICE after the call is already established.
Assume a topology of VOIP devices that signal over SIP and using ICE (with STUN/TURN) for establishing media connectivity. After the ICE connectivity checks are performed, both endpoints should have ascertained the best address candidate pairings (IP,port) and should be ready to stream media in both directions.
But my experience with SIP and plenty of documentation suggests that after the callee sends a 200 OK message to indicate he's in the answered state, the caller is to expected send a RE-INVITE with an SDP containing the specific address candidate selected by the connectivity checks.
Some links that describe the RE-INVITE with ICE are here and here (step 8). Rosenberg's tutorial (page 30) discusses that the RE-INVITE "ensures that middleboxes have the correct media address". I'm not sure why that's important.
Upon receiving a RE-INVITE, is the callee expected to reconfigure his ICE stack to switch sockets or addresses based on the new SDP received? Or is the RE-INVITE just a protocol formality to formally acknowledge the call has been established? If the RE-INVITE step was skipped and both sides started streaming media, what could go wrong?
The reason why I ask is because I am exploring using ICE over a signaling service that is not SIP. I'm trying to figure out if the RE-INVITE needs to be emulated.
One example of middlebox, which may be interested in the result of the ICE negotiation is a bandwidth manager.
Imagine an enterprise deployment, with endpoints inside the corporate firewall and others roaming around on the Internet, or behind private home firewalls. The deployment also includes a publicly accessible TURN server. Then let's imagine an endpoint inside the corporate firewall making a call. If the destination happens to be reachable on the same network, the call will go host to host and the TURN server will not be used (i.e. bindings will be de-allocated). This is a local network, and no bandwidth limitation needs to be imposed. On the other hand, if the call goes out to a roaming endpoint, then the TURN server will get involved, and data will flow through the corporate firewall, through what probably is a limited bandwidth uplink. We can very well imagine some policy that would want to limit the call's bandwidth. One way of doing it, is for the bandwidth manager to remain in the signaling path (using SIP record-routes) and look into the SDP of any INVITE going through, re-writing bandwidth values depending on media addresses.
I believe the general intention was, that legacy equipment of that type, which is not ICE aware, should keep working in a mixed environment introducing ICE endpoints. To keep this backwards compatibility, ICE should only introduce new processing (STUN checks, etc), but from the point of view of non-ICE-aware elements, it should not remove any existing rules (re-INVITEs are still needed to change the destination of a media stream).
In Rosenberg's tutorial I believe the re-INVITE is sent because the sockets chosen by ICE are different from those in the media and connection (m/c-lines) lines of the original SDP AND in order for any network elements that are in between the two user agents to be informed of the actual sockets that will be used RTP a re-INVITE is sent with the ICE selected socket(s) in the media and connection lines of the SDP.
If the ICE selected sockets were the same as the ones in the original INVITE request's SDP m/c lines then there would be no need for the re-INVITE request. Or if you know there are no "middleboxes" that need to be informed of the changes to the RTP sockets then there would also be no need to send the re-INVITE.
We currently have a company email server with Exchange, and a bulk email processing server that is using IIS SMTP. We are upgrading to a 3rd party MTA (zrinity xms) for bulk sending. I need to be able to keep sending the messages already queued for IIS when we switch to the 3rd party sofware. Can I simply move the IIS queue files to the Exchange server queue and have sending attempts begin automatically for them? If not, any suggestions on accomplishing this?
You should be able to move the *.eml files to the Exchange server's pickup directory. Or set the IIS SMTP service to smart host to the new MTA, assuming they (the 3rd party) allow SMTP relay from your IP address.
Moving the files will work. However, any email with a BCC line in the header will get sent out with the BCC intact. Some clients, such as gmail, will display the information to the recipient, thus breaking the whole point of BCC.
This happens when copying EML files to MS-SMTP (which Exchange also uses) because the BCC information is usually stripped out of the header in during the SMTP hand-off to (not from) MS-SMTP.
If that was how the messages were initially handed off, then it's possible that the EMLs you have were already broken into separate messages for each BCC, and that header was properly stripped.
Just a little gotcha to watch out for.