ADL Call Service - Missing Call Clearing Events?

Legacy Open AT
1

When a call is cleared with AT+CHLD=1x, no events at all are given to the Call Service Event Handler.

See also: https://forum.sierrawireless.com/t/adl-call-service-missing-adl-call-event-new-id-event/4904/1

2

None of the ADL_CALL_EVENT_ events includes the Call-ID apart from NEW_ID and RELEASE_ID, and NEW_ID doesn’t always happen anyhow: https://forum.sierrawireless.com/t/adl-call-service-missing-adl-call-event-new-id-event/4904/1

So how is one supposed to associate the events with the appropriate call in multiparty?

There is no API provided to release a specific Call-ID - and using AT+CHLD=1x “manually” doesn’t notify any events at all to the ADL Call Service: https://forum.sierrawireless.com/t/adl-call-service-missing-call-clearing-events/4930/1

3

Notes:

When ATH is issued, it clears all calls - and events are given to the Call Service Event Handler.

Calling adl_callHangup() is equivalent to issuing ATH.

4

We found that sometimes call end event is not passed to the application after adl_callHangup(). Issue was raised with Sierra Wireless and I have test build from them 2 days ago where problem seem to be fixed. Waiting for response from them if this fix will make it into new 7.45 release.
Most noticeable on 3G modules (Q26ex, FXT-003) running R7.44 firmware.

Please note that issue is intermittent and we could not reproduce it in stand-alone application. We had to collect lots of internal logs as instructed by SiWi to allow them to get to the bottom of it.

Our current solution – when we make or terminate the call, we start 10s timer. Once a call control event comes in, timer is stopped. if no call control events arrive, timer will expire and we will reset the module.

Hope it helps.

Rudolf

5

Likewise for AT+WATH.

This ADL Call Service seems to have more holes in it than a holey thing that’s been through an Iron Maiden, subject to an over-zealous firing squad, and laid to rest on a bed of nails :exclamation: :unamused: