Traversal call license usage on a Cisco VCS

[SupportAC]

Hi guys,

I have a customer with VCS and VCS-e x7.2.They receive many call frauda attemps that are prevented with block search rules . 

But the customer is discover that when call fraud hit VSC-e even with block search rules the box consume traversal license for less a second. 

My question is , VCS-e has a mechanism for prevent that?  I read about CPL/ find me service but im not 100% sure.

Many thanks

Carlos 

[Chris Swinney]

Hi Carlos,

I assume you are talking about SIP Spam attempts? If so, CPL (Call Policy) may well help is this is check first by the VCS. There are a number of threads on here regarding this an I believe there may even be a document posted that might help.

Cheers

Chris

[SupportAC]

Hi Chris,

Thanks for your reply.  Yes the fraud call are SIP spam attemps .

So if a  implement CPL i prevent VCS-E to send query to VCS-C? that ritght?

Carlos 

[Chris Swinney]

Indeed, as Marting says, If just a search is conducted then no call licence should be used until a endpoint is found and a call is placed. If the search blocks the lookup, then no call licence should be used.

However, using a simply CPL doesn hurt. SOmething like:

Source pattern:  (leave blank)

Destination pattern: .*@IP_Address_of_VCSE

Action: Reject

Then

Source pattern:  .*

Destination pattern: .*

Action: Allow

You could alway ensure that SIP UDP is OFFas well (unless you want it on for a specific reason).

Cheers

Chris

[SupportAC]

Hi Chris,

Thanks for your reply. Please see the attachment that i provied you.

First screeshoot you is a check pattern test , the tould fraud calls destination is matched 

00972597751891@93.190.152.15 

but on the call history " Second screenshoot " you see the 480 temporarly not available and  call duration of 1 second

The issue with creating a pattern more generic is that i can block non fraud call .

Regards

Carlos 

[Martin Koch]

Hi!

There is no screenshot attached.

It would be interesting to see the full search details (of all call legs) and of both VCSs (if it hits your second VCS-C).

[SupportAC]

Hi Martin ,

He the logs from VCS-e and C   plus a locate :

VCS-e :

Call details

You are here: Status Calls Calls Call details

Call information
State	Connection Failed
Start time	2014-04-02 17:03:05
End time	2014-04-02 17:03:06
Duration	1 second
Tag	e4f792b0-ba77-11e3-9513-0010f320813c
Serial number	e4f790f8-ba77-11e3-a6b3-0010f320813c

Bandwidth
Requested	1152 kbps
Allocated	1152 kbps
Route	DefaultZone -> TraversalSZtoDefaultZ -> TraversalSubZone -> Zone001ToTraversalSZ -> TZtoVCSControl

Leg 1
Bandwidth node	Default Zone
Source alias 1	sip:50011@x.190.x.x  (Url)
Target alias 1	sip:+00972592652763@x.190.x.x (Url)
Protocol	SIP
Address	95.211.89.233:5078
Transport	UDP
Reason	Not found
Cause	404

Leg 2
Bandwidth node	TZtoVCSControl
Target alias 1	sip:+00972592652763@93.190.152.15 (Url)
Protocol	SIP
Address	10.42.19.11:25067
Transport	TLS
Encryption type	None

Leg 3
Bandwidth node	TZtoVCSControl
Target alias 1	do-not-route-this-call (H323Id)
Protocol	H323
Address	10.42.19.11:1719
Reason	Not registered
Cause	Destination not found

Session 1
Status	Failed
Media routed	True
Call routed	True
Participant 1	Leg 1
Participant 2	Leg 2
Bandwidth allocated	1152 kbps
Bandwidth requested	1152 kbps
Route	DefaultZone -> TraversalSZtoDefaultZ -> TraversalSubZone -> Zone001ToTraversalSZ -> TZtoVCSControl

Session 2
Status	Failed
Media routed	True
Call routed	True
Participant 1	Leg 1
Participant 2	Leg 3
Bandwidth allocated	1152 kbps
Bandwidth requested	1152 kbps
Route	DefaultZone -> TraversalSZtoDefaultZ -> TraversalSubZone -> Zone001ToTraversalSZ -> TZtoVCSControl

VCS-C :

Call details

You are here: Status Calls Calls Call details

Call information
State	Connection Failed
Start time	2014-04-02 17:03:05
End time	2014-04-02 17:03:05
Duration	0 seconds
Tag	e4f792b0-ba77-11e3-9513-0010f320813c
Serial number	e4fb3ad2-ba77-11e3-98f0-0010f31ed7ac

Bandwidth
Requested	1152 kbps
Allocated	1152 kbps
Route	TZtoVCSEW -> VCSeToTraversalSZ -> TraversalSubZone -> NZoneMexicoToTraversalSZ -> NZoneMexico

Leg 1
Bandwidth node	TZtoVCSEW
Source alias 1	sip:50011@x.190.x.x (Url)
Target alias 1	sip:do-not-route-this-call (Url)
Protocol	SIP
Address	93.190.152.15:7001
Transport	TLS
Encryption type	None
Reason	Not found
Cause	404

Leg 2
Bandwidth node	NZoneMexico
Target alias 1	do-not-route-this-call (H323Id)
Protocol	H323
Address	10.26.5.202:1719
Reason	Not registered

Session 1
Status	Failed
Media routed	True
Call routed	True
Participant 1	Leg 1
Participant 2	Leg 2
Bandwidth allocated	1152 kbps
Bandwidth requested	1152 kbps
Route	TZtoVCSEW -> VCSeToTraversalSZ -> TraversalSubZone -> NZoneMexicoToTraversalSZ -> NZoneMexico

LOCATE :

Search completed.

Search (8)   State: Completed   Found: False   Reason: Not Found   Info: Policy Response   Type: SIP (OPTIONS)   CallSerial Number: 3bf11952-ba7c-11e3-97b4-0010f320813c   Tag: 3bf11af6-ba7c-11e3-9060-0010f320813c   Source (1)   Authenticated: True   Aliases (1)   Alias (1)   Type: Url   Origin: Unknown   Value: 50011@x.190.x.x    Zone (1)   Name: TZtoVCSControl   Type: TraversalServer   Path (1)   Hop (1)   Address: 127.0.0.1   Destination (1)   Alias (1)   Type: Url   Origin: Unknown   Value: sip:+00972592652763@x.190.x.x    StartTime: 2014-04-02 17:34:09   Duration: 0.39   SubSearch (1)   Type: Transforms   Action: Transformed   ResultAlias (1)   Type: H323Id   Origin: Unknown   Value: +00972592652763@cemex.com   SubSearch (1)   Type: Admin Policy   Action: Proxy   ResultAlias (1)   Type: H323Id   Origin: Unknown   Value: +00972592652763@cemex.com   SubSearch (1)   Type: FindMe   Action: Proxy   ResultAlias (1)   Type: H323Id   Origin: Unknown   Value: +00972592652763@cemex.com   SubSearch (1)   Type: Search Rules   SearchRule (1)   Name: Block Incoming calls with +   Zone (1)   Name: TZtoVCSControl   Type: TraversalServer   Protocol: SIP   Found: False   Reason: Not Found   StartTime: 2014-04-02 17:34:09   Duration: 0.19   Gatekeeper (1)   Address: 10.42.19.11:25067   Alias (1)   Type: H323Id   Origin: Unknown   Value: do-not-route-this-call   Zone (2)   Name: TZtoVCSControl   Type: TraversalServer   Protocol: H323   Found: False   Reason: Not registered - Destination not found   StartTime: 2014-04-02 17:34:09   Duration: 0.18   Gatekeeper (1)   Address: 10.42.19.11:1719   Alias (1)   Type: H323Id   Origin: Unknown   Value: do-not-route-this-call

PD : Now you can see the sreenshoots?

Thanks

Carlos 

[Chris Swinney]

Hi Carlos,

To my mind, this is a funny way of doing things.

I would set up a local Call Policy at the VCS-E using the rule mentioned above.

Or switch OFF SIP UDP at the VCS-E unless you have a reason to use it. In new installs (not upgrades) of the VCS (x8.1), SIP UDP is switch off by default, but I still like to have some CPL rules in place.

Chris

[Martin Koch]

Hmmm, how and where do you see that call license being used?

I just tried it. Rebooted my lab VCS to reset the call counter,

dialed into the VCS with and invalid URI and the counter is still 0 and the call history

shows me a 404.

Sure that you do not have a call loop or some alias being hit somewhere?

Do you have your search and call history and logs?
 

[SupportAC]

Hi Martin,

Thanks for yor reply and your effort . 

The first question : 

how and where do you see that call license being used? That information was provided by customer, I suppose that he check that status of VCS.E.

Im sure that call is not hit somewhere , regarding loop i suppose that i need to have the same search rule pointing from VCS-C to VCS-E? right?

Regards