cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2380
Views
0
Helpful
5
Replies

VCSC and VCSE Search Rule issue - Movi/SIP dialing

Darren Lapierre
Level 4
Level 4

Hello,

So, I have been stumped about this issue for quite some time now and I wanted to see if anyone here has happened upon the same issue.

To sum it up: Whenever I dial an IP address (for example the VTCtalk test sites 71.14.2.157 or 71.14.2.158) call using MOVI, the call hangs for exactly 30 seconds, then the call proceeds without issue.

I just am unsure what is going on.

As for the rules I put into each the VCSC and VCSE, I put near identical to the rules in the Cisco_VCS_Basic_Configuration_Cisco_VCS_Control_with_Cisco_VCS_Expressway_Deployment_Guide_X7-0.

Everything works fine. The call will always connect, but after the 30 seconds.

When I look at the search history, I see the call fail (time out) when it tries to dial as a SIP call, but will proceed during an H.323 attempt.

Here is the search. MOVI is registered to VCSE, dialing to an external IP address (71.14.2.157)

Search Result:

Search (20)

State: Completed

Found: True

Type: SIP (INVITE)

CallRouted: True

CallSerial Number:

StartTime: 2011-12-22 20:49:04

Duration: 32.67

Source (1)

Authenticated: False

Aliases (1)

Alias (1)

Type: Url

Origin: Unknown

Value: ******@domain.com

Zone (1)

Name: LocalZone

Type: Local

Path (1)

Hop (1)

Address: 192.168.0.199:55436

Destination (1)

Alias (1)

Type: Url

Origin: Unknown

Value: sip:71.14.2.157

SubSearch (1)

Type: Transforms

Action: Not Transformed

ResultAlias (1)

Type: Url

Origin: Unknown

Value: 71.14.2.157

SubSearch (1)

Type: Admin Policy

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: 71.14.2.157

SubSearch (1)

Type: FindMe

Action: Proxy

ResultAlias (1)

Type: Url

Origin: Unknown

Value: 71.14.2.157

SubSearch (1)

Type: Search Rules

CallsToUnknownIPAddresses (2)

Mode: Direct

Found: True

Zone (1)

Name: DefaultZone

Type: Default

Protocol: SIP

Found: False

Reason: Request Timeout

Gatekeeper (1)

Alias (1)

Type: Url

Origin: Unknown

Value: 71.14.2.157

Zone (2)

Name: DefaultZone

Type: Default

Protocol: H323

Found: True

Gatekeeper (1)

Address: 71.14.2.157:1720

Alias (1)

Type: Url

Origin: Unknown

Value: 71.14.2.157

Any help would be greatly appreciated. I am quite stumped with this.

D.

5 Replies 5

Jens Didriksen
Level 9
Level 9

This is normal behaviour and due to SIP first using UDP, then having to wait for INVITE to time out, then it'll try SIP TCP and finally H.323. You can turn of SIP UDP and it'll speed up the connection time somewhat.

Please rate replies and mark question(s) as "answered" if applicable.

I have the same problem, running X7.0.1. Even with UDP off, almost all call fail, because after 30seconds the call is disconnected before the VCS attemp to interwork to H.323.

I tried X5.2 and this kind of call works fine.

I have oppened a ticket on TAC to troubleshoot this.

PD: in my case, sometimes the Movi call arrives from DefaultZone (this should never happen).

Regards.

Sounds like you have a routing issue, I'm using X7.02, Movi 4.2 and have absolutely no problems at all in that regard.

However, I did have to reorganise the search rules and their priorities when upgrading from 5.x to 6.x as the way these were treated appeared to be a bit different, probably more correct actually, than what they were with 5.x.

So what worked under 5.x stopped working for me in 6.x, but once I got the priorities sorted it worked and it's been working very nicely ever since.

This is not the same issue as the original posters as he states it takes 30 seconds before the call connects,

quote

the call hangs for exactly 30 seconds, then the call proceeds without issue.

unquote

and that is normal behavour due to the SIP UDP INVITE timer, also according to his search results the address is found using H.323 (which is when interworking kicked in):

Name: DefaultZone

Type: Default

Protocol: H323

Found: True

Gatekeeper (1)

Address: 71.14.2.157:1720

Alias (1)

Type: Url

Origin: Unknown

Value: 71.14.2.157

So, it first tries SIP UDP, then SIP TCP, then H.323, which, in this case, it finds to be valid.

.

Please rate replies and mark question(s) as "answered" if applicable.

Ok. It is similar, but is different because in my case, that call not always connects. After 30 seconds, it tries H.323. Sometimes it works, but at least 90% of calls fails.

The Movi 4.2 is registered on a VCS E (cluster with 2 peers). This VCSE don´t have Presence server enable, so, it don´t have SIP Routes. The Search Rules are fine (call to IP address in a VCSE in Direct mode don´t need search rule. It should dial directly trough DefaultZone).

Duration: 32.04

Zone (1)

Name: DefaultZone

Type: Default

Protocol: SIP

Found: False

Reason: Request Timeout

Gatekeeper (1)

Alias (1)

Type: Url

Origin: Unknown

Value: 212.46.140.76

Zone (2)

Name: DefaultZone

Type: Default

Protocol: H323

Found: False

Reason: Temporarily Not Available

Gatekeeper (1)

Address: 212.46.140.76:1720

Alias (1)

Type: Url

Origin: Unknown

Value: 212.46.140.76

We disbaled UDP and the behaviour is the same (only the time to fail that changes from 30sec to 1sec). With UDP Off, the first Invite use TCP (Dst-alias-type="SIP" Protocol="TCP" Auth="YES"). It tries H.323 but also fails.

PS: All other devices in VCS C can call IP addresses. The problem only happen when using Movi4.2.

OK, your set-up differs somewhat from mine as I use two stand-alone VCS-C behind FW and a VCS-E in the public.

Movi 4.2 registering to VCS-C when user is on campus and to VCS-E when users are off campus, authentication is done, regardless of registering with VCS-C or VCS-E, on the VCS-C with direct intergration to AD.

Took a little while to get it to work due to authentication settings needing to be different for different zones though.

No doubt TAC should be able to see what's going on from your logs etc.

Please rate replies and mark question(s) as "answered" if applicable.