One-Sided Fade Outs on IPO4 5

[573dawn]

Hi All, new thread for a not-so-new problem. I'm sure some of you are well aware of my dropped call issues. Afte changes made today, we are getting fewer drops, though not eliminated. However, we have this new problem: The call will "fade out" while you are on the phone. It doesn't drop, but one or the other party will get silence, while the remainign party can still hear the opposite party. This lasts a few seconds and then both parties can hear each other again.

In Monitor I can see:

********** contact lost with 192.168.3.180 at 14:13:28 6/7/2007 - reselect = 2178 **********
******************************************************************


********** SysMonitor v6.0 (5) **********

********** contact made with 192.168.3.180 at 14:13:28 6/7/2007 **********

********** System (192.168.3.180) has been up and running for 2days, 22hrs, 34mins and 31secs(254071121mS) **********

Along with the occasional dopped packets. But these calls DON'T disconnect, just fade in and out.

 

[kurthansen]

Dawn,

I looked at the cisco link you put on your message and I thought it was odd that there was no traffic that was marked AF41. So I looked at the configs you sent me and someone changed the signaling on all your systems to DSCP 0. Default on IP Office is dec 34 or AF41. So the signaling isn't being prioritized.

To change the diffserve setting on IP Office you would go to the system then lan Tab. Under there there is a Gatekeeper tab. You will see DSCP, DSCP hex and Sig DSCP. Sig will be set for 0 it needs to be 34 to work with the policy you are using.

 

[573dawn]

kurthansen, thanks! I wondered about that too, actually. I will make that change as soon as everyone is off the phone <g>. Why would anyone have changed this from the default? What does it do? I don't even know what it is, so I didn't change it.

Also, OT, I sent you an email a while back regarding your next potential trip to LOTO, did you get that?

Thanks, Dawn

 

[kurthansen]

It is the signaling between IP Offices. It is all the stuff other then voice traffic that goes between IP phones and IP system (Trunks).

I got your email. Sorry been very busy and not sure if/when I will be back in that area. My wife and I have decided we are going to move so that may take all of our vacation time.

 

[573dawn]

kurthansen, Ok, sig dscp has now been changed on all DS units to 34. I am now seeing matching packets for af41 but they still aren't showing in the columnar dscp listing. Of course now the phones would choose to slow down! But I did notice that one cisco shows dscp ef and the other dscp 46. I have looked at both DS units and they are definitely 46, so what is ef? It isn't hex for 46 so should I change my policy map to 46 on that cisco?

I hope your possible move is a positive thing. If you ever do make it here again, the email remains valid, just let me know, you sacrificed alot of your time for us.

 

[kurthansen]

EF is Expedited Forwarding is decimal 46. My guess is that you have different versions of software on your Routers that one shows 46 while the other shows EF. I am not sure why the columns on the routers aren't showing the traffic correctly. When I showed our Cisco guy your info he couldn't remember seeing that before.

EF 101 11 0 00 0x2E 46 0xB8 184 EF Expedited Forwarding
AF4 100 01 0 00 0x22 34 0x88 136 AF41 Assured Forwarding AF(z)
100 10 0 00 0x24 36 0x90 144 AF42
100 11 0 00 0x26 38 0x98 152 AF43
AF3 011 01 0 00 0x1A 26 0x68 104 AF31
011 10 0 00 0x1C 28 0x70 112 AF32
011 11 0 00 0x1E 30 0x78 120 AF33
AF2 010 01 0 00 0x12 18 0x48 72 AF21
010 10 0 00 0x14 20 0x50 80 AF22
010 11 0 00 0x16 22 0x58 88 AF23
AF1 001 01 0 00 0x0A 10 0x28 40 AF11
001 10 0 00 0x0C 12 0x30 48 AF12
001 11 0 00 0x0E 14 0x38 56 AF13

 

[573dawn]

You are correct, I do have different software versions, 12.2 on one, 12.3 on the other. I am going to try and get all of them on the same version next week, I can' do it on a weekend.

Meanwhile, here is the current reporting, strange:

to3mm#sho policy-map int se0
Serial0

Service-policy output: voipQos

Class-map: VoIP (match-any)
941913 packets, 191630059 bytes
5 minute offered rate 35000 bps, drop rate 0 bps
Match: ip dscp ef
939532 packets, 191440131 bytes
5 minute rate 34000 bps
Match: ip dscp af41
2381 packets, 189928 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 768 (kbps) Burst 19200 (Bytes)
(pkts matched/bytes matched) 4316/872915
(total drops/bytes drops) 0/0

Class-map: class-default (match-any)
1488333 packets, 156992342 bytes
5 minute offered rate 22000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9

dscp Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
af11 0/0 0/0 0/0 32 40 1/10
af12 0/0 0/0 0/0 28 40 1/10
af13 0/0 0/0 0/0 24 40 1/10
af21 0/0 0/0 0/0 32 40 1/10
af22 0/0 0/0 0/0 28 40 1/10
af23 0/0 0/0 0/0 24 40 1/10
af31 0/0 0/0 0/0 32 40 1/10
af32 0/0 0/0 0/0 28 40 1/10
af33 0/0 0/0 0/0 24 40 1/10
af41 0/0 0/0 0/0 32 40 1/10
af42 0/0 0/0 0/0 28 40 1/10
af43 0/0 0/0 0/0 24 40 1/10
cs1 0/0 0/0 0/0 22 40 1/10
cs2 0/0 0/0 0/0 24 40 1/10
cs3 0/0 0/0 0/0 26 40 1/10
cs4 0/0 0/0 0/0 28 40 1/10
cs5 0/0 0/0 0/0 30 40 1/10
cs6 1204/98852 0/0 0/0 32 40 1/10
cs7 0/0 0/0 0/0 34 40 1/10
ef 0/0 0/0 0/0 36 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10
default 1487217/156902909 0/0 0/0 20 40 1/10

to3mm#

AND

to21mm#sho policy-map int se0
Serial0

Service-policy output: voipQos

Class-map: VoIP (match-any)
23 packets, 4692 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp 46
23 packets, 4692 bytes
5 minute rate 0 bps
Match: ip dscp 34
0 packets, 0 bytes
5 minute rate 0 bps
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 768 (kbps) Burst 19200 (Bytes)
(pkts matched/bytes matched) 23/4692
(total drops/bytes drops) 0/0

Class-map: class-default (match-any)
50591 packets, 2381702 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Weighted Fair Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9

dscp Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
af11 0/0 0/0 0/0 32 40 1/10
af12 0/0 0/0 0/0 28 40 1/10
af13 0/0 0/0 0/0 24 40 1/10
af21 0/0 0/0 0/0 32 40 1/10
af22 0/0 0/0 0/0 28 40 1/10
af23 0/0 0/0 0/0 24 40 1/10
af31 0/0 0/0 0/0 32 40 1/10
af32 0/0 0/0 0/0 28 40 1/10
af33 0/0 0/0 0/0 24 40 1/10
af41 0/0 0/0 0/0 32 40 1/10
af42 0/0 0/0 0/0 28 40 1/10
af43 0/0 0/0 0/0 24 40 1/10
cs1 0/0 0/0 0/0 22 40 1/10
cs2 0/0 0/0 0/0 24 40 1/10
cs3 0/0 0/0 0/0 26 40 1/10
cs4 0/0 0/0 0/0 28 40 1/10
cs5 0/0 0/0 0/0 30 40 1/10
cs6 1111/50113 0/0 0/0 32 40 1/10
cs7 0/0 0/0 0/0 34 40 1/10
ef 0/0 0/0 0/0 36 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10
default 49485/2332118 0/0 0/0 20 40 1/10

to21mm#

 

[kurthansen]

That is odd. I don't know how much I would trust the column information on the bottom. The stuff above the table shows traffic that is marked correctly. I wonder why the second router doesn't show any thing on 34.

 

[573dawn]

I wondered that too, that one is the one here at the main site. It still doesn't show any packets for 34, which seems kind of impossible.

 

[Gibsonic]

this thread needs more cowbell...i mean stars.

 

[kurthansen]

Take a look at network traffic with ethereal or wireshark and see if the IP Office is marking packets.

 

[573dawn]

kurthansen, I will do that, I have ethereal around here somewhere. I'm leaving a bit early today, but will post the results tomorrow!

Gibsonic, ********SUPERSTAR********** thread!