![]() | |
| |||||||||||||||
| |||||||||||||||
| Meridian Systems Welcome to the Nortel Meridian Forums Including Meridian Options 11-81C CS1000M Meridian Mail Call Pilot Companion and Sucession Hospitality OTM MAT MICB RAN NetGateway ..., and all other Applications |
| Tags: caller, different, entries, loops, pri, two |
![]() |
| | LinkBack | Thread Tools | Display Modes |
| | #1 (permalink) | ||||||||
| Junior Member
Location: Texas Rep Power: 0 ![]() | Ok here's one for all: I have one PRI loop used for incoming and outgoing external calls. Loop 1 I have one PRI loop used for calls to a third party application (IAO) Loop 2 This is my current CLID entry which sends all calls with the sites main number (The 1's are examples ENTRY 0 HNTN 111 ESA_HLCL ESA_INHN NO ESA_APDN YES HLCL 1111111 DIDN NO HLOC LSC CLASS_FMT DN Now, for Loop 1 I need all calls to follow Entry 0, for Loop 2 I need all calls to display the four digit DN of the set that's calling. I've tried setting up Entry 1 and telling the DCH to use OPT1 (Not sure that's what it's for) and in the route for Loop 2 I've tried to set CLEN to 1. Nothing works the set always follows it's own caller id entry (Entry 0 is programmed on the sets). Ok, so some of you are going to ask what type of trunks are configured on these loops, well they are both DID trunks as the third party application at the end of loop 2 can only connect to a DCH that is an NI2 interface. This would be so much easier if I could configure loop 2's trunks as TIE but the option is not available. Any suggestions are appreciated. Now on to my last question. Is there a way, at the set level, to set a timer to disconnect a set from an external call after so many minutes. Thanks again. | ||||||||
| | |
| | #2 (permalink) | |||||||||
| Moderator ![]() ![]() gei_spot is going phishing
Location: Somewhere in this vast universe on a little rock that looks like a grape. Rep Power: 13 ![]() | Quote:
__________________ | |||||||||
| | |
| | #3 (permalink) | ||||||||||
| Junior Member
Location: Texas Rep Power: 0 ![]() | Quote:
| ||||||||||
| | |
| | #4 (permalink) | ||||||||
| Junior Member
Location: Texas Rep Power: 0 ![]() | Ok so now I'm able to establish a DCH using an IFC of D100, I see the call going through using DCH messaging: DCH 31 IMSG SETUP REF 00008004 CH 0 TOD 11 58CALLING #:4499 NUM PLAN: NUM UNKNOWN CALLED #:3499 NUM PLAN: NUM UNKNOWN But I get the following error when the call is made: PRI0227 Protocol Error: Message received in NULL state. Output data: DCH: x DATA: y . Where: x = D-channel number and y = Message type. Action: Contact your technical support group if the problem persists. Severity: Critical Any suggestions? | ||||||||
| | |
| | #5 (permalink) | ||||||||
| Senior Member ![]() Rachelle is curious
Location: Lou, KY Rep Power: 11 ![]() | What kind of mechanic is this? Can't tell anSUV from a truck I believe that Nortel must have a PEP for this. Here is why I say that: Way back when, we were on rls. 23 and we converted to ISDN/PRI circuits. We were constantly getting the PRI227s and a few others of the same ilk. When our vendor was contacted they said that it was just a signalling glitch between the LECs CO and our PBX but, it would not be service impacting and to ignore those errors. We did so for years. We are now on rls. 25.3 and we don't get those errors very much if ever, now. All of our circuits are configed as TIE going back to D250s. Based on our experiences, and depending on your release of software, I would not worry too much, as long as your call processing is flowing as wanted. rlc | ||||||||
| | |
| | #6 (permalink) | ||||||||
| Junior Member ![]()
Location: Wisconsin Rep Power: 7 ![]() | You have told your switch that it is talking to a DMS100 (Nortel) so your switch is looking for specific messages, for example I have 3 ties going to a Cisco CM, which is connected with PRI and the IFC is SL1 (call manager needed the Nortel to be the Network) everytime the Cisco calls a Nortel and recieves a busy I get a PRI 227 because the Nortel is looking for a message that the cisco is not sending. Everything is working fine if you can weed through all the PRI errors. My fix is going to be next week when I change all the PRI's going to 3rd party switches to use QSIG. | ||||||||
| | |
| | #7 (permalink) | ||||||||
| Junior Member
Location: Texas Rep Power: 0 ![]() | Ok for those that may be, in the future, integrating a CIC made by I3 to a nortel application ie. Option 11 - 81c. This is how we got the T1 between the two systems to work after trying every IFC combination out there. Have the I3 system setup as ESS5 and SIDE being USER, setup the Meridian switch as ESS4 and SIDE being NET (out of the box route, tie trunks and d-channel nothing in RCAP) and the calls will work perfectly. Thanks to all of you for your responses. | ||||||||
| | |
![]() |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
| Display Modes | |
| |
Similar Threads | ||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Caller ID name on SBC PRIs | jheath | Meridian Systems | 1 | July 20th, 2003 10:59 PM |
| Block Caller ID? | Wildman | Meridian Systems | 6 | March 10th, 2003 04:26 PM |