I want that my MC52i auto accept an incoming call. If I use AT commands to answer manually (ATA) it works fine, but I'm not able to force the modem auto accepting an incoming call. On other devices it works with ATS0=1 but not on the MC52i. I think it has something to do with the GPRS Mode?
What type of call are you trying to accept, voice or CSD? Setting S0 ought to be enough for this. Try to enable AT+CRC=1 and examine the +CRING: <type> unsolicited result code (see 27.007 for details). Does it fail to auto answer all incoming calls? Try to have it auto answer both voice calls and data calls. Try to call from PSTN, ISDN and mobile phone (both same operator and different operator. Try several different phone models). If it fails to answer all those cases then you probably have to write off auto answer as a possibility. Oh, by the way, also try with several different sim cards (from at least more than one operator) in the modem to rule out problems with the operator/subscription.
I have probably given enough options to tweak so that testing every single combination is not feasible and useful, but pick some variations of all of them and set up at least 20 different test cases.
Although very unlikely, I'll mention the following for completeness and as a background to one of the many reasons why testing with several different operators is important:
There could be a problem if the network does not include call type information in the Bearer Capability in the SETUP message and then the phone does not know how to answer the call. This is very unlikely today, but several years ago some network could behave so. Because of this the phones used to have a "receive next call as" configuration to determine how to behave then. But I assume all newer phones to just ignore this scenario (It was applicable back in the days when Ericsson made mobile phones in their own brand, at least I remember seeing seeing this configuration option in their single menu style phones like T28. I do not remember if it survived the conversion to the icon based menus).
Related
Sorry for my bad english.
I use asterisk + frepbь. My task is to make sure that employees can not make the transfer of the call to mobile numbers. It's about transfer, not about calls directly. When, by example, one caller calls another, the latter should not be able to make a call transfer to the mobile number.
Help please solve this problem.
You can have any dialplan in TRANSFER_CONTEXT variable.
After that you have deal yourself in detecting if number is mobile in dialplan.
https://www.voip-info.org/wiki/view/Asterisk+variables
I'm quite new to working with Arduino/GSM and have had problems getting basic HTTP functionality working. I am currently facing multiple problems - one being that the 3G shield I am working with (SIMCOM SIM5216A) does not seem to want to connect to a carrier! :(
However, the problem I would like to focus on for this question is that Phone Functionality - designated through the AT+CFUN command - does not seem to be maintained through power cycles. Additionally, sometimes after modifying the CFUN, the modem will run a soft reset.
Here is the command I have been using to modify the phone functionality of the modem:
AT+CFUN=1,0
I am under the impression that the second parameter should stop it from running a soft reset.
I have attempted to save the AT configuration by following advice in this question's accepted answer - here is the output from power on:
START
+STIN: 25
+STIN: 25
+CPIN: READY
SMS DONE
PB DONE
AT+CFUN=1,0
OK
AT&W
OK
However, whenever I next reset, I will get the following:
AT+CFUN?
+CFUN: 4
OK
So, my question is how can I save the CFUN configuration to be consistent between power cycles? (If you happen to be able to offer advice on why I can see medium-strength signal but cannot connect to an operator network, any advice would be welcome there too, however that is not the focus of this question)
With thanks,
BadDevH.
Exactly what that is saved with AT&W is a rather muddled, see this answer for details. However, regardless of that, the AT+CFUN command is controlling such a dynamic behaviour that I cannot imagine any manufacturer ever that has saved this with &W. Think more of CFUN more like setting a fixed cruise control speed while driving a car. There is no way the car will continue with the speed from last time when started.
For normal phones the default behaviour is value 1 - full functionality - because that is the very core functionality of what they do1, but for a GSM module shield, I am guessing that the default behaviour is set to no radio in order to save power, so it stays off until you need it at which point you need to explicitly turn it on.
1
And even in the case of no sim card present, it shall still be able to make emergency calls.
I am developing an java-asterisk application that is calling subscribers to deliver messages. At some moments during the call, I need to monitor whether the subscriber is talking or is silent. I need to monitor that for a fairly long time (1-3 seconds) but don't want to interrupt the flow of the outgoing message.
The way I am doing it now is as below
streamFile(*file A*);
exec("WaitForSilence","300,1,1");
waitStatus=getVariable("WAITSTATUS");
streamFile(*file B*);
This works fine but it is only a 300ms detect and a 1s timeout, so from the subscriber point of view the silence between file A and file B is almost unnoticeable. But if I want to listen for longer (say 3 seconds for example) then the subscriber's experience will be ruined.
What I would need is a function similar to "WaitForSilence" but that:
runs in parallel to the script;
delivers its outcome in a variable channel with a name that I define (as there might be several calls to the function, and I need to get all the results)
I've been looking for more than aweek now and couldn't find a way to do that. Any ideas?
Code you provided will do wait, after that will do playback.
There are no way do that simple in one application.
Posible ways:
1) create c/c++ application(asterisk guru skill required) for that.
2) create enother channel, mix it with ChanSpy and in that channel do silence detect. Complexity - expert in asterisk.
Both are not so short(more then 2-3 screens of code), so can't be described in this site.
You can also try use Background application, but i am afraid it will not work too.
I have a DirectShow webcam application. I make use of Sample Grabber to get the buffer callbacks and IVideoWindow to control the display co-ordinates for the Preview. I have Preview and Capture Streams which I run as below.
g_pBuild->RenderStream(&PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video,cam,g_pGrabberF,pNullRenderer2); g_pBuild->RenderStream(&PIN_CATEGORY_PREVIEW, &MEDIATYPE_Video,cam,NULL,NULL);
On certain On board cameras, IMediaControl::Run followed by IMediaControl::Stop followed by IMediaCOntrol::Run doesn't switch on the camera.
Extenal USB cameras work properly here. How can I diagnose more on this? Any pointers, please help.
Maybe its specific to a certain hardware issue in the unit.
Do a quick test by adding sleep of 1 sec between calls.
If it does help than you need to find a way to know when to unit state in idle or not.
There are two important parts of the question which you did not provide:
Filter graph topologies
HRESULTs of the method calls
A problem you might be having is that one of the filters in the topology does not handle well state transitions and fails somewhere between states. Supposedly your second Run meets it still trying to complete Stop. You might get a HRESULT there which indicates the issue (better for you) or the filter fails silently.
The filter graph's is the unlikely source of the bug itself. Chances are high that it does everything flawlessly, however since internally it distributes the calls between filters, one of the filter is letting you down.
I'm learning about the various networking technologies, specifically the protocols UDP and TCP.
I've read numerous times that games like Quake use UDP because, "it doesn't matter if you miss a position update packet for a missile or the like, because the next packet will put the missile where it needs to be."
This thought process is all well-and-good during the flight path of an object, but it's not good for when the missile reaches it's target. If one computer receives the message that the missile reached it's intended target, but that packet got dropped on a different computer, that would cause some trouble.
Clearly that type of thing doesn't really happen in games like Quake, so what strategy are they using to make sure that everyone is in sync with instantaneous type events, such as a collision?
You've identified two distinct kinds of information:
updates that can be safely missed, because the information they carry will be provided in the next update;
updates that can't be missed, because the information they carry is not part of the next regular update.
You're right - and what the games typically do is to separate out those two kinds of messages within their protocol, and require acknowledgements and retransmissions for the second type, but not for the first type. (If the underlying IP protocol is UDP, then these acknowledgements / retransmissions need to be provided at a higher layer).
When you say that "clearly doesn't happen", you clearly haven't played games on a lossy connection. A popular trick amongst the console crowd is to put a switch on the receive line of your ethernet connection so you can make your console temporarily stop receiving packets, so everybody is nice and still for you to shoot them all.
The reason that could happen is the console that did the shooting decides if it was a hit or not, and relays that information to the opponent. That ensures out of sync or laggy hit data can be deterministically decided. Even if the remote end didn't think that the shot was a hit, it should be close enough that it doesn't seem horribly bad. It works in a reasonable manner, except for what I've mentioned above. Of course, if you assume your players are not cheating, this approach works quite reasonably.
I'm no expert, but there seems to be two approaches you can take. Let the client decide if it's a hit or not (allows for cheating), or let the server decide.
With the former, if you shoot a bullet, and it looks like a hit, it will count as a hit. There may be a bit of a delay before everyone else receives this data though (i.e., you may hit someone, but they'll still be able to play for half a second, and then drop dead).
With the latter, as long as the server receives the information that you shot a bullet, it can use whatever positions it currently has to determine if there was a hit or not, then send that data back for you. This means neither you nor the victim will be aware of you hit or not until that data is sent back to you.
I guess to "smooth" it out you let the client decide for itself, and then if the server pipes in and says "no, that didn't happen" it corrects. Which I suppose could mean players popping back to life, but I reckon it would make more sense just to set their life to 0 and until you get a definitive answer so you don't have weird graphical things going on.
As for ensuring the server/client has received the event... I guess there are two more approaches. Either get the server/client to respond "Yeah, I received the event" or forget about events altogether and just think about everything in terms of state. There is no "hit" event, there's just HP before and after. Sooner or later, it'll receive the most up-to-date state.