[cisco-voip] intercluster trunk over IPSec VPN
Abebe Amare
abucho at gmail.com
Wed Nov 21 07:21:42 EST 2012
Hello,
I changed the trunk to SIP on both CUCM and CUCME and the problem is solved.
thanks for your support
Abebe
On Mon, Nov 19, 2012 at 4:47 PM, Abebe Amare <abucho at gmail.com> wrote:
> 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/20121121/a241299d/attachment.html>
More information about the cisco-voip
mailing list