QoS seems wrong 1

[peterdonnelly]

Hello brains. External callers have been reporting terrible crackling on calls. Internal IP to IP calls are perfect and calls across the WAN are sweet too. Internal callers only occasionally notice crackling on the external calls. One thing I have noticed is that packets from the call server are tagged as DSCP56. This doesn't seem right but element manager reports DSCP 46 in use. All tagging is trusted from telephony ports throughout my LAN. Why is DSCP56 coming in and would it be affecting/causing the aforementioned behaviour. BTW. Our support company want to reseat the PRI card and reboot the system to apply a list of patches and PEPs. Does this seem OK? finally, has anyone heard of Pri cards loosing sync with the ISDN from the exchange thus manifesting itself in crackling calls. Lots of love. Peter

 

[Firebird Scrambler]

Hello Pete

Have you checked the ISDN 30 clocking on your system in LD 60?. Your fault sounds to be a classic case of this happening.
Also in LD 60, key in LCNT to print off the ISDN traffic and you should normally just see "0's" in the results.

Your ISDN bearer must be locked and not in free run.

All the best

Firebird Scrambler
Meridian Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[peterdonnelly]

What should i be doing in ld 60? BT were on site and disabled channels and made outgoing calls for testing but i dont think testing was complete enough.

 

[Firebird Scrambler]

Hello Pete

In LD 60 you need to key in LCNT to see the ISDN traffic results. Also key in something like SSCK 4 0 or SSCK 8 0 etc. It depends on where your isdn cards are located.

However, it's best to go into LD 73 and e.g.

>LD 73
REQ PRT
TYPE PRI2
FEAT SYTI

MGCLK 4 0 3
PREF 4 0 3
SREF
CCGD 15
CCAR 15
EFCS NO

REQ END

>LD 60
DTI000
SL-1 --- SYS-12/AXE-10 SWE/NUMERIS/SWISS/TCNZ
/EUROISDN/SING/THAI/MSIA/INDO/CHNA
/INDI/PHLP
CHANNEL TIMESLOT MAPPING

.
SL-1 NETWORK TIMESLOT
B-CHANNEL 1 -15 1 -15 1 -15
16-30 17-31 17-31
D-CHANNEL 31 16 16
SSCK 4 0
ENBL
CLOCK ACTIVE
CLOCK CONTROLLER - LOCKED TO SLOT 3
PREF - 3
SREF -
AUTO SWREF CLK - ENBL

.lcnt

PRI2 TRK LOOP 220
MNT NNDC NNC OOS
BPV- 000 000 000 000
FAP- 000 000 000 000
SLP- 000 000 000 000
CRC- 000 000 000 000
G2 - 000 000 000 000
MAINT NONEWCALL UNAVAIL SEVERE
TOTAL 24HR BPV - 000000000 000000000 000000000 000000000
TOTAL 24HR CRC - 000000000 000000000 000000000 000000000
TOTAL 24HR FAP - 000000000 000000000 000000000 000000000
TOTAL 24HR SLPREP - 000000000
TOTAL 24HR SLPDEL - 000000000
TOTAL 24 HOUR G2 AIS -000000000
TOTAL 24 HOUR G2 LFAS -000000000
TOTAL 24 HOUR G2 LMAS -000000000
TOTAL 24 HOUR G2 RAI -000000000
TOTAL 24 HOUR G2 LOS -000000000
TOTAL 24 HOUR G2 RAIE -000000000

The main thing is to see the link as "LOCKED" and not "FREE RUN"


All the best

Firebird Scrambler
Meridian Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[curtismo]

Is this a 6.0 system? If so, see my previous post at

http://www.tek-tips.com/viewthread.cfm?qid=1587725

Are you also seeing this wrong Diffserv tagging out of your MGC cards also? I have taken Wireshark sniffs that I can prove there is something wrong here. Confirm your QoS Diffserv settings in Element manager but I would be your DSCP are set correctly for 46.

My provider has had this report from me for weeks but has not yet given me a solution. Maybe with a second person on Tek-Tips reporting the problem will have others check out their installations.

 

[peterdonnelly]

let me capture the data from the MGC as well. i will report back.

 

[curtismo]

If your situation is similar to mine, here is the reasoning why external calls are having problems, and IP-IP calls are not:

1. PRI trunks are in a cabinet/chassis with MGC incorrectly tagging packets as CS7, which your routers/switches may or may not be throwing away, or your router equipment is ignoring, since thet are looking for DSCP 46 (EF) tags as normal.

2. IP to IP set calls are ok since the Nortel UNISTIM phones are correctly setting up an RTP speech path using DSCP EF.

3. Anything between multiple cabinets/chassis (such as digital sets or analog sets) will also be incorrectly tagged.

Again, I can prove that there is something screwey with 6.0 MGC cards incorrectly tagging voice packets, but have yet to get anyone at the provider to move on it. Would be nice to have someone else confirm an issue, which I believe you may find on your system.

 

[peterdonnelly]

i am in agreement with you curtismo however i am running version 5 on my cs1000 but thst could just be by-the-by. what i am capturing is packets coming from the DSP on my MG controller is going onto the LAN (TLAN) with DSCP56 and VLAN priority 7 and the switches are all set to honour tagging. I have flagged this with my provider and they are not too sure what to do as yet. what do you think I do next. By the way, as part of this problem my provider just patched my system and cycled the power.

 

[curtismo]

I just went from 4.5 to 6.0, so first experience with MGC cards, etc. I'm wondering whether there is a common patch (as our vendor installed the current 6.0 Deplist on our multiple systems) or MGC loadware change that is causing the issue across versions.

I'd say its time to run it up the flag with ETAS. Yes, I can write filters for my switches and routers to resolve the issue, but all that is is a band-aid for what I believe is a root-cause problem. For various reasons that I cannot go into I can't force the issue at this time with my provider, even though I am sure there is a problem.

 

[peterdonnelly]

BT are going to replace a card in the local exchange tonight at 6pm. I will report back.

 

[curtismo]

Not sure how replacing an exchange card is going to help your situation, as it looks like your PRI is clean.

 

[peterdonnelly]

BT have replaced an exchange card and reported occurrences of crackling have been reduced to 1 in a day. The call is still open at the moment.

 

[peterdonnelly]

Whoops. Users still reporting crackling. It's funny how you actually need to push users to report this sort of thing. Either way, we are still getting crackling. Back to the drawing board. Will report back findings.