Sorry to re-post this... I sent the last one from a mobile T-Mobile account
and their IP was evidently picked up as spam. My apologies for the "spam
message" that was sent to the list earlier!
Can someone help me understand how to identify frame slips from
"pri debug", "pri intense deb
Our MailScanner believes that the attachment to this message sent to you
From: [EMAIL PROTECTED]
Subject: RE: [Asterisk-Users] Identifying Frame Slips from PRI debug
is Unsolicited Commercial Email (spam). Unless you are sure that this message
is incorrectly thought to be spam, please
> Just to clarify, the frame slips are on the T1 circuit which
> is delivering your PRI service.
That is correct.
> If you are correctly adjusting your timing leaving to match
> the recevieved timing from the CO there will be no slips. I
> am unaware of any mechanism within an * server to repor
Just to clarify, the frame slips are on the T1 circuit which is
delivering your PRI service.
If you are correctly adjusting your timing leaving to match the
recevieved timing from the CO there will be no slips. I am unaware of
any mechanism within an * server to report this. Of course T-BER
>> Can someone help me understand how to identify frame slips
from "pri debug",
>> "pri intense debug", or any other method?
>>
>> I am familiar with zttest, avoiding interrupt sharing,
mucking with ACPI,
>> making sure DMA is on, etc... I have a
On 21 Dec 2005, at 15:18, <[EMAIL PROTECTED]> wrote:Can someone help me understand how to identify frame slips from "pri debug","pri intense debug", or any other method? I am familiar with zttest, avoiding interrupt sharing, mucking with ACPI,making sure DMA is on, etc... I have a list of changes
Can someone help me understand how to identify frame slips from "pri debug",
"pri intense debug", or any other method?
I have 2 Dell 18xx servers (at different locations) connected to the PSTN
via PRI's. One is connected with a T100P and the other via a TE110P. Both
are in production and seem
