source=[h323Id='cisco' ] IncomingCalls

[Ozgur Shahin]

Hi!

Help me please

i have not sip server 

the device has global_IP

i configured "sip listenport off"  

but

"Cisco" cals me 

Oct 24 14:23:52.816 ppc appl[2786]: 163.82 H323Call I: h323_call_handler::handleH323CallInd(s=1) Incoming call indication (rate=64000 lang='' tlph=1 source=[h323Id='cisco' ipv4 ='202.57.32.35' ] dest=[ipv4 ='MY_IP' e164=' ' ])

Oct 24 14:23:52.828 ppc appl[2786]: 163.83 IxCtrl I: iXController(0x49e00514) registerProtocolUser: proto=1, user=0x49e0060c

Oct 24 14:23:52.836 ppc appl[2786]: 163.84 MainEvents I: LayoutUpdated(p=1) outputNo=2 og=8

Oct 24 14:23:52.854 ppc appl[2786]: 163.86 MainEvents I: LayoutUpdated(p=1) outputNo=2 og=8

Oct 24 14:23:52.856 ppc appl[2786]: 163.86 MainEvents I: LayoutUpdated ...frame[SelfviewPip] selfviewPip p=1 src=1 ig=3 x=7487 y=7499 w=2409 h=2409 l=1 b=1 snapBorder stretch

Oct 24 14:23:52.866 ppc appl[2786]: 163.87 MainEvents I: IncomingCallInvite(p=2) remoteURI='h323:cisco' displayName='cisco' localURI='h323:MY_IP'

Oct 24 14:23:52.882 ppc appl[2786]: 163.88 MediaStreamController I: SC::PlayReq(og=12) path='/sounds/nordic.mp4', toneType=file

[tec cou]

add to CPL "unauthenticated-origin="cisco" destination=".*"><reject status="403"/> " works well.

I think there should be better protection, but will be watching ...

thanks a lot.

[Jens Didriksen]

As you can see from my earlier post that's exactly what I'm using.

/jens

[tec cou]

is right !!

[Patrick Sparkman]

Attached is the CPL script I'm using.  We're checking credentials on the Expressway DefaultZone.

As you can see it's working for us below:

H323 (Setup) cisco 0441227806181 Denied by policy View
H323 (Setup) cisco 00441315070102 Denied by policy View
H323 (Setup) cisco 000441227806181 Denied by policy View
H323 (Setup) cisco 00000441315070102 Denied by policy

I typically usually add both authenticated and unauthenticated in cases like this, just to make sure I catch anything that might somehow find it's way through the other.

[Chris Swinney]

Tidy, like. Well done all.

[Jens Didriksen]

"We're checking credentials on the Expressway DefaultZone."

Looks like that might be the key as I currently don't do that as I found in the past that it broke my JabberVideo service for our external users.

Haven't looked at it again since then (x6 or so), so guess it's time to take another look at it.

Having said that, the CPL worked fine blocking the unwanted SIP calls without checking the credentials on the VCS-E DZ, but this is a different thing altogether.

Just checked the VCS-E and haven't had any of these calls since I last edited the CPL - so, gonna have to wait and see for now.

/jens

[Martin Koch]

you can easy simulate them, just put an endpoint on a public ip, call the h323 "cisco" and dial 00442234234234234@yourvcsip ;-)

happy Halloween

[Jens Didriksen]

Tried that remotely from home with an MXP, but it won't accept E.164 Alias or H.323 ID unless the call mode is "Gatekeeper/Callmanager", but for this purpose it has to be "Direct". Also, the calls appear to use a range of ip addresses as the origin in the same attack, not cisco@VCS_IP (which I can easily block).

/jens

[tec cou]

I can add as CPL? please do not do this constantly and intruding

[renee.arena1]

what is CPL?

[Patrick Sparkman]

Call Processing Language, you can use a CPL script with the VCS/Expressway products to manipulate how calls are being made or received.

[mark hackett]

Now, it could be I'm missing something obvious, but it's interesting that these attempts are not reaching or piling up in the auto-attendant either of our MCU's (4210&5320)

I believe I'm seeing them fail here in the error log: