Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Connection time

Since our upgrade from 5x to 7x we're experecing a delay of 40-50 seconds for calls to connect. We have a VCS, VCSE, MCU AND ISDN GW.  We're running C20s and MOVI.

For example

I’ve attached two images the first image shows a call placed from my MOVI application to IP address 217.45.116.244. At 8:31.41 the search has completed and the call is placed into the nontraversal queue? Then at 8:32.30 (some 50 seconds later) the call is then routed into the traversal queue and passed to the VCSE. In image VCSE the call is picked up at 8:32.30 and completes 6 seconds later.

Somethings happening on my VCS that's taking 50 seconds to pass to the VCSe

Prior to 7x all direct IP calls went through straight away.

Anyone any ideas?

Thanks.

                  

Rod

Everyone's tags (1)
8 REPLIES
Gold

Connection time

Rod,

on your VCS-C, what is the 'Calls to unknown IP addresses' setting set to in VCS Configuration > Dial plan > Configuration?

On a VCS-C, this should normally be set to 'Off', it sounds to me as on your VCS-C, it is set to 'On'.

The delay may be caused by the VCS-C sending a UDP-based SIP INVITE towards this IP address, which will linger for 30 seconds before timing out, followed by the SIP call being passed to the VCS-E.

The workaround for this is to disable SIP UDP on the VCS, at the VCS Configuration > Protocols > SIP > Configuration page (Although from what I recall, SIP UDP defaults to Off in X7).

- Andreas

New Member

Connection time

Hi Andreas

Thanks for the quick reply.

The VCS-C 'Calls to unknown is set to indirect'

I will set it to off and report back

Rod

Gold

Connection time

Setting it to 'Indirect' on the VCS-C should do the trick, assuming that the IP address in question is in fact unknown to the VCS (Meaning it does not belong to a locally registered endpoint) and that you have an AnyIPAddress search rule targeting the traversal zone towards your VCS-E.

A diagnostics log (Network log level = DEBUG) of a test call such as this would probably be helpful, although you shouldn't post such a log on this public forum

- Andreas

New Member

Connection time

Hi Andreas

I set the Calls to unknows and the call won't complete.

I then disabled SIP as you noted and I couldn't log back into MOVI.

Our infrastructure uses both SIP and H323 endpoints (SIP for Cisco and H323 for some older Sony systems)

Rod

Gold

Connection time

Rod,

you shouldn't disable SIP altogheter, only SIP UDP.

Also, calls to unknown IP addresses should be set to 'Indirect' on your VCS-C, since setting it to 'Off' will not allow the call to pass to the VCS-E.

- Andreas

New Member

Connection time

Hi Andreas,

Sorry for the misunderstanding. I've disabled the SIP UDP on both the VCS-C and VCS-E. The strange thing is that URI lookups dial out straight away however IP lookups take the 50 seconds..

I've also noticed that if I call an IP address and wait the 50 seconds for the call to go through - if I cancel the call on either my MOVI client or the remote system and the try and dial the remote system straight away the call goes straight through without delay.

If I leave the client for a few moments it goes back to the 50 seconds again...

Rod

Gold

Connection time

Rod,

check your PM inbox.

- Andreas

Re: Connection time

Hello!

Do I assume correct that your movi client is registered to the vcs-c?

Can you check

* sip is enabled (tcp and tls) but udp is disabled

* that your sip traversal zone is active in between the vcs-c and -e?

* that the traversal client & zone is porperly configured (and uses tls for the sip part)

If it would be I would expect the movi call hit the vcs-e with sip, but it does with h323.

Also your vcs-e log shows some traversal client timeout. If this is your VCS-C this would not be good.

Check that your firewall does not block or change (alg/nat helper) the packets.

Please remember to rate helpful responses and identify

341
Views
0
Helpful
8
Replies