Asterisk - Detect answer via sip trunk - sip

I have a SIp trunk and I want to make an outgoing call to a external analog number and play a message when the other side answers it.
The problem is that the message be played as soon as it finish dialing the number, without waiting to answer.
Between SIP extensions works fine but not for outgoing external calls.
Any help?
Details:
The call is initiated from the CLI (for simplicity)
CLI> Originate Sip/MySipTrunk/destinationNumber extension 6789#from-sip
in the dial plan:
[from-sip]
ext => 6789.1, answer ()
ext => 6789,n, Playback (demo-congrats)
ext => 6789.n, hangup ()
Thanks....

You need setup answer detection on hardware used for dialout.
You also can write tone detection application, but that require guru level of knowledge and c/c++ programming experience.
There are no tone detect app in default asterisk install.
If detection is ok, issue can be with incorrect order in your "dialler". You can try switch order of call(first callout, not call ext) to be ok.
ps create dialling application require more then advanced level in asterisk. there are alot of other issues in this field.

I think there is an issue with your SIP trunk provider. I'm pretty sure there is 200 OK quite immediately after INVITE and then fake ringing in RTP audio.

not sure whether this was answered. but I see . btn your extension and answer application on the first line.
ext => 6789,1, answer ()
ext => 6789,n, Playback (demo-congrats)
ext => 6789,n, hangup

Related

How do I programmatically turn on/off Mute Groups on my Behringer X32?

I've got a Behringer X32 rack, which uses an extension of the OSC (Open Sound Control) protocol. This particular rack communicates via UDP packets on port 10023. A fellow named Patrick Maillot actually has some pretty extensive albeit unofficial documentation of the protocol, including multiple executables you can download to interact with the system (outside of the official Behringer apps).
What I would like to do is pretty simple, though I'm having a hard time getting up to speed with this. I want to be able to mute and subsequently un-mute Mute Group 1 on my device. The mute group is already set up; all I want to do is utilize the protocol to either activate or deactivate it.
I can successfully connect to the rack using the X32_Command.exe program. But wading through the documentation, here's what I came up with as my best guess for which commands I should be sending:
/config/mute/1/ON
/config/mute/1/OFF
However, I don't think I have the syntax right (or maybe I've just got the wrong set of commands altogether), because those don't seem to do anything. In the X32_Command.exe console application I appear to receive the following responses when issuing those commands, respectively:
->X, 20 B: /config/mute/1/ON~~~
->X, 20 B: /config/mute/1/OFF~~
However, nothing actually happens on the rack. The mute group isn't affected at all when I issue these commands. How do I get this working? What am I doing wrong?
Just saw this (better late than never). The correct syntax for X32_Commmand.exe would be (as stated in the documentation):
/config/mute/1 ,i 0
/config/mute/1 ,i 1

Sending at commands to mobile phone

I try to find library which may make a call from mobile phone and receive status of answer(answered, busy, missed etc.) Mobile phone will be Nokia 6300 or any other which will more optimal for this target. Phone will be connected through USB. The ideal solution - is cross-platform library (but distribution platform will Windows). I glad to get any suggestions how to solve my goal including sending AT commands.
Thank you!
I assume you are talking about voice calls, right? For just the basic functionality you can look at the response from ATD and use atinout, e.g.
C:\>echo ATD123456890; | atinout - COM14 -
OK
C:\>
for a successfully answered call, and with BUSY instead of OK for a busy call, and not answered I think will return NO CARRIER.
Now, I have not tested atinout with a modem on windows, so I do not know how well this works, but I know it compiles fine with both cygwin and mingw, but the cygwin compiled binary seems not to be able to open a com-port properly, so try first compiling with mingw. By all means report success/failure on this.
For additional call progress information, I think there is some newer command specified in the latest versions of 27.007 for this which is unlikely supported by your phones, but AT+CIND is probably supported and you might also get some useful information from AT+COLP and similar commands.
Try to play with at+clcc.
Currently this is only command I could find to detect whether call was initiated.
It returns complex string: "1,0,2,.....", so you should start timer task and track third digit: 2 - init the call, 0 - call dropped, 3 - wait signal received (ringing).
check this help http://www.activexperts.com/serial-port-component/tutorials/gsmdial/

Testing from JUnit if a SIP Soft Phone is ringing, answered a call, disconnected

I want to initiate calls to two numbers using a 3rd party API. I need to make sure that the devices ring when they get the calls, media starts to transmit when the call is answered, and the call is terminated when hungup.
Ideally I would like to do this from JUnit tests so that I can automate this whole process. But any other tool will also be fine.
So this is what I want to do programatically,
1) Configure two SIP soft phones to answer on 2 different numbers using some credentials provided by the test.
2) Make a call using the API
3) Assert that two phones are in ringing state
4) Answer the call
5) Assert that RTP media is being transmitted among them
6) Hang up
7) Assert that the call is now successfully disconnected
I am quite new to telephony, so would appreciate any pointers on any tool or SDK that will help me accomplish this.
Please check out SipUnit https://code.google.com/p/commtesting/wiki/SipUnit.
It can do all above except check out the media is flowing yet.
Check out the KitCAT framework. It's based on JUnit and can support all of your requirements. It supports multiple user agents, which can all be coordinated within a test case. It also provides coordination with other protocols (e.g., RTP, HTTP).
Sample code:
SIPAgent callee1 = createAgent("callee1"); // sip:callee1#host
SIPAgent callee2 = createAgent("callee2"); // sip:callee2#host
// invoke your API here
invoke3rdPartyAPI(callee1.getSipURI(), callee2.getSipURI());
pause(2000);
assertThat(callee1, is(invited()));
assertThat(callee2, is(invited()));
callee1.answer();
callee2.answer();
pause(500);
assertThat(callee1, is(connectedTo(callee2))); // check for SDP match
callee1.playAudio(audioFileName);
pause(500);
assertThat(callee2, has(incomingMedia());
callee1.disconnect();
pause(500);
assertThat(callee2, is(disconnected()));
Check out the complete API here.

How to tell the difference between an offline and online mobile phone via sip?

For a toy project I want to find out if a mobile phone is connected to gsm or not. So I thought "Okay, let's use my local sip provider and see".
But in both cases, the thing goes like this:
I send an INVITE
0 s: I get a 100 Trying
5 s: I get a 183 Session description
I get an audio stream, in the one case with the ringing, in the other case with a "The person you are calling is…"
If I wait long enough (~ 40 s), I get a more appropiate status code like 180 Ringing.
Audio analysis is not an option, really.
Any hints on where to go now?
(I used twinkle for testing and a local german sip-provider.)
This issue is endemic in the way telephone networks work, and is not specific to SIP or IP. It's why, when you place a call to another country and the number is busy, you might sometimes hear your local country's busy tone, or you might hear a different busy tone that comes from the other country. In the latter case you cannot detect except by audio analysis, what the problem is. In SS7 and ISDN we speak of Q.931 cause codes instead of SIP error codes, but the principle is the same.
There's an argument to be made for configuring telephone systems to emit status codes instead of audio error messages. For callers using normal phones, the originating switch (the one closest to the caller) can then map that code to the appropriate spoken error message or audio tone. That way, when the call is being placed by software rather than by a person, the software can have access to the actual error code right away.
On the other hand you can also argue for having the remote switch (the one nearest the destination or the one that encounters the problem) speak its own error message. That switch knows best what the actual problem is. For example, a mobile operator can emit a spoken error message saying that the mobile phone you are trying to call is currently out of range. There is no Q.931 code (or SIP error code for that matter) with that meaning. It could return 27=Destination out of order?? Or 35=Destination unattainable?? Both of those codes are so esoteric, who knows what error message the local switch would translate them to (in practice: probably just a reorder tone, which is really user-unfriendly to a human caller). And when you try to map Q.931 cause codes to SIP error codes back and forth, even more information is lost because the codes really don't match up well at all. It's likely to be a much better user experience for the caller if the remote switch just plays back an informative, appropriate, recording which describes the problem.
Since there is this dilemma (arguments on both sides), we can conclude that this will not likely be resolved by completely standardizing on one way or ther other way anytime soon.
Anyway, sometimes this is configurable: your SIP provider may be able to configure your trunk for coded errors instead of recorded messages. If they offer this (some do), it's worth a try to set this option. But results will vary: this option only affects its local behaviour. In general if you want immediately call clearing with cause code and are instead getting a recorded error message from the other end, you will not be able to do anything about it, because the switch that makes the decision on which way it's going to respond is the remote one.
When using the audio message method, a proper Q.931 cause code or SIP error code usually comes eventually (after the recording is finished), but as you point out, it's probably too late by then.

Asterisk callback with IVR survey

I´m pretty now to all this Asterisk-thingy and I wonder, is there a way how to call a user back from asterisk after he ended (hangup) call and give him a IVR survey, then save results somewhere (in form of audio records or DTMF inputs) ?
Sure there are alot of way to do that. But all require understanding of how asterisk works.
Hangup events can be detected by "h" extensions something like this
exten => h,1,System(/etc/asterisk/create_callback.sh)
After that you have create script for callback, see
http://www.voip-info.org/wiki/view/Asterisk+auto-dial+out
You need create IVR in your dialplan
http://www.voip-info.org/wiki/view/Asterisk+Dialplan+Introduction
If you have programming experience you can use AMI(Asterisk Manager Interface) to generate your calls from Asterisk to your customers, based on whatever logic. Once the customer answer the call all you have to do is redirect it to your IVR context.
For the IVR(survey) portion, you may want use AGI(Asterisk Gateway Interface). You can access both APIs with virtually any programming language. Take a look of the following:
Adhearsion (Ruby)
Asterisk-Java or Astive Toolkit (Java)
PHPAGI (PHP)
Good luck.