Topic: SAIL - Using the hash key as the send key

[ldkeen]

I'm trying to get the hash key (#) working as the "send key" in SAIL but having some problems:
If I dial a number then hit the # key it works perfect - the call is initiated immediately as expected, but if I receive a call and try to blind transfer then hit the hash key it doesn't work. Is this normal behaviour? example:
dial 5000 then # the call is initiated straight away
receive a call then decide to transfer:
dial # (announcement transfer) dial 5001 then # but get invalid. It appears the # during the transfer is not being interpreted as the send key. If that's a bit confusing here's some logs:
Normal dialing (5001#)

Code: [Select]

-- Executing [5001@internal:1] AGI("SIP/5000-0898a850", "selintra|OutCluster|5001") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script selintra completed, returning 0
    -- Executing [5001@default:1] AGI("SIP/5000-0898a850", "selintra|InCall|") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script Executing Application: (Dial) Options: (SIP/5001|30|tTwW)
    -- Called 5001
    -- SIP/5001-08988610 is ringing
  == Spawn extension (default, 5001, 1) exited non-zero on 'SIP/5000-0898a850'
    -- Executing [h@default:1] Hangup("SIP/5000-0898a850", "") in new stack
  == Spawn extension (default, h, 1) exited non-zero on 'SIP/5000-0898a850'

transfer during call (transfer call to 5001#)

Code: [Select]

-- Executing [5000@internal:1] AGI("SIP/5003-08988728", "selintra|OutCluster|5000") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script selintra completed, returning 0
    -- Executing [5000@default:1] AGI("SIP/5003-08988728", "selintra|InCall|") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script Executing Application: (Dial) Options: (SIP/5000|30|tTwW)
    -- Called 5000
    -- SIP/5000-087bee00 is ringing
    -- Call on SIP/5000-087bee00 left from hold
    -- SIP/5000-087bee00 answered SIP/5003-08988728
    -- Started music on hold, class 'default', on SIP/5003-08988728
    -- <SIP/5000-087bee00> Playing 'pbx-transfer' (language 'en')
    -- Stopped music on hold on SIP/5003-08988728
    -- AGI Script selintra completed, returning 0
    -- Executing [5001#@internal:1] AGI("SIP/5003-08988728", "selintra|OutCluster|5001#") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/selintra
    -- AGI Script selintra completed, returning 0
    -- Sent into invalid extension '5001#' in context 'default' on SIP/5003-08988728
    -- Executing [i@default:1] BackGround("SIP/5003-08988728", "invalid") in new stack
    -- <SIP/5003-08988728> Playing 'invalid' (language 'en')
    -- Executing [i@default:2] Hangup("SIP/5003-08988728", "") in new stack
  == Spawn extension (default, i, 2) exited non-zero on 'SIP/5003-08988728'
    -- Executing [h@default:1] Hangup("SIP/5003-08988728", "") in new stack
  == Spawn extension (default, h, 1) exited non-zero on 'SIP/5003-08988728'
If I don't hit the # key during the blind transfer then after about 10 or 15 seconds the call is transfered without problems. Would be great to have the send key (#) work during transfers as well.
Regards, Lloyd

[SARK devs]

Hi Lloyd,

Hope you are well.

I'm assuming these are POTS phones we are talking about, because we wouldn't recommend the internal asterisk transfer mechanics for SIP devices... However, here's what we know...

If I don't hit the # key during the blind transfer then after about 10 or 15 seconds the call is transfered without problems

You're just too impatient mate - it's 8 seconds.

The reason the # doesn't work a second time is that you're actually in an application at that point (transfer).  However, you  can adjust the timedelay at dial end in Headers=>features.conf=>transferdigittimeout.

Normally we run this at around 3 seconds for pots phones, which is usually good enough.  As to a terminate key (like the #), you would have to play around with features.conf and look at the source code to see if there is such a thing.

Best

Jeff

[ldkeen]

Hey Jeff,
Thanks for the reply. This was happening with an analogue phone connected to a Linksys PAP2T. I just assumed that it was the PAP2T that was causing the problem. But I tested with my GXP2000 and it does the same thing (though I believe there is a setting for the GXP2K to use the # key as the send key). I got my mate to test his and he said that his worked (-443). It's no great drama, just trying to tweak the system a little.

You're just too impatient

That's what my wife keeps telling me
Thanks, Lloyd