What are the differences between On-net calls and Off-net calls?
How could I make international call under On-net call?
The 'On-Net' is used when your call or message originates on your home operator's network and terminates to another mobile number that resides with your operator. It does not matter if the person you are calling is using the home network or is off Island roaming with a different provider. 'Off-Net' applies when the call or message is made on a different network, e.g. whilst you are roaming, or if you are using your home network and make a call or send a message to a number that resides with a different network provider
Related
Suppose I have an IoT device which I'm about to control (lets say switch on/off) and monitor (e.g. collect temperature readings). It seems MQTT could be the right fit. I could publish messages to the device to control it and the device could publish messages to a broker to report temperature readings. So far so good.
The problems start to occur when I try to design the API to control the device.
Lets day the device subscribes to two topics:
/device-id/control/on
/device-id/control/off
Then I publish messages to these topics in some order. But given the fact that messaging is typically an asynchronous process there are no guarantees on the order of messages received by the device.
So in case two messages are published in the following order:
/device-id/control/on
/device-id/control/off
they could be received in the reversed order leaving the device turned on, which can have dramatic consequences, depending on the context.
Of course the API could be designed in some other way, for example there could be just one topic
/device-id/control
and the payload of individual messages would carry the meaning of an individual message (on/off). So in case messages are published to this topic in a given order they are expected to be received in the exact same order on the device.
But what if the order of publishes to individual topics cannot be guaranteed? Suppose the following architecture of a system for IoT devices:
/ control service \
application -> broker -> control service -> broker -> IoT device
\ control service /
The components of the system are:
an application which effectively controls the device by publishing messages to a broker
a typical message broker
a control service with some business logic
The important part is that as in most modern distributed systems the control service is a distributed, multi instance entity capable of processing multiple control messages from the application at a time. Therefore the order of messages published by the application can end up totally mixed when delivered to the IoT device.
Now given the fact that most MQTT brokers only implement QoS0 and QoS1 but no QoS2 it gets even more interesting as such control messages could potentially be delivered multiple times (assuming QoS1 - see https://stackoverflow.com/a/30959058/1776942).
My point is that separate topics for control messages is a bad idea. The same goes for a single topic. In both cases there are no message delivery order guarantees.
The only solution to this particular issue that comes to my mind is message versioning so that old (out-dated) messages could simply be skipped when delivered after another message with more recent version property.
Am I missing something?
Is message versioning the only solution to this problem?
Am I missing something?
Most definitely. The example you brought up is a generic control system, being attached to some message-oriented scheme. There are a number of patterns that can be used when referring to a message-based architecture. This article by Microsoft categorizes message patterns into two primary classes:
Commands and
Events
The most generic pattern of command behavior is to issue a command, then measure the state of the system to verify the command was carried out. If you forget to verify, your system has an open loop. Such open loops are (unfortunately) common in IT systems (because it's easy to forget), and often result in bugs and other bad behaviors such as the one described above. So, the proper way to handle a command is:
Issue the command
Inquire as to the state of the system
Evaluate next action
Events, on the other hand, are simply fired off. As the publisher of an event, it is not my business to worry about who receives the event, in what order, etc. Now, it should also be pointed out that the use of any decent message broker (e.g. RabbitMQ) generally carries strong guarantees that messages will be delivered in the order which they were originally published. Note that this does not mean they will be processed in order.
So, if you treat a command as an event, your system is guaranteed to act up sooner or later.
Is message versioning the only solution to this problem?
Message versioning typically refers to a property of the message class itself, rather than a particular instance of the class. It is often used when multiple versions of a message-based API exist and must be backwards-compatible with one another.
What you are instead referring to is unique message identifiers. Guids are particularly handy for making sure that each message gets its own unique id. However, I would argue that de-duplication in message-based architectures is an anti-pattern. One of the consequences of using messaging is that duplicates are possible, so you should try to design your system behaviors to be stateless and idempotent. If this is not possible, it should be considered that messaging may not be the correct communication solution for the need.
Using the command-event dichotomy as an example, you could perform the following transaction:
The controller issues the command, assigning a unique identifier to the command.
The control system receives the command and turns on.
The control system publishes the "light on" event notification, containing the unique id of the command that was used to turn on the light.
The controller receives the notification and correlates it to the original command.
In the event that the controller doesn't receive notification after some timeout, the controller can retry the command. Note that "light on" is an idempotent command, in that multiple calls to it will have the same effect.
When state changes, send the new state immediately and after that periodically every x seconds. With this solution your systems gets into desired state, after some time, even when it temporarily disconnects from the network (low battery).
BTW: You did not miss anything.
Apart from the comment that most brokers don't support QOS2 (I suspect you mean that a number of broker as a service offerings don't support QOS2, such as Amazon's AWS IoT service) you have covered most of the major points.
If message order really is that important then you will have to include some form of ordering marker in the message payload, be this a counter or timestamp.
I am writing a build script which has some password protected files (keys). I need a way to prompt the user once for the password and then use this key across multiple scripts. These scripts do not live inside the same shell, and may spawn other windows via dbus. I can then send them commands, one of which must have access to the password.
I have this working already, but at a few points the passphrase is either used directly on a command-line (passed via dbus), or is put into a file (the name then passed to the other script). Both of these are less secure than I want*. The command-line ends up in a history which may be stored in a file, as well as appearing in the process list, and the second option stores in a file which can be read by somebody else.
Is there some standard way to create a temporary communications channel between two processes which could communicate the password and not be intercepted by another user on the system (including root)?
*Note: This is primarily an exercise to be fully secure. For my current project the temporary in-file storage of the password is okay.
Setting "root being all-powerful" aside, I would imagine that a Private DBus Connection would do the trick although the documentation I could find seems a little light on what exactly makes a private connection private.
However, the DBus Specification, more specifically, the Message Bus Specification subsection on eavesdropping says in part:
Receiving a unicast message whose DESTINATION indicates a different
recipient is called eavesdropping. On a message bus which acts as a
security boundary (like the standard system bus), the security policy
should usually prevent eavesdropping, since unicast messages are
normally kept private and may contain security-sensitive information.
So you may not even need to use private connections which incur more overhead costs. But on a risk/reward basis with security being paramount, that may be the more secure alternative for you. Hope that helps.
After googling I come to know some basic definition as,
Outbound calls - A call center agent or representative contacts the customer.
Inbound calls - A call center agent or representative takes calls coming into the contact center.
My questions are,
1 Are these terms applicable to call centre setup only ?
2 Routing of inbound call is diffrent from routing of outbound call(Technical aspects like protocol, switching methods etc)?
3 Whether calls are handled diffrently based on inbound & outbound, by network elements?
These are not specific to callcenters only.
-Outbound calls means all calls from your internal network routed outside (to the public internet or to another carriers). Usually more complex routing rules are applied for this (for example you might route prefix A to carrier X and prefix B to carrier Y)
-Inbound calls are the opposite. Usually there are no any routing rules (except authentication) and you just try to match the incoming call with one of your extension. If the target is not present in your network then you might reject the call or forward to the appropriate network
We have an asterisk system which has only 3XXX SIP phones. And we have some queues.
I am using AddQueueMember application to add the agents to queues dynamically as the following
AddQueueMember(queue_name,SIP/5XXX#10.10.X.X)
AddQueueMember(queue_name,SIP/6XXX#10.10.X.X)
AddQueueMember(queue_name,SIP/7XXX#10.10.X.X)
and after queue show command
Members:
SIP/5XXX#10.10.X.X(dynamic) (Invalid) has taken no calls yet
SIP/6XXX#10.10.X.X (dynamic) (Invalid) has taken no calls yet
SIP/7XXX#10.10.X.X (dynamic) (Invalid)has taken no calls yet
But when i try to add incoming calls to this "queue_name" it says Unable to join the queue.
On the other hand when i add an registered asterisk member to this "queue_name" which has 3XXX phone number as i told you above. It is working and the queue can handle all the incoming calls with rr strategy. And it is valid for all the queues in my systems.
AddQueueMember(queue_name,SIP/5XXX#10.10.X.X)
AddQueueMember(queue_name,SIP/6XXX#10.10.X.X)
AddQueueMember(queue_name,SIP/7XXX#10.10.X.X)
AddQueueMember(queue_name,SIP/3XXX)
and again after queue show command
Members:
SIP/5XXX#10.10.X.X(dynamic) (Invalid) has taken no calls yet
SIP/6XXX#10.10.X.X (dynamic) (Invalid) has taken no calls yet
SIP/7XXX#10.10.X.X (dynamic) (Invalid) has taken no calls yet
SIP/3489 (dynamic) (Not in use) has taken no calls yet
So is there a way for queues to handle incoming calls without adding this 3XXX phones? Can you show me a better solution for that?
Thanks and Regards
You will have to add them as SIP peers in /etc/sip.conf, for example:
[5001]
disallow=all
host=10.10.X.X
type=friend
dtmfmode=rfc2833
allow=alaw
qualify=yes
canreinvite=yes
insecure=port
context=somecontext
and then do AddQueueMember(queue_name,SIP/5001). It all depends on your configuration.
If 10.10.X.X is your dial out trunk registered in sip.conf where 5XXX extensions are registered, then AddQueueMember(queue_name,SIP/YourDialOutTrunk/5XXX) should work.
I want to develop an iPhone application whose main function is to hang up an outgoing phone call after X amount of seconds/minutes have passed since the call was placed, not from when the call was connected. After hanging up, the application will automatically redial to continue the phone call without any user intervention. The application will only redial in the case the same application has hanged up the call. If any of the parties hang up the call, the application will not redial.
Expected features to be developed are:
Add and update a list of phone numbers to monitor
The user must be able to type in directly a phone number or select it from the address book. The list will show the name and phone number monitored like “Roberto Ibarra: 33 5555 5555”. This list will serve as the database of phone numbers the application will identify as outgoing calls that must be hanged up and redialed automatically after X amount of minutes have passed. The application must not affect incoming calls or outgoing calls to numbers other than the ones on this list.
If possible, the application must fully integrate with the OS dialing system so that calls placed from any part of the phone will be monitored. For example, if a call is dialed with voice commands it should be monitored by this application.
Alert and hang up
The application must send a BEEP 5 seconds before hanging up, so as to both parties in the call can hear it and be aware the call will be about to end. This will not be configurable by the user, it will always happen 5 seconds before ending the monitored call. If the call is an outgoing call and the number is part of the list of numbers to monitor, the application will then hangup the call once the X amount of minutes/seconds have been reached. This beep can be a DTMF tone.
Automatically redial a monitored call that was ended by the application
The application will automatically redial the number that was being called to continue the call ONLY if the call was automatically ended by the application because the time limit was reached. If the call was ended by the user, then the call must NOT be redialed.
Copy protection mechanism
The application must have a copy protection mechanism based on the phone's IMEI. The application must ask the first time for a code and show the phone's IMEI. The code will be generated by a third party website by entering the IMEI and if correctly entered in the phone, then the application will work.
The algorithm will be based on a hash from the IMEI and some seed to be determined. The crypt function should be something like MD5 or some other function available in the OS in the majority of the phones using the OS.
You cannot do this. You have no access to calls made from the device and certainly can't hangup any in process calls. The closest you can come is asking the phone application to dial a number.