BGS5: ATH first RING and ignore further 'outdated' RING URCs from same call? | Thales IoT Developer Community

Hello,

i'm want my java application to do some action (once) on first RING and then ATH the connection.
The problem is that on BGS5 ATCommandListener ATEvent (that handles CLIP/RING URCs) is called multiple ***** consequently (in different threads), even if i issue ATH command to the call. It is called multiple ***** if execution was delayed for some reason (for example it is delayed most ***** at first start of midlet, or if stdout is set to file, or during issuing ATH command).

Here is my sample code below

public void ATEvent(String Event) {
       Logger.log("AT Event start");
      if (Event.indexOf("+CRING:")>0) {
         Logger.log("RING");
      }     
         if (Event.indexOf("+CLIP:")>0) {                                
            Logger.log("CLIP");
            .......
               try {                 
                  Logger.log("sending ATH...");
                  String res = atCommand.send("ATH\r");
                   Logger.log("result = "+res);
                   Logger.log("sent.");
               } catch (IllegalStateException e) {
                     Logger.log("Exception");
               } catch (IllegalArgumentException e) {
                     Logger.log("Exception");
               } catch (ATCommandFailedException e) {
                     Logger.log("Exception");
               }
              
         }
         Logger.log("AT Event finished");
   }

and output:
06:12:59Thread-14 : AT Event start                 <- RING urc
06:12:59Thread-14 : RING
06:12:59Thread-14 : AT Event finished
06:12:59Thread-19 : AT Event start                 <- CLIP urc
06:12:59Thread-19 : CLIP
06:13:00Thread-19 : sending ATH...
06:13:05Thread-19 : result = ATH
OK

06:13:05Thread-19 : sent.
06:13:05Thread-19 : AT Event finished      
06:13:05Thread-35 : AT Event start               <- RING urc ??
06:13:05Thread-35 : RING
06:13:05Thread-35 : AT Event finished
06:13:05Thread-37 : AT Event start               <- CLIP urc ??
06:13:05Thread-37 : CLIP
06:13:05Thread-37 : sending ATH...
06:13:06Thread-37 : result = ATH
OK

06:13:06Thread-37 : sent.
06:13:06Thread-37 : AT Event finished

I am not expecting second ring and clip events. If execution is delayed more, then i can receive much more 'outdated' ring and clip events from same call which is already finished. What is the best practice to ignore second and further 'outdated' ring urcs from same call?
On Tc65i there were no such problems..