Track inbound call on T1 that's using IDC... 1

[QuantumSchema]

Hey all!

I'm a long time silent reader here and have gotten most of my knowledge of the Option 11 from these forums. So with that said, I'm an IT veteran but a newcomer to the Option 11 and extremely proficient w/ Asterisk. So I'm up to speed on telephony, just not the three letter commands of the Opt 11.

So, we're in the process migrating from the Opt 11 to Asterisk and have the two tied together via an internal T1 trunk. When I "migrate" an extension to the new system, I change the DN on the TN (so I don't out anything), and then I create a DSC using a RLI that we have that sends the original extension prefixed with a 1 (ext=xxx; RLI ext=1xxx) over the internal T1 trunk.

Everything works fine for common extensions. The one that got me yesterday is a fax extension we have. It's set up as a common analog extension in the Opt 11. Its using an IDC to get to the extension. So I changed the DN on the TN for that extension and it appeared to work. So now the CO sends the 3 digits in, the IDC maps them to the DSC, and then over the RLI it goes. What's interesting is that for some callers, it sends it over the RLI to the new fax extension, and for other callers it sends it to the receptionist. (Just an FYI... we have 3 PRIs... 1 local and 2 long/toll-free).

We thought it was just long distance numbers that were going to the receptionist but that was proved to not always be the case.

So... that brings me to my question... I'd like to do a trace on inbound calls on the T1 cards (or PRIs) to see if maybe the CO is sending different digits and its using a different IDC or if they are sending the right digits and something else is happening to IDC.

I've read up on LD80 and TRAK, TRAC, and TRAD and I think TRAD is my ticket but the docs mention a loop and channel. Well, T1's have 23 channels so is there a way to watch all calls on a loop or do they mean DCH?

If I'm not mistaken, it wasn't until we changed the DN and created a DSC that this started happening.

Thanks in advance all!

 

[telebub]

Turn on d-channel messaging in LD 96 and make test calls while watching the d-channel.

LD 96
.enl msgi (dch #)

To turn it back off when finished:

LD 96
.dis msgi (dch #)

 

[QuantumSchema]

Awesome! Thanks telebub! I'll run over to the comms room now and give it a shot!

Thanks for the quick reply!

 

[bdjoe5]

In LD 96, you want to enable the D-channel messaging for the particular PRI(s).

.enl msgi x (x = dch number)
this will show real time INBOUND calls on that PRI

for future, or since you're coming in and also CDP'ing out, you can do...
.enl msgo x
this will show OUTBOUND calls on that PRI

 

[QuantumSchema]

bdjoe5, thanks for the note on watching the outbound on the PRI too! That'll be brilliant to watch the entire call flow if its going over the internal T1!

 

[bdjoe5]

No Problem..it is useful, expecially in your case with the CDP.

good luck!

 

[QuantumSchema]

Alrighty... I noticed the difference...

If I call from my cell it goes over the internal trunk and the new fax. I see the call as:

Called #:55555555 NUM PLAN: E164
Calling #:7777777 NUM PLAN: E164

If I call from an external line that ends up going to the Receptionist, it says:

Called #:55555555 NUM PLAN: E164
PROGRESS: ORIGINATING END IS NOT ISDN
Calling #:7777777 NUM PLAN: E164

Any thoughts? That's the only difference I see right now.

Also, to disable DCH logs, is it .dsl?

Thanks!

 

[bdjoe5]

to disable you do...

.dis msgi x
.dis msgo x

still thinking about the other problem...

 

[StanleySteamer]

You need to look at the DSEL prompt in the tie line trunk route.
If it's VCE then try 3VCE.
Usually it works best when it's 3VCE for faxes (at least in N.A.) when you aren't doing video or data calls. Sometimes fax calls get tagged at the originating end with a bearer capability (BCAP) that is rejected by the 3VCE setting. I have seen similar problem to yours with fax calls from Europe. In that case VOD should work.

 

[QuantumSchema]

I'm printing off the RDBs now. Some were 3VCE, others VCE, and the rest VOD. Once they're done printing, I'll marry them up to the DCHs.

StanelySteamer, in your post you made reference to the Opt 11 deciphering between fax or not. The problem I'm facing now happens to all calls. Voice and fax. Also, this was working before I changed the DN of the TN and created a DSC of the original extension.

Basically, the IDC mapped 097 (the last 3 of the DID) to 241. 241 was the DN bound to a TN. I changed the DN on the TN to 86241. I then created a DSC for 241 and gave it RLI 12 which does the digit manipulation to 1241 and sends it over the internal T1 tie.

I haven't done it yet but I'd feel pretty confident that if I out'ed the DSC and changed the TN's DN back to 241 it would work again.

 

[StanleySteamer]

So the big difference now is that the calls are routed across the tie lines. That's the RDB to look at. Or it may be at the Asterisk end.
Where is that receptionist that gets the redirected calls? On the opt11 or the asterisk?

 

[QuantumSchema]

The receptionist is on the Opt 11 side.

I just did a few tests. I out'ed the DSC and changed the original TN's DN back to 241 and it worked. So, I went a head and created a new DSC for an unused DN and changed the IDC for 097 to point to it. It again went to the receptionist. ::scratches head::

The DSEL for the T1 tie is VCE. In order to change that though, do I have to out it first? (I'm hoping you say no)

Thanks for the fast responses too! I really appreciate it.

 

[telebub]

No, change it on the fly

 

[QuantumSchema]

Well that's good to hear telebub!

So here comes my Opt 11 ignorance... is this what I'd do?

LD 16
REQ CHG
TYPE RDB
CUST 0
DMOD 4
ROUT 6

and then hit enter all the way until I get the DSEL prompt or do I have to fill in all the data for each field?

Also, what could go wrong here? Would the DCH fall off? Will I loose calls? Will I need to restart the DCH on the Asterisk box? Is there anything on the Asterisk side that should change?

 

[telebub]

Just hit return down to DSEL, enter 3VCE, then hit return all the way back to REQ. Nothing detrimental will happen.

 

[QuantumSchema]

YOU HAVE GOT TO BE KIDDING ME!!!!! LoL

If I could buy you guys a beer I would!!! It worked. I changed the RDB's DSEL to 3VCE and it worked! This probably would have taken the Verizon guy hours to figure out and plus I couldn't get him here for another week or so.

Wow! No DCH drop or anything. It just works!

So, now that the hard part is out of the way... would someone be kind enough to explain what DSEL, VCE, and 3VCE means and the difference between VCE and 3VCE. I'm one of those guys who likes to know what it is I did instead of saying "Well, it works now.".

Thanks again you guys!!!!!!

 

[StanleySteamer]

My understanding, without getting too deep into ISDN, is that the bearer capability is set by the originating fax line as Group 3 fax or "3.1 khz audio". You could do this on a 500 type line on the opt11 with CLS FAXA.

The bearer capability is supposed to be honoured by all the ISDN carriers throughout the route of the call so that none of them will do anything to degrade the integrity of the fax like compression or routing over IP with an incompatible codec. If the bearer capability is simply voice (VCE) then the carriers can do all kinds of things to re-arrange the bits and still end up with a two-way conversation. But faxes or modems aren't as forgiving as the human ear.

The DSEL prompt is the Opt11's way of honouring the bearer capability (or not). 3VCE usually works for faxes, modems and voice. If you were using the lines for ISDN video you would need to set DSEL to VOD. Now that I think about it, I usually always set DSEL to VOD.
Using VCE or 3VCE tells your ISDN carrier that you don't need the full 56K provided by the b-channel and they may charge less. I think that is (or was) common in Europe but not where I come from.

I can't think of the reason that calls were intercepted by the attendant but I think it is because your incoming PRI trunks had higher capability than the outgoing tie route. Seems like that should all be negotiated while the call is setup but maybe that what makes ISDN so much fun.