check out the developer area of spark, you will also find labs and if you google a bit sample scripts like on github. https://developer.ciscospark.com/ ... View more

i assume you are aware of: http://www.cisco.com/c/en/us/support/cloud-systems-management/prime-infrastructure/products-programming-reference-guides-list.html     ... View more

Splunk is really a great took which I would recommend to investigate to further check on the received data. But it seems to be a better way to have a dedicated syslog service and then hook to that with splunk. I would either simply run a dedicated linux vm with a syslog server (and possible splunk on that one as well). An other option on a windows system could be to use cygwin and then install syslog-ng, that would also give you the flexibility of a more advanced syslog server, but I would prefer linux or bsd. These links are just googled: http://answers.splunk.com/answers/28680/universal-forwarder-vs-dedicated-rsyslogsyslog-ng-servers-to-forward-syslog-to-splunk-indexer http://www.syslog.org/logged/running-syslog-ng-on-windows/ Please remember to rate helpful responses and identify helpful or correct answers. ... View more

An external system can register via sip and h323 to the VCS-E. It can be on a public ip, but it can also be behind NAT (no l3 h323 or sip features enabled!). You should not disable SIP but either block the communication for other systems then the VCS. On a public ip it should work to disable the sip listening port and enable sip outbound. The remote systems shall call the endpointaddress@domain.com and not the public ip of the endpoint or the VCS. Regards policies, they are more to define who shall be able to call who or do additional action like call forking, action on non reachable, ... In a case where you want do not want know who to block or only allow it will not help you. Unless you do not have an ISDN gw or something else what can generate costs when dialing you and others should run fine without additional policies. Using secure passwords and firewall management and non used ports is more important. If you have more questions, I would recommend that you open new threads for them. Please remember to rate helpful responses and identify helpful or correct answers. ... View more

I do not agree that it does not need to be a bug. Check out: CSCuf34508 There seems to be some issue with some (integrated) cameras and specific bandwidth configuration. (which I guess causes a resolution to be used which is some how not compatible). I would recoomend to report it as a bug to TAC so it gets a higher priority! Please remember to rate helpful responses and identify helpful or correct answers. ... View more

Hello Ahmad! It seems to be that other laptop (also got a report of a MacBook with Bootcamp) have similar issues. Selfview works fine, the call not, sometimes changing the bandwidth settings seem to help. Using an external camera is not always an option. As the bug CSCuf34508 itself shows status "fixed". Will there be a updated JabberVideo version addressing this issue and when will it be available? Please remember to rate helpful responses and identify helpful or correct answers. ... View more

Your assumption is not fully correct. Like mentioned as the first step you could evaluate if you really need to use sip. Instead of buying a VCS he could also use a service offering the registration as a service. Depending on the firmware and the setup it might even be that you will experience the same problems when you register the endpoint to a vcs if the endpoint stays on a non firewalled public ip. If the ISP can block it sure, normaly its done on a router of the customer itself. You would need to allow traffic from the sites you want to have sip calls from and block it from everyone else, if you can only block it completely, could also simply disable sip, ... ... View more

There are many organiations which see port and service scns already as a malicous action. So I would say you can not say NOT as it might depend of your position. There are option packets but the main annoying parts are INVITES, and if you have a VCS for example it will consume a call license if the call gets established. As this will eat up a call license and this is an unwanted call I also understand if somebody sees that as a malicious act. Anyhow if its malicious or just annoying, it sucks if your endpoint rings all the time or your log is flooded with such invites/options so you cant see anymore what you would like to see, ... ... View more

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 :-) ... View more

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. ... View more

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! ... View more

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, ... ... View more

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! ... View more