[cisco-voip] intercluster trunk over IPSec VPN

[Abebe Amare]

Hi,
I apologize for digging up an old issue. The problem I am facing now is
having No Ringback Tone for Calls from Cisco CallManager to Cisco
CallManager Express. I followed the guide on

http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a0080094c33.shtml#ringcme
but it did not solve the problem.
I have attached a trace file from the CUCM while making the call.





On Thu, Feb 16, 2012 at 2:28 PM, Abebe Amare <abucho at gmail.com> wrote:

> 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/20121119/b783b784/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cucm-trace.txt
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121119/b783b784/attachment.txt>