samsung ims implementation efforts

[martinetd]

(Related, but hopeless #2061 #2043 - sorry for reopening a new issue, I think it's better to start fresh)

Current Behavior:

known problem of volte not working on samsung device (commercially "A21", Japanese SCV49 model which has an 7884B if that matters)

... not bothering with the rest of the report template, as I don't feel it fits, sorry.

Additional context

So, after a week spent looking at this, all I could find on the internet is that "it is hard": no resources whatsover on what's been attempted, (obviously) no-one claiming they were successful, no idea if there are efforts in progress.

From what I could see samsung's implementation hasn't changed much in the last three years (from an old reddit comment), so if it were easy I'm sure it'd be done by now, but that's not a reason not to try for myself...

Could we please document this a bit?

• If there already are resources somewhere, I'm sorry. Please point me to it and I'll help! :)
• If there aren't I might as well start here as a token of good faith.

From what I can see, the samsung stock rom has something split into three.

imsd

(I replaced 'imsd' with a script that does strace -f -o xxx imsd.orig on the stock rom instead to debug)

• there's an imsd daemon that listen to /dev/socket/imsd, and sometimes handles requests from com.sec.imsservice to create an ipsec tunnel.

• A request looks like this: ipsec add 98755 98756 4022879052 341444836 6101 6100 7807 7777 null hmac-sha-1-96 <redacted 32 hex digits> ipv6 2001:<redacted> 2001:<redacted>\0, and seems to only happen once on first call made? at least airplane mode/out and new call didn't get a new one.

• When received, imsd creates a new AF_KEY socket and does stuff on it. There are helpful messages sent to /dev/socket/logdw along the way:

  4152  22:26:28.811483 writev(3, [{iov_base="\08\20\204-qbVHY0", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="Create Socket:9\0", iov_len=16}], 4) = 43
  4152  22:26:28.812496 writev(3, [{iov_base="\08\20\204-qb\t\356g0", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="Add reqID:1\0", iov_len=12}], 4) = 39
  4152  22:26:28.824215 writev(3, [{iov_base="\08\20\204-qb\356\323\0071", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="recv PFKEY sadb_msg_errno: 0\0", iov_len=29}], 4) = 56
  4152  22:26:28.826003 writev(3, [{iov_base="\08\20\204-qbw\232.1", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="Add reqID:2\0", iov_len=12}], 4) = 39
  4152  22:26:28.828589 writev(3, [{iov_base="\08\20\204-qb+\223T1", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="recv PFKEY sadb_msg_errno: 0\0", iov_len=29}], 4) = 56
  4152  22:26:28.830209 writev(3, [{iov_base="\08\20\204-qb\375\fr1", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="Add reqID:3\0", iov_len=12}], 4) = 39
  4152  22:26:28.833832 writev(3, [{iov_base="\08\20\204-qb\260\266\2511", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="recv PFKEY sadb_msg_errno: 0\0", iov_len=29}], 4) = 56
  4152  22:26:28.836608 writev(3, [{iov_base="\08\20\204-qb\345\263\2771", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="Add reqID:4\0", iov_len=12}], 4) = 39
  4152  22:26:28.841464 writev(3, [{iov_base="\08\20\204-qb\334\n\0332", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="recv PFKEY sadb_msg_errno: 0\0", iov_len=29}], 4) = 56
  4152  22:26:28.841948 writev(3, [{iov_base="\08\20\204-qb\3621-2", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="Add encrAlgo:null, reqID:1\0", iov_len=27}], 4) = 54
  4152  22:26:28.845374 writev(3, [{iov_base="\08\20\204-qb\301\363\\2", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="recv PKEY sadb_msg_errno: 0\0", iov_len=28}], 4) = 55
  4152  22:26:28.846313 writev(3, [{iov_base="\08\20\204-qb2`i2", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="Add encrAlgo:null, reqID:2\0", iov_len=27}], 4) = 54
  4152  22:26:28.862618 writev(3, [{iov_base="\08\20\204-qb\343\1X3", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="recv PKEY sadb_msg_errno: 0\0", iov_len=28}], 4) = 55
  4152  22:26:28.865616 writev(3, [{iov_base="\08\20\204-qb\210\317\2033", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="Add encrAlgo:null, reqID:3\0", iov_len=27}], 4) = 54
  4152  22:26:28.870228 writev(3, [{iov_base="\08\20\204-qb\336\16\3333", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="recv PKEY sadb_msg_errno: 0\0", iov_len=28}], 4) = 55
  4152  22:26:28.875655 writev(3, [{iov_base="\08\20\204-qbV\263\3463", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="Add encrAlgo:null, reqID:4\0", iov_len=27}], 4) = 54
  4152  22:26:28.882324 writev(3, [{iov_base="\08\20\204-qb)\334~4", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="recv PKEY sadb_msg_errno: 0\0", iov_len=28}], 4) = 55
  4152  22:26:28.888293 writev(3, [{iov_base="\08\20\204-qb\215\341\3324", iov_len=11}, {iov_base="\3", iov_len=1}, {iov_base="IPSecInterface\0", iov_len=15}, {iov_base="Close sock fd:9\0", iov_len=16}], 4) = 43

  That's probably enough to reimplement something equivalent with a bit more investigation if that turns out to be required, for starters imsd seems to be isolated enough that it could be re-used as is for debugging/further analysis.

/system/priv-app/imsservice/imsservice.apk

I believe this is what starts and corresponds to the com.sec.imsservice process above and communicates with imsd / does whatever is required to have calls forwarded from/to phone apps.

I didn't spend long enough on, just checked that its source wasn't provided in the opensource samsung package.

/system/framework/imsmanager.jar

I've peeked at it (decompiled) and it looks like some legacy proxy to "secims" (called legacyImsManager in logs, does getsystemService("secims") and proxies to it)

Not sure if anything at all or what uses it.

/system/lib64/libsec-ims.so

This appears to be what contains references to /dev/socket/imsd and calls into it, so we probably won't be able to find too much in the apk itself regarding what kind of api or usage is expected for this.

It is compiled with symbols though so could be much worse. needs further look.

/data/com.sec.imsservice

bunch of logs and config settings from my provider (SIP server etc) can be found there, probably helpful.

In particular, I don't get text messages either with the phh rom, and I see smsip in these settings so I believe the same service handles these -- but I see nothing at all that hints on how it's used (the string "smsip" doesn't seem present in AOSP sources), more investigation required there as well...

[martinetd]

oh, and please say if you don't want any reverse engineering done publicly as it's always a mess to justify in some context (asahi linux did great work documenting their RE team writing spec and implementers being 100% separate..)

probably late to say that but better late than never. In particular I don't think we need to stick to the imsd separation, I assume it's meant to avoid leaking ipsec keys to the java processes? but in my particular case null encryption is used so err I'm not going to be someone who cares, and if we can have something more generic that works accross devices I'm all for it.

[phhusson]

So, I got fed up of trying to reverse Samsung's IMS, it was way too intricated into Android framework for my taste, so I decided to go a totally different route: re-implement IMS from scratch as opensource software. This has some issues, notably no 2G/3G roaming, but has some beautiful features like allowing VoWifi over VPN over roaming eSIM.

There is some progress about it you can see at https://github.com/phhusson/ims It is capable of logging-in into IMS server, and sending/receiving SMS. Even the code for ims over wifi is there, though the whole IMS + ePDG pipeline work exactly once (I believe because of some kernel bug, I'm not sure)

The code is super hacky, and doesn't do the integration into Android IMS framework, but I believe it does show that can be done. I have various pcap captures of the IMS communication, including voice calls, but they include private data, so I don't want to share them. But you can probably catch them with tcpdump on stock rom just fine.

[martinetd]

great! I definitely agree it's not worth doing the same way they do, I tried to willy-nilly copy a few jar arround and that didn't work well :P

I only have a single phone so I'd rather avoid too many back and forths between roms, I'll take a few more traces of the stock rom over the weekend and give it a try/build up on it.

Basically once ipsec tunnel/SIP registration is setup "all that's left" is to

• read ipsec messages and generate appropriate android IMS framework events so e.g. caller rings and one can answer (I see the parsesms code creates anandroid.telephony.SmsMessage, so presumably only calls left)
• conversely register as calling account so when user calls we can send whatever is appropriate for setup (smsManager createForSubscriptionId is enough for that? Well, I guess I can try at some point, I need to find a sms test service or something that'll bounce messages back off me... Or just ask someone)
• code cleanup (I see hardcoded imei and user agent that probably need to go) ?
• check that double registration problem if it's a problem in practice

This looks promising!

[phhusson]

Which double registration?

For code cleanup, hardcoded imei and user-agent is not exactly my first concern -_-' the code is quite literally one giant function, the generation/parsing of SIP needs to be done, well, for real.

Implementing voice is not a small task, because it requires implementing RTP (or piggy-backing on Android's SIP stack if it still exists), and connecting to audiotrack/audiorecord, encode the voice, possibly do the negotiation of codec (the carriers I've checked support PCM8. Not compressing is stupid, but well, that's an easy start)

As for another issue, is that the code hard-codes the fact that IMS is encrypted into an ipsec tunnel, but some carriers (verizon) don't, so we need to allow this case

[martinetd]

Which double registration?

Sorry, meant what you mentioned with "the whole IMS + ePDG pipeline work exactly once" -- I'm not sure what this implies if e.g. the tower changes (for my ipsec traces it seems to depend on my local and some gateway IP that might change if I travel? not sure)

Implementing voice is not a small task, because it requires implementing RTP (or piggy-backing on Android's SIP stack if it still exists), and connecting to audiotrack/audiorecord, encode the voice, possibly do the negotiation of code

ugh. lineageos removed adding sip accounts from their caller https://github.com/LineageOS/android_packages_services_Telephony/commit/912dfd8a867f3d8da5944d90a48daa8d76236b14 but I'm not sure if that means android is removing it or just lack of support, I couldn't find that bug id... Digging a bit into it it seems the android framework's sip has been deprecated, so that's probably the reason: https://android.googlesource.com/platform/frameworks/opt/net/voip/+/09c9583861bb8e6255f01fb3c595061586001358

We probably want to use anything else that already does SIP for us instead of reimplementing it; that might handle all the rest automagically if we're lucky enough? I'll give it a look as time permits.

[phhusson]

Sorry, meant what you mentioned with "the whole IMS + ePDG pipeline work exactly once" -- I'm not sure what this implies if e.g. the tower changes (for my ipsec traces it seems to depend on my local and some gateway IP that might change if I travel? not sure)

Ah ok, I see the confusion, I really didn't explain anything there. This is "just" a bug in ipsec handling in Android: to do VoWifi, you need to do IPSec in IPSec. Android's way of handling networks mean that it sets IPSec context on sockets individually, rather than whole IP ranges. When doing IPSec over IPSec, if I remember correctly it does work, but it works exactly once, and then I need to reboot, to clear kernel's IPSec state.

Anyway this is really just for VoWifi, which isn't a priority

We probably want to use anything else that already does SIP for us instead of reimplementing it; that might handle all the rest automagically if we're lucky enough?

Right, so yet another thing I forgot to mention. I already managed to do full software IMS call (hence I'm pretty convinced it should work), this is using https://github.com/phhusson/doubango - that's an opensource IMS stack in C (nano readme at https://github.com/phhusson/doubango/blob/master/README-phh). I ran it on my computer (with some tweaks to read SIM card infos from the connected smartphone over ADB), and it can make calls (I didn't actually do a call because of broken OSS, but everything I've seen looked ok except the very last step of opening audio device). (The readme-phh mentions how to setup the VoWifi tunnel, and the ims is done inside this VoWifi tunnel, which means that the smartphone is used exclusively for SIM-card access, and not for data connection)

This stack can compile to Android, and there is already a demo app for it https://github.com/phhusson/imsdroid/ However, it is usable only as a dumb SIP client, it doesn't do the IPSec and the SIM-card security challenges on Android (again, since I managed to run it from my computer the feature is available it """just""" requires to integrate doubango's ipsec handling and SIM challenges with Android's API).

Now, using this doubango IMS/SIP stack is indeed a possibility, but I don't really like it. Doubango can either be integrated as a system service or as an app. If it's integrated as a system service, then we need to define all the API to communicate with it, AIDL, connect it to binder, register it to services, declare its selinux policy, etc. That's pretty painful (BUT it would allow us to bypass Android's annoying IPSec API, sooooo that's kinda good) and we need to find out how to forward audio to/from this service into Android framework. Or we can integrate doubango into an app, in which case audio handling is easier (though still requires piles of JNI), access to SIM card challenges as well, but connecting IPSec API gets hard.

Doubango is no longer maintained, since 4 years ago. I already had to hack it at some places to fix IMS support, and I'm afraid that scaling to more devices/carriers will be pretty hard because of the ""object"" C code base.

Doubango is the only opensource IMS implementation I'm aware of. It is possible to use SIP libraries instead, but then changes in those libraries will be required since they don't implement IMS, and at that point, I feel like I prefer rewriting the code on my own.

[martinetd]

[ipsec in ipsec setup]

Ok, I had misunderstood; I thought simple ipsec setup only worked once which seemed odd.

Anyway this is really just for VoWifi, which isn't a priority

Agreed, my local carrier doesn't even seem to support VoWifi (at least with the stock rom the option is off)... Although I guess now I think about it, if that works I could use my French SIM again through a VPN instead of some shady SIP account that doesn't connect to $bank half the time... sosh does seem to support vowifi... Well, that's for later anyway, my priority is to get rid of new phone's stock rom for now.

doubango

hmm yeah I don't feel great trying to integrate such a big unmaintained service... I'd rather not reinvent the wheel (reimplementing SIP with all kind of codecs etc sounds like a pain we don't need to go through), but I can see where you come from. Let me have a fresh look and I'll come back to you here before implementing anything more than basic tests anyway. For a v0 just writing a notification that "'somenumber' tried to call!" would probably be enough for me...

And thanks for taking the time to answer and move this forward!

[phhusson]

Although I guess now I think about it, if that works I could use my French SIM again through a VPN instead of some shady SIP account that doesn't connect to $bank half the time... sosh does seem to support vowifi... Well, that's for later anyway, my priority is to get rid of new phone's stock rom for now.

Sosh is annoying because they whitelist devices, I'm still not sure based on what... Also they whitelist devices in a very weird way: Once a SIM is whitelisted by puting it into an approved device, the SIM remains valid for volte/vowifi for 7 days.

Anyway, if I remember correctly, on Sosh when you're not whitelisted, you don't even get an IMS data connection. So you can check that easily, click "create IMS APN" and check "Request IMS network", then reboot, and see if you see two data connection (one internet and one ims) in ip address

I'd rather not reinvent the wheel (reimplementing SIP with all kind of codecs etc sounds like a pain we don't need to go through), but I can see where you come from.

Well, with regards to codecs, the carrier I checked (SFR and bouygues IIRC?), PCM is supported, so no worries. And then, "later", I'd like to support EVS, which I'm pretty sure no SIP client support, sooo

Let me have a fresh look and I'll come back to you here before implementing anything more than basic tests anyway. For a v0 just writing a notification that "'somenumber' tried to call!" would probably be enough for me...

Well, that's totally doable. Run https://github.com/phhusson/ims, ensure you managed to auth (on bouygues I need 3/4 tries to succeed, I have no idea why... I haven't tested on Orange much so I'm not sure), then call your number, and in logcat you should see the incoming SIP requests that tells you you're receiving a call.

With regards to SMS support, there is one "major" thing missing that I recall: when receiving an SMS, we need to ACK it to the network by sending a ACK SMS (and I'm not speaking of ACK as seen from user's point of view, it's really to the network). This is the same ACK as SMS over GSM (I didn't keep that specification...). Without that ACK, the SMS is sent over IMS, then the network sends it back out-of-IMS ("LTE NAS")

[martinetd]

(Just to be clear I'm not using sosh right now -- currently in Japan with UQ mobile as mvno. I'll try sosh through roaming later eventually if you'd like but I've never used volte at all with it back in France and SIM might not be compatible, and my old phone certainly isn't. I'll focus on UQ for now)

Follows mostly notes for myself, describing connection process with stock rom and highlighting differences I noticed between the that and what your test app does.

• imsservice sends first SIP REGISTER message in plain text, not in any ike session that I can see
  • unlike your app, all messages are sent in UDP; I've just tried your app as tcp and while the connection does open the register gets no response, and connection closes after 30s. Didn't try sending UDP manually yet will do tomorrow, everything that follows is from rom traces and code inspection
  • Security-Client: ipsec-3gpp;prot=esp;mod=trans;spi-c=45597;spi-s=45598;port-c=6101;port-s=6100;alg=hmac-md5-96;ealg=null, ipsec-3gpp;prot=esp;mod=trans;spi-c=45597;spi-s=45598;port-c=6101;port-s=6100;alg=hmac-sha-1-96;ealg=null (not sure why it's repeated twice, bug? but means the client already knows what algorithm to use for ipsec for this provider so we'd need to make a mapping for each mnc/mcc ? :| Although you seem to also be setting ealg=null despite having a valid ike?)
  • This and all following client messages include P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=<censored>, not sure if that is required or just informational; I'll try to skip it.
• response from carrier rejected (401 unauthorized) at this point
  • fills in WWW-Authenticate digest nonce for client next attempt
  • Security-Server: ipsec-3gpp;q=0.5;alg=hmac-sha-1-96;prot=esp;mod=trans;ealg=null;spi-c=2290866870;spi-s=3511130986;port-c=7807;port-s=7777
• imsd does some AF_KEY socket operations to setup the tunnel.
  • I see absolutely no ike handshake on tcpdump anywhere (-i any from phone), not sure if they happen through the modem somewhere I can't dump, if the handshake through the SIP exchanges was enough (spi-c/spi-s on each side) or if null encryption means it's optional?
  • comparing with the code, android.net.ipsec.ike that you're using doesn't have any ENCRYPTION_ALGORITHM_NONE or NULL that might fit the bill for my null ESP...
  • imsservice sends second SIP REGISTER, over ESP encapsulation.
  • digest nonce/challenge filled presumably with the SIM like you do, I couldn't trace how that's done in imsservice process... will find out when I try to reproduce tomorrow
  • There's an extra Security-Verify: ipsec-3gpp;q=0.5;alg=hmac-sha-1-96;prot=esp;mod=trans;ealg=null;spi-c=2290866870;spi-s=3511130986;port-c=7807;port-s=7777 along with the same Security-Client that was in first message
  • rest looks identical to first message to me aside of being encapsulated in ESP and port being different, this is still UDP.
• REGISTER is ok'd, follows a SUBSCRIBE (ok) then NOTIFY (also ok). You don't seem to bother with NOTIFY in your test app, not sure if it's useful at this point.

[martinetd]

Following up:

• I'm not sure on the tunnel, but I assume the messages sent in SIP are just enough for the ESP setup. This all works in your code with my carrier as well (after adjusting to use UDP, but I haven't checked if TCP wouldn't just work if used, that can be checked again later when we clean up code as it's a pain to change in all places correctly now). That's a pretty nice start!
• Question here if you know, I couldn't get the UDP packet to actually be sent on the right interface (rmnet1 in my case), I had to manually run ip -6 route add <pcscf>/128 dev rmnet1 table local to get it to work :/ Does it just work in the TCP case? I'm binding the DatagramSocket on myAddr (local address in the tunnel), and this part works as it's sending the packet with the tunnel source address anyway.. but without ip route adjusment it's sent over plain data apn or even wifi with a source address these networks don't know anything about so it's not quite likely to make it... Carrying on with workaround for now.
• I've spent almost 2 hours getting forbidden on the 2nd register, but after finding we weren't reusing the same callId as we should have been (along with many minor adjustments that probably weren't needed playing seven differences...) I've finally got a 200 OK (REGISTER)! :tada:
• on UDP the reply doesn't come back on the same port (using our portC/their portS to send, coming back from their portC to our portS) and I can't get this right in kotlin right now so can't continue after register (confirmed the OK through tcpdump), but at least there's progress. I'll probably get a kludgy text message implementation working over the next few days and can start thinking of what's next...

So, assuming I solve my two problems quickly (sending over right interface, actually receiving data back); how would you want to move forward? cleanup/breakdown our MainActivity.kt into a more flexible thing that can accommodate tcp/udp and various encryptions, so first split out some basic SIP sending wrapper/parsing (callbacks?) when we receive messages? I'm still extremely reluctant to implement the voice part (and honestly didn't take enough traces of when my phone was running the stock rom so I guess I'll be set to reflash it again...), but I can help lay foundations if you're willing to review... With a fair warning I'm a C dev so my kotlin might not look very natural at first.

[phhusson]

unlike your app, all messages are sent in UDP; I've just tried your app as tcp and while the connection does open the register gets no response, and connection closes after 30s. Didn't try sending UDP manually yet will do tomorrow, everything that follows is from rom traces and code inspection

Yeah that's indeed a discrepancy I saw too. I think I chose TCP based on traces I did with doubango, which defaults to TCP, but all other traces I've done were UDP. IMO UDP is more annoying to deal with, so if TCP works, I'd rather stick with it, but it's indeed something worth keeping in mind when possibly hitting carrier compatibiltiy issue.

not sure why it's repeated twice, bug? but means the client already knows what algorithm to use for ipsec for this provider so we'd need to make a mapping for each mnc/mcc ?

Theorically, that string can contain several crypto combos, and server answers which one to take. In practice, I've seen unhappy carriers already, so yes, the big mnc/mcc mapping will be required...

I see absolutely no ike handshake on tcpdump anywhere (-i any from phone), not sure if they happen through the modem somewhere I can't dump, if the handshake through the SIP exchanges was enough (spi-c/spi-s on each side) or if null encryption means it's optional?

Yes, there is no IKE. IKE is used only for ePDG (VoWifi). On mobile connectivity, IKE is replaced with SIP negotiation security-server/security-client/security-verify

digest nonce/challenge filled presumably with the SIM like you do, I couldn't trace how that's done in imsservice process... will find out when I try to reproduce tomorrow

You can see the computation for that in my code, but it's pretty much:

• extract the base64 payload sent by the SIP server
• send it to the sim
• send the sim's anwer back to the server ( + compute SIP digest + compute ESP keys which is more annoying)

REGISTER is ok'd, follows a SUBSCRIBE (ok) then NOTIFY (also ok). You don't seem to bother with NOTIFY in your test app, not sure if it's useful at this point.

Welp, i already forgot about it. It's an outgoing NOTIFY, not incoming? What does it contain? Maybe it's SIP's "presence" part, where we notify the server that the user is "available"?

This all works in your code with my carrier as well

Yay \o/ Please do test TCP, I'd like to postpone that part of refactor as much as possible...

Question here if you know, I couldn't get the UDP packet to actually be sent on the right interface (rmnet1 in my case),

This is Android's magical mess for network, you can have each socket routed independently. In my case, I do network.bindSocket(serverSocketFd) so this socket is on the "ims" network rather than "internet" network. That API is pretty annoying to debug and use, because as you mention you need to bind on an IP, but then ALSO on a network, and then you need to bind the IPsec configuration, and you need to do it in the exact order to make everyone happy, etc... It took me many tries before getting my current working state (which doesn't really include ePDG).

I've spent almost 2 hours getting forbidden on the 2nd register, but after finding we weren't reusing the same callId as we should have been (along with many minor adjustments that probably weren't needed playing seven differences...) I've finally got a 200 OK (REGISTER)! tada

Ah. Oh. Thanks. Gotta admit, my learning of SIP is 95% checking captures so that kind of stuff got over my head.

on UDP the reply doesn't come back on the same port (using our portC/their portS to send, coming back from their portC to our portS) and I can't get this right in kotlin right now so can't continue after register (confirmed the OK through tcpdump), but at least there's progress. I'll probably get a kludgy text message implementation working over the next few days and can start thinking of what's next...

You mean you do see that the answer comes from their portC back to our portS in the trace, and it's that socket that you haven't got to work yet, right? Sounds like yet another reason to prefer TCP (and another reason UDP refactor will be horrible...)

cleanup/breakdown our MainActivity.kt into a more flexible thing that can accommodate tcp/udp and various encryptions, so first split out some basic SIP sending wrapper/parsing (callbacks?) when we receive messages? I'm still extremely reluctant to implement the voice part (and honestly didn't take enough traces of when my phone was running the stock rom so I guess I'll be set to reflash it again...), but I can help lay foundations if you're willing to review... With a fair warning I'm a C dev so my kotlin might not look very natural at first.

I don't have strong opinions on the order of refactoring things. I'd start with a SIP message parser that reads from the fd and outputs a class SipAnswer(returncode, map<string,string> headers,ByteArray data) and use it everywhere rather than my beautiful (not) regexes, then the reciprocal to send SipRequests, After that, it depends on whether you want to implement UDP. If that's the case, you'll need to make message queues to have sync-ish request/answer, and then put every kind of request in its own nice and tidy function. Except for refactoring, something that would be useful is to have the app expose settings, and actual "send sms" button, so that users can test on their own device and carrier.

With regards voice, I'll probably take a look on my own if you don't move too fast, but I think there is plenty of things to do.

[martinetd]

TCP/UDP

Well, it's a bit more annoying because it's a different way of thinking but deep down there's only a single difference (that is replies don't come on the same socket we sent stuff to), I don't think it's that much worse once bugs are fixed. tcp also has its complexity that you need to spawn threads to accept new connexions which isn't needed at all on UDP (replies matched with CSeq), and UDP doesn't need regular keepalives so is better for battery; I'd also just rather stick with the same as traces I see if I can get it to work (but I will test TCP for development, if it doesn't work it'll be a pain)

NOTIFY

Sorry you're correct it came from carrier, and we need to ok it.

Ah. Oh. Thanks. Gotta admit, my learning of SIP is 95% checking captures so that kind of stuff got over my head.

Same here and it's also why I think it would have been worth using a lib -- this is all fairly well standardized from what I can see, even the security stuff in there, so we'll at least want to check specs. token length, cnonce length, call id format etc all seem arbitrary and are different from what you picked on my carrier and I've changed all this stuff to match before finding the callId changed, so we'll probably want to experiment and this and see just how much we need in the mnc/mcc option table...

source network and network.bind()

Ahah, I had the network.bind (only for service listen interface for you), what I was missing was the network.SocketFactory. I probably just need to make it ... network.DatagramSocketFactory or something... but that doesn't exist... oh well at least the documentation clearly states sockets made this way are sent on the right interface so this is it, I'll look a bit more. Thanks!

(EDIT: looks like I just can separate the bind out and use network.bind instead as you suggested, will test later™)

refactoring

I'm currently thinking this level of abstraction

• SipMessage (first header, map with rest of headers, content bytes array)
  • specialized into SipResponse(return code instead of first line of header, let's match terminology with https://datatracker.ietf.org/doc/html/rfc3261 here with response instead of answer);
  • request doesn't seem to need specializing except perhaps to set default headers on initialization?
• SipNetwork (TCP/UDP, client port, service port, option for VoWifi?) ; totally ignoring the fact that tcp happens on multiple sockets, they'd be aggregated in a read thread or something so API is identical... Something like:
  • send(SipMessage, optional child socket) with callback for CSeq answer to X, callback return code defines if it it kept or destroyed on use (stuff like voice (INVITE) has multiple responses to the same CSeq)
  • simpler send() with internal callback that just waits for its reply for easier use (like register -> OK/NOK doesn't need complicated callbacks exposed and can just be waiting)
  • set callback for request X (callbacks would know what child socket the message came from to reply correctly)
  • log something if no callback has been set for something we just received
• SipProtocol: higher level that use of the above network/messages, knows what kind of infos to extract from responses, and handles basic callbacks.
  • higher level init() function for network creation & register/subscribe, register appropriate notice/messages/etc callbacks
  • higher level message() function to send sms
  • higher level voice handling whatever that is (happy to let you take a look first, I'll probably take a couple of weeks for the above...)

agreed app itself could also have some more flourish to allow easier tests/logs in UI; if sms integration is done there shouldn't need to be any test in app though as just normally sending a sms should use it? but app status should be obvious and some level of error/warning logs visible from app instead of logcat... I have no idea how UI stuff works so I'm leaving it for later.

just messages can be more or less replaced in place, but since I'll have probably broken things for you by fixing it for me this is probably going to be pretty destructive e.g. first commit that stashes all my test, then progressively adding messages, using them, adding network, using it, then finally restoring tcp code... well, I'll open draft PR as soon as I start working on messages anyway and we can move discussion there; that part is what you suggested so probably won't be too bad :)

[martinetd]

Today's progress:

• I got udp to work! I was just being silly with the ike parameters, using the right SPI for the receiver socket helps... With that I've confirmed I get everything, subscribe works; I didn't try much more now i'm happy so next:
• switched back to TCP, reverted all I did except for a few modifications like properly reusing callId. This appears to mostly be working, at least up till subscribe and receiving the NOTIFY requests from the provider with no problem... Until I tried sending myself a text message and that comes over as UDP over the port-s I sent. Interestingly NOTIFY opened a tcp socket as requested so it's not like my carrier can't do it, but they're not doing it for MESSAGES: it's udp over the same ports... Ah, in the tcpdump traces I see we failed to accept the next connection, I see a few SYN with same source/dest port as the NOTIFY request that are ignored, then it fell back to udp. Do you get a different server port-c (source port for their outgoing connections) on your carrier? I think that can be worked around with SO_REUSEPORT or something...

Anyway,

• I'll get back to UDP for my own usage for now instead of trying to fix that, but
• TCP works well enough for dev purposes, so I'll just commit properly my minimal modifications then work on class abstractions with tcp initially and add udp back as a SipNetwork abstraction when I get there.

Now I'm basically clueless about kotlin, so once I've got text messages working with udp for my device it'll be a few days of reading documentation, seeing how tests can be written etc. I'll probably post here at a quite lower rate unless I need help or want your opinion on something.

[phhusson]

With regards to kotlin usage, some notes:

• please no kotlin coroutines, so far in my experience, they are excellent footguns
• I have no strong opinion of sync vs async io. Threads are cheap enough that sync is ok. In C I usually prefer async, but java.nio API is a tad annoying so I usually chose sync (as you can see in this case)
• use immutable structures as much as possible for "interfaces" (for instance, parsing a sip message can be done with mutable hashmap, but should return an immutable/read-only map)
• I prefer inter-thread communication via BlockingQueue rather than java's synchronized() methods (though I'm often lazy and end up using dirty synchronized objects). Kotlin might have other more dedicated inter-thread communication that I don't know about that could be suitable
• Take note of data class this is a very useful syntax (notably to transfer messages across threads)
• That's probably something I'll do myself reviewing your code, but functional programming-style list-handling is usually more readable than for loops

[martinetd]

Thanks for the pointers, I'm thinking synchronous IO is probably good enough as well but that can change later anyway once we have the basics down. I'll also be very happy with functional programming style, no worry about that :) I've been reading up, kotlin looks quite better than java in that respect it's a good thing...

Going back to my fishes temporarily, I've got sms working; the 200 OK we're replying in the current version didn't work for me (had to add caller id) and I also added the second ack message reply so it seems to be working well enough... But this is also lacking some kind of keepalive, and I never got traces running long enough on the stock rom so I have no idea what they were doing to keep the tunnel awake :/ Do you happen to know what that looks like or have such traces? I'd rather not go back to stock rom at this point but if I'll need to might as well do it now before I'm done finishing reconfiguring the phone...

Right now when I now a confirmation code text is coming I can turn the ims app on afterwards and still get the message so it's sort of good enough, but we're going to need to do better.

I'll get started on refactoring now anyway, will open PR for early comments in a few days even if it's not ready.

[phhusson]

I have no traces of keep alives, but it's pretty easy for me to get traces, so i'll check.

[phhusson]

Can you give me a mail address I can send you my pcap to?

[phhusson]

pcaps sent. It is made from an official Mediatek IMS stack

Some observations:

• It mixes TCP and UDP, I'm not sure I understand what's difference between both
• I see the TCP connection kept open, and its kernel-sent keep-alives
• On UDP a \r\n\r\n is sent periodically, from port 5060 to 5060. I can't make any sense of this, this doesn't seem to match a pre-existing UDP "connection"
• Every 3000s the stack re-SUBSCRIBEs?

[martinetd]

Thanks!

Direct replies:

• I've seen TCP/UDP mix as well, but this was a bit different (server decided to send me UDP packets on ports I had declared as TCP because I didn't (couldn't?) accept new connection)
• TCP: ok, this one is even weirder than UDP: It's doing keepalive on the original plain connection where the first failed register took place, so neither the one in tunnel used to send nor accepted connections from server.
• port 5060 to 5060 was used for me on initial registration, so it's kind of similar I think it doesn't really matter as long as we send either as a sort of connectivity check? if tcp is available we'll get RST so it's best to set SO_KEEPALIVE on just one connection, any is probably fine. If no tcp send the udp one that'll likely get ignored. I'm not sure we'll ever get any feedback on problem with udp (one of the problems I have atm with my udp stack is that the first reply to NOTIFY is too big so we get an icmpv6 packet too big response, but I found no way in java to actually receive this at application level to resend -- we'll need to do resends ourselves). At least it might help towers etc not forget about us?... But I don't think it's useful if we have tcp anyway.
• 2:48:15 -> 3:38:15 -> 4:28:15 looks too precise to be anything else, yes... full REGISTER>, SUBSCRIBE>, NOTIFY< dance every 3000s.

One more thing, the mediatek stack seems to never close any connection; in me.phh.ims we're polite and close sockets when we're done using them but here the re-registers re-use the same connection, and the re-notify comes back from the same previously accepted connection. I believe this behaviour would work better for my provider as closing connection was the reason I couldn't accept it again. (reusing same source/destination port messes up conntrack). Let's stop closing things.

[phhusson]

With regards to re-doing register/subscribe/notify, one thing to note is that it's not the same register as the first one. The "re-connect" register's URI is the server's Contact, also the client sends its previous P-Preferred-Identity. Call-Id remains the same, cseq is incremented. I'm not sure if you see anything else

BTW, I don't report P-Access-Network-Info (I was too lazy to find its value). So far no operator complained, but some might.

[phhusson]

Wait no that's wrong. REGISTER still does sip:ims.mnc.mcc....., but SUBSCRIBE moves from sip:phonenumber@ims.mnc.mcc.... in first SUBSCRIBE, to server's Contact in subsequent SUBSCRIBEs

[martinetd]

I'm lazy, so I've done extra work... Here's a script that uses tshark -T json / jq to output one message per file:

#!/bin/sh

error() {
    printf "%s\n" "$@" >&2
    exit 1
}

for input; do
    dir="${input%.pcap}"
    [ "$dir" = "$input" ] && error "$input expected to end in pcap"
    [ -e "$dir" ] && continue
    mkdir "$dir"
    tshark -r "$input" -V -T json |
        ./jq-script -c |
        while read -r json; do
            file=$(echo "$json" | jq -r .filename)
            echo "$file"
            echo "$json" | jq -r .sip > "$dir/$file"
        done
done

with ./jq-script:

#!/usr/bin/jq -f

.[] | ._source.layers | select(.sip) | {
    "epoch": .frame."frame.time_epoch",
    "ipv6_src": .ipv6."ipv6.src",
    "ipv6_dst": .ipv6."ipv6.dst",
    "esp_spi": .esp."esp.spi",
    "udp_srcport": .udp."udp.srcport",
    "udp_dstport": .udp."udp.dstport", 
    "tcp_srcport": .tcp."tcp.srcport",
    "tcp_dstport": .tcp."tcp.dstport", 
    "sip_firstline": (.sip."sip.Request-Line" + .sip."sip.Status-Line"),
    "sip_method": .sip."sip.Request-Line_tree"."sip.Method",
    "sip_code": .sip."sip.Status-Line_tree"."sip.Status-Code",
    "sip_cseq": .sip."sip.msg_hdr_tree"."sip.CSeq",
    "sip_msg_hdr": .sip."sip.msg_hdr",
    "sip_body": (if .raw_sip."raw_sip.line" != "  " then .raw_sip."raw_sip.line" else null end)
} |
{
    "filename": (.epoch + "_" + (.sip_cseq | gsub(" "; "_")) + "_" +
        (if .sip_method then
            .sip_method
        else
            .sip_code
        end) + 
        "_" + .ipv6_src + "_" + .ipv6_dst +
        (if .esp_spi then
            "_esp_" + .esp_spi
        else null end) +
        (if .udp_srcport then
            "_udp_" + .udp_srcport + "_" + .udp_dstport
        else
            "_tcp_" + .tcp_srcport + "_" + .tcp_dstport
        end)),
    "sip": (.sip_firstline + "\r\n" + .sip_msg_hdr + .sip_body)
}

It's very ugly, but it does the job, and I can just diff *_1_REGISTER_REGISTER* with *_2_REGISTER_REGISTER* or similar :-D

(who said overkill?)

Anyway, differences for REGISTER

• sequence id increased
• branch part of Via regenerated
• authorization cnonce and nc are incremented (could/probably want to just rerandom the cnonce), but challenge is the original one we received as first 401 to first failed register so we'll need to remember that for the session lifetime
• security-client sends new spi-c/spi-s but I don't see the spi changing in the esp encapsulation, so we probably want to ignore that
• P-Access-Network-Info changed, but as you said we're not sending it and I consider that a feature -- I'm sure they have the info anyway if they really want it but might as well not send it everywhere...
• second REGISTER onwards updated the port they send for Contact, but it was the port they sent in the first subscribe already so if we keep contact as a state variable and update it we'll be reusing the correct one

Difference for SUBSCRIBE:

• the first line's recipient got updated to use the contact they received in reply to the first's SUBSCRIBE -- so similarly we just need to keep track anytime we get a new Contact header and always just use the last we found?
• similarly, Route and To have been updated by intermediate messages
• for 2nd onwards, the only difference was sequence and branch randomization

Reply to NOTIFY seems straightforward as it's just copying stuff from request.

Bonus: in your trace, there was a first REGISTER with the previous session when you restarted ims? that one has Expire: 0 instead of the normal 600000s... So it actively told the server that it's going away, we might want to be polite and do the same.

All in all it doesn't look so bad. I wonder why they send such a long Expire time if they're going to re-register anyway, but we can probably mimic it...

[phhusson]

Bug seen in the wild on Vodaphone idea(VI):

If we send: Security-Client: ipsec-3gpp;prot=esp;mod=trans;spi-c=411571743;spi-s=411571744;port-c=56655;port-s=56656;ealg=null;alg=hmac-sha-1-96

SIP server answers with: Security-Server: ipsec-3gpp;q=0.92;alg=hmac-sha-1-96;mod=trans;ealg=des-ede3-cbc,ipsec-3gpp;q=0.93;alg=hmac-md5-96;mod=trans;ealg=aes-cbc,ipsec-3gpp;q=0.94;alg=hmac-sha-1-96;mod=trans;ealg=aes-cbc,ipsec-3gpp;q=0.96;alg=hmac-md5-96;mod=trans;ealg=des-ede3-cbc,ipsec-3gpp;q=0.98;alg=hmac-md5-96;mod=trans,ipsec-3gpp;q=0.99;alg=hmac-sha-1-96;mod=trans;spi-c=394082394;spi-s=395718167;port-c=6052;port-s=6060

It does contain ealg=aes-cbc in the possibilities, even though the decision is ealg=null (higher q, and only one that matches our request). However the current code just does a str.contains("aes-cbc"), which will result here in true, so we switch to aes-cbc encryption, while the server expects ealg=null

[martinetd]

I guess that means we should do the headers splitting properly in SipMessages soonish then, that'll be easy to fix if we can have it in a list properly (sortedBy { it.properties["q"]?.toFloat() } or something like that)... Probably not worth implementing a dirty fix at this point.

Are there actually people already using this app yet? (read: how much do we actually want to hurry? I said I'd just use my new types in MainActivity.kt but looking at it again I preferred to start right away with a SipNetwork/SipManager to clean it all up at the same time, but that'll probably take me the whole week -- if it's useful to just fix this I can do the switch in MainActivity first and we can get that intermediate version merged faster)

[phhusson]

I guess that means we should do the headers splitting properly in SipMessages soonish then, that'll be easy to fix if we can have it in a list properly (sortedBy { it.properties["q"]?.toFloat() } or something like that)... Probably not worth implementing a dirty fix at this point.

At the moment we're only sending one Security-Client configuration, so we can just do the .contains() on the security-client rather than the security-server, it's not like the hack takes any more time than me saying it out loud

Are there actually people already using this app yet?

Nope. I'm just having the impatient people contribute a bit by testing it on their network.

how much do we actually want to hurry?

Well people have been waiting for ims on Samsung for multiple years now, and yet they are still very impatient when I'm telling them I'm working on it, and almost angry when i tell them it will take at least one year, soo let's just ignore them, and do it at whatever pace we want.

that'll probably take me the whole week

One week is totally fine, no worries.

[phhusson]

Additionally, still on "Vodaphone idea(IV)", both sip and tel P-Associated-URI are sent on the same line, rather than two lines: 05-16 12:50:56.363 26900 26926 D PHH : IPSEC Received < P-Associated-URI: <sip:+9188YYYYXXXX@ims.mnc022.mcc404.3gppnetwork.org>,<tel:+9188YYYYXXXX>

[martinetd]

Well people have been waiting for ims on Samsung for multiple years now, and yet they are still very impatient when I'm telling them I'm working on it, and almost angry when i tell them it will take at least one year, soo let's just ignore them, and do it at whatever pace we want.

Yeah, when I was reading about it it didn't look like a new problem, yet absolutely no-one actually willing to put in any work... :/ (edit: to clarify, lots of loud voices of people complaining it doesn't work for little actual effort. I was very glad to see you started this!) Oh well, we'll get here eventually :)

both sip and tel P-Associated-URI are sent on the same line

Ok, that shouldn't make a difference in My Grand Plans -- we'll be splitting these in two items in the p-associated-uri list.

[martinetd]

With the patches I just pushed we should now be handling both 'q=' for security-server and p-associated-uri on a single line if he'd like to try

[muralivijay]

@martinetd i have i tried to implement above you said the imsd , libims-sec,and some ims services apk and its shared libs

here my commits https://github.com/muralivijay/android_device_samsung_j7elte/commit/3e01d64ccda644696fad33bb3b37a4c05683f6a5 https://github.com/muralivijay/android_device_samsung_j7elte/commit/bff322bf7985108b01e01713eb39fc6d09986537

Also shim the libims-sec.so https://github.com/muralivijay/android_device_samsung_j7elte/commit/7ca151074afa8f145460d4ca2e784d546e261e43

Also lots of framework shared javas of imsservice.apk

vsimmanager.jar, secimshttpclient.jar, EpdgManager.jar, sercsapi.jar, ssrm.jar, samsung-services.jar, org.simalliance.openmobileapi.jar ,svemanager.jar

by checking logcat . then finally end-up with missing java lib called "com.samsung.android.feature.SemCscFeature" .

E AndroidRuntime: Caused by: java.lang.ClassNotFoundException: Didn't find class "com.samsung.android.feature.SemCscFeature" on path: DexPathList[[zip file "/system/framework/imsmanager.jar", zip file "/system/framework/rcsopenapi.jar", zip file "/system/framework/EpdgManager.jar", zip file "/system/framework/secimshttpclient.jar", zip file "/system/framework/vsimmanager.jar", zip file "/system/framework/sercsapi.jar", zip file "/system/priv-app/imsservice/imsservice.apk"],nativeLibraryDirectories=[/system/priv-app/imsservice/lib/arm, /system/priv-app/imsservice/imsservice.apk!/lib/armeabi-v7a, /system/lib, /vendor/lib, /system/lib, /vendor/lib]]

i can,t find it in any frameworks. also its csc related framework. required imsservice provisoning you can find it on /system/csc/others.xml

but when run imsd in terminal here its log

j7eltexx:/ # imsd INFO | RESIP | Security.cxx:987 | BaseSecurity::BaseSecurity INFO | RESIP | Security.cxx:998 | USE_BORING_SSL Initialize TLS_method INFO | RESIP | FdPoll.cxx:881 | epollcreate INFO | RESIP:DNS | AresDns.cxx:394 | DNS initialization: using c-ares v1.10.0 INFO | RESIP:DNS | AresDns.cxx:403 | DNS initialization: found 1 name servers INFO | RESIP:DNS | AresDns.cxx:409 | name server: 127.0.0.1 INFO | RESIP | Compression.cxx:44 | COMPRESSION SUPPORT NOT COMPILED IN INFO | RESIP | Compression.cxx:47 | Compression configuration object created; algorithm = 0 INFO | RESIP:TRANSPORT | TransportSelector.cxx:100 | No compression library available INFO | RESIP:DNS | DnsUtil.cxx:170 | local hostname does not contain a domain part localhost INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: CONFIG-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: REGI-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: CALL-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: CALL-SESSION(7) INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: CALL-SESSION(8) INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: CALL-SESSION(9) INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: CALL-SESSION(20) INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: IM-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: OPTIONS-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: OUT-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: IMSSMS-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: SS-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: SUPPLEMENT-SESSION INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: ALM-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: EUC-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: KA-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: PRESENCE-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: ISH-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: XQ-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: DNS-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: VSH-MGR INFO | RESIP:TRANSACTION | TuSelector.cxx:190 | register: VZWSIPDIALOG-MGR INFO | RESIP | StackThread.cxx:31 | StackThread wait time to select:1412290717 INFO | RESIP | SipStack.cxx:265 | Shutting down sip stack 0xf6b339a8 INFO | RESIP | StackThread.cxx:33 | StackThread start to process. WARNING | RESIP | StackThread.cxx:53 | Shutting down stack thread INFO | RESIP | SipStack.cxx:208 | SipStack::~SipStack() INFO | RESIP | Security.cxx:1055 | BaseSecurity::~BaseSecurity INFO | RESIP | FdPoll.cxx:642 | delPollItem fd=8 CRIT | RESIP | FdPoll.cxx:551 | FdPollItem idx=12 not deleted prior to destruction

if the imssevice.apk will not crash when ims will work in samsung . i think

[martinetd]

if the imssevice.apk will not crash when ims will work in samsung . i think

Yes, samsung has just been doing too many changes to android itself to accomodate their service -- we stopped this approach.

We (well, mostly phh) have SIP registration working on https://github.com/phhusson/ims and I'm working on cleaning this up right now -- there isn't much beyond registration (you can get text messages immediately after registering, no voice) but once the base is solid the plan is to finish making SMS work and then start with voice. It'll take a while longer but I think time would be better spent on this than trying to copy what samsung did, if you can program a bit please give https://github.com/phhusson/ims/pull/1 a review and test :)

My next step is adding a new layer to handle some of the network steps (initial setup, keepalives and some sort of generic request/response API to hide tcp/udp differences), but if you'd like to actually do something there is plenty to do that could be done in parallel:

• integrate SMS with android proper so you can receive/send them in text app (can SmsManager allow that or do we actually need to look further?)
• add some kind of better UI to allow interacting with the app for further debugging
• similarly to SMS try to see how to hook into the calling system, how does one provide a calling backend for the phone app?
• (I wouldn't recommend trying the SIP side of calls until I have the network layer done, but there's also plenty to test in that regard)

[muralivijay]

@martinetd I Have tried your refactor branch and main . both are stuck at requesting Ims network . how to fix it ? my network is jio and Vi

[martinetd]

@muralivijay please open an issue in ims repo with logcat messages (grep PHH); that means the APN cannot be setup but there might be infos why in there.