Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

Earlier rant on this subject: https://forum.kitz.co.uk/index.php/topic,22108.msg379638.html#msg379638

I suspect that (Apple’s) Facetime and iMessage use the internet all the time even when the corresponding parties are in the same LAN, which is utterly insane. (Apologies if I have got this wrong.) Fixing it would be trivial. That stupidity means that sending a picture or even worse a video clip using iMessage is incredibly slow because of my crummy 1.1 Mbps upstream speed when it only has to travel 5 m across the room. (Yes, I know, use Airdrop, which uses a weird mixture of Bluetooth and 802.11*, possibly for good reasons.) Some of this is the applications’ fault obviously. However more adventurous core networking educates app developers and core networking software devs can inspire change and the exploitation of new opportunities.

It is completely insane. Now because of my very limited upstream ( < 1 Mbps ), it’s painful to send stuff to Janet even though we’re in the same room. It would be so easy to fix. Try just sending to the IPv6 address of your peer, first taking a look at the globally routable IPv6 addresses that you both may have. If you both have one, compare the high 64 bits of each, and if they’re equal, then you’re good to go, and you can just send stuff between those addresses. If you don’t both have such a routable address, try pinging the other person’s IPv6 link-local address, they’re pretty much bound to have one, I would think. If that fails, then you’re not on the same LAN, or you’re perhaps on a WLAN with inter-client isolation, like many guest networks, where you can only access the internet and nothing else on the LAN. It would be rather better to sort-of ‘ping’ the other machine with some sort of distinct, identifiable protocol, one that identifies it as being an iMessage check, or whatever.

Unfortunately, you have to go to the central Apple servers at first, in order to get the other machine’s IPv6 addresses, which each machine can report in, initially and every time they change. A report should be a complete list of all interfaces’ IPv6 addresses, with additional fields added per interface, identifying what kind of link it is (eg 4G, 5G, WLAN/FTTP, WLAN/xDSL etc.), with scope, and with preference values giving est speed down/up and the cost per byte, plus any quota info, so that expensive or all-you-can eat links can be identified and software can make a choice to rule out some link types and prefer others.

[Alex Atkin UK]

It annoyed me no end when Skype moved to the server model, it made it much harder to achieve a HD connection.

Mind you it was always buggy, it would sometimes have trouble going HD even on the LAN with two clients right next to each other communicating directly.

Basically since CG-NAT started to roll out, everything moved to server-based as peer to peer could not be guaranteed to work (not that it ever could mind you, but uPNP was common so it usually did).  Why it can't just be a fallback option for when direct fails I do not know, so they can snoop on your data probably?

[XGS_Is_On]

uPNP isn't such a thing on corporate networks. Most of those paying for Skype and in turn Teams are corporate customers. The transactions on a local, layer 2 network are tiny in comparison to those across the Internet that will consume bandwidth on the WAN regardless. Bandwidth for Apple, Microsoft, etc, is really cheap and web sockets to hook clients together aren't a big overhead.

Folks working from home for corporates will likely either have a VPN that sends everything through the corporate network, be using a cloud security solution that fires 443 through a third party firewall solution or will have endpoint security software on the machine that isn't interested in allowing applications to listen to random sockets.

Haven't had uPNP running here since 2020 and haven't noticed any loss or degradation of functionality.

[craigski]

Apple FaceTime is P2P between devices, if the network will support it.

https://support.apple.com/en-gb/guide/security/seca331c55cd/web

[Alex Atkin UK]

uPNP isn't such a thing on corporate networks. Most of those paying for Skype and in turn Teams are corporate customers. The transactions on a local, layer 2 network are tiny in comparison to those across the Internet that will consume bandwidth on the WAN regardless. Bandwidth for Apple, Microsoft, etc, is really cheap and web sockets to hook clients together aren't a big overhead.

Folks working from home for corporates will likely either have a VPN that sends everything through the corporate network, be using a cloud security solution that fires 443 through a third party firewall solution or will have endpoint security software on the machine that isn't interested in allowing applications to listen to random sockets.

Haven't had uPNP running here since 2020 and haven't noticed any loss or degradation of functionality.

I guess that makes sense, but why drop P2P support entirely if they could just fall back to relay based when required?

My guess is they completely rewrote the code and couldn't be bothered with the expense to re-implement it.  But the video quality after the change was so bad I just stopped using it entirely.

[craigski]

I guess that makes sense, but why drop P2P support entirely if they could just fall back to relay based when required?

According to this article, Teams uses P2P on LAN, once call is established, see flow (5) on this diagram:

https://learn.microsoft.com/en-us/microsoftteams/microsoft-teams-online-call-flows.

Media traffic for peer-to-peer calls takes the most direct route that is available, assuming that the call doesn't mandate a media endpoint in the cloud (see previous principle). The preferred route is direct to the remote peer (client), but if that route isn't available, then one or more Transport Relays will relay traffic. It is recommended that media traffic shall not transverse servers such as packet shapers, VPN servers, and so on, since this will impact the media quality.

[Alex Atkin UK]

According to this article, Teams uses P2P on LAN, once call is established, see flow (5) on this diagram:

https://learn.microsoft.com/en-us/microsoftteams/microsoft-teams-online-call-flows.

Trouble is, I'm not talking about LAN.  My calls between me and my friend on Virgin would struggle to hit 720p when we both have 1080p cameras.  It had issues over P2P too, but not nearly as severe.  My guess is they deprioritise quality for free users, which was not an issue before as it didn't cost them in bandwidth when it was P2P.

[XGS_Is_On]

If you were both using uPNP should have been able to open ports and connect directly.

Depending on the app even without uPNP direct connections over UDP are doable via STUN and punching holes in firewalls with outbound sessions.

[XGS_Is_On]

A report should be a complete list of all interfaces’ IPv6 addresses, with additional fields added per interface, identifying what kind of link it is (eg 4G, 5G, WLAN/FTTP, WLAN/xDSL etc.), with scope, and with preference values giving est speed down/up and the cost per byte, plus any quota info, so that expensive or all-you-can eat links can be identified and software can make a choice to rule out some link types and prefer others.

None of an individual application's business what the links are and not within the gift of individual applications to make path selection choices: they just send requests to the operating system and if it has multiple paths it makes the decision else the first device with multiple paths does so. All that stuff is your Firebrick's problem and should be because it's the only device that knows how utilised each link connected to it is and is the only one with visibility of all of them.

Software can mark its packets and in the case of a mobile device can query the OS to find out if it's on WiFi or cellular and decline to send traffic if WiFi isn't available but that's about it. Some privacy decision on the part of Apple as no reason why it couldn't be done without anything exotic, just the IPv4, v6 and public IP if behind NAT, of the peer. iMessenger is not real time traffic and at least in the case of some messenger applications for privacy reasons clients only attempt to connect directly for interactive, real time traffic where sitting at a relay waiting isn't an option.

[Alex Atkin UK]

If you were both using uPNP should have been able to open ports and connect directly.

Depending on the app even without uPNP direct connections over UDP are doable via STUN and punching holes in firewalls with outbound sessions.

Maybe Teams is better, I just know Skype didn't do it after the revamp.

[Weaver]

Hi Carl, I agree with everything you said. I suspect there was some misunderstanding and I probably didn’t express myself well. The report with interfaces’ IP addresses is so that one party can be told which of the peer’s IPv6 address to use, the range of choices arising from the case where say an iPad has two network interfaces, for example one to a WLAN heading for a router and one to 4G/5G direct. This would be irrelevant if such a device kicked off a conversation first as the other end would see a source address and so see the results of the sending devices choice of interface and so choice of route. It would be relevant in the case where a remote machine was sending to a peer ‘cold’, using only cached info that it had in a database from previous sessions. Such a technique might be valuable as it involves the avoidance of initial server relay-based querying and indirect connection setup. Such information might well have become out of date as circumstances changed and a certain time for aging out cached info wouldn’t really help so much as circumstances can change rapidly if you’re talking to a remote mobile device that can move off a WLAN and have to go over to 4G/5G, so it might be better to also design for the possibility of inappropriate addresses being used and talking to the wrong host or to no one because the dest address you’re using is now incorrect. In such a case after a device has done an identity check it can fail over to the server relay-based fallback method, I would bang out packets address to both direct dest address and to our server straight away and then see what works, all to minimise initial setup  time. What I wrote was intended to be rather vague and a work in progress as a lot more thought would have to go into the design than has been given in the few minutes I’ve devoted here.

[XGS_Is_On]

It would be relevant in the case where a remote machine was sending to a peer ‘cold’, using inky cached info that it had in a database from previous sessions. Such a technique might be valuable as it involves the avoidance of initial server relay-based querying and indirect connection setup.

Hello!

The 'cold' send should never happen. Either it uses an existing socket that was kept open for a while just in case, which is legitimate, or it goes back through the original set up as this shouldn't take more than being generous a quarter of a second.

The thing that makes me nervous here is the idea of a remote party obtaining your IP address just by trying to send a file: IMHO that should never happen until the file is actively accepted and transfer only begins then. The transfer acceptance is going to require communication through a server anyway so if it's accepted the confirmation of the acceptance can go from server to the sender.

Annoying as it is have to remember that iMessage is first and foremost a messaging service not a file transfer service and is designed as a client-server application not peer to peer. You make good points however I think you're using the wrong tool for the job and it's preferable to use a different tool rather than wait on that one to be changed. Is that feasible?

We've moved as a whole away from peer to peer for partly security reasons.

[Weaver]

I see your point about security. I had not considered that. I would think the obtaining IP address security thing could be dealt with, but I’d have to give that a lot more thought.

I do do file transfer over iMessage, the need does come up occasionally.

In my situation, if I want to do something like Apple Facetime over my LAN, instead of getting 300 Mbps (perhaps halve that because of contention in a WLAN), I getting the video quality limited by the upstream ADSL2 bandwidth, which is about 0.7 Mbps after all overheads including TCP are subtracted. And before I forget, both parties are fighting over the upstream bandwidth. I do need to check that FaceTime is indeed guilty before I libel it further, mind.

A while ago, I was in bed as usual and my wife was in the office plugging in and unplugging network cables, and I used FaceTime so I could see what she was seeing and guide her.

> use a different tool rather than wait for that one to be changed. Is that feasible?
If I could give Apple some product feedback, there is a way to do it, but I forget now, then who knows they might simply fix it, it isn’t that hard. As for feasibility, I don’t know the spec of the various chat programs out there. I can’t use WhatsApp because the moronic thing only runs on phones, and I only have an iPad. They advertise a product for iPad, but incredibly this requires you to have a mobile phone as well  as the iPad. I don’t know whether or not any of eg WhatsApp, Facebook Messenger, Skype, Signal et al have sane routing. Of course the killer thing about iMessage and Facetime is that they are installed on every Apple device so if the other person is an Apple user, a big if, then you won’t have to somehow talk them through the business of installing a new app. Of course having said that, the multi-platform apps have a greater advantage still in that you’re not limited to only being able to communicate with the 20% that is the Apple slice of the cake. I don’t have a Facebook account, but my wife uses Facebook Messenger chat a lot, and that might be worth a look. End-to-end serious encryption is of course a must and that might rule out some applications.

You were talking about alternatives. For file transfer over the LAN, Apple has a program called AirDrop which does what I need but has no chat capability, nor video conferencing. For some reason, it kicks off the protocol using BlueTooth. I don’t know why that’s necessary, but it could be that they just found it makes things a lot easier. I would think something like the algorithm that I sketched out very badly earlier should be capable of handling things. I’m quite a fan of multicast too. It could be that Apple’s fake IP address and fake MAC address generation algorithms for privacy protection might be making life difficult for such a use case. I wonder if that presents a killer problem. I didn’t think about that before since I always have such features turned off. I can see why Apple did this privacy addressing thing, what with tracking going on in the London Underground (by MAC address ?).

[XGS_Is_On]

Facetime going via a relay rather than direct on the LAN is

iMessenger I get. Facetime is ridiculous: you accept the call, the respective clients should be provided one another's IP addresses, use uPNP or open UDP connections and communicate directly.

That's what decent clients do. They only fall back to relay if a direct connection can't be made. Wonder if the use of public IPs for everything confuses things, it expects IPv4 to be traversing NAT?