Database Develop

911 and e911 explained

Personal background: Associate degree in Laser Electro Optics. 12 years research and development semiconductor manufacturing, 15 years as an EMT, last 10 years as a 911 telecommunicator for Austin-Travis County Emergency Medical Services. 6 of those years as a Training Officer.
The reason for my (cough) resume is so everyone understands I have the technical background and experience to explain the differences between e911 and 911.
Public Safety Answering Point: the local organization tasked with answering emergency request phone calls and dispatching appropriate emergency resources. PSAP's are broken into two types, primary and secondary. The primary PSAP is typically the local police department for city's and the local sheriff's department for unincorporated areas. Some colleges have their own police department and may have their own PSAP. So realistically a person can connect to a different 911 call center depending upon their location within a small geographic area.
Large urban areas typically have secondary PSAP's. The secondary PSAP usually consists of public safety departments not related to law enforcement such as fire and/or emergency medical services (ambulance services) specially trained to send request specific resources dependent upon the emergency. In Austin and Travis County we run 120 thousand EMS 911 calls per year. The police department takes about 2000 911 calls per day.
911: a simple to remember phone number nation wide allowing everyone access to emergency services. No location information is transmitted or received. The PSAP is responsible for determining location by interrogation of the caller. This can a problem if the caller is altered or otherwise unable to give accurate information.
e911: Enhanced 911 was created to ensure location information was transmitted to the 911 call center regardless of the callers ability to give this information. The phone companies are responsible for ensuring this information is available and transmitted to the PSAP. Conventional e911 is effective for landline phones. Cell phones present a completely different problem.
Cell phones are required to meet two different location technology standards.
Phase 1 wireless data: as cell phone use skyrocketed in the nineties, legislation was passed requiring provider's to transmit location data based on the cell phone tower that the cell phone was connected to. While this is helpful, it is problematic due to the sheer size of the area that had to be searched if the caller was unable to give their location.
Phase 2 wireless data: legislation now requires GPS location data be provided by the cell phone company. This location information can be transmitted via the gps chip from the cell phone or via radio location triangulation using the cell towers in the immediate area of the caller.
So in a nut shell, my test of neobuddy's ICS indicated that 911 worked for a sim loaded phone. I did not test the phone with the sim pulled. I also did NOT verify that GPS data was being received by the PSAP.
If 911 works with your phone it should work in any area. I was connecting with two different PSAP's as I live right between two different area's and sometimes connect to one or the other.
Hope this clears some of the confusion. A good explanation is located at en.wikipedia.org/wiki/Enhanced_9-1-1.
genesis3 and I are still working on the cm7 issue and getting closer to a resolution.
Later tators
Sent from my Touchpad using xda premium

thanks a lot. i can confirm cm7.1 has 911 issue.
Sent from my SGH-T959 using XDA Premium App

Developers should also note that as technology continues to advance, video conferencing and text message 911 activation requirements will also be legislated in.
I firmly believe that Google should begin requiring manufacturers make their modem software and audio software open source. Manufacturers should also be required to provide detailed explanations of how the relevant library's interface with the operating system, modems and audio system when activating an emergency call. This is Androids achilles heel. All it will take is one national media event to slam the door on open source operating systems for cell phones. I love the freedom Android provides and the exceptional programing skilss of our developers.

Im sorry, while this is a great explanation, i really didnt get the bottom line....
What we have on nonsamsung roms then is just a plain 911 incapable of transmitting location?
Sent from a cell tower to the XDA server to you.

Im sorry, while this is a great explanation, i really didnt get the bottom line....
What we have on nonsamsung roms then is just a plain 911 incapable of transmitting location?
Click to expand...
Click to collapse
correct as none had the source code....but for 2.3 onwards rom.
genesis3 and I are still working on the cm7 issue and getting closer to a resolution.
Click to expand...
Click to collapse
made my day.....thanks a lot....will be keeping a close eye on this thread...

My understanding is the issue is only without a sim right?

The 911 issue is with SIM, i don't know about without and im not planning on finding out.

HaloMediaz said:
My understanding is the issue is only without a sim right?
Click to expand...
Click to collapse
It has to do with emergency mode (no dim) and when no compatible roaming network is around (no service) .
Sent from my HTC Sensation 4G

hmmm I havent called 911 in YEARS but it still feels nice to have the ability and this was a nice explantion thank you

MIUI 360 in Asheville NC works fine but not in other areas?

Hopefully they can test the cm9 test ports that are out now.
Sent from my SGH-T959 using xda premium

http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.

Genesis3 said:
http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.
Click to expand...
Click to collapse
Can we get independent confirmation of this? (not that I don't believe you)
Sent from my SGH-T959 using xda premium

Uh, the guy who tested and verified it is the OP on this thread.
Read the first post.

You typed all that from your touch pad? props
Sent from my SGH-T959 using XDA App

Genesis3 said:
Uh, the guy who tested and verified it is the OP on this thread.
Read the first post.
Click to expand...
Click to collapse
No, I get that. Just wanted to make sure he verified was all..

Genesis3 said:
http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.
Click to expand...
Click to collapse
Don't know who you are or where you came from but, you sir may have saved CM development for the vibrant community. Here's hoping and you're the man!!!
Sent from my SGH-T959

Genesis3 said:
http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.
Click to expand...
Click to collapse
I just downloaded your kang and running great so far, Thanks for you work !!
Question, is this 911 fix kernel dependent ? ie will it break if I flash another cm7 kernel ?
Thanks again for your hard work !!!

will replacing the kernel break both 911 and gps fixes?

I didn't save anything.
Here's the bottom line, if you're interested in it.
In the original Vibrant device directory there was a set of sources for libaudio -- one of the shared libraries that Android depends on to talk to the audio hardware in the phone. There was no documentation as to where this source came from, but I know where it didn't come from -- it didn't come from a public Gingerbread source for the Vibrant, because there isn't one.
It turns out the library this source builds does not work correctly but exactly why I'm not certain of. One of the problems with debugging this is that I have to have someone else test for me, which means I can't do the sort of testing I like to when I'm tracing things like this (a highly-iterative process that requires that I actually be staring at the debugging screen while doing the deeds that cause the bad behavior) since I can't call 911 myself.. Had the provenance of this code been documented originally (or lack thereof) I would have investigated this possible connection, as I knew the problem lay in the audio connectivity due to myriad kernel and application traces a couple of months ago. I didn't chase that library down and attempt to graft in other related versions because I assumed that the CM people knew what they were doing building that library from source rather than using a cribbed copy from, for example, Froyo or a different gingerbread build off a similar device.
Picking up a different shared library does work. Exactly what the provenance of that library is (e.g. was it grabbed from a binary, was it built from DIFFERENT source, where did it come from?) is also unknown.
Now that I have a working shared library on this device and a non-working one I'm going to compare traces. Maybe I'll get lucky and find the changes necessary in the source that's in the build tree and be able to fix that, at which point I'll know what I've got rather than having a "magic" library from God-knows-where.
Now here's the part that annoys me -- I was all over some of the CM guys about audio problems with other Samsung devices and tried to get access to the "not yet finished" repos because I expected that if I could run down the same sort of problem with ordinary calls in one of the OTHER Samsungs it was rather more likely than not that the same fix would be pertinent in some way on the Vibrant -- simply because manufacturers tend to use the same chipsets and bits, along with APIs, between different devices (it makes it easier for their coders and maintainers to do their jobs.) In addition when I started working one this one of the other protagonists didn't give me jack and crap about the provenance of anything in the device tree and, again, there's no docs embedded in the tree either. You can find the flamewar and slander aimed at me here if you'd like. It turns out I was on the right path; the problem this library allegedly fixed was having to hit <MUTE> twice to turn off and on the audio path. Sound familiar? Well, the pointer to the file that I found and integrated was from a bug logged against the I-9000, a similar phone to the Vibrant, and that library version works. What's changed in it? There's no set of commits logged against the ZIP file provided in that patch; is it a binary lift from a different build (e.g. some factory build) or did someone fix the source?
Who the hell knows because again, it's not documented in the bugtracker. Until I know where it came from and, if there's source, I have access to it, I won't support it. I don't play the "hide the sausage" game when it comes to alleged community coding projects.
I ran into something similar with the Triumph in that there was a different set of parameters coming up from the hardware when a wired headset was plugged in. That was easy to run down because I could do it and see what was going on; it was a literal couple of line change in the code once I found it. There are a couple of places in the libaudio source that might be the cause of this now that I have a reason to look in there, but without being able to easily reproduce the condition that creates the failure (e.g. call 911) it's a guess.
The ICS builds out at present have a different copy of the same compiled library and it also works. I bet that one works too on CM7 as it's fairly close to the metal and thus the API's probably the same (or close) on the Android side but I haven't tried it yet. I've got little reason to since I now have a libaudio.so that's functional on CM7 in any event.
While I've been working on the 911 issue (for a couple months on and off) I also traced down some actual working (properly) GPS libraries that handle the AGPS assist data in the correct way, something that other sets of them do not, and added those too. I also made a few other changes. The battery life is reported to be rather impressive, and the near-instant GPS locks most-definitely are. I can't speak much to the battery life view of the world as of yet but I will be looking at that; that's an area I know quite a bit about (getting these devices to properly go into deep sleep as they should) and the source tree I'm working with does have kernel source.
Any sideloaded kernel that leaves libaudio.so alone (check the zip file to make sure that /system/lib/libaudio.so is NOT present) should be ok, but no promises. Before you go screwing with kernels make sure you want to --you might break GPS performance as a number of the kernels have various attempts to get the GPS to work right and load various libraries along with the kernel itself with varying degrees of success.
I'd be willing to maintain this port but there are two conditions -- first, I expect apologies from the CM people who attacked me, in public, and second, I expect a formal commitment that there will be no more hiding of information. "I don't know" is an acceptable answer provided you run down the person who does -- someone does know because someone DID either import or code the material in question; silence and lack of documenting where things came from and how they came to be is not acceptable. When things go into the codebase through review they damn well ought to be documented. I played "talking to the brick wall" with the Triumph and now the Vibrant and I won't do it if I'm taking on responsibility for maintaining something.
If CM wants me involved in this that's the deal. If not I'll consider setting up a parallel build and set of repos for the bits that have to be changed from the base CM7 Gingerbread branch as I did for the Triumph if there are people interested in it, but my time is not unlimited and in all honesty my taste for working with the CM people and the CM code in general has been seriously damaged, never mind that what I have here seems to work just fine. As such the benefits of continued efforts are likely to be relatively small. If I decide against a continuing effort I will take the build environment that produced that I have now and attempt to set up a manifest so it can be cloned by anyone else who cares to do so, which should take care of others being able to build and run the KANGs from source if they wish. The latter may take a while as I need to find a day when I'm not busy and can put that together (again, lack of documentation doesn't help) and then pull a clean test from a zero base and make sure it builds and runs.
The Vibrant is no longer my daily device but I do still own one, and given its relatively modest resale value I'll probably keep it as a spare device -- it's a very credible phone and with working GPS code it actually locks faster and better than my Hercules does. It's biggest shortcoming is that it's relatively RAM-starved compared to more-modern devices.
Fancy that.

Samsung Galaxy 8.9" 4G Jelly Bean?

I have the 4G version, is this specific model have a working CM10 ROM? I know the Wi-Fi model does, just want to make sure this won't brick mine or anything.
I'm new to this, just got this today!

It does not. Our version (i957) uses a different chipset then the Wi-Fi version. Best to not flash.
Sent from my Galaxy Nexus using Tapatalk 2

CM10 will eventually support this device -- In fact, the device tree was just created by cyanogen yesterday @ https://github.com/CyanogenMod/android_device_samsung_p5att -- However, work still remains to get this code to even boot, let alone be functional as a daily driver. It will get there, eventually.
The ICS (4.0.4) ROM from Samsung for this device is currently in test with the carriers. The Korean variant (SHV-140) just received the ICS update a few weeks ago, and some of that code might help speed along the Cyanogen update.
The CM10 code currently on github does build, but the kernel does not seem to fully boot -- Locks up just after displaying the initlogo, with adb unavailable, so I have no idea how to get the dmesg. I suspect there are some needle-in-a-haystack sort of details that need to get ironed out, the kind of which probably will require some hardware hacking (ie: serial and/or jtag access) to get at... or for the official i957 kernel to get released.

The shv rom has to be out there somewhere
Sent from my SGH-I727 using xda premium

In for the first screenshot of a p5att (SGH-I957) running jellybean, in case you need some encouragement you won't be stuck on honeycomb forever...
No, it's not even close to stable.
Yes, pretty much everything is broken. IE no LTE, audio, and probably everything else I didn't try.
works: wifi, touchscreen.
No, I won't be maintaining a release for this, the people way smarter than me on the cyanogen team did all the real work on this.. I just built and kludged until I got it to boot with graphics If things go well you'll see a real release from the CM team sometime. For all I know they'll run into a horrible problem and give up, but you know how those guys are.. totally badass.
basic idea:
- breakfast cm_p5att-userdebug
- replace msm-8660-common kernel with code from jb-full branch
- *** edit to update: it seems there is no longer a jb-full branch, there is now just jellybean and jb-old. I'm guessing the out of date msm8660-common kernel from what was jellybean is now jb-old, and jb-full has become jellybean.. hmm.. working on seeing if this is the case (need to clone/build/boot it)
- hack p5att boardconfig
- pick your combination of samsung proprietary files, good luck, the note and/or skyrocket CM10 releases are your best starting point
- brunch p5att, consume more coffee and stuffs
- hack resulting .zip to remove assert for 957 (TWRP has wrong product ID lulz)
- hack ramdisk to enable adb on boot so you can debug why it doesnt come up
- hack proprietary files until you get working graphics
** (not for the faint of heart)

nrvate said:
In for the first screenshot of a p5att (SGH-I957) running jellybean, in case you need some encouragement you won't be stuck on honeycomb forever...
No, it's not even close to stable.
Yes, pretty much everything is broken. IE no LTE, audio, and probably everything else I didn't try.
works: wifi, touchscreen.
No, I won't be maintaining a release for this, the people way smarter than me on the cyanogen team did all the real work on this.. I just built and kludged until I got it to boot with graphics If things go well you'll see a real release from the CM team sometime. For all I know they'll run into a horrible problem and give up, but you know how those guys are.. totally badass.
basic idea:
lunch cm_p5att-userdebug
replace msm-8660-common kernel with code from jb-full tree
hack p5att boardconfig
pick your combination of samsung proprietary files, good luck, the note and/or skyrocket CM10 releases are your best starting point
brunch p5att, consume more coffee and stuffs
hack resulting .zip to remove assert for 957 (TWRP has wrong product ID lulz)
hack ramdisk to enable adb on boot so you can debug why it doesnt come up
hack proprietary files until you get working graphics
(not for the faint of heart)
Click to expand...
Click to collapse
nice job man!

EDIT: I created a separate thread for doing the CM10 build: http://forum.xda-developers.com/showthread.php?t=1867579
Cheers!
Still hacking stuff.. lol.. using the file list from the msm-8660 common proprietary file list, i grabbed that set of files from the CM10 i717 ROM and dropped them onto the i957. Working audio! Don't know about the mic, but it plays sound now. Also, it almost got LTE working... logcat -b radio shows the LTE radio finding the LTE cell and reporting signal strength, but the data session doesn't actually establish, even with the proper APN config. GPS looks like it might even eventually lock on, it found 2 sats after a while, but didn't get a lock. I suspect when full 4G comes up, it'll be able to use SUPL to get it's initial location then actually get a fix.
Downloading the gigantic i717 stock image, going to see if 4G plays nicer with the note radios, since I'm using the note RIL now.. Dan had mentioned he had successfully got the note radios running on the tab 8.9 LTE in an attempt to get voice calls up... the honeycomb RIL stuff just results in lots of errors, so thats straight fail.
I didn't realize how many software pieces go into the cellular data connectivity, yikes!
The more I delve into code and binary packages... the more it appears the 957 is very close to a supersized note! sweet.
Also, bluetooth finds my neighbors macbook, so it probably works, but my headset is at work and I haven't been there in a while (hence having time to do this fun stuff).
If anyone has any suggestions on getting LTE up, I'm all ears. If I can get LTE working, I might be tempted to try to package this beast up.
More fun...
Good grief, it looks like the userdebug variant compiles with all the radio debug flags on, thousands and thousands of lines of everything from verbose text to hex dumps!
i957 honeycomb radio: baseband shows unknown, isn't worth anything
i717 ICS radios, both UCLF5 and 6: entire tablet slows to a crawl once rild starts, fail! Nothing useful in the logs as to why, nothing hogging CPU time... no idea, abort
i727 skyrocket ICS radio I727UCALC4 (no idea how current or valid this radio really is): gets HSPA+ on old 3G "wap.cingular" SIM, no luck with tablet only LTE "Broadband" APN SIM. ~2-2.5mbit download speed.
i727 skyrocket ICS radio UCLD2: Obtained HSPA+ with Broadband APN data-only SIM. ~4.0-5 mbit download speeds. After ~10 minutes, found an LTE cell and pulled 30-35mbit down. After each radio reset (reboot, airplane mode, etc) it takes the 3-10 minute period to get LTE again, and it's also slow (10-50 seconds) to get on HSPA. All around sluggish to jump on a cell, but returns nice speeds once it does so.
i727 skyrocket ICS radio UCLF6 (latest I could find): Pretty much the same as UCLD2 above, similar speeds, but seemed to jump on LTE quicker after a reboot, but still takes a while when coming back from airplane mode. It's the latest, i think, and it works, so it's probably the way to go.
Pending investigation: RIL files -- going to try the skyrocket UCLF6 RIL and see how it works out. Currently still using the note RIL files. Tried UCALC4 skyrocket RIL and it didn't work at all, will try UCLF6 from stock skyrocket ICS release...
Looks like it doesn't like the Broadband APN on a tablet (data-plan-only) SIM. I tossed in a "old school phone SIM" from the 3G days, which is set up on an unlimited phone/data plan (as you could get ages ago) and gave it wap.cingular, and whamo, HSPA+ connectivity. Looks more like a configuration issue and/or the phone RIL/radio combination refuse to play nice with data-only SIM.
I've never tried to debug getting onto 3G/4G service at the RIL radio log level, so not totally sure what to look for, but... guessing it's trying to set up a voice bearer and the UMTS system says F you. need foods, sleep, etc... haha.
And more fun... Skyrocket UCLD2 radio returns HSPA+ connectivity on data-only SIM with Broadband APN, but no LTE. Set APN type to "supl" to enable SUPL, got the first GPS fix in about 2 minutes, after 5 more minutes found 12 sats and obtained 12m accuracy.. sweet!
Update: UCLD2 radio, after sitting around idling for 10 minutes while I made some munchies, decided it would pick up an LTE cell. No idea why it took so long, I'm really close to an LTE cell and both my other LTE devices have never (and don't presently) exhibit this behavior at my location. I suspect this is probably normal behavior of UCLD2 or UCLD2 plays less than optimally with the i957 radio... which should be the same as a skyrocket radio, considering both identify as an M8260 when inquired with "ati" via ttyACM0. Whatever the case, 50ms ping and 30 mbit down works for me...
I really should go to bed sometime...... and make a backup of this device before I bust something!
Adding a little more info: I modified device/samsung/p5att/BoardConfig.mk a little before building... Other devices with no SD card slot had BOARD_HAS_SD_CARD_INTERNAL defined, so i tossed that in. The BOARD_SDCARD_DEVICE_PRIMARY, BOARD_SDCARD_DEVICE_SECONDARY and BOARD_SDEXT_DEVICE_SDEXT values seemed bogus, and I knew the init scripts would set up /sdcard as a fuse device on the /data partition anyways, so I just commented them out.
I don't know if anything uses the 3 values I commented out, but since there's no actual mmcblk device for the fuse (filesystem in user space) emulated sdcard, it doesn't seem a valid value could be found, so, why set one.... Seems to work!
BOARD_HAS_SDCARD_INTERNAL := true
#BOARD_SDCARD_DEVICE_PRIMARY := /dev/block/mmcblk1p1
#BOARD_SDCARD_DEVICE_SECONDARY := /dev/block/mmcblk0p28
#BOARD_SDEXT_DEVICE := /dev/block/mmcblk1p2
Click to expand...
Click to collapse
But, this is my first attempt at hacking cyanogenmod onto a half-baked device, so... don't take my word for it
And before anyone asks, yes, I plan on releasing a flashable update for this, but first... figuring out enough to start from a fresh source tree and build from scratch so I can document how I did this... Let's beat the carriers to jellybean and forget ICS
(yes, I'm editing this post a bazillion times as try stuff, I'll put together something a little more coherent soon)

[Q] How much open is Android on LG Optimus 4X HD?

The title may look weird but that's the best sentence I could find to summarize my question.
One of the myths about mobile phones is that they have back doors for the secret services or goverments to tap into and listen to phone calls or SMS messages. This was something we could never be sure about at the old days of Nokia (R.I.P.) "black box" phones.
I've been developing software for more than 20 years but my experience with Android is only 10 months and I've not dived into the big sea of custom ROMs and kernels yet.
My question is simple. How much of custom ROMs and kernels on this device (or any other Android phone) are open source and is it "much" enough to be sure that there is no back door or hidden function?
I would be grateful if ROM and kernel experts can answer this question.

well, honestly this Q sounds a bit strange, but here we go:
1) kernel:
all kernels MUST be 100% open source.
2) device tree
also the device tree has to be open source, just like the kernels
3) ROM
ROMs do not have to be open source. but nearly all (except stock based) custom ROMs for our device are open sourced. otherwise we wouldn't be able to compile them
a special topic are stock ROMs.... i have never seen an open sourced stock ROM from any manufacturer (except google ofc).
now, back doors:
i never heard of a rumor that custom ROMs would have back doors. actually we are working on finding unknown (unwanted) backdoors to fix them.
But for stock ROMs, i personally wouldn't be too sure there is no back door...
Backdoor or not, big agencies (like the NSA for example) do not need backdoors to your phone, they have way more capabilities/possibilities
So it's quite useless thinking about it IMO, as you cannot change anything about it

postacik said:
My question is simple. How much of custom ROMs and kernels on this device (or any other Android phone) are open source and is it "much" enough to be sure that there is no back door or hidden function?
Click to expand...
Click to collapse
Short answer: Not enough.
Longer answer: The kernel and some custom ROMS are open source, but many of the drivers (which operate at root level) remain closed. It should also be plausible to hard-code additional functionality into the hardware of a phone.

The thing that gets the least scrutiny is baseband since it runs on custom hardware. Even with closed source drivers it's arm code running on Linux so lots of people can understand it.
ROMs and kernels aren't really an issue though.

[Q] AOSP LYZ28E & Wi-Fi Calling Issue

I need help to figure out how to get Wi-Fi calling to work on AOSP LYZ28E on Nexus 6 and T-Mobile.
I have built many ROMs with AOSP source code from 5.1 on up and have encountered problems with sound & video not working properly with pure source code. I've always been able to find the solutions here on XDA.
With LYZ28E for Nexus 6, a straight build using pure AOSP source code (using repo init, repo sync & make with no additional code) I can't even get a ROM built that has working data on cellular signal.
Straight out of the box on this build, there is no cellular data signal, volume fades, video doesn't work, VoLTE doesn't work & Wi-Fi Calling doesn't work, even though the settings are there.
I've found the solutions for everything except for Wi-Fi Calling. My ROM has a few features added in including Battery & Notification lights, resizable nav bar and battery percentage text, and the sound, video & VoLTE works.
But for the life of me I can't get Wi-Fi calling to work. It works in my house on the factory image so I know it's not a problem with my location or infrastructure settings.
I've looked through the few ROMs here on XDA to compare my code with their Wi-Fi Calling commits, and I can't see any differences. I know I'm missing something, but I can't find it and don't know exactly where to find it. Google searches don't bring up anything useful.
I'm hoping someone here can help point me in the right direction or give me some clues on where to look. I've attached some screen shots of my settings & APN.
I truly appreciate any help you kind folks can provide.
Thanks

from what ive read around, you need to have an edited kernel, with the proper edits, to get wifi calling to work on aosp. what are the edits, i dont know, but it needs to be done. you can look at chroma roms source code to look what was done to get wifi calling to work.

Thanks simms, I saw ZephiK had some kennel work in his Git, so I'll look into that and see what I can do from there.
Thank you very much for the tip!

good luck!

Thanks I'm going to download his kernel source and try to figure out if I can stick it into my files and see if it builds or if I need to compile it separately or whatever needs to be done haha
I'll update this thread with the results...
Onward and upwards
EDIT: I managed to finally get wifi calling to work on my rom, thanks to Pure Nexus ROM source. It turns out the AOSP stock kernel does enable wfc out of the box. There's just a lot of proprietary vendor files I didn't have that I obtained from the Pure Nexus source.
So, yeah, finally got everything working on my rom that I want

With the release of an unofficial CM 13 build for most s5 models, Wi-Fi calling.

Simply put, the new unofficial build of CM 13 for the s5 is amazing. I didn't know the s5 could be that smooth. However I am locked back to a stock rom just to keep wifi calling. http://forum.xda-developers.com/galaxy-s5/unified-development/rom-cyanogenmod-13-0-android-6-0-t3237502
Now the word on the street was we would get it http://www.tmonews.com/2015/10/cyanogenmod-13-android-rom-will-have-t-mobile-wi-fi-calling-support/
However, after that one picture leaked. Not a single word was said again about the mater. Now I can assume the feature hasn't entirely made it over to our rom, or that implementation is on a more per device basis. (device specific codes). Either way, I don't want to wait till April just to be let down by another buggy official rom.

So many voip programs, why depend on build in one?