[cisco-voip] intercluster trunk over IPSec VPN

Tue Feb 14 10:43:17 EST 2012

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> 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/<http://www.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> <abucho at gmail.com>
>>> *Sent:* Thu, Feb 09, 2012 4:52:50 AM
>>> *To:* Ryan Ratliff <rratliff at cisco.com> <rratliff at cisco.com>
>>> *CC:* cisco voip <cisco-voip at puck.nether.net><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/<http://www.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
>>>
>>>
>>
>>
>
> _______________________________________________
> 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/20120214/44415180/attachment.html>