[cisco-voip] intercluster trunk over IPSec VPN

[Abebe Amare]

Hi Nick, Peter

Enabling H323 fast start on both ends did the trick. I highly appreciate
all of the incredible support I received from the group.

best regards,

Abebe

On Thu, Feb 16, 2012 at 1:28 AM, Nick Matthews <matthnick at gmail.com> wrote:

> A few notes:
> -ICT to CME isn't the recommended option.  ICT is very similar to
> H.323 so it will work but you may run into weird issues like transfers
> failing with ICT vs H323 Gateway.
>
> -When the ASA creates the IPsec tunnel it will automatically copy the
> DSCP marking from the inside packet to the outside packet.  So if
> you're correctly doing QoS based on DSCP you should still be in good
> shape.  If you need it based on L4-L7 it would need to happen before
> the ASA.  On a router you use 'qos pre-classify' if it's doing both
> the tunneling and QoS.
>
> -IPSec through any wan acceleration is probably not very effective.
> It may be best to exempt the entire stream, as well as any RTP/UDP
> traffic.
>
> -Pete has a very good point.  They call it fast start for a reason.
> When you switch it to a H323 gateway enable both inbound and outbound
> fast start.  You'll need to check 'MTP Required' and make sure you've
> got a software MTP on a router to do g729 mtp sessions.  This could
> cut down a few seconds of delay.
>
> -nick
>
> On Wed, Feb 15, 2012 at 8:28 AM, Wes Sisk <wsisk at cisco.com> wrote:
> > Abebe,
> >
> > I also believe Jason has a good point.  I have only seen bad results when
> > combining with WCCP mechanisms.
> >
> > /wes
> >
> > On Feb 15, 2012, at 3:52 AM, Abebe Amare wrote:
> >
> > Hi Peter,
> >
> > It is possible to create an ICT pointing to a CME. On the CME side, you
> just
> > configure voip dial-peer pointing to the CM. Saying that, here is a how
> the
> > problem manifests:
> > 1.The problem occurs during call set up and on one leg (the caller does
> not
> > hear the receiver). This happens regardless of the call setup originating
> > from the CM or CME side.
> > 2.The caller usually does not hear the other side for few seconds (3-4);
> > this happens right after the ring-back tone is stopped.
> > 3.The receiver when picking up the phone and starts by saying hello the
> > other party does not hear any voice until 3-4 seconds elapse.
> >
> > Wes, I will collect packet captures and call statistics from the phone
> > concurrently and compare the result.
> >
> > best regards,
> >
> > Abebe
> >
> > On Wed, Feb 15, 2012 at 12:20 AM, Jason Aarons (AM)
> > <jason.aarons at dimensiondata.com> wrote:
> >>
> >> My coworker spent a month in November working a issue only to find a
> >> Riverbed was messing with control traffic. Not your issue, but I find
> you
> >> spend more in labor hours than you get back in bandwidth costs.  I’d
> exclude
> >> voip.  How much wan optimization can you get out of G.7xx ?
> >>
> >>
> >>
> >> From: cisco-voip-bounces at puck.nether.net
> >> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Abebe Amare
> >> Sent: Tuesday, February 14, 2012 12:45 PM
> >> To: Wes Sisk; Stephen Welsh; Mike King
> >>
> >>
> >> Cc: cisco voip
> >> Subject: Re: [cisco-voip] intercluster trunk over IPSec VPN
> >>
> >>
> >>
> >>
> >>
> >> Hi Wes,
> >>
> >> Here is how the devices involved are connected
> >>
> >> CUCM->6509->ASA->Packetshaper->2821->VSAT Link->Internet<-ASA<-CUCME
> >>
> >> I do not have control over the CUCME on the remote side for the moment.
> >> The VPN tunnels terminate at the ASA on each side. I am not comfortable
> with
> >> configuring QoS on the ASA, that is why I configured on the 2821. And
> since
> >> the 2821 can not see the pre-tunnel traffic, I decided to put the
> traffic
> >> passing over the tunnel in LLQ.
> >> The VSAT link is used for basic Internet browsing. The speed of the VSAT
> >> connection is 768 kbps and we do take slow TCP connection as
> acceptable. We
> >> use IronPort web security appliance together with Packetshaper to
> tightly
> >> control what goes on the link.
> >>
> >> I have collected some RTP streams using wireshark and it does not show
> >> excessive jitter, delay or packet loss in the RTP analysis which seems
> to
> >> contradict what I shared about the RTP statistics directly from the
> phone.
> >> How do I find out if the call setup signalling is delayed?
> >>
> >> regards,
> >>
> >> Abebe
> >>
> >> On Tue, Feb 14, 2012 at 7:15 PM, Wes Sisk <wsisk at cisco.com> wrote:
> >>
> >> My QoS is a bit rusty as it's time to re-certify.  That said "put the
> VPN
> >> traffic in LLQ" doesn't sound quite right.  It is *voice* that needs to
> be
> >> in LLQ.
> >>
> >>
> >>
> >>
> >>
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/netstruc.html#wp1044413
> >>
> >>
> >>
> >> Otherwise, it might be beneficial to conduct some tests to better
> >> understand the network.  What traffic flows over the VSAT link?   Is the
> >> call setup signaling delayed?  Is there excessive delay at the
> beginning of
> >> any TCP/UDP stream or is that unique to the UDP/RTP voice traffic?
> >>
> >>
> >>
> >> Regards,
> >>
> >> Wes
> >>
> >>
> >>
> >>
> >>
> >> On Feb 14, 2012, at 1:23 AM, Abebe Amare 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: icmp_seq=0 ttl=254 time=577 ms
> >> 64 bytes from 192.168.100.1: icmp_seq=1 ttl=254 time=579 ms
> >> 64 bytes from 192.168.100.1: icmp_seq=2 ttl=254 time=587 ms
> >> 64 bytes from 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> 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>
> 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> 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 Single Number Reach (WA)
> >>
> >> 317.569.4255 Single Number Reach (IN)
> >> 317.569.4201 Fax
> >> dennis.heim at cdw.com
> >> cdw.com/content/solutions/unified-communications/
> >>
> >>
> >>
> >> From: 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> 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>
> >> Sent: Thu, Feb 09, 2012 4:52:50 AM
> >> To: Ryan Ratliff <rratliff at cisco.com>
> >> CC: cisco voip <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>
> 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>
> 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 Single Number Reach (WA)
> >>
> >> 317.569.4255 Single Number Reach (IN)
> >> 317.569.4201 Fax
> >> dennis.heim at cdw.com
> >> cdw.com/content/solutions/unified-communications/
> >>
> >>
> >>
> >> From: 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
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >>
> >> cisco-voip mailing list
> >>
> >> cisco-voip at puck.nether.net
> >>
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >>
> >>
> >> _______________________________________________
> >> cisco-voip mailing list
> >> cisco-voip at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> cisco-voip mailing list
> >> cisco-voip at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> itevomcid
> >
> >
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > 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/20120216/3caa5794/attachment.html>