I worked on the technical side of WhatsApp's special pricing program (aka zero rating) from when it started, through integration with the Facebook Mobile Partner Portal until I left in late 2019. We provided partners IP addresses (well a list of cidr ip/subnet lengths) and email updates when IPs changed. Some partners wanted hostnames, but it wasn't usually effective to manage that way; hostnames seemed to work great for WAP based special pricing, but not for direct tcp. But AFAIK, airline programs were done by the airlines (or whoever does their internet service) without consultation with WhatsApp. (A special plan for messaging without multimedia wasn't within the WA policy, at least while I was there, so we wouldn't have helped them build the product they wanted anyway)
There are lots of possible ways to identify WhatsApp traffic, but I never had a chance to figure out what they were really doing. During that time period, if I was on a flight, I was usually with my young child and it's hard to keep focus for debugging networking on a plane, anyway. What I saw when I was looking was more like what joshvm describes elsewhere. The messaging only plans seem to allow most low bandwidth connections, with high latency, but they'll actively supress some things, and others stall beyond some threshold; sometimes you could get a couple media files to transfer, but then it would stop, etc. WhatsApp was engineered to work with the world's terrible networks, so it will usually work ok for messaging as long as packets get through eventually; connection and ping timeouts are long on client and server, because sometimes it takes a lot of seconds. If DNS doesn't work, that's fine too. Multimedia would usually retry and resume enough to work even if connections didn't last long, so I'd guess there was something actively supressing that, but I don't really know.
FWIW, chat isn't TLS, so SNI isn't the answer there, although at least in the past, the protocol was very identifyable. Been gone for a while and don't regularly tcpdump my connections to WA anymore, so I don't know if that changed though. Multimedia is https, and probably has SNI, although that used to vary by platform.
I always thought WhatsApp published their list of IPs (segregated by standard chats vs media), but it seems they only share CIDR blocks with operators privately: https://www.whatsapp.com/cidr.txt
And you say there's no segregation between chat and media - and I trust your out of date info more than my completely made up guesses.
Yeah, that text file included messaging and multimedia (and verification and the website, etc); there was another one that included those and VoIP relay servers (but VoIP also can do p2p, so it's harder to include in special pricing), until it moved to the private portal. Customer service would sometimes provide the link to that text file, and operators we had an active agreement with would get an email when the file was updated (or sometimes when my scripts broke and did stupid things, sorry operators). (While I was there) We never provided a chat only file, because chat only is not a user experience we wanted to have happen.
There are lots of possible ways to identify WhatsApp traffic, but I never had a chance to figure out what they were really doing. During that time period, if I was on a flight, I was usually with my young child and it's hard to keep focus for debugging networking on a plane, anyway. What I saw when I was looking was more like what joshvm describes elsewhere. The messaging only plans seem to allow most low bandwidth connections, with high latency, but they'll actively supress some things, and others stall beyond some threshold; sometimes you could get a couple media files to transfer, but then it would stop, etc. WhatsApp was engineered to work with the world's terrible networks, so it will usually work ok for messaging as long as packets get through eventually; connection and ping timeouts are long on client and server, because sometimes it takes a lot of seconds. If DNS doesn't work, that's fine too. Multimedia would usually retry and resume enough to work even if connections didn't last long, so I'd guess there was something actively supressing that, but I don't really know.
FWIW, chat isn't TLS, so SNI isn't the answer there, although at least in the past, the protocol was very identifyable. Been gone for a while and don't regularly tcpdump my connections to WA anymore, so I don't know if that changed though. Multimedia is https, and probably has SNI, although that used to vary by platform.