PRI over Point to Point 2

[overcast32]

Got a few questions about PRI...

I am somewhat of a Teleco newb - so bear with me please

First, let me give you our basic setup...

Ohio Office - Primary Switchboard
KY Office - Secondary/Slave Switchboard.

Both systems are Magix 2.1 V 8.0 using 100DCD cards for interoffice connection - Full DS1, no channels split out for anything (one is set to PRI, of course). The DS1 is pretty much going right into the 100DCD cards, no external CSU/DSU is in use. Currently the CallerID works decently for inter-station calls.

And my Questions:

We are getting PRI activated on our incoming trunks shortly. We would like for CallerID to work even when calls are transferred from the receptionist at the Ohio office to a user in KY (I know it will work fine when incoming calls are using DID straight to KY) - will this work out of the box with this phone system, or is there a card we can add for it to work? So far, our Telecom vendor is saying this won't happen as it's not a feature in the Merlin Magix...

Also - the receptionist console has the add on that will show who has a busy station internally in Ohio - but it doesn't work over the DS1 - it won't show which KY users have a line in use. Is it possible to get that console to show which lines are in use on the far end of the DS1?

Please let me know if I need to clarify any of that

TIA!

 

[overcast32]

Oh - actually, I do need to clarify one point.

We are looking for the PRI to come over the DS1 - if the outside caller just inputs an extension number when they hit the auto-attendant.

I'm not sure - would it be possible to pass the inward PRI info over if the receptionist transfers? I can see that not working....

Thanks!

 

[papabear762]

My first concern is that you said in the first post that "one is set to pri". Both should be pri. I ASSUME that you have this correctly programmed, or it wouldn't work. The caller ID should be passed on a transfered call, but the dss will not show ext. status from the node site.

From your second post, yes the new trunking pri, if programmed correct, will transfer across from the auto-attendant.

The phone system does lose the caller ID after a short period of time. If the receptionist talks to the caller for a couple of minutes, the caller ID is not there.

This is only what I have observed from my pri network installations. This is not info. out of a book or manual anywhere. Hope it hepls.

 

[Pepperz]

The DSS won't show far end activity, you really shouldn't be able to number it so that it could work, since those extensions should all be in the non-local UDP.If a caller comes in on switch A, on a DID, and automatically routes to an extension on switch B, the CID should show. If it is transferered from A to B, it MAY show, but I'm not sure.
The whold thing COULD depend on Delta Queen traffic at the time of the call, (just kidding)

Pepperzgm at gmail dotte comm

 

[overcast32]

Ok - well, yes PRI is being turned on on both ends, so the incoming trunks will all have PRI active, on both ends.

I also read in here somewhere that the Point-to-Point should just allow all 24 channels to be used by the merlin system w/o setting aside anything for PRI - this makes sense, so I need to double check that setting.

Any suggestions on optimal settings for the PtP DS1 between the 2 Merlin Switches?

I got an Avaya manual, so I'll look through that too - I assume that's the best resource for getting these things programmed right? We do have a programmer for it, but he's been way busy lately.

Thanks for the reply

That's our primary concern; however, we just want the PRI to carry over if they hit the auto-attendant, input and extension and then travel over the PtP to get to the proper station - hopefully with DID information intact

 

[overcast32]

haha, thanks Pepp - but each end has some DID trunks, but commonly callers will call into the main swtich, and transfer via the Auto-attendant...

If the call's tranferred the DSS will show activity? I guess if the call comes in on the remote end, through a DID trunk, I can see why the DSS wouldn't show it at all - I guess no devices or add ons are made that can make this happen either, huh?

 

[papabear762]

The PRI settings is what passes the caller ID, or so I was told years ago and have been programming that way since.

 

[overcast32]

ok - so when you set up a PtP between two swtiches, you keep the PRI active?

ok - Just checking, I think I had read in here somewhere that wasn't necessary, and that the merlin would handle it all - but I thought I would ask, before I looked into doing anything like that.

 

[overcast32]

Oh and you know - the manual doesn't specifically say - do the 024 TDL cards support CID?

It didn't mention that particular card...

 

[papabear762]

when you order the t1, you should get a open pipe. The host merlin is providing the pri signaling. If you are talking in pri language on one end you must understand pri on the other end. Ever try understanding spanish if you aren't fluent speaking it? You may get the basics of the conversation, but you lose parts of the conversation ( the caller ID ). The D-channel handles that. So you get 23 channels for open communication. You still need to program ALL the PRI settings in both switchs. It is a lot, but that is the only way to optimize the efficientcy of the pipe.

 

[overcast32]

ok - just scratch that, I seen Merlinman's post in the "Magix Point -Point locks up 3X a day." thread.

I didn't read that right - I'm guessing in his situation, the provider is setting up PRI on that PtP or whatever...

Our PtP is just a straight pipe - but yeah, I understand the Merlin itself will certainly need to be programmed to use PRI over that PtP.

So it was my goof for not understanding the thread I read 100%.... lol

I did look into the manual some and it does state it will send CID over on transfers - like you said, up to a certain amount of time...

" Transferring a Call
The telephone receiving the transfer displays standard incoming call identification information until
the transfer is completed. The second screen shows call transfer information. Caller ID information
appears on the display.
Calls returned after the transfer return interval expires also display standard incoming call
identification information."

That's out of the 2.1 release manual. If you read further, it leads you to believe it may drop the CID in certain instances...

I noted it didn't mention anything specifically about the Auto-attendant, so I'm assuming it just looks at those as transfers also.