[cisco-voip] intercluster trunk over IPSec VPN

Stephen Welsh stephen.welsh at unifiedfx.com
Tue Feb 14 10:54:07 EST 2012


Generally anything over 150ms delay is perceived by the user and they will end up talking over each other, however for off-shore environments VSAT may be the only communications option, so the users are used to the delayed communication and adapt accordingly.

I've assisted with VOIP over VSAT configurations in the past, you typically have to use every trick in the book to get the bandwidth as low as possible, i.e. increase the payload size, use the most compressed codec your equipment support etc.

But fundamentally if you don't have a valid and proven QoS configuration it will fall apart very quickly, due to the inherent limitations of VSAT.

I'm assuming the access speed is low (i.e. below 768k), so you need to ensure interleaving is also enabled or else a large data transfer will disrupt your RTP stream.

Thanks

Stephen

On 14 Feb 2012, at 15:43, Mike King wrote:

Abebe,

I can't find the snrd i was looking for, but I found it for the CUCME.
http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/srnd/design/guide/nstrct.html#wp1043924

Generally, to get acceptable audio quaility, it's not recommended to go above 100msec of delay.

Mike

On Tue, Feb 14, 2012 at 1:23 AM, Abebe Amare <abucho at gmail.com<mailto:abucho at gmail.com>> wrote:
Hi Wes, thanks a lot for your detail explanation, it is very educational.

I should have stated earlier that the Internet connection is a VSAT link. Here is a ping output from the CUCM to the far side CUCME,

admin:utils network ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1<http://192.168.100.1/>: icmp_seq=0 ttl=254 time=577 ms
64 bytes from 192.168.100.1<http://192.168.100.1/>: icmp_seq=1 ttl=254 time=579 ms
64 bytes from 192.168.100.1<http://192.168.100.1/>: icmp_seq=2 ttl=254 time=587 ms
64 bytes from 192.168.100.1<http://192.168.100.1/>: icmp_seq=3 ttl=254 time=584 ms

--- 192.168.100.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3036ms
rtt min/avg/max/mdev = 577.892/582.386/587.697/4.048 ms, pipe 2

I have configured QoS on the gateway routers to put the VPN traffic in LLQ with reserved bandwidth. What other mechanisms do you suggest to improve the voice quality?

best regards,

Abebe


On Mon, Feb 13, 2012 at 6:06 PM, Wes Sisk <wsisk at cisco.com<mailto:wsisk at cisco.com>> wrote:
Hi Abebe,

Those are pretty bad.  These are of particular concern:
Rcvr Codec  G729
Sender Codec G729
Rcvr size    20ms
sender size  20ms
Rcvr Packets 476
sender packets 709
Avg Jitter     31
Max Jitter    185
Rcvr discarded 1
Cumulative Conceal ratio 0.0319
Max Conceal ratio 0.0446
Conceal sec  5
Severly conceal sec 1

I interpret this as:
G.729 has a lower MOS so we're starting with less audio quality.  The phone sent 709 packets but received 476 packets.  At 20msec packetization the phone has sent 14.1 seconds of audio but received only 9.5 seconds of audio.  The phone cannot begin counting until the first RTP packet arrives so this may account for an additional gap between these metrics and actual user experience.  The tx/rx is normally very similar. Either there was a delay in signaling negotiating bidirectional audio or this phone first started receiving RTP packets ~5 seconds into the call.  After that Jitter of 31 is not great but would generally still be intelligible audio.  Max jitter of 185 is pretty much impossible to recover.  Each packet should contain 20msec of audio.  At least one packet arrived 185msec late.

Recvr discarded 1 means the phone discarded one rtp packet it received.  Discard can happen for several reasons but with max jitter 185 it is very likely the packet was just too late to be used.  When a 20msec slice of audio is unavailable the phone attempts to conceal that in the audio stream.  This leads to next stats:
Conceal sec  5
Severly conceal sec 1

For 5 seconds the phone used the g.729 packet loss concealment algorithm to try and mask the absence of packets.  This is going to be silence, noise, or otherwise unintelligible audio to the user.

It looks like something is indeed inhibiting RTP packet flow toward this phone.  A packet capture will show more details but it's not particularly necessary from the phone/application perspective.  The underlying packet network needs some improvements to delivery adequate voice quality.

/wes

On Feb 13, 2012, at 9:31 AM, Abebe Amare wrote:

Hi Wes,

Here is the call statistics from the phone for one call

Rcvr Codec  G729
Sender Codec G729
Rcvr size    20ms
sender size  20ms
Rcvr Packets 476
sender packets 709
Avg Jitter     31
Max Jitter    185
Rcvr discarded 1
Rcvr lost packets 0
Avg MOS LQK   0.0
Min MOS LQK   0.0
Max MOS LQK   0.0
Cumulative Conceal ratio 0.0319
Max Conceal ratio 0.0446
Conceal sec  5
Severly conceal sec 1

Is the jitter too high?

regards,

Abebe

On Fri, Feb 10, 2012 at 8:32 PM, Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:
I was surprised to find that SLA is not included in the IPBase module of v15, nor in the UC module. You need the Data module.

Sent from my iPhone...

"There's no place like 127.0.0.1"

On Feb 10, 2012, at 12:20 PM, Dennis Heim <Dennis.Heim at cdw.com<mailto:Dennis.Heim at cdw.com>> wrote:

Maybe a good place for some IP SLA monitoring.

Dennis Heim
Senior Engineer (Unified Communications)
CDW  Advanced Technology Services
10610 9th Place
Bellevue, WA 98004

425.310.5299<tel:425.310.5299> Single Number Reach (WA)
317.569.4255<tel:317.569.4255> Single Number Reach (IN)
317.569.4201<tel:317.569.4201> Fax
dennis.heim at cdw.com<mailto:dennis.heim at cdw.com>
cdw.com/content/solutions/unified-communications/<http://www.cdw.com/content/solutions/unified-communications/>

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Wes Sisk
Sent: Friday, February 10, 2012 10:36 AM
To: Abebe Amare
Cc: cisco voip
Subject: Re: [cisco-voip] intercluster trunk over IPSec VPN

most likely still packet throughput issues. packets may be late to the point of discarded. they would not technically be lost in that case.

this would manifest as high jitter.  setup the initial all and press the "i" or "?" button twice on the phone to see call statistics.  beyond that take a packet capture.  wireshark has some decent RTP analysis tools built in.

/wes

On Feb 10, 2012, at 6:41 AM, Abebe Amare wrote:

Dears, thank you all for the excellent support

I managed to keep the VPN tunnel up be sending periodic ping but the problem still persist. Bandwidth is reserved for at least four calls (taking into consideration VPN overhead) on a Packetshaper and the call quality is good mid-conversation. But it is is clipping the first few seconds. I dont see any packet loss n the CMR records for a test call. What should I be looking for?

thanks in advance

Abebe


On Thu, Feb 9, 2012 at 5:57 PM, Wes Sisk <wsisk at cisco.com<mailto:wsisk at cisco.com>> wrote:
TCP keepalives are only used while a call is active.

When no call is active there is no active h323/h225/h245 signaling, tcp session, or udp.  The only exception is when gatekeeper is used. Then gk registration messages are maintained.  Those are over UDP between the h323 ep and gk.

for a static ICT defined between two CUCM clusters there is no network activity without an active call.

For the duration of an active call the tcp keepalive parameter will help.

regards,
wes

On Feb 9, 2012, at 8:13 AM, Adam Frankel (afrankel) wrote:

Options Ping was added in 8.5(1).

The parameter "Allow TCP KeepAlives For H323 " should take care of this for H323 ICT.

-Adam

________________________________
From: Abebe Amare <abucho at gmail.com><mailto:abucho at gmail.com>
Sent: Thu, Feb 09, 2012 4:52:50 AM
To: Ryan Ratliff <rratliff at cisco.com><mailto:rratliff at cisco.com>
CC: cisco voip <cisco-voip at puck.nether.net><mailto:cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] intercluster trunk over IPSec VPN


Hi Ryan,

The CUCM version is 6.1.3.1000-16. Is the SIP options ping parameter available in this version? Where would you enable it if it is available?

thanks in Advance,

Abebe
On Wed, Feb 8, 2012 at 8:07 PM, Ryan Ratliff <rratliff at cisco.com<mailto:rratliff at cisco.com>> wrote:
What about a SIP trunk with options ping enabled?

-Ryan

On Feb 8, 2012, at 7:05 AM, Abebe Amare wrote:

Hi Dennis,

Configuring a persistent L2L tunnel proved to be very elusive. I settled for running a periodic ping scheduled to keep the tunnel running.

Thanks for your help

Abebe
On Tue, Feb 7, 2012 at 6:16 PM, Dennis Heim <Dennis.Heim at cdw.com<mailto:Dennis.Heim at cdw.com>> wrote:
I think you answered your own question. IPSEC tunnel’s take time to bring up. Maybe you could tweak some of the VPN negotiating parameters, or create a separate L2 tunnel profile/group just for your voice that is permanent and does not have an inactivity timer.


Dennis Heim
Senior Engineer (Unified Communications)
CDW  Advanced Technology Services
10610 9th Place
Bellevue, WA 98004

425.310.5299<tel:425.310.5299> Single Number Reach (WA)
317.569.4255<tel:317.569.4255> Single Number Reach (IN)
317.569.4201<tel:317.569.4201> Fax
dennis.heim at cdw.com<mailto:dennis.heim at cdw.com>
cdw.com/content/solutions/unified-communications/<http://www.cdw.com/content/solutions/unified-communications/>

From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Abebe Amare
Sent: Tuesday, February 07, 2012 4:10 AM
To: cisco voip
Subject: [cisco-voip] intercluster trunk over IPSec VPN

Dears,

I have configured an Inter-Cluster trunk from CUCM to another site with CUCME. There is an IPSec L2L VPN terminating at ASA 5500 firewall on both ends

CUCM --->ASA 5540--->Internet <---ASA 5510<---CUCME

On the ASA,the IPSec tunnel is terminated after 30 minute of inactivity (default) which is causing a problem. When a phone in one site tries to call another phone in the other site there is a noticeable gap before actual conversation is heard over the phone. Once conversation starts, there is no delay or break in audio. Has anyone faced this issue?

best regards,

Abebe

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip





_______________________________________________

cisco-voip mailing list

cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip



_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip




_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120214/759a14bc/attachment.html>


More information about the cisco-voip mailing list