First i would like to apologize for my bad english, I wish you will understand my problem.
Here's my question, for my internship, I need to create a fonctionality that allows a caller to put his call in waiting, with a button, and to take the call back with that button again. And i think there's an option with SIP protocol that allows to do that, but i just can't find it, i searched in internet in some documentations, the only thing I might know and i'm not even sure is that it could be an option in a re-INVITE request, that can be send by the called or the caller one, if someone could help me ?
Thanks
The feature you are looking for is achieved by implementing the Call Hold Scenario on a SIP Call.
there are 3 ways to put the call on hold at the press of the button.
Generate a Re-INVITE SDP with SendOnly option - the answer shall contain a recvonly and in this case you can go ahead and inject hold music media through the rtp stream.
Sending inactive in the Re-INVITE SDP which basically puts the media inactive for the session. This is when no rtp exchange is desired.
Sending the 0.0.0.0 notation for the Re-INVITE SDP - This is the old deprecated format of call hold when IPV4 was still the norm [still is!!] but it makes sure the RTP doesn't have a ip to be sent.
All of these mechanisms rely on the basic methods and hence it shouldn't be very difficult to achieve using any client software.
Related
I've been working with the Wayland protocol lately and many functions include a unit32_t serial parameter. Here's an example from wayland-client-protocol.h:
struct wl_shell_surface_listener {
/**
* ping client
*
* Ping a client to check if it is receiving events and sending
* requests. A client is expected to reply with a pong request.
*/
void (*ping)(void *data,
struct wl_shell_surface *wl_shell_surface,
uint32_t serial);
// ...
}
The intent of this parameter is such that a client would respond with a pong to the display server, passing it the value of serial. The server would compare the serial it received via the pong with the serial it sent with the ping.
There are numerous other functions that include such a serial parameter. Furthermore, implementations of other functions within the API often increment the global wl_display->serial property to obtain a new serial value before doing some work. My question is, what is the rationale for this serial parameter, in a general sense? Does it have a name? For example, is this an IPC thing, or a common practice in event-driven / asynchronous programming? Is it kind of like the XCB "cookie" concept for asynchronous method calls? Is this technique found in other programs (cite examples please)?
Another example is in glut, see glutTimerFunc discussed here as a "common idiom for asynchronous invocation." I'd love to know if this idiom has a name, and where (good citations please) it's discussed as a best practice or technique in asynchronous / even-driven programming, such as continuations or "signals and slots." Or, for example, how shared resource counts are just integers, but we consider them to be "semaphores."
You may find this helpful
Some actions that a Wayland client may perform require a trivial form
of authentication in the form of input event serials. For example, a
client which opens a popup (a context menu summoned with a right click
is one kind of popup) may want to "grab" all input events server-side
from the affected seat until the popup is dismissed. To prevent abuse
of this feature, the server can assign serials to each input event it
sends, and require the client to include one of these serials in the
request.
When the server receives such a request, it looks up the input event
associated with the given serial and makes a judgement call. If the
event was too long ago, or for the wrong surface, or wasn't the right
kind of event — for example, it could reject grabs when you wiggle the
mouse, but allow them when you click — it can reject the request.
From the server's perspective, they can simply send a incrementing
integer with each input event, and record the serials which are
considered valid for a particular use-case for later validation. The
client receives these serials from their input event handlers, and can
simply pass them back right away to perform the desired action.
https://wayland-book.com/seat.html#event-serials
As Hans Passant and Tom Zych state in the comments, the argument is distinguishes one asynchronous invocation from another.
I'm still curious about the deeper question, which is if this technique is one commonly used in asynchronous / event-driven software, and if it has a well-known name.
I am using asterisk 11.9.0 and i want to generate an outgoing call.I found that for outgoing i have to make a .call file and place it in a var/spool/asterisk/outgoing.I am following the link below
http://the-asterisk-book.com/1.6/call-file.html#call-file-parameter
my code is same as given in the above link,the above example uses only single fixed number to call.
My problem is that
i have to generate an outgoing to a number fetched from database(outgoing to new number everytime),so how to write the code of .call file for multiple numbers outgoing and how to pass these numbers fetched from database to .call file from my extensions.conf
Is there any way to do that.
I am new to asterisk.
Any help would be appreciated.
You can use vicidial.org software to do that things.
Note, it is very bad idea do outboudn dialler-like app in asterisk without understanding asterisk logic and very-hi skills in programming/database.
For more info you also can use this page
http://www.voip-info.org/wiki/view/Asterisk+auto-dial+out
Might be easier using WombatDialer as it has a plain API where you can tell it what you want it to do and it will take care of the rest. We have a plain set up for outbound and it took maybe a couple of days from zero to what we have now. ViciDial would have been overkill.
On why rolling your own is not a great idea, the Wombat manual is quite clear: http://manuals.loway.ch/WD_UserManual-chunked/ch01.html#_why_was_wombatdialer_created
You could also use the AMI (Asterisk Manager Interface), would be easier to program with a deamon running in the back to control what gets dialed and the responses to those dials. Mora info here https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=4817239.
Being new to Android development I have been researching StackOverflow for an answer to this question: How to mute the phone ringer for all incoming messages and calls when I am supposed to be in a Meeting as indicated by my Calendar.
I am able to access the calendar and able to check if present time is within the times set for an event. But how do I send any incoming phone calls to voice mail (and send a text message to caller).
I have gone through lots of questions here:
"How to detect incoming calls, in an Android device?"
"Incoming call broadcast receiver not working (Android 4.1)"
"How to detect incoming call with the help of Broadcast Receiver?"
"Custom incoming/outgoing call screen in Android"
"how to make an incoming call from our application"
"Android: Taking complete control of phone(kiosk mode), is it possible? How?"
"How to disconnect incoming call in android by programatically"
The ITelephony using AIDL looked promising untill I found out that it no longer works under Android 4.2 etc due to security issues.
At the moment the answer:
"How to detect incoming calls, in an Android device?" seems to be better simply because it seems to handle incoming calls in an elegant way - but the answer does not talk about how to (a) Silence the Ringer, (b) End the Call/Divert it etc - the example explains how to determine what state the phone is in at any given time. The other drawback seems to be I am struggling to unregister the listener function which means even after the example app has been terminated, the listener still seems to remain active and jumps into action whenever there is a call. Only way to stop that seems to be to restart the phone - which is very annoying.
The other aspect is that most of these questions are a year or more old and some of the old answers are no longer valid - as I mentioned earlier - the ITelephony looked promising but no longer works with new phones.
The Google documentation seems to suggest that a program can programmatically wrap up an answer to an incoming call in a SMS Text message by sending an Intent etc - but no examples anywhere and looks like the Google's documentation may be out of date (or I am reading an old version of it on the internet - though don't know how it is possible since I am using Google Search to find an answer.)
Silencing the ringer and stopping the incoming / outgoing call is still possible.
First, the example from "How to detect incoming calls, in an Android device?" is the correct way to detect the incoming call.
Now, for silencing the ringer and stopping the call:
First, create an interface named "ITelephony" under the "com.android.internal.telephony" package:
http://i.stack.imgur.com/UQoVc.png
And add this code to the interface:
public interface ITelephony
{
boolean endCall();
void answerRingingCall();
void silenceRinger();
}
Then, on the method where you want to silence the ringer and stop the call, add this code:
//TelephonyManager
TelephonyManager telephonyManager = (TelephonyManager)context.getSystemService(Context.TELEPHONY_SERVICE);
// Get the getITelephony() method
Class c = Class.forName(telephonyManager.getClass().getName());
Method m = c.getDeclaredMethod("getITelephony");
// Disable access check
m.setAccessible(true);
// Invoke getITelephony() to get the ITelephony interface
ITelephony telephonyInterface = (ITelephony) m.invoke(telephonyManager);
//Invoke silenceRinger
telephonyInterface.silenceRinger();
// Invoke endCall()
telephonyInterface.endCall();
Finally, in your manifest, you need to add these permissions:
<uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS" />
<uses-permission android:name="android.permission.CALL_PHONE" />
<uses-permission android:name="android.permission.MODIFY_PHONE_STATE" tools:ignore="ProtectedPermissions" />
I have tested this code on many devices and it works, if you have any problem, feel free to ask me :)
everyone, I am porting the WinPcap from NDIS6 protocol to NDIS6 filter. It is nearly finished, but I still have a bit of questions:
The comment of ndislwf said "A filter that doesn't provide a FilerSendNetBufferList handler can not originate a send on its own." Does it mean if I used the NdisFSendNetBufferLists function, I have to provide the FilerSendNetBufferList handler? My driver will send self-constructed packets by NdisFSendNetBufferLists, but I don't want to filter other programs' sent packets.
The same as the FilterReturnNetBufferLists, it said "A filter that doesn't provide a FilterReturnNetBufferLists handler cannot originate a receive indication on its own.". What does "originate a receive indication" mean? NdisFIndicateReceiveNetBufferLists or NdisFReturnNetBufferLists or both? Also, for my driver, I only want to capture received packets instead of the returned packets. So if possible, I don't want to provide the FilterReturnNetBufferLists function for performance purpose.
Another ressembled case is FilterOidRequestComplete and NdisFOidRequest, in fact my filter driver only want to send Oid requests itself by NdisFOidRequest instead of filtering Oid requests sent by others. Can I leave the FilterOidRequest, FilterCancelOidRequest and FilterOidRequestComplete to NULL? Or which one is a must to use NdisFOidRequest?
Thx.
Send and Receive
A LWF can either be:
completely excluded from the send path, unable to see other protocols' send traffic, and unable to send any of its own traffic; or
integrated into the send path, able to see and filter other protocols' send and send-complete traffic, and able to inject its own traffic
It's an all-or-nothing model. Since you want to send your own self-constructed packets, you must install a FilterSendNetBufferLists handler and a FilterSendNetBufferListsComplete handler. If you're not interested in other protocols' traffic, then your send handler can be as simple as the sample's send handler — just dump everything into NdisFSendNetBufferLists without looking at it.
The FilterSendNetBufferListsComplete handler needs to be a little more careful. Iterate over all the completed NBLs and pick out the ones that you sent. You can identify the packets you sent by looking at NET_BUFFER_LIST::SourceHandle. Remove those from the stream (possibly reusing them, or just NdisFreeNetBufferList them). All the other packets then go up the stack via NdisFSendNetBufferListsComplete.
The above discussion also applies to the receive path. The only difference between send and receive is that on the receive path, you must pay close attention to the NDIS_RECEIVE_FLAGS_RESOURCES flag.
OID requests
Like the datapath, if you want to participate in OID requests at all (either filtering or issuing your own), you must be integrated into the entire OID stack. That means that you provide FilterOidRequest, FilterOidRequestComplete, and FilterCancelOidRequest handlers. You don't need to do anything special in these handlers beyond what the sample does, except again detecting OID requests that your filter originated in the oid-complete handler, and removing those from the stream (call NdisFreeCloneOidRequest on them).
Performance
Do not worry about performance here. The first step is to get it working. Even though the sample filter inserts itself into the send, receive, and OID paths; it's almost impossible to come up with any sort of benchmark that can detect the presence of the sample filter. It's extremely cheap to have do-nothing handlers in a filter.
If you feel very strongly about this, you can selectively remove your filter from the datapath with calls to NdisFRestartFilter and NdisSetOptionalHandlers(NDIS_FILTER_PARTIAL_CHARACTERISTICS). But I absolutely don't think you need the complexity. If you're coming from an NDIS 5 protocol that was capturing in promiscuous mode, you've already gotten a big perf improvement by switching to the native networking data structures (NDIS_PACKET->NBL) and eliminating the loopback path. You can leave additional fine-tuning to the next version.
I want to write a client program that communicates with the application server via standard TCP/IP. The client can speak to the application server and be authenticated by simply speaking in a specific text based protocol. The traffic will be encrypted, but there won't be username/password. If another application tries to communicate with the application server and if the application doesn't use the correct text based protocol, the application server will silently discard packets.
Waiting for suggestions.
You can use a simplified version of TLV (Tag Length Value).
The basic idea is to define a set of message types which are represented by a code of fixed size (the T for Tag). Depending the type of message the contents of it (the V for Value) can very so you specify its length (the L for Length) before the contents. The Length field also has fixed size
Suppose you have one message used to send user data to the server. You can define a message like:
0x01 0x0018 0x11 0x0003 tom 0x12 0x000F tom#hotmail.com
Tag: 0x10 User data. Length: 0x0018 Value: sub tags
Tag 0x11: user name Length: 0x0003 Value = tom
Tag 0x12: email. Length: 0x000F. Value = tom#hotmail.com
Edited:
I was about to forget: Merry Christmas :)
Take a look at BEEP.
You might also find some good examples at four.livejournal.com; he's gotten good results writing an HTTP parser using the Ragel state machine generator, and also by hand.
if your not comfortable with the limitited functionality (verbs) provided HTTP just add more verbs. This is what the REST architecture is for.
If you want to continue down your path of folly (your talking about reinventing HTTPS), then use protocol buffers to create a protocol -- it will save you hours of grief.
-- edit --
If your objective is to understand the programming involved with web-servers, you might want to read apache's code dissected by the FMC group into a collection of models. I have read this PDF multiple times -- it is an absolute gold mine.
All the other comments are good, and stuff like BEEP, or doing some custom TLV encoding can get you along way, as well as using something like Google protocol buffers, but none of these are what I'd really call real simple.
A very simple text based protocol could just use a new line as the message delimiter. This is how IRC does it. Its not the most efficient, but if your messages are reasonably small it could work quite well. You could also prefix your message with a much shorter line telling the receiver how long the next message is.
If you want to use a light framework, look at libevent. It can assist in your IO and do line delimited reading for you.
If the language (protocol) is not already determined for you, then that is what you should design first, or look at something that already exists - XML, JSON chunks, netstrings, etc.
You can look at some of the sample code from TCP/IP Sockets in C.
It has many examples of doing client/server communication in C. Without more details, it's difficult to know what you really want to handle...
For communicating between bespoke apps, you can just send your text format in TCP packets. You can use an extremely simple text format, but you should make sure that it starts with some text that clearly identifies to your server that it is a packet from your client, and not from an imposter. (Clearly this is not terribly good security, but that's not the point of your question).
A good place to start is to use XML for your text-based format. This is dead simple to write/read, and is flexible and extensible so you can easily add more information to your packets at a later date - the biggest thing you can get wrong is to use a communications format that can't be extended!
Once you have basic comms working, you can enhance the format to send more information, add encryption and other security measures, and consider moving to a binary (more secure, more compact and efficient) format. BUt you can work your way to this stage in small easy steps.
So the right direction:
Get two programs talking via TCP. Just a simple packet with the text "bob" in it is enough at this stage, just to verify that the messaging is working. There are any number of simple tutorials on the web to get this going, and it's just a few lines of code once you work out what's needed.
Then build your packets. Start with the simplest approach that gives you a unique ID (to verify that the packet is from the right program) and a means to add new data to the packet easily in future. Xml is ideal for this. Don't worry about security, just concentrate on the actual "conversation" you wish to convey between the programs - what data they wish to exchange and how to encode it.
Step by step improve the communications protcol until it achieves what you want - smaller, faster, binary, more robust, fault tolerant, secure, etc. Each of these steps will be an interesting little challenge and by the time you've done them all you'll have learned a lot.
Look at the chapter on text protocols in 'The Art of UNIX Programming' by E S Raymond. It covers a lot of the relevant ideas at a high level, with good examples, and explanations of why they are good examples. It mentions BEEP.
I've recently read a book on this topic. It's called "TCP IP Sockets in C", by Michael J. Donahoo and Kenneth L. Calvert. You if you can afford it, it's a nice tutorial/reference book to have.
If you'd like you can try create the client<->server pair in Java, as it is easier to grasp the idea, and then rethink the solution at a lower level in C.