[asterisk-users] PRI TBCT - Practical Experience, Anybody?

[Matthew Fredrickson]

Jay R. Ashworth wrote:
> On Mon, Sep 08, 2008 at 11:28:13AM -0500, Matthew Fredrickson wrote:
>>>> For DMS100's version of TBCT, called RLT, one leg *must* be inbound and 
>>>> the other *must* be outbound.  No other combination is going to work. 
>>>> This is explicitly mentioned in the protocol in RLT.
>>> Ok.
>>>
>>> Just found this in my archive.
>>>
>>> Matt: should I assume that this implies that if my switch is provisioned
>>> for NI2, and my Asterisk is set to DMS, that things aren't going to work
>>> well at all?  :-)  (Outbound calls, FWIW, seem to work fine like that...)
>> Probably not.  You can obviously try this out, but don't be surprised if 
>> this doesn't work.  You usually want to have your switchtype (which 
>> likewise sets the version of TBCT which is used) set to the same thing 
>> that the other end is provisioned to be.
> 
> Ok.  I've run a simple test:
> 
> exten => 727xxxxxxx,1,Dial(${TRUNKY}/727yyyyyyy,,r)
> exten => 727xxxxxxx,2,Hangup
> 
> Where TRUNKY is a group that points to the same T-1 on which the calls
> are coming in.
> 
> And what I get is:
> 
> -- Accepting call from '727zzzzzzz' to '727xxxxxxx' on channel 0/1, span 4
> -- Executing Dial("Zap/73-1", "Zap/g3/727yyyyyyy||r") in new stack
> -- Requested transfer capability: 0x10 - 3K1AUDIO
> -- Called g3/7276471274
> -- Zap/74-1 is proceeding passing it to Zap/73-1
> -- Zap/74-1 is ringing
> -- Zap/74-1 answered Zap/73-1
> -- Attempting native bridge of Zap/73-1 and Zap/74-1
> -- Channel 0/1, span 4 got hangup request, cause 16
> -- Hungup 'Zap/74-1'
> == Spawn extension (default, 727xxxxxxx, 1) exited non-zero on 'Zap/73-1'
> 
> (I think I got all those numbers sanitized properly.)
> 
> And yes, the call went through, and had the CNID of the originating
> phone, as I want.
> 
> So, since I can't tell from the logs -- no timestamps -- I have to guess
> from when the messages show up, but I can't tell if the attempted native
> bridge is *succeeding*.  How would I know that it had?  We do
> *successful* ones in other contexts, and I don't recall seeing a
> 'success' message on those.
> 
> Will I actually need to do PRI debug on that span to tell?
> 
> Or will seeing "hangup" messages while I'm still talking be the solution?

Seeing hangup messages on the console while the audio path remains 
indicates success :-)

--
Matthew Fredrickson
Digium, Inc.