point to point IP500 issues connected via Sonicwall NSA220 over a shared 20M Charter pipe

[akakillroy]

We recently moved our point to point 20M charter connection between our two branches and are experiencing some latency issues, namely when a call is transferred from the main branch to the remote branch, long delay before anyone can hear or speak. Delayed ringtones, where no rings occur then someone answers. However once the call is established everything seem fine. This also occurs when we call between locations. Here is some of the log traffic for reference. Anyone have any ideas?

08:36:30 4197783117mS H323Evt: SESS 283e SetOperational local 10.23.1.85:0 remote 0.0.0.0:0 to 0
08:36:30 4197783117mS H323Evt: SESS 283e SetRemUDP 0 -> 49152, remote IP 0.0.0.0 -> 10.23.2.85
08:36:30 4197783118mS CMMap: PCG::MapBChan pcp[168]b0r1 cp_b 0 other_cp_b 0 type CGTypeSimple
08:36:30 4197783118mS CMMap: PCGS CPReserveCodec for the other end (pcp[168]b0r1) true
08:36:30 4197783118mS CMMap: PCG::MapBChan pcp[24]b1r0 cp_b f55c2e7c other_cp_b f55cc6bc type CGTypeSimple
08:36:30 4197783118mS CMMap: a=6.19 b=21.43 M12
08:36:30 4197783118mS CMMap: PlatformConnectionAudioSAP::Bind pcp[168]b0r1 to 6.19
08:36:30 4197783118mS CMMap: PlatformConnectionAudioSAP::ConnectVoice (connect) pcp[168]b0r1 echo_cancellation set to 0
08:36:30 4197783118mS CMMap: PlatformConnectionAudioSAP::ConnectVoice pcp[168]b0r1 Configure 6.19
08:36:30 4197783119mS CMMap: PlatformConnectionAudioSAP::ConnectVoice rtpRelay Open got rtpRelay ID: 1
08:36:30 4197783119mS CMMap: PlatformConnectionAudioSAP::ConnectVoice rtpRelay Configure success
08:36:30 4197783119mS CMMap: PlatformConnectionAudioSAP::ConnectVoice local IP addr 10.23.1.85:49154, Remote IP addr 10.23.2.85:49152
08:36:30 4197783119mS CMMap: PlatformConnectionAudioSAP::ConnectVoice DSP IP addr 1.1.1.3:32770, telogyHost IP addr 1.1.1.1:12
08:36:30 4197783119mS CMMap: PlatformConnectionAudioSAP::ConnectVoice rtpRelay Start success
08:36:30 4197783119mS CMMap: PlatformConnectionAudioSAP::ConnectVoice pcp[168]b0r1 ConnectIndication 6.19
08:36:30 4197783119mS H323Evt: SESS 283e SetOperational local 10.23.1.85:49154 remote 10.23.2.85:49152 to 1
08:36:30 4197783120mS CMMap: a=1.3 b=0.0 R0
08:36:30 4197783120mS CMMap: PCG::MapBChan pcp[68]b1r0 cp_b f5588630 other_cp_b 0 type CGTypeSimple
08:36:30 4197783120mS H323Evt: SESS 283f SetOperational local 10.23.1.85:0 remote 0.0.0.0:0 to 0
08:36:30 4197783120mS H323Evt: SESS 283f SetRemUDP 0 -> 49154, remote IP 0.0.0.0 -> 10.23.2.85
08:36:30 4197783121mS CMMap: a=1.3 b=0.0 PCGS CPReserveCodec (pcp[167]b0r1) true
08:36:30 4197783121mS CMMap: PCG::MapBChan pcp[167]b0r1 cp_b f55cc9c0 other_cp_b f5588630 type CGTypeSimple
08:36:30 4197783121mS CMMap: a=1.3 b=6.18 M12
08:36:30 4197783121mS CMMap: PlatformConnectionAudioSAP::Bind pcp[167]b0r1 to 6.18
08:36:30 4197783121mS CMMap: PlatformConnectionAudioSAP::ConnectVoice pcp[167]b0r1 Configure 6.18
08:36:30 4197783121mS CMMap: PlatformConnectionAudioSAP::ConnectVoice rtpRelay Open got rtpRelay ID: 2
08:36:30 4197783121mS CMMap: PlatformConnectionAudioSAP::ConnectVoice rtpRelay Configure success
08:36:30 4197783121mS CMMap: PlatformConnectionAudioSAP::ConnectVoice local IP addr 10.23.1.85:49152, Remote IP addr 10.23.2.85:49154
08:36:30 4197783121mS CMMap: PlatformConnectionAudioSAP::ConnectVoice DSP IP addr 1.1.1.3:32768, telogyHost IP addr 1.1.1.1:10
08:36:30 4197783122mS CMMap: PlatformConnectionAudioSAP::ConnectVoice rtpRelay Start success
08:36:30 4197783122mS CMMap: PlatformConnectionAudioSAP::ConnectVoice pcp[167]b0r1 ConnectIndication 6.18
08:36:30 4197783122mS H323Evt: SESS 283f SetOperational local 10.23.1.85:49152 remote 10.23.2.85:49154 to 1
08:36:30 4197783123mS H323Evt: v=0 stacknum=17 State, new=ICProceeding, old=Present id=868
08:36:30 4197783125mS H323Evt: v=0 stacknum=17 State, new=Active, old=ICProceeding id=868
08:36:30 4197783131mS CMLineRx: v=17
CMConnectAck
Line: type=IPLine 17 Call: lid=17 id=868 in=1

 

[DaIPOTek]

The problem definitely lies within the Sonicwall. Do you have proper QoS applied to the traffic between sites?

 

[akakillroy]

I configured the setting in the firewall to bypass all filtering, and added bandwidth priority. Added exclusions for all three IP's of the IPOFFICE and the Voicemail Server. I have an open call with SOnicwall but they can't seem to find the issue, they think its the phone system. It was working before switching to the SOnicwall.
Anyone else here with a Sonicwall that can share what you configured?

Sonicwall said that one site was sending tagged packets but the other side was not. Sonicwall says they will pass the taggs.

 

[akakillroy]

I followed the instructions here and applied them to the LAN port X6 I have the point to point connected and it does not seem to help :-(

http://help.sonicwall.com/help/sw/e...olicies_FirewallSettings_QoSMapping_Snwls.htm

 

[akakillroy]

I think I am getting somewhere, still getting long delays connecting between the branches, but fewer error messages in the trace:

10:02:34 4202946994mS CMCallEvt: 0a17015500099a40 0.629312.0 134389 RAS.0: StateChange: END=B CMCSConnReq->CMCSConnected
10:02:34 4202946995mS CMMap: a=240.1 b=0.0 X
10:02:34 4202946995mS CMMap: PCG Conference create g C[369] (240.1)
10:02:34 4202946996mS CMCallEvt: 0000000000000000 0.629311.0 -1 TargetingEP: StateChange: END=X CMCSOffering->CMCSDelete
10:02:34 4202946996mS CMCallEvt: 0000000000000000 0.629311.0 -1 BaseEP: DELETE CMEndpoint f187d2c0 TOTAL NOW=4 CALL_LIST=2
10:02:34 4202946997mS CMCallEvt: 0a17015500099a3d 0.629309.0 134388 Reception.0: StateChange: END=B CMCSConnReq->CMCSConnected
10:02:34 4202946997mS CMTARGET: 0a17015500000013 1.19.1 134388 Q931 Trunk:1 CHAN=1: ~CMTargetHandler f1738614 ep f177f764
10:02:35 4202947005mS CMExtnEvt: v=(null) State, new=Idle old=Idle,0,0,2210: Feature Key Pressed 19CPLFeatureOffHook
10:02:35 4202947006mS CD: CALL: 1.19.1 BState=Connected Cut=3 Music=0.0 Aend="Line 1" (1.2) Bend="" [Reception(2210)] (0.1) CalledNum=106 (Receptionist) CallingNum=6189718262 (WIRELESS CALLER) Internal=0 Time=8614 AState=Connected
10:02:35 4202947007mS CMMap: a=1.2 b=0.0 R0
10:02:35 4202947007mS CMMap: PCG::MapBChan pcp[67]b1r0 cp_b f5588948 other_cp_b f1689f3c type CGTypeConference
10:02:35 4202947007mS CMMap: a=240.1 b=1.2 M11
10:02:35 4202947008mS CMMap: PCG::MapBChan pcp[95]b1r0 cp_b f556dadc other_cp_b f1689f3c type CGTypeConference
10:02:35 4202947008mS CMMap: a=240.1 b=0.1 M11
10:02:35 4202947008mS CMMap: PCG::MapBChan pcp[23]b1r0 cp_b f55c3784 other_cp_b f1689f3c type CGTypeConference
10:02:35 4202947008mS CMMap: a=240.1 b=21.11 M11
10:02:37 4202949724mS CMExtnEvt: JENNIFER HARTMA: No user activity
10:02:50 4202962928mS CMExtnEvt: SONNY DISHER: No user activity

 

[Westi]

Have you tried rebooting your firewalls and Network switches yet?

Joe W.

FHandw, ACSS (SME)


"This is the end of the world, make sure to buy your T-shirt before it is too late"
Original expression of my daughter

 

[akakillroy]

Yes, they have been restarted. I did discover this in my cisco router, and communicated with Sonicwall and it seems that we needed to add an explicit QoS rule on the access rule.

class-map match-all Voice-sig
match ip dscp af41
class-map match-any Voice-rtp
match ip dscp ef
match protocol rtp
!
!
policy-map Voice-voip
class Voice-sig
bandwidth percent 5
class Voice-rtp
priority percent 33
class class-default
fair-queue

So far that seems to be helping.