10-27-2014 12:56 AM - edited 03-18-2019 03:34 AM
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
Solved! Go to Solution.
10-31-2014 12:47 AM
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.
10-31-2014 01:48 AM
As you can see from my earlier post that's exactly what I'm using.
/jens
10-31-2014 01:51 AM
is right !!
10-31-2014 08:26 AM
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.
10-31-2014 08:26 AM
Tidy, like. Well done all.
10-31-2014 03:09 PM
"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
10-31-2014 04:08 PM
you can easy simulate them, just put an endpoint on a public ip, call the h323 "cisco" and dial 00442234234234234@yourvcsip ;-)
happy Halloween
Please remember to rate helpful responses and identify
11-02-2014 02:37 PM
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
10-28-2014 02:53 AM
I can add as CPL? please do not do this constantly and intruding
01-10-2017 08:20 AM
what is CPL?
01-10-2017 08:59 AM
Call Processing Language, you can use a CPL script with the VCS/Expressway products to manipulate how calls are being made or received.
11-18-2014 08:02 AM
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:
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide