Callback Application

New features you'd like see on SIP Sorcery
Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Callback Application

Post by Aaron » Sun Jul 13, 2008 10:30 am

Hi All,

There has been some discussion recently about the shortcomings of the Callback application so I thought I'd start a discussion to see what most people are trying to do with it.

The way the Callback mechanism currently works involves a bit of a hack. First the sipswitch places a call from itself to the first call leg. Once that call leg is answered there will only ever be silence as the sipswitch does not deal with audio so can't play anything. The call is then placed to the second leg and as soon as that leg is answered the first call is re-invited to the second leg and the second leg is re-invited to the first leg. As you're probably realising it's a bit convoluted.

The main problem with this approach is that there will be silence on the first leg until the second leg is answered. When coming up with the application this did not seem like a problem as the original requester wanted to use it to call himself back. So as long as he put his own number as the first call leg he would know to expect a brief period of silence.

Since then the use of the application seems to have extended and people are using it to place calls where they won't be on the first leg and the period of silence is causing problems.

There are a few different ways I can think of that the Callback application could be enhanced:

1. Probably the best one would be that the sipswitch partners with a Media server so that something can be played when the first call leg is answered to let the person know what's going on. For example the sipswitch could ring the first call leg and as soon as it's answered transfer it to a SIP destination that plays back a recorded prompt such as "please wait while your call is connected".

2. An alternative would be to blind transfer the first call leg immediately upon answer. This would mean the first person would pick up and then very shortly after would hear the ringing tone for the second call leg. The issue with this is that the provider you send the first call leg to has to support blind transfers. From my testing not too many providers do support blind or attended transfers.

If anyone has any additional ideas or views please feel free to contribute.

Regards,

Aaron

trottm
Posts: 38
Joined: Sat Jul 28, 2007 9:52 pm

Post by trottm » Tue Jul 15, 2008 10:15 pm

This may be getting away from tweaking the existing callback feature but the most valuable use of callback for me is Direct Inward System Access (DISA). The development of many of the other PBX offerings showed that this was a much requested feature. EasyPBX had a good implementation (before they disappeared) which was feature rich, although that also made it rather heavy handed. My favourite DISA aplication now is at LiberaIlVoip.com, although sadly only in Italian. It is a good starting point for comparison as it is very fast and simple with virtually no audio, not even a dialtone. It just works very well.

An example application would be:
On holiday you take a travel SIM with free incoming calls. You dial a DID registered with MSS solely to trigger callback - saves need for IVR. Server traps CallerID and hangs up (or not as with LIV). After a short delay (preferably adjustable) MSS initiates first call leg with cheap provider e.g. Voipcheap to your cellphone. For security MSS could be pre-configured with the phone numbers of those phones eligible to invoke callback. Saves need to type in Callthru PIN. After the call is answered, MSS invokes the DISA call and you hear a dialtone or indeed silence. You enter the number you wish to call which is dealt with through your dialplan. That way you can have shortcut numbers to speed up the dialing of frequently called numbers.

If you want some instructions on setting up DISA at libeailvoip so you can check it out let me know.

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Post by Aaron » Wed Jul 16, 2008 8:01 am

trottm wrote:An example application would be:
On holiday you take a travel SIM with free incoming calls. You dial a DID registered with MSS solely to trigger callback - saves need for IVR. Server traps CallerID and hangs up (or not as with LIV). After a short delay (preferably adjustable) MSS initiates first call leg with cheap provider e.g. Voipcheap to your cellphone. For security MSS could be pre-configured with the phone numbers of those phones eligible to invoke callback. Saves need to type in Callthru PIN. After the call is answered, MSS invokes the DISA call and you hear a dialtone or indeed silence. You enter the number you wish to call which is dealt with through your dialplan. That way you can have shortcut numbers to speed up the dialing of frequently called numbers.
Hi trottm,

That sounds very close to what the person that originally requested the Callback application in the sipswitch wanted to be able to do with it. The only caveat is that the server you enter your numbers into has to be a 3rd party provider and not the sipswitch.

As an example at Blueface we provide a mini-gateway type IVR for our users who are out on the road. It's convenient for them to dial in to get cheap international calls when they are away from their VoIP lines. If I wanted to I could send the second leg of a Callback from my sipswitch to that IVR to allow me to place calls where I could enter the number.

Regards,

Aaron

User avatar
rmclaren
Posts: 68
Joined: Sun Feb 17, 2008 10:28 pm
Location: Connecticut

Post by rmclaren » Mon Jul 21, 2008 1:47 am

I would take up trottm's offer with regard to DISA at LiberaIlVoip.com. I'm sure I could eventually struggle through the Italian interface. However, a few hints would be much appreciated.

trottm
Posts: 38
Joined: Sat Jul 28, 2007 9:52 pm

Post by trottm » Tue Jul 22, 2008 2:45 pm

Even better someone has already been there before me:

http://scopezoom.com/guide8.htm

This guy has a slightly different implementation as he uses Voxalot for both trunks. I just use it for outbound to take advantage of the dialplan and therefore have the shortcuts etc. Hope it works for you, if not let me know.

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Post by Aaron » Sun Aug 03, 2008 10:14 am

Hi All,

I've started work on a Callback application approach that allows the destination number to be keyed in. Because a media server is required to do this I have used a Blueface Asterisk server to do the DTMF decoding. As with the rest of the sipswitch this service is provided as is and support for it should be requested through this forum and not through the blueface support channels.

In addition the method of use described below is not how we intend the app to end up but is an interim step to get an understanding of the mechanism and also hopefulyl some feedback from anyone reading this. There are a few tricks going on so unfortunately using the method below while not difficult to set up is not simple to understand and is not for the faint hearted.

The way the mechanism works is:

1. You need to forward a call to 306@194.213.29.54:5061 to get an audio request to enter your number (press # to complete the number),

2. After the number has been entered your call will hangup and this is where there is a new trick. At this point the Blueface Asterisk server has decoded the DTMF entered and sends a SIP MESSAGE request back to the sipswitch with the number in its body. Previously the sipswitch would have rejected MESSAGE requests but now it has been programmed to accept them and forward them through to the dial plan (script plans only),

3. After the message request has arrived in the dialplan the number entered in step 1 is available for use in the callback application.

The Ruby script needed is demonstrated below:

Code: Select all

#Ruby

## New processing block for MESSAGE requests.
if req.Method.ToString() == "MESSAGE".ToString() then

  sys.Log("message=#{req.Body}")
  sys.Callback("yourphone@provider", "#{req.Body}@provider")

else
 
  ## Put your existing Ruby dial plan here.

  ## The forward to get the MESSAGE request with the number generated is.
  sys.Dial("306@194.213.29.54:5061")

end
It's pretty complicated at this point and the next step is to get to a stage where after the audio prompt for the number is dialled and that call is hungup the sipswitch can catch the BYE and then do some dial plan processing without causing the original call to be hungup. That should make it a lot simpler to use.

In the meantime for anyone brave enough to try there is the opportunity to initiate arbitrary call forwards based on a callback...

Regards,

Aaron

sudeepdennis
Posts: 43
Joined: Mon Sep 24, 2007 4:40 pm
Location: bangalore, india

Post by sudeepdennis » Sun Aug 03, 2008 2:28 pm

Hi Aaron.

Thanks for the new setup.

But I think there is a problem with the sys.Callback as such. Everything works fine if both the calls are to two SIP providers. It used to work fine (a month ago when i tried).

But if one of the legs is a account@local or account@sip.mysipswitch.com (account being my main or sub account), the callback does not work. Monitor says

Code: Select all

" Call not proceeding as one of the call legs did not result in a valid destination. 
"
Rgds,
Sudeep

Edit: I am able to call these accounts using the sys.Dial feature though.

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Post by Aaron » Mon Aug 04, 2008 1:07 pm

Hi Sudeep,

There was a bug with the Callback function and forwarding to a local user when the Callback was initiated from a MESSAGE request as is the case with the new approach. Thanks for highlighting it.

I have fixed up the signalling bug so that now the Callback calls will be signalled correctly. However during testing I noticed that I wasn't able to set up calls properly if my own sipswitch account was used as a call leg in the Callback. This was because one of the mechanisms that it relies on is the ability to send an RTP packet to each leg of the Callback in order to get the RTP flowing to the correct sockets. If your phone happens to be behind a NAT, as mine is, this packet will never get through and the Callback will never get any audio. This is not somehting new and would have always been present.

Regards,

Aaron

trottm
Posts: 38
Joined: Sat Jul 28, 2007 9:52 pm

Post by trottm » Thu Aug 07, 2008 10:01 pm

Aaron,
The new code works great apart from the callback statement doesn't execute. I tried just a simple callback via two SIP providers but still no joy. Yet if I comment out all the code around it and dial in to MSS the callback is triggered. I am confused.
Otherwise the number pickup is great as there are no problems with DTMF etc. Good start.

User avatar
rmclaren
Posts: 68
Joined: Sun Feb 17, 2008 10:28 pm
Location: Connecticut

Post by rmclaren » Sat Aug 09, 2008 8:23 pm

I hope this means that any Asterisk server can provide this function. If I set up a subaccount for my Unslung NSLU2 with Asterisk 1.6, can it be used to assist the Callback procedure for my calls? If so, would you be able to share your Asterisk coding?

Post Reply