Sippy Software, Inc.

This is an application that user cannot use directly by calling some number. To initiate the application either the XML-RPC interface should be used or a special CLD translation rule on connection can be used or A record should be inserted directly into the callback_requests table.

The main use case of the application is as follows.

1. A record via tr. rule or by other means is created in the callback_requests table.
2. Callback monitor discovers the record and initiates call leg to original_cli number with the given identity (original_cli as CLI, username or authname as authname and md5secret).
3. User picks up his phone.
4. 2 Way Callback application starts and initiates the call to the actual CLD number with the given identity (username as CLI, authname and md5secret). Each of the identity values can be optionally overridden by explicit specification in corresponding field twoway_cli, twoway_authname and twoway_md5secret.
5. The phone is picked up at the destination.
6. Conversation takes place.

Using special CLD translation rule you can initiate a 2 way Callback

You may use a translation rule to create a 2 way callback request.

Call routing setup

1. Add vendor connection. Set the Asterisk's host/port in the Destination field of Vendor Connection (ex: 192.168.0.100:5062).
2. Set the CLD Translation Rule for the connection to the value: s/.*/ani_2way_<actual CLD>/
3. Add route to this connection.

* For example if a user should be called back and then connected to the extension 12345 then the CLD translation rule should be look like this: s/.*/ani_2way_12345/

Using the callback_requests table directly

Lets review the table callback_requests, only significant fields.

• username, authname and md5secret are the identity of the user to use when originating both call legs. The md5secret is HA1 value in hexadecimal representation. HA1 is calculated as MD5 of the string "<username>:<realm>:<password>" (without quotes).
• twoway_cli, twoway_authname and twoway_md5secret are optional identity pieces to use when originating second call leg.
• original_cli - The CLI of the user that requested the callback.
• original_set_cli - use this CLI when creating callback call leg.
• original_cld - This field must contain a value in the form "2way_<actual CLD>".
• next_call - This field shows the time of the next attempt to call. It may be useful for scheduling the callback in a future.
• call_id - This field can be preset to some value in which case the callback call will use this Call-ID. If the field contains NULL then the random value is generated and placed in this field during the call.
• twoway_call_id - This field can be preset to some value in which case the call to destination will use this Call-ID. If the field contains NULL then the default value is constructed based on call_id and placed in this field during the call.
• status and result - contain current status of the call. More information see here 

For example if the user 801 should be called back at extension 87654321 and then connected to the extension 12345 then the corresponding SQL query should look like this:

  INSERT INTO callback_requests (
     username, 
     authname,
     md5secret,
     original_cli,
     original_cld
  )
  VALUES (
    '801',
    '902',
    '<md5secret>',
    '87654321',
    '2way_12345'
  )

NOTE: The authname value can be omitted in which case the username value will be used as an authname instead.