Hook flash / hook switch / blind transfer on non-zap channel

Asterisk Asterisk Support
1

Background:
I have an obi110 extension hooked up to my PBX in a Flash (Piaf) box. The obi110 acts as phone extension, google voice trunk and PSTN trunk. Calls can be answered and sent via the phone extension. It works, so far. Now, my current challenge is utilizing the blind transfer feature of asterisk. My PSTN line has the tandem transfer function (meaning I can transfer the current individual on the current line to another number by flashing the current line, dialing the new number, and hanging up). More info at: obitalk.com/forum/index.php?topic=2678.0

Question:
Is it possible to flash a non-zap channel via the dial plan? If so, how?

Comment:
Such a simple question but I can’t find the answer anywhere.

2

RFC 2833 hook flash is deprecated by RFC 4733.

I’m not sure if Asterisk can generate the hook flash RFC 2833 event, although it has some support. There is also little guarantee that the peer SIP system would understand it.

The Transfer application may help you do this by the standard SIP means, but note that Asterisk only does blind transfers, and the handling of failed transfers is flakey.

This should have been asked on Asterisk Support.

3

I should add that Asterisk offers to support incoming media event type 16 (hook flash) but I’ve never come across a peer system that also offers this capability.

4

Thank you for moving this topic to Asterisk Support.

On my trunk and obi110, my dtmfmode=RFC2833. Can I send the media event 16 hook flash and, if so, how? I currently have an ivr with an option that activates the following custom destination: custom-tandem-transfer,3213214321,1

In my extensions_custom.conf, I have the following:

[custom-tandem-transfer] exten => _X.,1,Playback(followme/pls-hold-while-try) exten => _X.,n,senddtmf(ENTERINFO) exten => _X.,n,senddtmf(${EXTEN}) exten => _X.,n,Hangup()

I tried replacing ENTERINFO with F and then R. Both crashed when ran.

5

If it really crashed, you need to report it on issues.asterisk.org!

I’d have to trawl through the code to see if and how senddtmf can be used to source a hook flash. In any case, you ought to look at the SDP negotiation, as, if the downtream system doesn’t offer to accept telephony event 16, Asterisk shouldn’t send it.

6

I am not sure if senddtmf® or senddtmf(F) is a supported function. By crashed, I mean the IVR hangs up the line due to non-zero result. I looked at SDP negotiation, which I interpreted to mean register, invite, etc. but I am unclear how that relates to RFC transmission. Doesn’t RFC specify the type of DTMF transmissions to use? Also, I am unclear whether obi110 will accept event type 16 (due to limited information) but I want to at least try sending one to see if it does anything with it. The actual obi110 unit is listed to say that it does perform hook flashes.

7

Unless the remote party’s SDP contains:

a=ftmp:10 0-16

assuming that there was also an

a=rtpmap:101 telephone-events…

and the m line contained 101,

the remote side will not accept RFC 2833 hook flashes.

The important thing is that the 16 is there. I think it could also be 0-15,16, etc.

The RFC describes the possibilities, but for anything other than 0-9, a, b, c, d, * and #, the SDP must negotiate that event in.