# GPRS always + GSM calls when needed **URL:** \ **Category:** Open AT\ **Created:** [August 10, 2007, 11:54am UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518 "2007-08-10T11:54:59Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![operapg](https://avatars.discourse-cdn.com/v4/letter/o/ce7236/32.png) [@operapg](https://forum.sierrawireless.com/u/operapg)\ **Post date:** [August 10, 2007, 11:54am UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/1 "2007-08-10T11:54:59Z")
I didn’t know if I should post this here or in the FCM section, so here it goes: First of all, this is how my application should behave: - GPRS connection should always be active (I do it using WIP GPRS bearer). - One socket is connected to UART 1 when it is active. - GSM data calls should always be accepted. When a data call is active, it has to be connected to UART 1 (automatically answered with ats0\>=2). So far it is easy, but here comes the problem: - The data coming from the GSM call has to be monitored for certain purposes. This means that I need to subscribe to GSM flow with adl\_fcmSubscribe. Obviously, I can’t subscribe to GSM flow while WIP is using GPRS flow. How I do it: 1. Subscribe to GSM call events with adl\_callSubscribe. 2. Establish GPRS connection with WIP. 3. Open sockets, etc… When I get ADL\_CALL\_EVENT\_RING\_DATA: 1. Close sockets. 2. Disconnect with wip\_bearerStop (I get WIP\_BERR\_OK\_INPROGRESS). 3. After 1 second, and without waiting for WIP\_BEV\_STOPPED event, subscribe to GSM flow with adl\_fcmSubscribe (this is why ats0 is set to \>=2, so that I can subscribe the flow before the call is answered). I have been unable to think of a better way to do it. Anyway, this works, but only the first time. The second (and subsequent) times, adl\_fcmSubscribe returns ADL\_FCM\_RET\_ERROR\_GSM\_GPRS\_ALREADY\_OPENNED. And in fact, it is correct, as WIP library never gets past WIP\_BERR\_OK\_INPROGRESS, so I guess it gets stuck somewhere in there and doesn’t release GPRS flow. Anyone has experienced something similar, or is it just me? By the way, I initialize the WIP library in my adl\_main function with wip\_netInit and never terminate it. I’ve tried terminating it too with same results. ---
**Author:** ![awneil](https://avatars.discourse-cdn.com/v4/letter/a/49beb7/32.png) [@awneil](https://forum.sierrawireless.com/u/awneil)\ **Post date:** [August 10, 2007, 12:08pm UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/2 "2007-08-10T12:08:17Z")
> [@operapg](#): > > 1. After 1 second, and without waiting for WIP\_BEV\_STOPPED event, subscribe to GSM flow with adl\_fcmSubscribe Why do you not wait for WIP\_BEV\_STOPPED ? As far as I can tell, this is the event that tells you that WIP has finished with its FCM subscription - so you need to wait for it! These are the Traces I get immediately after a wip\_bearerStop call: ```auto 158.164 Trace CUS4 25 FCM Unsubs 1 : 0 158.164 Trace CUS4 30 [ADL port] IsAvailable(80) : 1 159.105 Trace CUS4 21 Get Mem 0106F8F4 159.105 Trace CUS4 21 Get Mem 0106F400 159.105 Trace CUS4 27 Call unsubs 0023AC05 : 0 159.105 Trace CUS4 3 Bearer Event 4: WIP_BEV_STOPPED. ``` > [@](#): > > (this is why ats0 is set to \>=2, so that I can subscribe the flow before the call is answered). Wouldn’t it be better to use ATS0=0 (ie, no auto-answer), and have your Open-AT application handle the call? That way, your application would be in complete control, and not in a “race” to beat the auto-answer… > [@](#): > > I guess it gets stuck somewhere in there and doesn’t release GPRS flow. See above - I think that’s why you need to wait for WIP\_BEV\_STOPPED ? ---
**Author:** ![operapg](https://avatars.discourse-cdn.com/v4/letter/o/ce7236/32.png) [@operapg](https://forum.sierrawireless.com/u/operapg)\ **Post date:** [August 10, 2007, 1:26pm UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/3 "2007-08-10T13:26:59Z")
Hi awneil, and thanks for answering! > [@awneil](#): > > Why do you not wait for WIP\_BEV\_STOPPED ? > > As far as I can tell, this is the event that tells you that WIP has finished with its FCM subscription - so you need to wait for it! Sorry, I didn’t explain it all. I do it that way because it takes 9 rings for WIP\_BEV\_STOPPED to arrive when there is an incoming call, and some operators end the call before that. > [@awneil](#): > > Wouldn’t it be better to use ATS0=0 (ie, no auto-answer), and have your Open-AT application handle the call? > That way, your application would be in complete control, and not in a “race” to beat the auto-answer… I know, but for legacy reasons it is done like that. It was done like that when I took the project from someone else, and clients don’t like to see stuff changed in GSM related things. They think that this way it will always work, even if I have a bug in my app. > [@awneil](#): > > See above - I think that’s why you need to wait for WIP\_BEV\_STOPPED ? Actually, I tried some stuff that I didn’t include in my post (it already was quite long). One of them was manually establishing and terminating the connection with custom commands. This way, I could do a wip\_bearerStop and wait for WIP\_BEV\_STOPPED whenever I wanted. I could connect and disconnect at my wish. This worked all the time: 1. Connect. 2. Open sockets, etc. 3. Disconnect and wait for WIP\_BEV\_STOPPED. 4. Go back to 1. This didn’t work: 1. Connect. 2. Open sockets, etc. 3. Disconnect and wait for WIP\_BEV\_STOPPED. 4. Receive a call (made by me with another modem), answer it, hang up (from the other modem). 5. Go back to 1 → get stuck in WIP\_BERR\_OK\_INPROGRESS, no WIP\_BEV\_STOPPED event. ---
**Author:** ![awneil](https://avatars.discourse-cdn.com/v4/letter/a/49beb7/32.png) [@awneil](https://forum.sierrawireless.com/u/awneil)\ **Post date:** [August 10, 2007, 1:38pm UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/4 "2007-08-10T13:38:17Z")
> [@operapg](#): > > I do it that way because it takes 9 rings for WIP\_BEV\_STOPPED to arrive when there is an incoming call, and some operators end the call before that. Hmmm… I think if that’s how long it takes for the event to arrive, then that is how long you have to wait! If you’re messing with the stuff that WIP wants before it tells you it’s finished with it, I think that’s asking fo trouble… 😮 > [@](#): > > clients don’t like to see stuff changed in GSM related things Yes, but the system must surely be able to cope with a call not getting answered, and re-try it? ---
**Author:** ![operapg](https://avatars.discourse-cdn.com/v4/letter/o/ce7236/32.png) [@operapg](https://forum.sierrawireless.com/u/operapg)\ **Post date:** [August 10, 2007, 2:00pm UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/5 "2007-08-10T14:00:28Z")
> [@awneil](#): > > Hmmm… I think if that’s how long it takes for the event to arrive, then that is how long you have to wait! When there is no incoming data call the event comes almost immediately, at least in my case. > [@awneil](#): > > If you’re messing with the stuff that WIP wants before it tells you it’s finished with it, I think that’s asking fo trouble… 😮 You are absolutely right, but I have been unable to find another way. I’ve asked for a decent solution to this issue for over a year now (to our provider here in Spain, not directly to wavecom), as I had similar problems with edLib too. I guess we are not important enough, but it seems like such an obvious need to me. Letting the wavecom do it’s stuff and send GSM data to UART 1 on it’s own works great, I should be able to do it too. > [@awneil](#): > > Yes, but the system must surely be able to cope with a call not getting answered, and re-try it? Sure, and it does, but I meant that they don’t want to get rid of the ats0 because, for them, that “always works”. ---
**Author:** ![tobias](https://avatars.discourse-cdn.com/v4/letter/t/c67d28/32.png) [@tobias](https://forum.sierrawireless.com/u/tobias)\ **Post date:** [August 13, 2007, 6:21am UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/6 "2007-08-13T06:21:41Z")
1. When you open your GSM data flow, do you first check with adl\_fcmIsAvailable that the flow is available for subscription? 2. After your GSM data call is finished, do you make sure you receive the ADL\_FCM\_EVENT\_FLOW\_CLOSED if it’s the calling side that hangs up, or manually close the flow if you are the one who hang up? You might also want to check afterwards that GSM and GPRS flows are available with the above command, before start up GPRS again. ---
**Author:** ![operapg](https://avatars.discourse-cdn.com/v4/letter/o/ce7236/32.png) [@operapg](https://forum.sierrawireless.com/u/operapg)\ **Post date:** [August 13, 2007, 7:13am UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/7 "2007-08-13T07:13:01Z")
Hi tobias. > [@tobias](#): > > 1. When you open your GSM data flow, do you first check with adl\_fcmIsAvailable that the flow is available for subscription? Yes, I do, but it’s quite unnecessary because it always returns TRUE, even when adl\_fcmSusbscribe returns ADL\_FCM\_RET\_ERROR\_GSM\_GPRS\_ALREADY\_OPENNED. > [@tobias](#): > > 1. After your GSM data call is finished, do you make sure you receive the ADL\_FCM\_EVENT\_FLOW\_CLOSED if it’s the calling side that hangs up, or manually close the flow if you are the one who hang up? Yes, I always receive ADL\_FCM\_EVENT\_FLOW\_CLOSED. > [@tobias](#): > > You might also want to check afterwards that GSM and GPRS flows are available with the above command, before start up GPRS again. For the sake of curiosity, I’ve put some adl\_fcmIsAvailable calls around. It always returns TRUE. For example, both GSM and GPRS flows are available in WIP\_BEV\_IP\_CONNECTED event! ---
**Author:** ![awneil](https://avatars.discourse-cdn.com/v4/letter/a/49beb7/32.png) [@awneil](https://forum.sierrawireless.com/u/awneil)\ **Post date:** [August 13, 2007, 8:43am UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/8 "2007-08-13T08:43:35Z")
> [@tobias](#): > > 1. After your GSM data call is finished, do you make sure you receive the ADL\_FCM\_EVENT\_FLOW\_CLOSED if it’s the calling side that hangs up… > [@operapg](#): > > Hi tobias.Yes, I always receive ADL\_FCM\_EVENT\_FLOW\_CLOSED. Note that there are certain situations where you might not get the ADL\_FCM\_EVENT\_FLOW\_CLOSED; see: [wavecom.com/modules/movie/sc … low\_closed](http://www.wavecom.com/modules/movie/scenes/forums/viewtopic.php?t=709&highlight=flow_closed) 😠 ---
**Author:** ![awneil](https://avatars.discourse-cdn.com/v4/letter/a/49beb7/32.png) [@awneil](https://forum.sierrawireless.com/u/awneil)\ **Post date:** [August 13, 2007, 9:10am UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/9 "2007-08-13T09:10:31Z")
In my application, the unit is normally idle and can accept an incoming Data Call (CSD), or establish a GPRS session as required. If a GPRS session is started after a data call has been handled (and correctly closed with ADL\_FCM\_EVENT\_FLOW\_CLOSED etc), I find that I never get the WIP\_BEV\_STOPPED when trying to close the GPRS session. In other words, this is not just a problem when a data call “interrupts” a GPRS session - it seems be be a fundamental problem with WIP whenever any Data call has previously used the FCM GSM Flow!! 😮😠 ---
**Author:** ![operapg](https://avatars.discourse-cdn.com/v4/letter/o/ce7236/32.png) [@operapg](https://forum.sierrawireless.com/u/operapg)\ **Post date:** [August 13, 2007, 9:39am UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/10 "2007-08-13T09:39:57Z")
> [@awneil](#): > > In other words, this is not just a problem when a data call “interrupts” a GPRS session - it seems be be a fundamental problem with WIP whenever any Data call has previously used the FCM GSM Flow!! 😮😠 Yes, I know. That’s exactly what I meant in one of my previous posts when I said: > [@](#): > > 1. Connect. > 2. Open sockets, etc. > 3. Disconnect and wait for WIP\_BEV\_STOPPED. > 4. Receive a call (made by me with another modem), answer it, hang up (from the other modem). > 5. Go back to 1 → get stuck in WIP\_BERR\_OK\_INPROGRESS, no WIP\_BEV\_STOPPED event. ---
**Author:** ![tobias](https://avatars.discourse-cdn.com/v4/letter/t/c67d28/32.png) [@tobias](https://forum.sierrawireless.com/u/tobias)\ **Post date:** [August 13, 2007, 1:35pm UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/11 "2007-08-13T13:35:44Z")
What versions are affected by this? I don’t do GSM Data calls in the products I work on now, but it’s interesting to know if it’s the 3.1x series (Q24…) or 4.1x or 4.2x (Q2686/Q2687) that is affected. I’m currently working with SDK 3.15/FW6.57c and SDK 4.21/FW6.62 myself. ---
**Author:** ![operapg](https://avatars.discourse-cdn.com/v4/letter/o/ce7236/32.png) [@operapg](https://forum.sierrawireless.com/u/operapg)\ **Post date:** [August 13, 2007, 1:47pm UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/12 "2007-08-13T13:47:32Z")
> [@tobias](#): > > What versions are affected by this? I’m using Q24PLUS/Q2406B with Open AT v3.15. ---
**Author:** ![tobias](https://avatars.discourse-cdn.com/v4/letter/t/c67d28/32.png) [@tobias](https://forum.sierrawireless.com/u/tobias)\ **Post date:** [November 15, 2007, 2:39pm UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/13 "2007-11-15T14:39:54Z")
I believe we have been bitten by this bug too now… A bug report has been sent and I hope that it reaches Wavecom in time… So far we have only seen this bug after first setting up GPRS, then disconnecting due to incoming data call, subscription and unsubscription of the GSM data flow, then set up GPRS again. Our testing has been with Q2686/6.63/4.22a. If anyone knows of a solution, or if Wavecom has responded to this issue, please post. ---
**Author:** ![tobias](https://avatars.discourse-cdn.com/v4/letter/t/c67d28/32.png) [@tobias](https://forum.sierrawireless.com/u/tobias)\ **Post date:** [November 19, 2007, 6:08pm UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/14 "2007-11-19T18:08:13Z")
I have received word that this issue is gonna be fixed in 6.63d and that there currently is no workaround, as the flow closed event is not generated. I don’t know when that is supposed to be released though. ---
**Author:** ![joeyyang](https://avatars.discourse-cdn.com/v4/letter/j/b4bc9f/32.png) [@joeyyang](https://forum.sierrawireless.com/u/joeyyang)\ **Post date:** [December 25, 2007, 9:10am UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/15 "2007-12-25T09:10:25Z")
Hi, Everyone, I also meet this question when I use GPRS setting: wip\_bearerOpen(&myBearer, “GPRS”, myHandler, NULL) return ok. wip\_bearerSetOpts(myBearer, WIP\_BOPT\_GPRS\_APN, “emome”, WIP\_BOPT\_LOGIN, “”, WIP\_BOPT\_PASSWORD, “”, WIP\_BOPT\_END); I can receive “WIP\_BERR\_OK\_INPROGRESS” info, but I can’t receive “WIP\_BEV\_IP\_CONNECTED” message. And I often meet this situation when I install machine in the car. When I drove on the freeway and speed is approximately 80-100 KM, this situation happen “Everytime”, But when I test in office (in one place, don’t move), this situation don’t happen. I confused about this situation so I search the forum. Now I think maybe this situation is a bug. Because I don’t know how to solve this question, I share my test experience to everyone. I hope wavecom can solve this question quickly. 😒 ---
**Author:** ![tobias](https://avatars.discourse-cdn.com/v4/letter/t/c67d28/32.png) [@tobias](https://forum.sierrawireless.com/u/tobias)\ **Post date:** [August 14, 2008, 8:14am UTC](https://forum.sierrawireless.com/t/gprs-always-gsm-calls-when-needed/1518/16 "2008-08-14T08:14:34Z")
6.63d solves the problems we had with CSD and GPRS. It was released together with SDK 4.26.