Changing from PRI to CT1 involves a config setting. Under the trunk settings the signal mode is what you're looking at as far as PRI or CT1. Robbed bit is CT1, message oriented is PRI. Todd -----Original Message----- From: usr-tc-admin@mailman.xmission.com [mailto:usr-tc-admin@mailman.xmission.com]On Behalf Of Dan Houtz Sent: Thursday, November 07, 2002 9:23 AM To: usr-tc@mailman.xmission.com Subject: Re: [USR-TC] Help with LPBK/D-ALM I believe changing from PRI to CT1 is not a setting but, instead, a different firmware. Is this correct or am I way off base? Dan ----- Original Message ----- From: "Lee Terrell" <leet@directcon.net> To: <usr-tc@mailman.xmission.com> Sent: Thursday, November 07, 2002 9:22 AM Subject: Re: [USR-TC] Help with LPBK/D-ALM
Charles Sprickman wrote:
On Thu, 7 Nov 2002, Joel - Fox Computers wrote:
But if you're missing options on a DSP, I would expect that to be more an NMC issue than the ARC. Like with V.92 - all DSP's with the newest code support it, but if the NMC code isn't new enough, the options are not available in TCM and therefore cannot be enabled.
Very good point. From the previous post it sounds like the cards are
not
set for PRI. If they are setup for CT1, that loopback/D-ALRM LED should not be lit. Perhaps the working DSPs were set for PRI way back when the chassis was initially installed and they are holding that setting across firmware upgrades, but the new cards w/new code are not being "talked to" correctly by the NMC due to an older code version...
Of all the weird DSP behaviour I've seen, I don't think I've seen this as a hardware failure mode...
So, when you say not being talked to correctly by the NMC due to an older code version, you are referring to older code on the NMC correct? If that is the case then it would be worth a shot to re-arrange my PRIs to free up a slot on my chassis with the newer NMC code and see if I have any better luck configuring the DSP.
All I have ever worked with are PRIs, I've never used or looked at a hardware configuration for CT1. What are some signs I can look for in either TCM or the CLI to verify if these DSP cards are configured to accept PRI or CT1? Or maybe I'm way off on this too, I've never seen any explicit settings for a PRI or CT1, so that should probably be specified by the options in the trunk settings right?
As I said earlier, I did see in the CLI from the "sh modem_group" command that the card reports 24 modems available rather than the 23 that show up under PRI, so based off that little bit of information it would make sense to say these DSPs are probably setup to accept CT1.
By loading a configuration from a DSP currently working on a PRI, shouldn't that over-write any CT1 configuration and change it to show the same PRI config as a working DSP? Or would this not work depending on the NMC code version?
I had initially assumed that because these DSPs came to me with 1.2.37 for the code version, I should have access to any possible configuration options available from that code version and those added up to the 2.1.9 I'm running now. But now I'm seeing that was a dangerous assumption. I'd like to be able to get newer code for my components, but that's not going to happen unless I find a magical way to dig up a contract.
It sounds like I at least have a few more things to try before I write these off as faulty hardware.
Thanks for the added feedback.
-Lee
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc
_______________________________________________ USR-TC mailing list USR-TC@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/usr-tc