A lot of calls with numbers "100" and "101". Looks like self calls.

[Razumets17]

Hi!!

Some our codecs have same problem. They recieve outbound calls from numbers "100" and "101". And if look clother this calls cominf from the same white IP address as address of codecs. So it means codecs calls by itself. And this call repeats too often last time(approximetly 30 times per day)

Why it happens and How to solve it?

With Best Regards,

Andrei Razumets.

[Martin Koch]

Hello Andrei,

Yea, if you search a bit you will find many postings related to these type of calls in the forum.

Most are about problems on the VCS, but on the endpoint its the same.

Your endpoint is most likely on a public ip, has NAT from a public ip (or you have an internal network issue / trojans :-)

What happens is that there are always scans on the internet for open telephony gateway

services or exploits.

If you are registered to a VCS-E you might not need the direct ip connectivity, so you could

block traffic from the outside.

If you need to have it on a public ip I would also firewall it and block what you do not need

(management, sip, ...)

An other option is if you do not need SIP disable that as most of these scans are just SIP/UDP.

Never verions also support to disable the sip inbund port:

xConfiguration SIP ListenPort: Off

How is the endpoint deployed and how are you using it?

Andrei: Please rate the answer and set it to answered if it is!

[ahmashar]

5 stars to you, Martin. excellent work.

[Razumets17]

It just single endpoint(c20) in customers network.

He haven't VCS and he use point-to-point connectuvity approach.

Could you advise how solve it without swithing off  SIP on the codec?

[ahmashar]

Hei Andrei,

In addition to what Martin said here, I would also suggest to open a TAC so you get customized CPL script for your VCSs and increase the protection against intruders.

regards, Ahmad

[Dharmesh Nandoria]

Hi All,

This issue is related to which is having fix in TC 6.2 .

CSCue55239

SIP : Ghost call.  SIP Port scanned from outside.

Kind regards,

Dharmmesh

[Razumets17]

Unfortunately I couldn't open this link.

Reason-

Error 118 (net::ERR_CONNECTION_TIMED_OUT):

[Martin Koch]

Yea, also cant open that link (which points to:

https://cdetsng.cisco.com/webui/#view=CSCue55239 )

But you can go to

http://tools.cisco.com/Support/BugToolKit/action.do?hdnAction=searchBugs

and enter the id:

CSCue55239 (just dont care if this CS string is shown as a link, just copy and paste it in the tools.cisco.com link)

Maybe that link:

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCue55239

works for you (which also might get rewritten by the forum, ...)

Anyhow thats whats written inside:

SIP : Ghost call.  SIP Port scanned from outside.  


Symptom
Ghost call. It appears that the codec is calling  itself automatically. Placing a codec on a public IP will cause calls  from SIP scanners. These scanners (e.g. SipVicious) are used to detect  possibilities for exploiting PSTN trunks. 
Condition
The  system is on public IP or reachable from the outside and not protected  well enough. This makes it possible to initiate SIP calls over direct  IP.
Workaround
Make sure the system is well protected and  that it is placed in DMZ if you need to have it on public IP. It is  possible to only allow calls from the VCS by disabling the listenport on  5060/5061, but then SIP outbound needs to be enabled so that the VCS  can reach the endpoint.
xConfiguration SIP ListenPort: On
xConfiguration SIP Profile 1 Outbound: On 

Btw, it looks that the workaround there is described wrong as its says listen port on.

Actually I do not see that it is a bug, rather than a feature request, as it can be

wanted to be handeld like that. I saw other vendors having an option only allowing the

gruu to be dialed up when registered.

Anyhow, this is dependent on your deployment. You did not mention if you have a vcs or an other

call control or if its a stand alone system.

You can hope that TC6.2 fixes your issue, but that might only be adressed if you are registered to a VCS.

You can try to block sip udp in the firewall thats a good start to block most of the unwanted calls.

If you want to use SIP (especially be reachable) you should anyhow place the system behind

(and as well only allow whas needed and block for example the management and system internal ports) a firewall

and use a call control like vcs, cucm, ...

[Martin Koch]

Btw, why do you need SIP?

For IP based dialing or hostnames its way more common to use h323.

On SIP you normaly want to use proper URI dialing like system@domain.com.

The support for proper URI dialing is also a key argument for a proper call control.

And Andrei, please rate the postings!

[Razumets17]

Thanks a lot again for your help.

[Martin Koch]

Andrei, you are welcome! Thank you for rating!

Did you had the chance to try it out?

Did this answer your question or do you still wonder about something?

If its answered please set the thred to answered so others can find it

when they have the same problem.

[Paul Woelfel]

Hi Martin,

I would say it is the other way round. H323 was very common and still is, but SIP is the protocol of the future. I think there is much more effort put in developing SIP further and more and more systems support SIP. You also see Cisco pushing SIP, like Conductor and TS only supporting SIP.

My Installations basicly use SIP and only have H323 as fallback.

[Martin Koch]

Maybe I did not write it clear enough.

This seems to be a system on a public ip with no call control.

That is a deployment style itself which is aged out, but in this deployment its

uncommon to use SIP, I do not say that SIP is uncommon.

With a single device without a call control he will not be happy as dialing in and out

without a propper uri might have its limitations and

ip only stand alone is simply not that much used on the public internet for video conferencing

using sip, such old deployment is mostly base on h323.

The problem is caused by sip being enabled and public reachable.

So if he is using it as an independent device, does he really use SIP? If not

his problem will be solved by disabling SIP.

Sure the best would be to register it to a vcs-e and put a firewall upfront to block sip

and management ports to the endpoint and have a well configured VCS which takes

care of unwanted calls, but thats not given here.

By today deployed with the vcs the conductor does not care about the protocol as its

a CPL service, the tps supports h323 as well.

And agin, dont get me wrong, I am anyhow coming from the SIP world and agree that

the TelePresence deployments already use sip and will use even more in the future.

So yes, you are right, but no I did not mean that and no it does not fit here :-)

[Razumets17]

Yes it's stand alone endpoint with public Ip.

But my customer would like to call by Jabber client which registered in cisco server( how I understood it using only sip without vcs and converting to h323). So how he could to make call if he swithced off SIP on this devise? How many ways we have dor solvation this question?

Thanks for advance.

[MIKE ZINNER]

A lot of these 100@ and 101@ calls come from a SIP scanning program called sipvicious.  It is NOT a malicious program as-is.  It was written to probe sip servers to see what could be learned about them.  If you're curious about sipvicious, you can download it & play with it.  It does require Python version 2.6 to run, and can be run on Windows and Linux.