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,
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!
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?
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.
This issue is related to which is having fix in TC 6.2 .
SIP : Ghost call. SIP Port scanned from outside.
Yea, also cant open that link (which points to:
But you can go to
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:
works for you (which also might get rewritten by the forum, ...)
Anyhow thats whats written inside:
|SIP : Ghost call. SIP Port scanned from outside.|
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.
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.
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, ...
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 firstname.lastname@example.org.
The support for proper URI dialing is also a key argument for a proper call control.
And Andrei, please rate the postings!
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.
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.
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 :-)
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.
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.