Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations biv343 on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

G3si DID handling

Status
Not open for further replies.

njadmin

Technical User
Sep 5, 2006
101
US
I have a Definity G3si R12 with 2 tenants and one just switched providers. They used to have two trunk groups one for DID and one for main number. The new provider isn't able to split the channels into groups, so I now have to move all channels to one trunk group and handle them from there. I've never had to deal with this part of the system and all the info I'm finding doesn't match my system.
Where the heck should I start looking to split out the DID numbers from the main number. I know the DNIS is getting passed but I don't know where to go about routing the calls.

Thanks

Jason
 
Does your new service provider send DID and DNIS on the same PRI? A trunk group belongs to one Tenant Number so will need separate trunks for each business. If it is a PRI, the provider should be able to send both DID and DNIS on the same trunk.
 
The trunk is an analog T split voice and data. The primary tenant (me) is set to have the channels grouped by the provider so only certain blocks of numbers get picked to the channels for the trunk group:
ie - block 365-11xx -- 365-12xx - are restricted over channels 1-12
block 365-15xx -- 365-16xx - are restricted over channels 13-24
trunk group 1 answers channels 1-12
trunk group 2 answers channels 13-24

That's how it was done, now all channels are in one group but I don't know how to grab the DID called and route it to the extension. Right now I have the trunk group set to insert digits so it gets routed to their attd script.
 
I assume (a dangerous thing to do) that both trunks are PRI. Trunk 1 goes to business A and trunk 2 to business B. If the carrier is sending the DNIS, you probably do not have to do anything. If they are sending DID numbers, they may be sending a different number of digits than you are set up to support. You may have to check your incoming call handling treatment table to be sure you are not deleting too many (or not enough) digits.

Can you confirm you are using a PRI and does the carrier send your DID numbers? How many digits are they sending?
 
I was just re-reading your original message. I thought you had two trunks but you only have one.

In that case, you may need to order another trunk since each trunk group belongs to one tenant number, or you need to put everyone into the same tenant number. A major concept behind tenant partitions is to keep folks from using someone elses trunk groups. I don't see how you can use one trunk group in two tenant partitions.

Someone out there may have a better idea/work around.
 
these are not PRI and The tenants have physically separate T lines.
I did a trace on the tac:
12:39:29 Calling party trunk-group 1 member 2 cid 0x22
12:39:29 Calling Number & Name NO-CPNumber NO-CPName
12:39:29 tone-receiver 01A1303 cid 0x22
12:39:29 active trunk-group 1 member 2 cid 0x22
12:39:29 dial 7099
12:39:29 ring hunt-group 1 cid 0x22
12:39:31 active station 7401 cid 0x22
12:39:43 idle trunk-group 1 member 2 cid 0x22

The dial is set in the trunk group to send them to the attd script.
I'm not sure where to look for what is being sent to me. I know I asked the tech and they are sending 4 digits (xxx-1011)
 
Try removing the deleted/inserted digits from the trunk group. Do DID's start to work?
 
This is what I get when I removed the insert digits

14:33:15 Calling party trunk-group 1 member 5 cid 0x142
14:33:15 Calling Number & Name NO-CPNumber NO-CPName
14:33:15 tone-receiver 01AXX05 cid 0x142
14:33:15 active trunk-group 1 member 5 cid 0x142
14:33:17 dial 1011
14:33:17 ring hunt-group 51 cid 0x142
14:33:37 no answer hunt-group 51 cid 0x142
14:33:37 coverage-path 51 point 1 cid 0x142
14:33:37 dial 1011
14:33:37 ring hunt-group 99 cid 0x142
14:33:40 active station 7395 cid 0x142
14:33:45 idle trunk-group 1 member 5 cid 0x142

Call was routed properly. Now how to I send numbers that don't match to the main attd 7099
 
How is the field DID/Tie/ISDN/SIP Intercept Treatement set in system-parameters features?
 
Are you using a real attendant console or is the "attendant" just a regular station? Do you have anything set in "change listed"?

 
Only one tenant has a console the tenant I'm working on just goes to a prompt system then out to the extensions (Audix is used for their auto-attd).
The cha lis has the primary console and night service set for tenant 1
 
It sounds like tenant 1 is being handled OK. However, it sounds like tenant 2 is going to an automated attendant which requires a mailbox in order to be eligible for transfering a call.

That is a setting in the AUDIX on the "change system parameters" page. If Transfer Restriction is set to digits, it should allow transfer to any number dialed. If it is set to Subscriber, it will only transfer to extensions that have a mailbox. It takes an Avaya login to change that field.
 
Once the call hits the Audix box it's handled fine, I need to have the PBX route the inbound DID block (DNIS from 1010 - 1030) right to the extension. Without the second trunk group for this tenant I don't know how to deal with that. Would it be possible to use a vector to match the DNIS and then route if matched?
 
The VDN method should work but you will need to build 20 VDN's pointing to the same number.

Another thought, if you create one VDN and vector routing to the operator, add 3 entries in the uniform dial plan like 101, 102, 103, say they are 4 digits long, delete the digits and insert the digits for the VDN and say it is an extension. Might be less work and not eat up your VDN supply.
 
I think I have it working right.
Looks like the last guy who set this up created hunt groups with the DNIS as the extension number. I just removed the insert digit from the trunk page and now the DID calls are routing. The main number also is ringing to the auto-attd.
I'll make sure to keep an eye on it for the next few days.

Thanks for the help (I noticed it when I was looking over the VDN list)
 
One question though, how does the trunk-group know that if there isn't a match for the DNIS to dial the auto-attd? I don't see anything in the trunk page. What's the actual process for an incoming call? (sorry but I never really understood it)

like this:

CO --- PBX - trunk-group -- magic - vec/vdn/term-ext/hunt/sta/attd
 
I took a quick look into that and it appears to be dependent on how you are set up. Like if you are using change listed or the system wide DID/Tie/ISDN/SIP Intercept Treatment field. I don't have a definitive answer.

I think that would be a great question for the forum. Someone out there probably has a quick answer.
 
OK, I'll try a new thread for that one.

Thanks again
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top