what are you actually trying to accomplish? Maybe AGI is the wrong approach.
I am trying to deal with mobile phones running SIP clients. The basic problem is that SIP clients on mobile phones are not quite like SIP clients on computers or hard-phones. SIP clients on mobile phones, like any app on a mobile phone are subject to the operating system judging the process as being unused and killing it. Of course when that happens, any SIP registration that SIP client had is dead.
So how does such a killed SIP client respond to an
INVITE for example? Well, there is a concept on mobile O/Ses of being able to re-start a previously killed app called push notification. A message is sent from a server to a mobile phone telling it that it should start up a given app and give it a message, to which the app responds however it wants.
So in the case of a SIP client on a mobile device, the SIP server that wants to send it an
INVITE first has to check if the client is still connected (i.e. has an open TCP socket for example). If it is, it can just send a SIP message (
INVITE for example) as if it were a regular device. If there is no open socket though, then the mobile O/S has killed the client and now the SIP server has to send a push notification to the mobile device. The SIP server then has to wait for the client to be started (by the mobile O/S) and re-
REGISTER so the SIP server. Once the registration has been done, the SIP server can send a SIP
This process of sending a push to the point of being able to send an
INVITE only takes a small number of seconds so it’s pretty workable. Assuming the device is on and willing to respond. But what if a user has turned their phone off? The SIP server ends up timing out waiting for a SIP
REGISTER. No big deal. Such a device just doesn’t get an SIP
INVITE and the caller is routed to the regular “no answer” path.
That’s how voice is covered. But SIP also allows for
MESSAGE, which SIP servers and soft-clients can use to implement SMS. So the above process all works the same for
MESSAGE as it does
INVITE. If a mobile client has been killed, the SIP server has to wait for it to wake up and
REGISTER before it can send the SIP
MESSAGE, which again can happen within a small number of seconds, but can be longer or can even time out. Due to the non-realtime aspect of messaging, a SIP server might want to set a timeout for a soft-client to
REGISTER for a
MESSAGE to a relatively long time. Say 10, 30 or even 60 seconds to increase reliability.
This all still works fine, even with a long timeout, when the final target of the dialplan is to just send a
MESSAGE and then end the call flow since having the diaplan sitting waiting possibly 10s of seconds to send the message doesn’t hold anything else up. The only thing it’s trying to do is send a message.
However! If you want to send a message to a mobile device in the middle of a dialplan operation that is expected to continue on and do other work, like maybe
Dial() some extensions to bridge them to an incoming call, that delay in the
AGI() command is disastrous to the process of bridging an incoming call to some extensions. This is where you want the process of sending the message to go off on it’s own and not hold up the dialplan while it does it’s work, effectively putting the message sending process in parallel with the process of bridging the incoming call to extensions, rather than being a serial and blocking process. In this case you want the
AGI() to return immediately and have the process it started continue on in the background, finally sending the message once the mobile SIP client wakes up.
Since I am already using AMI in the AGI script to detect when the mobile SIP client has re-
REGISTERED, it seems that the previously posted suggestion of using AMI to do the
MessageSend() is the best solution.
Unless somebody else sees a completely different and better way to skin this cat.