I have a customer with a PRI that has completely failed, last Friday morning. Calls go out just fine, but ANY incoming calls provide one ring and then are dropped. Our trace on the system shows that a clear request is being sent by the serving CO switch (Verizon with a DMS-100).

Here's a little history:

The customer had their PRI from XO Communications for about two years, but it went down as frequently as three times per day. XO and Verizon could not ever figure out what was happening, so the customer just lived with rebooting the system. It usually came back up after that.

They eventually got fed up and switched to Verizon. Since both telcos are using a DMS switch, we didn't have to do much of anything except to move the cable from one smart jack to the other. It worked fine for a month without interruptions whatsoever.

Friday, they called us reporting that even a reboot wasn't doing the trick. We sent out a technician, armed with a replacement PRI card, among several other cards just in case. Nothing worked, so he referred this matter to Verizon. Since the customer had already opened up a ticket for this, Verizon was on the ready. They showed up, connected a T-Bert and came up with, well you already know what their answer was.

We spent all day Saturday taking another system over there and connecting it directly to the circuit where it enters the building in the basement. Same exact thing; works fine for outgoing; incoming results in one ring and then the call drops.

Today, I had two technicians out there to brainstorm and had Verizon back out twice. Same results. All new hardware, yet still the same canned answer from Verizon.

The customer was in the process of arranging to have a "fake" POTS line assigned to be used as a fallback in the case that the PRI failed. They did this because of the years of problems they had with intermittent outages. Although Verizon was charging them for a POTS line, it didn't really exist. It was just an alternate resource they would have available for emergency redirecting of calls. This just got completed recently, and my guess would be sometime late Thursday.

So now, as it sits, the customer has all of their inbound traffic directed to a cell phone where messages are taken. Employees then call the person right back. Verizon refuses to do much of anything else, except to keep coming out and showing us that their tester says, well again you know what they said. They claim that they can't escalate this because with it being a holiday, they don't have any higher-eschelon people to dig further. The customer is back in business tomorrow morning and their system still isn't working.

Even the same Verizon tech has indicated that all he can do is confirm the integrity of the pipe. He can't force anyone's hand since he shows that the circuit terminates proplerly. He does agree that someone messed up with the translations in the DMS, but only off-record.

They are a very long-term customer and I begged them not to go back to Verizon. They went against my advice and did it anyway. I doubt that they will jump ship and take their business to another vendor, but I do feel as if I owe them some kind of an explanation as to why this is happening.

The system is a Vodavi DVX+3 using 3.11 software. Like I said, it was humming along fine and then just stopped. Even with a complete equipment change-out, nothing has changed. I need help from you guys familiar with the DMS who can chime in with a donation of ammunition so that I can fire back at them.

Oh, and yes, Verizon claims that they ran a D channel trap, but our switch clearly shows a disconnect request being received from the CO every time a call is presented. They aren't seeing this, if the trap was actually run at all.

Hep me please, hep me!

Ed I think you've nailed it, sounds like either translations got messed up or D channel failing. I would think if it were the T-1 itself you'd have trouble bothways, maybe not the exact same trouble but some kind of trouble. Now the only problem is if they are testing the circuit D4 or just monitoring they may not see the problem on a SF T-1, the LEC's are bad about that.

Hey Ed see if you can get verizon to provide you with a copy of that trap. I agree it is not a pipe problem, A protocol analzer at the site is the only true way I see Verizon proving out this ckt. The t-bert will prove the loop, big deal, we know it is up, you are making outbound calls on it. Unfortualtley without being able to see the trap their is not much more I can suggest, maybe 5etek-Mike or Dexman has some input

Hey Ed.

You might try renting a TPI 570 Pri tester. This can monitor and terminate a PRI and can be rented fairly cheap.

This will give you a D Channel trap as well.

Being a DMS tech at a previous job is sounds that they do not have the number tables routed properly.

I would have them terminate to a Tberd and make incoming and outgoing calls this should prove it is there problem. The Tberd will let you make calls but the capture feature is less than desired.

Agree with Anthony..a protocol analyzer is necessary. Good luck finding one available in their system. Even SBC..sorry the new at&t had only limited access available for the entire local area code. Then when it got to site they had to find a craftsman that could operate it. A TBerd is only going to show pipe integrity not protocol issues. If an outbound call will establish and run for the duration then there is definitely a translation issue in their CO. ALLN1 probably has nailed the diagnosis as it looks like a breakdown in the numbers/group routing table. The only way I can get SBC/at&t to budge off center is to threaten to file an "executive complaint" to the president. They then run through their ass trying to do what they were supposed to do in the first place.

Had the same issue on a data T1 last year- Incoming packets dropping like crazy with nothing but a laptop connected to a brand new modem right out of the box. Turned out to be a provisioning issue on the telco side that was only resolved (after 4 hours) by being lucky enough to talk to the right support engineer at the telco who didn't have a preconceived notion that all his customers were clueless. Hang in there.

Just FYI.

There is a Tberd that will terminate, place and recieve calls if it has the option installed.

I personally have used the 2209 and the 224 to do this. The are great for placing calls and recieving calls but lacks in capturing D Channel signalling. Very difficult to decode. The TPI 570 will do this much better and easier. Also can be printed to a terminal emulation program for sending to the telco.

Have your tried to change your signalling to NI-2? It sound like the carrier is not sending the right ISDN Q.931 and or a protocol mismatch. Have them come with there T-BERD.

a fireberd is the way to go, but like RBF said they are few and far between and require a quilified tech. Swapping protocol just as a test is not a bad Idea, I have seen ckts function, poorly, but still function with a mismatch. I would also file the executive complaint, light a fire under their a$$ and hopefully get a tier 2 or 3 tech involved. Though you may want to be prepared, if you do get tier 3 involved they will probally want Voadavi tier 2 support on the line as well.

We can't change protocol with this system, so we really don't have a choice. It's fixed at NI-1 for BRI and NI-2 for PRI. Verizon swears that's how their end of the circuit is configured. OUr only options are the CO switch type, and dialing plan. We have tried variations of all parameters but all that does is affect our outward dialing capability.

You've changed calling and called parameters if available? Guessing but in some manufacturers there are versions of unknown,national,subscriber,international,etc.
Check also to see if they updated the CO about the time the problem appeared. Have also seen the wrong trunk group keyed into a MAC at the CO on an unrelated customer cause this.

Since you've changed the PRI board with the same result I'd demand a joint vendor with their protocol analyzer as the customer and attorney are standing by.

Ed,
Not too long ago, we resolved a very similar symptom with a PRI: Luckily, it turned out to be something quite simple: Although most of our PRIs are "B8ZS/ESF", this specific PRI was initially requested to have the coding and framing set for AMI/SF, which we had done both here in the switch, as well as confirmed at the far end (terminated to a Siemens switch). However, our Mini-mux 840 that transported the PRI from here to the Siemens was still set at B8ZS/ESF. Our switch indicated the PRI as in-service (but with a local alarm on the DS1), and *all calls dropped after the first ring. As soon as we updated the setings on the Mini-mux to reflect AMI/SF, the alarm cleared, and calls processed fine.

I have to agree with gcave: Recent telco software change, causing a Q.931 protocol's call setup message data mismatch (in the 5E, we would receive "level 3 errors" when retrieving the PRI status).

BTW: What is the "caller" hearing after an inbound call is dropped? Are they receiving a recorded announcement, reorder tone, or silence?

Where are you directing the DID's too? Have you tried moving the DID to an extension another device? I have run into these issues a long time ago..luckilly the Tadiran diplays Q9.31 messenging so you could nip it in the butt. It's weird you can place calls and not recieve..that means the d-channel is up. You definately need to see what they are sending you. Possibly they are sending 7 digits?

Mike: What the caller hears depends on the type of line they are calling from. If calling from another PRI, just one cycle of ringback tone is heard, then the calling PRI is given the command to drop the connection. If calling from a POTS line, one cycle of ringback is heard, then a reorder tone is returned.

Coral: We have confirmed that they are sending us three digits, which is what we are looking for. We even set up a completely different switch and programmed routing tables to receive anything from 1-7 digits for just one particular DID number. No matter what, the result was the same thing as above.

I'll call a local contact [DMS100 Tech] to get his opinion for us. Like Anthony said, this may require Vodavi TierII speaking directly with Verizon TierII. PRI calls simply dropping after the first ring doesn't usually start happening "out of the blue"..I think that some type of software or translations change had to have occurred at Verizon's end. Make sure that you identify as closely as possible when this actually began happening.

Could there be a possible conflict with the PRI's BTN (billing telephone #?) The BTN has alot to do with the Q.931 setup message (i.e: if the BTN is no longer a valid TN, the setup message will prevent the PRI calls from processing due to a billing conflict.) That's why this puzzles me...the outbound calls process fine across the same PRI.

Mike that is possible but I would think they would get a direct reoreder not a partial ring. Wish we could get our hands on a d-channel trap, It would give us a lot more to go on.

Hey Ed,

Can you provide the entire set of "D" channel messages for the call reference of a disconnected call? I have my co-worker who would like to take a look at what you have.

Dexman.

I don't have anybody on-site now to capture a trace and since the PRI is my only way to get into the system's modem, I can't get one right now. All that I can remember was that the last line of trace information provided is that our switch receives a PRI clear request right before the call drops. From what I can tell, our switch is being told to drop the call, so it does.

Update: The customer got fed up when Verizon threw their hands up over the issue. They are having them bring in ten POTS lines to replace the PRI. That really stinks.

that really does stink, hopefully verizon will deliver the POTS lines via a T1 and channel bank

Sorry to hear that news, Ed. I wish we were able to have seen the D-Channel message for the dropped calls. It's a shame that the 10 individual lines can't be a temporary solution, just until they can resolve the incoming calls over the PRI.

What a joke. How can they not fix this problem rather quickly? It's a PRI, they're not trying to get Verizon to provide service to the moon! There has to be someone in that company that can see what the problem is. I would be embarassed if my company gave service like Verizon has given this customer.

Ed, I'm sorry you and your customer got stuck with this.

Thanks for the support, guys. I just got off the phone with the customer and it turns out that the ten POTS lines are a temporary solution that was actually offered by Verizon. This will buy us some time to get XO to heat up their old circuit so we can show them that the system works. Once that's done, the customer will then be able to make an eductated decision as to whether they should go back to XO or give Verizon another chance to straighten it out.

good deal. Hopefully they will go back to XO

You all are not going to believe this. The customer just called and told me that they have received four calls today, BUT only from international destinations. So, as it appears, they cannot receive calls from any domestic numbers, but they can receive calls from foreign countries.

And Verizon still can't figure it out, swearing that it must be something in our equipment. Yeah, OK.

Ed, just a thought have Verizon check to make sure they are not passing any network spacific information along with the call

On my way home tonight, on a whim, I tried calling the customer from my cell phone, but I blocked my number by prefacing the number with *67. The call went through just fine. It does this regardless of whether the caller ID feature is enabled in our switch or not.

I tried it from home and got the same result. If no calling number is sent, the call goes through fine. Does this give you CO guys any better information to work with? Verizon is still scratching their heads.

Sounds like Verizon is sending a disconnect when it inserts the data stream for CID. The CID is inserted between the 1st and second ring.

On a PRI?

I've never heard of this type of symptom with PRIs. Good job isolating this problem down to impacting only the CID associated calls. I like your point Bill, but I wouldn't rule out a local software problem; possibly a corrupted file, that's misinterpreting the CID datastream and disconnecting the call (I wish we could test an inbound call at the demarc with a TPI 570): Ed, in your original post, you mention that when your client was using XO Communications, the PRI "went down" as many as 3 times a day.."Went Down" = Inbound calls dropping after 1st ring also?

I'm assuming it's the same as a POTS as to where it's inserted and it also fits in with Ed's trouble shooting. I don't know it for a fact Larry. Guess I should has worded it as an assumption on my part. I would also assume the CID is sent over the talk path and not the D channel. I don't know near as much about ISDN service as most of you though.

Just Bill

Just for info the PRI CID info is sent over the D channel as you stated along with the did digits. The switch and the telephone system negotiate in a way the channel that the call is going to be on and then the call is connected.

As for the cause of calls not completing when CID info is sent. I know I have had this problem before but I do not remember what it was. I will call one of my switch buddies and see if he remebers.

He ed.

Do you have an option to set your dialing plan to unknown.

Yep, I shouldn't have even commented on it. Thanks for the information.

Ed, I don't know this system but on the older Toshibia DK's this would happen if the name was sent with the caller id info.

We had a similar problem only reversed could receive can't call out. 3 days later a very tired and irate Embarq tech (10:00 @ night)who could not call out on his T Berd chewed out his own CO programmers and we all found out the problem together. Software upgrade Nortel had done recently on fairly new Central Office was the problem, they had to move the circuit back to some of the old equipment to get it to work. Not sure what they did with the circuit after that but it hasn't missed a beat since. Good luck Ed I feel your pain!

POTS: I really don't know if name is being sent, but that's a great thing for us to check. Their former PRI account didn't have name. I am still confused as to why name would have been added to a 40-day old account without being requested, but we ARE dealing with Verizon.

BReed: I am sure that what you experienced is causing the same thing here. Seems as if DMS offices are not as resilient as ESS's when maintenance or upgrades are performed.

ALLN1: Yes, we have the option of "unknown", but that only applies to outward dialing. Outward dialing works fine.

JustBill: I am in agreement with you about the CID info being sent between ring cycles ONLY because a virtual POTS line came into the equation recently as their failsafe rerouting destination. It seems as if Verizon activated this virtual POTS line, set it up for a test, then forgot to take it off after the test. With a virtual number within the switch having no assigned destination, I would think that the call to it would be rejected. This is exactly what is happening.

All that I know is that a call with the number blocked gets through, but the minute that calling party information is sent (unblocked call), it returns one ringback tone and then drops the call. At least this problem is consistent.

Ed,

I have seen a very similar problem on an XTS MPB2, where the carrier was supplying a PRI from a DMS 10 and for some reason the Caller ID out of the blue would cause our PRI board to go out and then actually reset the whole system every time a call would come in. Worked with vodavi and we had the carrier turn off Caller ID and BAM the circuit worked fine. They rebuilt the circuit with CID and it ran fine for a while and a few weeks later the same thing had happened call would come in and mass confusion would start. The carrier ended up fixing the problem on their switch and we have not had any issues since. let me know if you need anything else or mybe if i can explain it better to you.

I meant to send a PM. Please delete this. Thanks!

Well, here's today's update. XO was kind enough to reactivate their old circuit and put a test number on it. The customer moved the system back to the XO circuit and it worked perfectly!

They then contacted Verizon and had caller ID removed from their circuit and it worked perfectly.

This is so painfully obvious that it's a Verizon programming problem an has been since day one, yet they still refuse to tear out and rebuild the circuit.

The customer is now seriously considering going back to XO since they went above and beyond to help a customer, even one that's not their own anymore. I can't say that I blame them.

That's impressive that XO would do that. I'm glad you've proven the problem and I hope the customer pays your bill.

Switch carrier, problem clears. Turn off CID, problem clears. It's still not our problem? Boy they must really have some whiz bang techs. Thanks for letting us know Ed.

It's a shame, but I can't blame them if they switch back to XO Communications either. Cheers to the XO folks for allowing a previous customer the ability to prove that this problem wasn't with their local Vodavi System. Calls dropping versus no CID is not an acceptable response from Verizon, and it shouldn't take them very long to tear down and rebuild their PRI.

You were right, Bill! :thumb: There is some type of corruption in the CID being sent from Verizon to this Vodavi System.

Wow...that is very impressive of XO, very impressive.

Mike, that was just a lucky guess. Like I said I don't hold a candle to the knowledge of PRI's as most of you do on this board. Got to get lucky once in awhile. Ed proved it when he had them turn CID off. You'd think that would have nailed it and they would have no problem pursuing THEIR trouble.

Bill, I see what you were saying. I thought you meant that a PRI sends the CID on the second ring, normally. I know you're a T-1 whiz and I was doubting myself, not trying to call you out.

-Larry

Hey Larry, I doubt myself. So no problem. My strength lies in 10 pin arms.

I originally thought that the same "incoming calls" problem was occurring over either provider's PRI, hence a software problem at the Vodavi. Ed really pushed them in the right direction to isolate the problem directly at Verizon. This must be an extremely rare problem with CID over a PRI.

Have heard of issues where the delivery of name and number in a single packet vs. usuall dual packet structure can cause trouble.

Since Verizon owns everything, it's a safe bet to believe that the original XO problem of the PRI "going down" several times a week is in Verizon's equipment.

In the 40 years that I have been in the telephone business I have learned:

1. If a DMS is in the Verizon circuit, chances are it is not optioned correctly.

2. If the circuit is going through a SLIC, chances are: a. the back-up batteries are causing the system to fail; b. the protectors are carbon AND gas; c. the "new" circuit module is optioned differently even though it is the same model number.

3. The "old" telephone tech just reset "something" and it worked for a month with no failures....

And Finally......

4. (This overheard as two Verizon techs were on a confrence bridge between two COs and forgot that I was still on the call) "Yep...the trouble is leaving here OK!!"

What you really need is an "older than 12" telephone tech that knows the difference between getting a ticket complete and actually "Fixing" the problem.

Rcaman

Friday's update: Spent a collective 2.5 hours on the phone with four people from Verizon and the customer in a conference call. They dropped us several times when adding parties. It looks like they were sending number and name information, but our switch lacks the software for name delivery. We don't know for sure, but it makes sense that the extra D channel information would be enough to knock down a call.

Now, the question is who made this mistake? Did the customer make the assumption that name and number was OK? Did Verizon make this assumption? All that I know is that we didn't make the mistake. We begged the customer to NOT switch to Verizon based upon years of experience in dealing with them. Somebody's on the hook for what will be thousands of dollars in overtime billing from us.

I always thought that when circuits transfer from one carrier to another, the new provider obtains an CSR to ensure that all details are covered. Looks like Verizon didn't do this.

I am concerned now because the customer has put the system back on Verizon's circuit after the bending-over backward that XO did to help them. I hope that they are just doing this to get through the weekend before they give the account back to XO permanently. It stinks that so many people, including those in upper-level management at Verizon had to waste so much time on such a simple oversight.

Bill, now you know a little bit more about PRI's. You can learn new things here without even trying!

Glad to hear you got it fixed Ed.

Oh, it's not fixed yet until the customer decides which carrier to use for local service. Since it took so much effort and a week of temporary forwarding to a cell phone, I doubt that Verizon is high-up on the list of contenders.

That SHOULD HAVE been picked up rather quickly, and to boot CID with name is normally a billable feature on a PRI and not a cheep one at that. Your csr may want to check their Bill and see if they were being charged. WIth a little luck your csr will go back to XO

I used to work for a CLEC from 1999 to 2002 as a 5E tech. I would always hear horror stories like this one. After the Telecommunications bust I went back to installing phone systems and such. On several occasions I had to call ATT (SBC) to turn up PRI's going to my Tadiran PBX's. On two instances my D channel would never come up. First thing out of their mouth was "its your equipment"... Well as all of you know that doesn't sit well with a seasoned PBX tech you know.... I wasted a whole weekend and had to charge my customer about 48 hours of overtime for a D channel that was provisioned to another location instead of the place I was working. It took the whole weekend and 4 people from ATT on a conference call and calling in some "bigshot" to make a decision on what to do about the issue. Finally at 9:30pm on a sunday we got service. Now I dont know about you guys but I would take a CLEC over ATT, Sprint, and Verizon any day. When I was working for a CLEC, most of them were trying to re-invent the wheel and most CLEC's perished in a firey death... I think for the most part people running the show for them have learned from their mistakes and most the services they provide are top notch and stable. I love working with Time Warner here in Houston. They are probably the easiest company to work with when there is an issue at one of my customers sites. My company is a Channel partner for them, but we are also an ATT authorized rep. 9 times out of 10 we recommend Time Warner just due to the fact they are much easier to work with and there is no finger pointing.

Ed this sounds so familiar. I have a customer in Virginia Beach that is trying to switch carriers on 2 PRI's working as one group but with 2 D channels. The existing carrier has not had a failure in over 5 years. I also begged the customer not to switch, but bottom line prevails. The pretest was a disaster; the new carrier could not handle the 2 D channels. They also requested to change from 5ESS to NI2 to DMS100 and back to 5ESS and then once again to NI2. I had to shut them down and get the hotel back on the old carrier. Now back on the old circuit we have a new problem with garbled speech being heard on incoming calls. I have cleared this remotely by taking them down to 1 PRI. We may now have a bad board due to all the resets and power cycling during the pretest. THE CUSTOMER STILL WANTS TO MOVE TO THE NEW CARRIER.

Seems money talks.... Or cutting the corners to save a buck...

Hey Larry does that hotel owners last name start with a "P"?

This is one of the few times that the owner is not a "P". :shrug:

I think breed is correct dms 100 switches have problems with alot of old pri cards or systems you switch it to a 5e switch and see what happens

In my last 10 - 12 years at Transmission Engineering @ Vz, the 5E had the fewest ISDN-PRI D channel troubles as compared to the DMS-100. Unfortunately the naming conventions used to describethe PRI D channel protocol are not uniform, to include CPE PBX switches.

5E National 1 & National 2 are not know as the same in DMS land. DMS did not support, as of in 2002, the 5E Custom ISDN D CH protocol.

The trouble should have been refered to Vz Tier Two Technical Support. Even though most PRI issues are switch troubles, the transport support folks get the call first.

Suggest that the Vz customer account manager, or at a minimum, the Vz RSB handling the PRI trouble contact TTS for help. As one poster reccomended, the use of a IDSN-PRI test set (TPI Model 95, etc-A plain old T-Berd will only test the transport, not the D channel) would go a long way in decoding the LEC switch ISDN protocol to see if it katched what ever equivalent the PBX is running.

The T1 techs from VZ that I had worked with used a t-bird to test for CLEC's that would test the T1. but had another version that could answer and place calls. When they are the provider they should do this for you.

Somebody has to prove their side beyond reproach.

Make them prove to you the incoming calls come in on channel 1, that they can answer, and hold up the connection. The ILEC' s techs can call their supervisor to get the tester to do it.

Then in the meantime, I would be trying to prove my side beyond reproach. You might even get your future ClEC to provide a tester.

I have been the Verizon field tech trying to prove my side. I had to use test equipment because I had no idea what the vendor had. It would have every setting to try, show the channel, and let you talk on it. I would feel pretty good when it would do all of this. I would then compare all my settings with what the Vendor had:
Ascend(in on channel 1, yours switch should be desend, out on channel 23,all channels turned up, rec digits the same. (because I was an outside guy I used to get this screwed up with the inside guys all the time. They would say I am sending 3......Mine would say Rec digit 3. Then I would make them say, I am stripping off 5 digits and sending you 3. OK.OK) B8ZS, ESF.

I am on the Vendor side now, trying to be beyond reproach, so I feel your pain.I came in on one of these that had had the switch changed out, and had the same trouble with the substitute switch, but they were progamming the same problem back in.Calls would mis-route or cut-off on incoming. Switch was on acsend because it wouldn't call out on desend. Telco had 4 channels turned down. Everybody got on same page, all was good.

It pays to make that field tech prove it to you.

Now on my side, I use the same substitute switch to test all PRI's. I have never even had to change a setting to get it to work to do most test, as long as the digits match. I have a block with a phone.

In my little world (NORSTAR) it has has it's own symtoms, that tell me all I need to know.
like, if my prime set for trunks is none, the Phone co. gives caller ATB. If prime set is the main phone, all calls will at least default to that phone.
We had a setting, business name, that to this day I don't fill in because it may lock up the switch and cause a reset.
I use mine to do all CKT test because I don't know all the brands.
I backed the phone company down with my switch several times, especially intermittent trouble. I keep this baby plugged in all the time. 5 minutes and 2 long cords.
Somebody has to bring up their end. I had the GTE high freaks,(T1 boys) tell me one time, not our T1/pri, and then I got to tell them back" well you guys have the maintenance contract" and I made them bring one out the switch. Intermittent for a year, then the telco PBX dept was on my side. It was finally fixed by building a new ckt. NO NO NO not just the pair, every part new.
I have even hauled their (cust) switch to a known good PRI, ( a church that gets special treatment)
and I could knock down. (I used to short the pair on this one just to see how many hits it would take to knock it down and how the switch would act.)
Another thing Vz was bad about. We would work an order, get everything working, and at some point in the future something would update and make it match the billing for instance. Then we would have to put things back. Most of this had to do with dates on the order. It had to do with their computor systems doing the order the way it was written, not the way it was working.
In their defense, it was usually easy to tell when they had something screwed up because more customers would have trouble too.
I do know this. Things can change, and no person does it, because the mistake was really made 40 days before. That when they are doing a manual cut so to speak, they set the update date to 2099 or some crap to keep the switch out of it.
This could even be some kind of crazy VZ routing issue(inbound is their baby, outbound is yours.) It could be using a different route coming from international.
SUBSTITUTION-there is no substitute.
Keep us posted. PS I'll mail you mine.