A two B-channel transfer (2BCT pr TBCT) occurs when Asterisk directs the telco switch to bridge two B-channels together, thereby freeing the B-channels on the digital interface for Asterisk, and taking Asterisk out of the loop for that call. This is achieved by Asterisk sending a FACILITY message telling the telco switch to do the channel bridging at its end. Once the telco accepts the 2BCT request, it sends DISCONNECT messages to both legs (both B-channels) of the call, and the call continues bridged at the telco. Some telco switches may send a NOTIFY message to Asterisk indicating when the call is hung up, but Asterisk silently ignores this message (no processing of the NOTIFY is performed by Asterisk).
In Asterisk only the EuroISDN switchtype (Also known as ETSI) is capable of initiating a 2BCT request and responding to a 2BCT request. All other supported switchtypes can only initiate a 2BCT request, not respond appropriately to one. This applies regardless of whether Asterisk is acting as the CPE or the NET side of the connection.
Requirements
Dgiium Digital card (Single, Dual , Quad or Octal span card)
Switchtype defined in chan_dahdi.conf, Currently the following Switchtype supports this feature
euroisdn
national
4ess
5ess,
dms100 (qsig is nonfunctional)
LibPRI 1.4.11.5 or greater.
Note: With the dms100 switchtype, there must be one inbound call into Asterisk and one outbound call from Asterisk for 2BCT to work. All other switchtypes work OK regardless of whether calls are inbound or outbound, any combination can be used.
Configuration
To enable: edit /etc/asterisk/chan_dahdi.conf, and ensure the following lines are above the channel definitions:
facilityenable = yes
transfer = yes
callwaiting=no
callwaitingcallerid=no
faxdetect=no
Note: According to source code faxdetect should not have any effect on asterisk being able to initiate a 2 B-Channel Transfers, however that your initial configuration should have this set to no to guarantee to guarantee asterisk to not have any interest on the audio, once you have confirmed that asterisk initiates the transfer you can enable for further testing. See Limitations for more information
Also, in your extension.conf, you need to to have DYNAMIC_FEATURES disabled, to Disable edit /etc/asterisk/extensions.conf and set DYNAMIC_FEATURES= in the general setting. You can also do it in the dial using using the following commands
exten => 1234567890,1,Set(DYNAMIC_FEATURES=)
exten => 1234567890,n,Dial(DAHDI/g0/987654321)
Limitations
Asterisk can only initiate a 2BCT when it has no interest audio of the call. This is the reason that you need to disable any feature that requires asterisk to listen to audio in order to perform actions (such as recordings, features codes, wait for caller ID information, etc )
Asterisk requires to be able to perform a native bridging with the DAHDI channels, you can confirm if asterisk is doing by native brigding by set the verbose level to 3 and attempt a transfer
CLI > --- Native bridging DAHDI/i1/1234-13f3 and DAHDI/i1/9874-13f4
2BCT is limited to calls are that on the same span. Call on diffrent spans will still be able to be transfer but asterisk will bridge the channels locally, therefore staying on the media path and not releasing the channels.
The telco switch must have 2BCT enabled for this to work.
Facility message
This is an example of how asterisk sends the transfer request to the telco. Please note that the FACILITY message should be sent moments after the native bridging is complete. For NI2, 5ESS, 4ESS switches the method will contain ROSE_NI2_InitiateTransfer. For DMS100 will be ROSE_DMS100_RLT_ThirdParty
-- Native bridging DAHDI/i1/5554443333-146a and DAHDI/i1/2221110000-146b
PRI Span: 1 Adding facility ie contents to send in FACILITY message:
PRI Span: 1 ASN.1 dump
PRI Span: 1 Context Specific/C [1 0x01] <A1> Len:19 <13>
PRI Span: 1 Integer(2 0x02) <02> Len:2 <02>
PRI Span: 1 <13 90> - "~~"
PRI Span: 1 OID(6 0x06) <06> Len:7 <07>
PRI Span: 1 <2A 86 48 CE 15 00 08> - "*~H~~~~"
PRI Span: 1 Sequence/C(48 0x30) <30> Len:4 <04>
PRI Span: 1 Integer(2 0x02) <02> Len:2 <02>
PRI Span: 1 <13 8B> - "~~"
PRI Span: 1 ASN.1 end
PRI Span: 1 INVOKE Component Context Specific/C [1 0x01]
PRI Span: 1 invokeId Integer(2 0x02) = 5008 0x1390
PRI Span: 1 operationValue OID(6 0x06) = 42.840.10005.0.8
PRI Span: 1 operationValue = ROSE_NI2_InitiateTransfer
PRI Span: 1 InitiateTransfer Sequence/C(48 0x30)
PRI Span: 1 callReference Integer(2 0x02) = 5003 0x138B
PRI Span: 1
PRI Span: 1 > DL-DATA request
PRI Span: 1 > Protocol Discriminator: Q.931 (8) len=29
PRI Span: 1 > TEI=0 Call Ref: len= 2 (reference 775/0x307) (Sent to originator)
PRI Span: 1 > Message Type: FACILITY (98)
PRI Span: 1 TEI=0 Transmitting N(S)=18, window is open V(A)=16 K=7
PRI Span: 1
PRI Span: 1 > Protocol Discriminator: Q.931 (8) len=29
PRI Span: 1 > TEI=0 Call Ref: len= 2 (reference 775/0x307) (Sent to originator)
PRI Span: 1 > Message Type: FACILITY (98)
PRI Span: 1 > [1c 16 91 a1 13 02 02 13 90 06 07 2a 86 48 ce 15 00 08 30 04 02 02 13 8b]
PRI Span: 1 > Facility (len=24, codeset=0) [ 0x91, 0xA1, 0x13, 0x02, 0x02, 0x13, 0x90, 0x06, 0x07, '*', 0x86, 'H', 0xCE, 0x15, 0x00, 0x08, '0', 0x04, 0x02, 0x02, 0x13, 0x8B ]