Process eSIM notifications after profile operations per SGP.22 spec#38241
Process eSIM notifications after profile operations per SGP.22 spec#38241fangli wants to merge 2 commits into
Conversation
fangli
changed the title
Process replay diff reportReplays driving segments through this PR and compares the behavior to master. ✅ 0 changed, 66 passed, 0 errors |
fangli
changed the title
fangli
force-pushed
the
esim-process-notifications
branch
from
96af772 to
70e4547
Compare
fangli
changed the title
…tions Added comment to clarify the purpose of the sleep.
|
I have verified the PR on my comma 4 device manually. Since I don't have comma 3, comma 3 is not manually verified. |
| try: | ||
| operation() | ||
| finally: | ||
| time.sleep(1) # Need to wait for 1s after the operation is finished so the eUICC/modem can settle down. |
There was a problem hiding this comment.
can't we check some status? we should never have indiscriminate sleeps like this, especially for so long
|
@greatgitsby any other comments? |
|
Downloading/deleting have no problem without sleep. However, according to my test, the notification processing will hit It turns out that the switch operation returns before the APDU is ready. A better solution would be re-attempt processing notification every xx milliseconds until X second timeout (which is a bit overengineering and unnecessary IMHO). The best approach would be ensuring switch operation doesn't return until the switch complete and APDU fully ready - but is this possible in terms of a clean design/implementation? I doubt it. The current PR made a tradeoff between complexity and reliability, considering how frequent the esim.py will be used in real scenarios. But please suggest if you prefer different flavors. |
|
notifications are per spec best effort. we can rip out this behavior from the critical path and have a daemon in modem.py handle async notif procesing. we get 1) perf improvements and 2) better reliability in this path if notif fails |
3 participants
Summary
Process pending eSIM notifications after profile-changing operations and send the correct pending notification payload to the SM-DP+.
Without this PR, the pending notification will accumulate on the eUICC, and lead to inconsistency between the eUICC and SM-DP+ server.
Why
GSMA SGP.22 defines notification handling as part of the consumer RSP flow. Profile operations such as install, enable/disable, and delete can leave pending notifications on the eUICC that should be delivered to the notification receiver using ES9+
HandleNotification, then removed from the eUICC with ES10bNotificationSent/RemoveNotificationFromList.This matters especially after profile download failures and profile switches. The eUICC can generate pending notifications for install results and profile management operations. Leaving those queued can confuse later eSIM operations and carrier-side state.
References:
Changes
download,switch, and confirmeddelete, attempt to process pending eSIM notifications.Testing
0.0/0.0.0 - Unknown error.BF37Profile Installation Result TLV was accepted with HTTP 204.0x30pending notification object, which was accepted byHandleNotificationand removed successfully withNotificationSent.APDU failed with SW=6881or see no notifications yet, so this adds a short settle delay before the best-effort notification pass.