Is the SIM card, COMP128 v1 and another version can be cloned? In real network operator can we use it and have two SIM card?
The answer is Yes and No, depending what you mean by two SIM cards.
If you have two identical SIM cards identified by their same IMSI and Ki (Key). Only one will work at any time.
If you use SIM1 in a device it will authenticate to the network and receive what is called a TMSI (Temporary Mobile Subscriber Identity). The network will from now on address this subscriber by this TMSI.
If you start up SIM2 the authentication will happen and the network will associate you with a new TMSI.
Any SMS or Call will re routed to the last "authenticated" SIM. authentication could be retrigged by bootup, location change etc.
Related
I'm trying to create Zigbee P2P using XB24C27WIT-004 modules with Digi USB explorers(CP2102). I am using 2 laptops and connected the XBee modules to each of them. I have added the modules to X-CTUs and changed the DL of one module as MY of another module and vice versa. Both are on same channel and same PAN ID. But i couldn't see the serially transmitted data from one console to another. The console window is as shown in the image. The commands are being seen when i'm trying to discover other radio.The console window. The function is set to ZIGBEE TH Reg for both modules.
Have you configured one as a coordinator (ATCE=1) and the other as a router (ATCE=0) so they can join to each other? The Router can keep ATDH and ATDL as 0 to target the coordinator. I'm not familiar with using the 16-bit network address for the destination, so I'd recommend setting ATDH to the router's ATSH, and ATDL to ATSL.
To confirm that the devices are joined to each other, their operating PAN ID (ATOI and ATOP) must match. Once you see that, see if the router can send data to the coordinator, and then from the coordinator to the router. You can use ATNR on the router to perform a Network Reset so it will try to re-join your coordinator. You might need to set ATNJ to 0xFF on the coordinator to allow joining.
a general question about sending realtime messaging from a cloud server
to users with handsets.
I'm creating new ecommerce: ROSPO - Snap Commerce for Local Trades
( enjoy small video introduction: http://www.rosposhop.com )
Now, my problem is to find the BEST way to deliver Online Orders
(submitted by online buyer) to a seller with a cell phone in his hands.
Order delivery must be in REALTIME and with a "delivery receipt"
confirmation requirement (I need to know for sure if order arrived into
the seller mobile phone, so no beloved e-mails, sorry).
1. Push Notifications
A native app with some sort of push notification protocol for orders
notifications ?
by example using https://developer.android.com/google/gcm/index.html for
Android, something similar fo IoS, something similar for Microsoft Phone
OS, etc.) ?
2. SMS
pros:
- Old plain "delivey receipt" SMS text messages. They always reach
receivers also in area without 3G coverage...
- SMSs do not require any native app. any sort of cellphone is ok.
cons:
sending (and receiving) SMSs is expensive! Let consider text message orders could be many SMS's segments... (an order is usually 160 x N chars), with N = 2-8. And just sending a single SMS, with some gateway providers in Europe cost is between 0.03 to 0.07 EUR.
Any further suggestion ?
BTW, any good experience with SMS gateway providers like: Twillio.com /
Nexmo.com ? I used until now with success Italian Skebby.com, but I
possibly need the CHEAPEST&AFFORDABLE provider that act in worlwide
countries (ROSPO servers will be instantiated in any city all around the
world...)
thanks :-)
giorgio
I don't think any option is really able to provide reliable delivery receipt. SMS is unreliable in various countries, and device Push Notifications can be over-ridden on the local device but still look like they've been sent on your side.
That said SMS is the most general solution to the problem and will cover the most use cases. If you're going to go the Push Notification route though I guess that means you'll have an app on the user's device, in which case the most reliable way would be to have push notifications (or maybe give the user an option to have SMS aswell/instead?) which they then need to acknowledge receipt within the app. That way you're relying on their action to confirm acknowledge it rather than making assumptions based on delivery.
Update: Now there's Catapush: push notifications with sms fallback feature :)
I'm trying to display some cameras connected to a dvr which in turn is connected to a Huawei router that has the ability to connect to the Internet via the mobile network.
I tried with a tim card and everything goes wonderfully (the tim's ip is dynamic so I have used no-ip to be able to always access the dvr and I made the forwarding by opening the right doors outside to the inside), but as the area in which you installed the dVR, it does not take tim signal (not even wind, or 3), I had to put the vodafone's sim but from what I've read on the internet but not the public ip to mobile customers, but access through NAT ..
None of you know the way to be able to access a remote PC via a network that uses NAT?
When behind NAT, the best course of action is to establish a connection from inside the NAT to some remote machine.
There are several ways to achieve that, such as creating a (reverse) ssh tunnel or using a remote desktop utility such as logmein, teamviewer or ammyy.
i see latency issue - when i send a timelineitem from my glassware app, it takes a long time to appear on glass device.
I see the item in developer playground (https://developers.google.com/glass/playground)
Is it isolated issue on my WiFi (unlikely)? or some optimization done at Mirror server which queues timelineitems and sending in a specific interval to glass device?
Thanks
After doing some more investigation (In my case, i have setup private network inside enterprise network), i found out that some of the ports are blocked by firewall settings for incoming traffic from outside network, so glass device was not getting notifications from the Mirror Server.
It is possible either Channel API or XMPP is used in receiving notification messages from Mirror server to Glass. Those ports might have blocked by my firewall settings. I ran wireshark, still it is not clear which protocol or port is used in receiving notifications.
Also it is possible that glass device could get (HTTP GET) newly available cards from the mirror server by polling on specific time interval or other cases(changing WIFI network, etc).
I called Glass help, i could not get any feedback.
I would really appreciate if someone (from Google) could shed some light (port and protocol details) on how Glass gets notification from mirror server when new timeline card is available.
This is a known issue:
https://code.google.com/p/google-glass-api/issues/detail?id=185
Issue has been fixed by updating to XE10.
I want to host an SMS application on GAE and all my traffic will come
from a SMS GATEWAY with a single IP address.
Is that fine(I'm expecting 500 dynamic requests/sec) ?
Will there be any problems like unusual traffic errors or any other issues ?
EDITED
More info:
My users send queries through SMS which will be routed to my app from SMS GATEWAY(single IP address).
My app processes those queries and reply back through SMS (again through SMS GATEWAY).
I can reply using URL FETCH(not a problem) but what i'm worried about is if I receive some 500 dynamic requests/sec from single IP address , GAE might block them thinking them as Dos(denial of service) attack .
GAE either asks the user to enter a captcha at https://www.google.com/accounts/DisplayUnlockCaptcha or redirects to sorry.google.com and displays an error message itseems if it receives unusual traffic from single IP . But my users access app only through SMS.
Please look at this production issue filed.
It would be technically doable - your app can detect the user's IP via the REMOTE_ADDR environment variable, and if it's the one you want, show them the actual page (showing them a 403 otherwise). Your second question is a bit trickier to answer - your App Engine app could handle it assuming you wrote it in a scalable manner (not a trivial assumption!) and if you can afford the amount of traffic you're trying to throw at it.
You're right to be concerned that getting that level of traffic from a single IP might set off some form of DoS protection - it shouldn't, but it's impossible to rule it out. If it were to happen, you could file a production issue, and we'd take care of it.