Alcatel Unleashed

Hi Joao,
I presume you are using IpDesktopSoftPhone for the agents, can you give me its version number.
The test with a real 4068 will help me to confirm if the issue is an IPDSP or an OmniPCX RECORD issue.

JP

Hi,

the IPDS is 90% on 10.0.1.2 and some others in 10.0.1.3.

I'm configuring an 4068 set to substitute one agent for the day today and see what happens.

Hi all,

Well, i tested with a 4068 hard phone, and the records are poor quality too.

I changed the last Cisco Switch by another 6450, applied the QoS rule, but it's still bad.

Is this log what should happen with the rules?

3/12/14 10:39:45 NI[1/0]: Apply QoS configuration (cli)
3/12/14 10:39:45 [@10:39:43] rule 'R.VOICE_DSCP_46' matched:accept
3/12/14 10:39:45 DoubleTagged. 802.1p 0 cvlan 0 c802.1p 0
3/12/14 10:39:45 svlan 920 VRF (null) port 1/25 -> 1/24
3/12/14 10:39:45 MAC XX:XX:XX:XX:XX:XX -> YY:YY:YY:YY:YY:YY
3/12/14 10:39:45 TOS 0xb8 (UDP) 1.1.1.1:32514 -> 2.2.2.2:32596

Thanks

Hi Joao,
sorry for the delay in the answer.

I talked to the VOIP experts around me and they cannot understand why the recording is bad when you have a call with an external party. This does not sound logical. Replication is done by the softphone and the quality of the live call is OK.
That said,
my recommendations are:
-1- Change the QOS policies to be sure the replication streams are carried correctly on your network (the ports used for stream replication are given in the OmniPCX-RECORD documentation). An advice from the Data/Voip experts is to change your QOS strategy and prioritize all the packets to/from the OmniPCX-Record server.
-2- If you are not successful with the first recommendation, you can try to determine where the issue happens by capturing and converting to audio the rtp streams with wireshark : desktop level, recorder, in between.

I look forward hearing from you


JP

Can you post a small network diagram of your environment? I don't see any reason why you should have bad quality. With that we can see were you can do some test points.

jpalbinet: I'll try and post some feedback.

cavagnaro:

The network is quite big, but taking a snapshot of the way from and to the recorder:


UserDesktop(112 desktops, being 65 agents) <-------> 3x6450-48 <-----1 Gbps FO link------> CAD

CAD = Merge point for 5 other places like this site above. In total, 6x1Gbps FO links arrives in this place, what's added to 4x6450-48 (stacked) and 1x6450-24 (non-stacked) user stations

From CAD, we continue:

CAD <------1xLinkAgg(2x1Gbps FO)----> DATA CENTER

in Data Center, we have one 6900-T40. This 6900 has some LinkAgg for the VMware servers (4x1Gbps each). OmniRecord is in one of them. This 6900 has another LinkAgg (2x1Gbps) for one Cisco 45xx, that gives access to another 12 fiber optics remote sites. I think this Cisco has nothing to do in this case, because no server or user is connected to it, regarding the Recording.

OXE Appliance Server is connected to the 6900.

The only other FO connected to 6900 goes to the last site of our topology, that's where the Crystal HW and NPRAE links are connected.

DATA CENTER <----- 1Gbps ----> 1x6450-24 <-------- INTIP -------->

From this 6450, there are 2 Ciscos 2960 connected but a Giga common port, and adds no more thank 50 stations.

What's more weird is:

Many of these Alcatel switches where Cisco with no VLAN configured (!). The problem was only in the recording, but the agents got quality voice when talking.

We changed for Alcatel Switches and configured VLANs but the FO links stayed on the Cisco 45xx. The network was much faster, but the problem continued. Good quality voice when talking, bad recording.

We got the uplinks connected directly to 6900, and the quality of the voice, when talking, got worst, but usable.

We applied the QoS rules on all alcatel switches, using Source Vlan. Voice got even more worse!!!

Then i took of the QoS rules, and now the voice when talking is good, but recording is poor.

I know it's very, very strange, but it is what is happening.

I'm preparing, as suggested by jpalbinet, some QoS rules only for the RTP packets itself, because using only clan would get youtube packets with priority too, for example.

I'm just not so sure how i can eventually "see" that the packets are really being priorized.


Thanks for all.

Hi everybody.

I applied the following QoS now:

! QOS :
qos trust ports
policy condition C.IP.INTIP.DESTIN destination ip 1.1.1.1
policy condition C.IP.INTIP.SOURCE source ip 1.1.1.1
policy condition C.IP.RECORDER.DESTIN destination ip 2.2.2.2
policy condition C.IP.RECORDER.SOURCE source ip 2.2.2.2
policy condition C.UDP.PORT.RANGE.DESTIN destination udp port 32000-32999
policy condition C.UDP.PORT.RANGE.SOURCE source udp port 32000-32999
policy condition C.VLAN.FROM.VOICE source vlan TEL_VLAN
policy action A.SET.DSCP.VOICE dscp 46
policy action A.SET.PRIO.5 priority 5
policy rule R.IP.RECORDER.SOURCE condition C.IP.RECORDER.SOURCE action A.SET.PRIO.5 log
policy rule R.IP.RECORDER.DESTIN condition C.IP.RECORDER.DESTIN action A.SET.PRIO.5 log
policy rule R.VLAN.FROM.VOICE condition C.VLAN.FROM.VOICE action A.SET.DSCP.VOICE
policy rule R.UDP.VOICE.DSCP.46.SOURCE condition C.UDP.PORT.RANGE.SOURCE action A.SET.DSCP.VOICE
policy rule R.UDP.VOICE.DSCP.46.DESTIN condition C.UDP.PORT.RANGE.DESTIN action A.SET.DSCP.VOICE
policy rule R.IP.INTIP.SOURCE condition C.IP.INTIP.SOURCE action A.SET.PRIO.5
policy rule R.IP.INTIP.DESTIN condition C.IP.INTIP.DESTIN action A.SET.PRIO.5
qos apply

In the weekend, the problem was a little bit reduced, but still happens. Today will be the fire test, because in the weekend works are reduced too.

Does anyone has any tip for these rules?

Hi Joao,
As already said, streaming is replicated at the desktop level (IPDSP).
Ports used for replication always starts from 2000 , it depends how many calls are in progress at any given time.
if 100 are recording it will go to 2200 , if 300 , it will go to 2600 and so on.
You can try to add rules in order to be sure that rtp packets are correctly carried from the desktops to the recorder.

Have you tried to listen to the streaming (the replicated one) by using wireshark on the desktop?

Good luck with that.

JP

Hi jpalbinet,

I added the following rules:

policy condition C.UDP.PORT.RANGE.RECORDER destination udp port 2000-2999
policy rule R.UDP.RECORDER condition C.UDP.PORT.RANGE.RECORDER action A.SET.PRIO.5

I got the packets in wireshark, and saw that only destination to recorder are 2000+.

I have three questions:

1. How can i listen to wireshark packets? I know how to do with SIP packets, but not NOE.

2. I'm a little bit confused about DSCP 46 or PRIO 5. Are they the same? Does the result is the same? Which one is better?

3. Should i have these rules only on the first switch or in all of them? I have applied in all of them, but in qos log i keep seeing DOUBLETAGGED and i don't know if it's good.

Thanks to all.

Answering to 1
Not an expert on this, but this is what I've being told:

1. Open the traces > select a UDP packet (from phone to the recorder) > go to Analyze > decode as > select RTP and apply.
2. Now select Telephony > Go to RTP and show all streams > select a stream and select analyze.
3. Now play the stream in the player.