asterisk users - Dec 2005 - Identifying Frame Slips from PRI debug

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 to work fairly well for voice, though we have had
mixed success with SpanDSP.  The phone company recently called me to let me
know that their switch showed we were experiencing a number of frame slips,
error seconds, unavailable seconds, and FES(I think?) on both of our PRI
circuits.  They also surprised me by showing up at one of the sites to test
the circuit.  All of their tests show the circuit as fine.

I am familiar with zttest, avoiding interrupt sharing, mucking with ACPI,
making sure DMA is on, etc... I have a list of changes I intend to make to
the server(s), but don't know how to actually watch the output to see if my
changes are affecting the # of frame slips.

I have several other similar machines in production connected via PRI to
different phone companies, and I suspect they are experiencing the same
issues... but that the other phone companies are not as pro-active in
letting me know there are problems.  Any help would be tremendously
appreciated!

Thanks!

Eric

On 21 Dec 2005, at 15:18, <ewr@erols.com> 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 I intend to  
> make to
> the server(s), but don't know how to actually watch the output to  
> see if my
> changes are affecting the # of frame slips.
>
First things first;
Check your timing param in zaptel.conf, you almost certainly want
it set to 1 if you are connecting that span to a phone company and it is
the only such connection on that board.

Tim.

http://www.westhawk.co.uk/

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20051221/88fc8264/attachment.htm

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 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 I 
>>>> intend to make to the server(s), but don't know how to
actually
>>>> watch the output to see if my changes are affecting the # of
frame
>>>> slips.
>>>
>>> First things first;
>>> Check your timing param in zaptel.conf, you almost certainly want
it
>>> set to 1 if you are connecting that span to a phone company and it 
>>> is the only such connection on that board.
>>
>> The timing is already set to 1 for each of the cards.
>
> Ah, worth asking. Also, just in case, have you powercycled those boxes 
> since you set the timing source ?
Yes.  These boxes were all set "correctly" during their original
install,
and have been power cycled several times since then.
> I had no end of trouble 'till I noticed that a cold-start seemed to be 
> the only thing that ensured that both ends of the link _knew_ that I'd 
> changed the timing settings.
>
> I've mentioned this on-list a while back and got mixed reactions, some 
> folk felt cold start is overkill and a mod/load/unload is enough, but 
> everyone agrees that an asterisk reload isn't enough.
>
> The only other thing I can advise is that you look at running the 
> patch that Matt (Fredrikson?) from Digium put out a month or so back, 
> it allows the low level HDLC protocol to run on the chip, not in the
kernel.
> I haven't looked at it as I don't think it is supported on the
older
cards.

I am aware of this patch (5313), but it appears to only work for TE4XX/TE2XX
cards.  Since the two cards I am using are T100P and TE110P I don't think it
is currently an option.

Eric

Hi,
 
When I call to my asterisk server, voice prompts play ok but when it
goes to music on hold, sound is all broken. Why is that, is there some
ports which Music on hold uses which are not configured properly, or
there is some other reason.
 
Zeeshan A Zakaria
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20051224/ab9f6d32/attachment.htm

On Saturday 24 December 2005 14:42, Zeeshan wrote:
> Hi,
>
> When I call to my asterisk server, voice prompts play ok but when it
> goes to music on hold, sound is all broken. Why is that, is there some
> ports which Music on hold uses which are not configured properly, or
> there is some other reason.
>
> Zeeshan A Zakaria
Are you calling from a cellphone (mobile ) ?

Usually MOH sounds terrible on a mobile/cellphone because the GSM codec cannot 
handle music properly

Pail

-- 
Paul Hewlett - CottonPickinMinds - www.cottonpickinminds.co.za
Tel: +27 21 852 8812      Cel: +27 84 420 9282      Fax: +27 86 672 0563
--