Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
Hi Guys, I am sorry if my issue is not related to this but I think it is. I have a PRI with Bell Canada and when I dial in and have the call transfered to a context to dial out and then have those two channels bridged, the call disconnects with cause 16 just exactly as Jay R. Ashworth shows in his CLI output. Bell Canada support RLT or know as 2BCT or TBCT to some but we have not requested that feature. However, we don't care to keep two channels tied up. Is this not possible through PRI? [zap_bridge] exten = s,1,answer exten = s,n,Dial(ZAP/g0/416777) If incoming leg of call is through PRI and outgoing leg is through SIP or analogue ZAP everything works just fine. But the moment Call comes in through PRI and goes out through PRI both channels drop. I should say that call rings the 2nd party and 2nd party sees Caller ID info and when they press Talk then there is the busy signal. I can post all the debug and bore you with it but maybe someone already knows the answer. I have been looking for this for couple of days now and I don't seem to get anywhere with answers. Input is much appreciated. Bruce -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
Problem resolved with setting transfer=no in zapata.conf. On Mon, Apr 12, 2010 at 9:14 PM, bruce bruce bruceb...@gmail.com wrote: Hi Guys, I am sorry if my issue is not related to this but I think it is. I have a PRI with Bell Canada and when I dial in and have the call transfered to a context to dial out and then have those two channels bridged, the call disconnects with cause 16 just exactly as Jay R. Ashworth shows in his CLI output. Bell Canada support RLT or know as 2BCT or TBCT to some but we have not requested that feature. However, we don't care to keep two channels tied up. Is this not possible through PRI? [zap_bridge] exten = s,1,answer exten = s,n,Dial(ZAP/g0/416777) If incoming leg of call is through PRI and outgoing leg is through SIP or analogue ZAP everything works just fine. But the moment Call comes in through PRI and goes out through PRI both channels drop. I should say that call rings the 2nd party and 2nd party sees Caller ID info and when they press Talk then there is the busy signal. I can post all the debug and bore you with it but maybe someone already knows the answer. I have been looking for this for couple of days now and I don't seem to get anywhere with answers. Input is much appreciated. Bruce -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
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 = 727xxx,1,Dial(${TRUNKY}/727yyy,,r)
exten = 727xxx,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 '727zzz' to '727xxx' on channel 0/1, span 4
-- Executing Dial(Zap/73-1, Zap/g3/727yyy||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, 727xxx, 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.
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Fri, Sep 12, 2008 at 10:56:40AM -0500, Matthew Fredrickson wrote: 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 :-) Then, as I suspected, I'm failing. I need to confirm that it's actually provisioned with the carrier, and which switchtype I'm really on. Can *you* confirm, off hand, that 1.2 would do TBCT at *all*? Someone on IRC thinks it wouldn't. -- j -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
Jay R. Ashworth wrote: On Fri, Sep 12, 2008 at 10:56:40AM -0500, Matthew Fredrickson wrote: 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 :-) Then, as I suspected, I'm failing. I need to confirm that it's actually provisioned with the carrier, and which switchtype I'm really on. Can *you* confirm, off hand, that 1.2 would do TBCT at *all*? Someone on IRC thinks it wouldn't. It will only attempt it for DMS100 switchtype. You must have 1.4 libpri for any other switchtype. Matthew Fredrickson ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Fri, Sep 12, 2008 at 12:12:56PM -0500, Matthew Fredrickson wrote: Can *you* confirm, off hand, that 1.2 would do TBCT at *all*? Someone on IRC thinks it wouldn't. It will only attempt it for DMS100 switchtype. You must have 1.4 libpri for any other switchtype. Will libpri 1.4 work with asterisk 1.2? Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
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 = 727xxx,1,Dial(${TRUNKY}/727yyy,,r)
exten = 727xxx,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 '727zzz' to '727xxx' on channel 0/1, span 4
-- Executing Dial(Zap/73-1, Zap/g3/727yyy||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, 727xxx, 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?
And how, again, can I tell what's actually at the other end of the span?
Cheers,
-- jra
--
Jay R. Ashworth Baylink [EMAIL PROTECTED]
Designer The Things I Think RFC 2100
Ashworth Associates http://baylink.pitas.com '87 e24
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Those who cast the vote decide nothing.
Those who count the vote decide everything.
-- (Josef Stalin)
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
AstriCon 2008 - September 22 - 25 Phoenix, Arizona
Register Now: http://www.astricon.net
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Thu, Sep 11, 2008 at 12:41:12PM -0400, Jay R. Ashworth wrote: Will I actually need to do PRI debug on that span to tell? I did a pri debug to a file, I can see the call go, I see no indication that it actually tried to generate a TBCT/RLT request. Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Fri, Aug 15, 2008 at 03:03:23PM -0500, Matthew Fredrickson wrote: Let me clarify some of this. Under no circumstances can Asterisk receive a TBCT request. We just ignore them. We can initiate them however. There are different TBCT implementations, dependent on which switch type is used, with different restrictions associated with each switch type selected. For true TBCT (on switchtypes of NI2 and 5ESS, AFAIK), you can have any combination of inbound and/or outbound channels (one inbound/one outbound, two inbound, two outbound) and transfer them to the upstream switch. The protocol doesn't care. 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...) Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
Jay R. Ashworth wrote: On Fri, Aug 15, 2008 at 03:03:23PM -0500, Matthew Fredrickson wrote: Let me clarify some of this. Under no circumstances can Asterisk receive a TBCT request. We just ignore them. We can initiate them however. There are different TBCT implementations, dependent on which switch type is used, with different restrictions associated with each switch type selected. For true TBCT (on switchtypes of NI2 and 5ESS, AFAIK), you can have any combination of inbound and/or outbound channels (one inbound/one outbound, two inbound, two outbound) and transfer them to the upstream switch. The protocol doesn't care. 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. Matthew Fredrickson ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
Jay R. Ashworth wrote: I'll assume you've watched it on a PRI, so I'll defer, but I wouldn't expect that myself; I would expect that when you tell the switch to transfer it, you go immediately from one B channel to 0. You should expect that; in fact, that's what the 'TB' in 'TBCT' stands for... for a time, there are two B-channels involved. TBCT is a method of taking two existing already connected B-channels and linking them together into the network, it is not a 'transfer' facility where you provide a target DN and an existing call is 'transferred' to that destination. That feature is ELT (Explicit Line Transfer) and may also be known by other names, or possibly Call Deflection (CD) depending on whether you do it before the call is answered or after. In the scenario you outlined, the original caller (party A) calls this mediator (who answers as party B1). They then place a call (party B2) to you (party C), which you answer. Once that call is established, they can TBCT party A and party C, thus dropping the party B1/B2 legs. You will never see party A's identifying information on the call to you unless party B decides to provide it to you in some fashion; the network signaling would never know to provide it to you, since this is not a call transfer in the RDNIS sense of 'call transfer'. -- Kevin P. Fleming Director of Software Technologies Digium, Inc. - The Genuine Asterisk Experience (TM) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Tue, Aug 19, 2008 at 07:35:03AM -0500, Kevin P. Fleming wrote: Jay R. Ashworth wrote: I'll assume you've watched it on a PRI, so I'll defer, but I wouldn't expect that myself; I would expect that when you tell the switch to transfer it, you go immediately from one B channel to 0. You should expect that; in fact, that's what the 'TB' in 'TBCT' stands for... for a time, there are two B-channels involved. TBCT is a method of taking two existing already connected B-channels and linking them together into the network, it is not a 'transfer' facility where you provide a target DN and an existing call is 'transferred' to that destination. That feature is ELT (Explicit Line Transfer) and may also be known by other names, or possibly Call Deflection (CD) depending on whether you do it before the call is answered or after. In the scenario you outlined, the original caller (party A) calls this mediator (who answers as party B1). They then place a call (party B2) to you (party C), which you answer. Once that call is established, they can TBCT party A and party C, thus dropping the party B1/B2 legs. You will never see party A's identifying information on the call to you unless party B decides to provide it to you in some fashion; the network signaling would never know to provide it to you, since this is not a call transfer in the RDNIS sense of 'call transfer'. *Aha*. Got it. So whether I can, as a recipient, get the CNID of the call originated by the second party depends on whether they can send it to me. That is, *that* part is a capability of the second party, and the only capability the second party's IXC has to provide is bare TBCT. I understand better now, Kevin; thank you very much. I'm in that conference call in about 20 minutes. ;-) Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
You should expect that; in fact, that's what the 'TB' in 'TBCT' stands for... for a time, there are two B-channels involved. TBCT is a method of taking two existing already connected B-channels and linking them together into the network, it is not a 'transfer' facility where you provide a target DN and an existing call is 'transferred' to that destination. That feature is ELT (Explicit Line Transfer) and may also be known by other names, or possibly Call Deflection (CD) depending on whether you do it before the call is answered or after. In the scenario you outlined, the original caller (party A) calls this mediator (who answers as party B1). They then place a call (party B2) to you (party C), which you answer. Once that call is established, they can TBCT party A and party C, thus dropping the party B1/B2 legs. You will never see party A's identifying information on the call to you unless party B decides to provide it to you in some fashion; the network signaling would never know to provide it to you, since this is not a call transfer in the RDNIS sense of 'call transfer'. -- Kevin P. Fleming Kevin, This answer is excellent! Very well-worded and definitely useful to help someone grasp the idea behind TBCT. -MC ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Sat, Aug 16, 2008 at 09:35:10PM -0400, Ron Joffe wrote: On Saturday 16 August 2008 14:37, Jay R. Ashworth wrote: TBCT is a feature of LEC/IXC edge switches; there isn't much use for it in any other context. I don't care if you're using Asterisk to be an edge switch, but it's a *carrier* feature, by and large. Certainly in the specific instance I'm discussing, it is. Why would TBCT not be applicable in a scenario where * is being utilized as a slave to a main PBX. * might receive a call from the PBX, and then want to transfer it to another extension on the PBX itself. Hmmm. Perhaps. But if the Asterisk is upstream of the PBX, then the *PBX* would need to know how to deal with it. I see your point... but it's still orthogonal to what I need to know. :-) Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Fri, Aug 15, 2008 at 11:56:30PM -0500, Tilghman Lesher wrote: There's no hairpin involved: the point of TBCT is that you tie up *0* timeslots instead of 2, to forward a call. There is a hairpin involved. The call (for several milliseconds at least) is using two channels on the PRI before the 2BCT succeeds, and then the call no longer takes up any channels. It is only when the PRI detects the hairpin, through the native bridge code that it is able to detect that the call is eligible for 2BCT. I'll assume you've watched it on a PRI, so I'll defer, but I wouldn't expect that myself; I would expect that when you tell the switch to transfer it, you go immediately from one B channel to 0. Why would an Asterisk instance call itself on the same span? Very simple. Call your main number, and if you don't have special logic in your internal dialplan context to handle that, the call will go out to the telco and dutifully come right back in on the same circuit. Sure, but that's not a target for TBCT anyway. Similarly, Asterisk cannot complete a 2BCT request, if Asterisk is on the NET side of the PRI circuit. That might could be added in the future, but it is not supported now. So in summary, Asterisk can request 2BCT, but it cannot perform a 2BCT if requested from the other side. Nothing can perform a TBCT unless it's a PRI server, not a client; it's function of 5ESS's and DMSen; you have to be an SS7 speaker to do it in the first case. I don't think that's the case. Matt would know more, and his reply suggests that it certainly would be possible for Asterisk to do this. SS7 is not at all required here. Allow me to phrase it differently: TBCT is a feature of LEC/IXC edge switches; there isn't much use for it in any other context. I don't care if you're using Asterisk to be an edge switch, but it's a *carrier* feature, by and large. Certainly in the specific instance I'm discussing, it is. Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Saturday 16 August 2008 14:37, Jay R. Ashworth wrote: TBCT is a feature of LEC/IXC edge switches; there isn't much use for it in any other context. I don't care if you're using Asterisk to be an edge switch, but it's a *carrier* feature, by and large. Certainly in the specific instance I'm discussing, it is. Jay, Why would TBCT not be applicable in a scenario where * is being utilized as a slave to a main PBX. * might receive a call from the PBX, and then want to transfer it to another extension on the PBX itself. Thanks, Ron ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] PRI TBCT - Practical Experience, Anybody?
I may have to do some work with TBCT, and probably cross-carrier TBCT, here shortly, and I haven't ever worked with it. If anyone on the list ever has, I'd be interested to know: 1) Only the carrier first involved with the call has to actually be provisioned for it, correct? 2) Both incoming and outgoing calls can be TBCT'd? 3) If a placed call is transferred to me via TBCT, can I get the DN of the original target call sent to me as CNID? 4) Does it, in fact, matter if the call placer, and the TBCT target, are on the same IXC? I want someone to place calls for me, talk to the people for a while, and then do an unsupervised transfer to me wherein I can capture the other party's number off the call itself and feed the calls into my VICIdial/Asterisk instance. All my incoming lines are Zap/PRI. Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
1. The carrier you are connected to must be licensed for it and have the necessary software, if the carrier requires, your circuit(s) must be provisioned for it. The originating/destination carriers shouldn't matter. 2. Both incoming and outgoing calls can be transferred to a second outgoing call; I think it's theoretically possible to connect two incoming calls, but I haven't done that. 3. This may rely on your carrier. My carrier allows me to include anything I choose as outbound ANI--I don't abuse it. 4. To the best of my knowledge, the originating caller and destination can be anywhere in the world. Your scenario sounds workable to me. My experience (non-Asterisk) is using NI2 on DMS and 5E switches in North America. Carrier personnel are generally unfamiliar with TBCT and your initial installation will probably involve a little frustration. --Don Don Kelly PCF Corp Real Support for your Virtual Office TM 651 842-1000 888 Don Kell(y) 651 842-1001 fax -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jay R. Ashworth Sent: Friday, August 15, 2008 12:52 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: [asterisk-users] PRI TBCT - Practical Experience, Anybody? I may have to do some work with TBCT, and probably cross-carrier TBCT, here shortly, and I haven't ever worked with it. If anyone on the list ever has, I'd be interested to know: 1) Only the carrier first involved with the call has to actually be provisioned for it, correct? 2) Both incoming and outgoing calls can be TBCT'd? 3) If a placed call is transferred to me via TBCT, can I get the DN of the original target call sent to me as CNID? 4) Does it, in fact, matter if the call placer, and the TBCT target, are on the same IXC? I want someone to place calls for me, talk to the people for a while, and then do an unsupervised transfer to me wherein I can capture the other party's number off the call itself and feed the calls into my VICIdial/Asterisk instance. All my incoming lines are Zap/PRI. Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On 8/15/08, Don Kelly [EMAIL PROTECTED] wrote: 1. The carrier you are connected to must be licensed for it and have the necessary software, if the carrier requires, your circuit(s) must be provisioned for it. The originating/destination carriers shouldn't matter. Most carrier sales people don't know what TBCT is unfortunately, and even if a carrier is capable of doing it, it is a possiblity that not all of their equipment is capable of doing it. One client of mine tried to get TBCT working across all 16 of their PRIs(all on the same carrier) and it only worked on 4 of them, supposedly because not all of the telco equipment was capable of the feature. 2. Both incoming and outgoing calls can be transferred to a second outgoing call; I think it's theoretically possible to connect two incoming calls, but I haven't done that. This actually depends on the kind of PRI service you have. For instance with DMS100 circuits you can only do TBCT with calls that come in to your circuit, not with outgoing calls. As for connecting two incoming calls, since that is not possible in Asterisk(to natively bridge two incoming calls together) I can't see how you would get that to work even if it is possible in TBCT. I believe that only DMS100, NI2 and 5ESS PRI signalling protocals are capable of TBCT with the current zaptel code-base. Also, the two B channels involved in the TBCT have to use the same D channel. MATT--- ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Fri, Aug 15, 2008 at 02:37:46PM -0400, Matt Florell wrote: Most carrier sales people don't know what TBCT is unfortunately, and even if a carrier is capable of doing it, it is a possiblity that not all of their equipment is capable of doing it. One client of mine tried to get TBCT working across all 16 of their PRIs(all on the same carrier) and it only worked on 4 of them, supposedly because not all of the telco equipment was capable of the feature. I expect to fight this battle, yes. :-) This actually depends on the kind of PRI service you have. For instance with DMS100 circuits you can only do TBCT with calls that come in to your circuit, not with outgoing calls. As for connecting two incoming calls, since that is not possible in Asterisk(to natively bridge two incoming calls together) I can't see how you would get that to work even if it is possible in TBCT. To be more clear, what I'm after is to have *someone else besides me* place calls out their PRI, and then TBCT those placed calls to my DN. By the time the calls get to me, they should just be standard phone calls. So I expect the call-placing-party to need TBCT, but not me. I believe that only DMS100, NI2 and 5ESS PRI signalling protocals are capable of TBCT with the current zaptel code-base. Also, the two B channels involved in the TBCT have to use the same D channel. And I'm probably not concerned with whether Asterisk can deal with TBCT, because Asterisk probably won't be involved at that stage; just once the call's transferred to me. But before I inquire of said second party whether they *can* do that, I wanted to confirm it was possible. Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Friday 15 August 2008 13:45:11 Jay R. Ashworth wrote: On Fri, Aug 15, 2008 at 02:37:46PM -0400, Matt Florell wrote: Most carrier sales people don't know what TBCT is unfortunately, and even if a carrier is capable of doing it, it is a possiblity that not all of their equipment is capable of doing it. One client of mine tried to get TBCT working across all 16 of their PRIs(all on the same carrier) and it only worked on 4 of them, supposedly because not all of the telco equipment was capable of the feature. I expect to fight this battle, yes. :-) This actually depends on the kind of PRI service you have. For instance with DMS100 circuits you can only do TBCT with calls that come in to your circuit, not with outgoing calls. As for connecting two incoming calls, since that is not possible in Asterisk(to natively bridge two incoming calls together) I can't see how you would get that to work even if it is possible in TBCT. To be more clear, what I'm after is to have *someone else besides me* place calls out their PRI, and then TBCT those placed calls to my DN. By the time the calls get to me, they should just be standard phone calls. So I expect the call-placing-party to need TBCT, but not me. I believe that only DMS100, NI2 and 5ESS PRI signalling protocals are capable of TBCT with the current zaptel code-base. Also, the two B channels involved in the TBCT have to use the same D channel. And I'm probably not concerned with whether Asterisk can deal with TBCT, because Asterisk probably won't be involved at that stage; just once the call's transferred to me. But before I inquire of said second party whether they *can* do that, I wanted to confirm it was possible. 2BCT works when the telco originates the call and Asterisk is hairpinning the call back out the same PRI circuit. However, Asterisk does not support the opposite direction. That is, a call originated from Asterisk that comes back in via the same PRI circuit cannot be 2BCT. I'm not certain whether this is a limitation of Asterisk alone or of the protocol, but it cannot be done. Similarly, Asterisk cannot complete a 2BCT request, if Asterisk is on the NET side of the PRI circuit. That might could be added in the future, but it is not supported now. So in summary, Asterisk can request 2BCT, but it cannot perform a 2BCT if requested from the other side. -- Tilghman ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
Tilghman Lesher wrote: On Friday 15 August 2008 13:45:11 Jay R. Ashworth wrote: On Fri, Aug 15, 2008 at 02:37:46PM -0400, Matt Florell wrote: Most carrier sales people don't know what TBCT is unfortunately, and even if a carrier is capable of doing it, it is a possiblity that not all of their equipment is capable of doing it. One client of mine tried to get TBCT working across all 16 of their PRIs(all on the same carrier) and it only worked on 4 of them, supposedly because not all of the telco equipment was capable of the feature. I expect to fight this battle, yes. :-) This actually depends on the kind of PRI service you have. For instance with DMS100 circuits you can only do TBCT with calls that come in to your circuit, not with outgoing calls. As for connecting two incoming calls, since that is not possible in Asterisk(to natively bridge two incoming calls together) I can't see how you would get that to work even if it is possible in TBCT. To be more clear, what I'm after is to have *someone else besides me* place calls out their PRI, and then TBCT those placed calls to my DN. By the time the calls get to me, they should just be standard phone calls. So I expect the call-placing-party to need TBCT, but not me. I believe that only DMS100, NI2 and 5ESS PRI signalling protocals are capable of TBCT with the current zaptel code-base. Also, the two B channels involved in the TBCT have to use the same D channel. And I'm probably not concerned with whether Asterisk can deal with TBCT, because Asterisk probably won't be involved at that stage; just once the call's transferred to me. But before I inquire of said second party whether they *can* do that, I wanted to confirm it was possible. 2BCT works when the telco originates the call and Asterisk is hairpinning the call back out the same PRI circuit. However, Asterisk does not support the opposite direction. That is, a call originated from Asterisk that comes back in via the same PRI circuit cannot be 2BCT. I'm not certain whether this is a limitation of Asterisk alone or of the protocol, but it cannot be done. Similarly, Asterisk cannot complete a 2BCT request, if Asterisk is on the NET side of the PRI circuit. That might could be added in the future, but it is not supported now. So in summary, Asterisk can request 2BCT, but it cannot perform a 2BCT if requested from the other side. Let me clarify some of this. Under no circumstances can Asterisk receive a TBCT request. We just ignore them. We can initiate them however. There are different TBCT implementations, dependent on which switch type is used, with different restrictions associated with each switch type selected. For true TBCT (on switchtypes of NI2 and 5ESS, AFAIK), you can have any combination of inbound and/or outbound channels (one inbound/one outbound, two inbound, two outbound) and transfer them to the upstream switch. The protocol doesn't care. 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. Hope that helps a bit. Matthew Fredrickson Digium, Inc. ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Fri, Aug 15, 2008 at 02:49:17PM -0500, Tilghman Lesher wrote: To be more clear, what I'm after is to have *someone else besides me* place calls out their PRI, and then TBCT those placed calls to my DN. By the time the calls get to me, they should just be standard phone calls. So I expect the call-placing-party to need TBCT, but not me. I believe that only DMS100, NI2 and 5ESS PRI signalling protocals are capable of TBCT with the current zaptel code-base. Also, the two B channels involved in the TBCT have to use the same D channel. And I'm probably not concerned with whether Asterisk can deal with TBCT, because Asterisk probably won't be involved at that stage; just once the call's transferred to me. But before I inquire of said second party whether they *can* do that, I wanted to confirm it was possible. 2BCT works when the telco originates the call and Asterisk is hairpinning the call back out the same PRI circuit. However, Asterisk does not support the opposite direction. That is, a call originated from Asterisk that comes back in via the same PRI circuit cannot be 2BCT. I'm not certain whether this is a limitation of Asterisk alone or of the protocol, but it cannot be done. I'm not sure we're not talking at cross purposes, here, Tilghman... but TBCT is an instruction to an end-office that sent you a call to yank it back off your timeslot and forward it along to someone else. There's no hairpin involved: the point of TBCT is that you tie up *0* timeslots instead of 2, to forward a call. Why would an Asterisk instance call itself on the same span? Similarly, Asterisk cannot complete a 2BCT request, if Asterisk is on the NET side of the PRI circuit. That might could be added in the future, but it is not supported now. So in summary, Asterisk can request 2BCT, but it cannot perform a 2BCT if requested from the other side. Nothing can perform a TBCT unless it's a PRI server, not a client; it's function of 5ESS's and DMSen; you have to be an SS7 speaker to do it in the first case. Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Fri, Aug 15, 2008 at 03:03:23PM -0500, Matthew Fredrickson wrote: Under no circumstances can Asterisk receive a TBCT request. We just ignore them. We can initiate them however. There are different TBCT implementations, dependent on which switch type is used, with different restrictions associated with each switch type selected. For true TBCT (on switchtypes of NI2 and 5ESS, AFAIK), you can have any combination of inbound and/or outbound channels (one inbound/one outbound, two inbound, two outbound) and transfer them to the upstream switch. The protocol doesn't care. 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. Oddly, I learned about TBCT *from the feature planning guide concerning the DMS100*, to which I had a subscription 10 years or so ago; I don't recall it having a different name or limitations. I can lay my hands on that issue; I will. But, again, I wasn't concerned with whether Asterisk could do anything specific with TBCT, except catch calls sent to me by someone else performing one. Which my original message was pretty clear on. :-) Cheers, -- jra -- Jay R. Ashworth Baylink [EMAIL PROTECTED] Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Josef Stalin) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] PRI TBCT - Practical Experience, Anybody?
On Friday 15 August 2008 22:16:34 Jay R. Ashworth wrote: On Fri, Aug 15, 2008 at 02:49:17PM -0500, Tilghman Lesher wrote: To be more clear, what I'm after is to have *someone else besides me* place calls out their PRI, and then TBCT those placed calls to my DN. By the time the calls get to me, they should just be standard phone calls. So I expect the call-placing-party to need TBCT, but not me. I believe that only DMS100, NI2 and 5ESS PRI signalling protocals are capable of TBCT with the current zaptel code-base. Also, the two B channels involved in the TBCT have to use the same D channel. And I'm probably not concerned with whether Asterisk can deal with TBCT, because Asterisk probably won't be involved at that stage; just once the call's transferred to me. But before I inquire of said second party whether they *can* do that, I wanted to confirm it was possible. 2BCT works when the telco originates the call and Asterisk is hairpinning the call back out the same PRI circuit. However, Asterisk does not support the opposite direction. That is, a call originated from Asterisk that comes back in via the same PRI circuit cannot be 2BCT. I'm not certain whether this is a limitation of Asterisk alone or of the protocol, but it cannot be done. I'm not sure we're not talking at cross purposes, here, Tilghman... but TBCT is an instruction to an end-office that sent you a call to yank it back off your timeslot and forward it along to someone else. There's no hairpin involved: the point of TBCT is that you tie up *0* timeslots instead of 2, to forward a call. There is a hairpin involved. The call (for several milliseconds at least) is using two channels on the PRI before the 2BCT succeeds, and then the call no longer takes up any channels. It is only when the PRI detects the hairpin, through the native bridge code that it is able to detect that the call is eligible for 2BCT. Why would an Asterisk instance call itself on the same span? Very simple. Call your main number, and if you don't have special logic in your internal dialplan context to handle that, the call will go out to the telco and dutifully come right back in on the same circuit. Similarly, Asterisk cannot complete a 2BCT request, if Asterisk is on the NET side of the PRI circuit. That might could be added in the future, but it is not supported now. So in summary, Asterisk can request 2BCT, but it cannot perform a 2BCT if requested from the other side. Nothing can perform a TBCT unless it's a PRI server, not a client; it's function of 5ESS's and DMSen; you have to be an SS7 speaker to do it in the first case. I don't think that's the case. Matt would know more, and his reply suggests that it certainly would be possible for Asterisk to do this. SS7 is not at all required here. -- Tilghman ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2008 - September 22 - 25 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
