Securing Cisco Video Networks: a video demonstration

[]  The rise of Video conferencing as a preferred means of collaboration advocates for continuous  conversations on the issue of security. This entry seeks to contribute to that discussion.

Hope you find this useful.

 

 

Deploying Cisco Jabber Guest Server- Part one – a video demonstration

Hello and welcome to this entry on Jabber guest. ‘Cisco Jabber Guest is a [Web-Based ] consumer-to-business (C2B) solution that extends the reach of a company’s internal enterprise telephony to people outside of the corporate firewall’ via the aid of a link that is posted or published on the company website. Thus, without any specialised hardware, jabber guest turns a regular webpage into a video/collaborative end-point at the moment that a consumer clicks on the web-based link/hyper-link.   A customer or client is now able to establish high-definition video communication with someone stationed within the internal network or even at a remote location by using a simple browser!

Jabber guest links/hyperlinks can also be embedded into documents and custom apps.

Please view the link below for a quick yet very detailed introduction.

http://youtu.be/n-USuvpNC6c

The video Demonstration  below is part one of two parts.

1) This part (part one) will focus on deploying a  Jabber guest cluster.
2) And part two will focus on integrating the jabber guest cluster with an Expressway cluster
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Today’s outline.
:::::::::::::::::::::::::::

1) Today I will be deploying Cisco Jabber guest in a cluster of three servers.

3) Then I will configure sip trunks between jabber guest and CUCM

4) After configuring the Jabber guest links on the Jabber guest server, I will then advertise/publish the links to a website.

5) I will then browse to the webpage and click on the link (that was published in step 4) in order to establish a video call between the web-based caller (i.e me) and the internal called device (jabber for windows soft-phone)

The result will be a call between a browser and a jabber for windows client. Enjoy!

 

 

 

 

Thanks for visiting

 

Regards!

Configuring Collaboration Edge- Mobile and Remote Access on Expressway- a video demonstration

Hint: Somewhere around 19 min into the recording I mentioned ‘server signing authority’ instead of ‘Certificate signing authority’.  Please process the information accordingly.

The promise of Mobile and remote access technology is that , using the Expressway-C and E servers, external devices are able to register to the corporate network  and  gain access to services  which are located within the corporate LAN without need for a VPN.  Internal services like voice-mail, directory, audio- video calls, on-premises instant message and presence information become transparently and seamlessly available to a mobile and remote devices as they move in and out of the network with no extra user education or involvement.

In the first half this video demonstration, I will:

i) Walk through what we already have configured on the corporate LAN.

In the second half, :

i) I will first of all install the Expressway-C and establish communication between Expressway-C with the internal servers like CUCM and IM&P.

ii) Then the expressway-C  is  connected to the Expressway-E via a traversal zone. The Expressway-E sits in the DMZ. The traversal zone is the link between the internal and external network.

iii) Finally, a jabber client is registered to the network via the Expressway-E. The jabber client is able to access internal services through the aid of the traversal zone that exist between the Expressway-E server that is  on the outside or DMZ of the network  and the Expressway-C server which is inside the network. .

Enjoy

 

A glimpse into the boot process of Cisco Jabber

This blog entry was never intended to be made public  but as I have picked up  so many things from reading other people’s blogs, I thought I’d add this entry here in case its of use to anyone . Anyway, the reason behind this work is very simple: In order to find a problem when looking at the logs of broken device, you first of all need to know what they look like when everything is working fine.

The following is an output from  the jabber logs (CSF-UNIFIED.LOG)that I collected from one of my Lab PC (s) running jabber 9.1.5  that was  registered to cucm and presence server 9.x.

Jabber  processes are starting.

————————————————–

Starting new instance of Cisco Jabber

————————————————–

[lugin-runtime\impl\PluginRuntime.cpp(93)] [plugin-runtime] [initialize] – Initializing plugin runtime

\JabberCoreUiPlugin.cpp(48)] [plugin-runtime] [initPlugin] – Jabber Core UI Plugin initializing...

Jabber front-end /

 

IMPStackCap::StackManager::initialise] – LoginMgr started…

[IMPStackCap::StackManager::initialise] – PresenceClient started…

[IMPStackCap::StackManager::initialise] – Config started…

2013-12-01 00:27:31,448 INFO  [0x000003c8] [esets\adapters\imp\StackManager.cpp(118)] [csf-unified.imp.stackManager] [IMPStackCap::StackManager::initialise] – BuddyList started…

2013-12-01 00:27:31,448 INFO  [0x000003c8] [esets\adapters\imp\StackManager.cpp(121)] [csf-unified.imp.stackManager] [IMPStackCap::StackManager::initialise] – Presence started…

2013-12-01 00:27:31,448 INFO  [0x000003c8] [esets\adapters\imp\StackManager.cpp(124)] [csf-unified.imp.stackManager] [IMPStackCap::StackManager::initialise] – IMP2P started…

[csf-unified.imp.stackManager] [IMPStackCap::StackManager::initialise] – Group Chat started…

csf-unified.imp.stackManager] [IMPStackCap::StackManager::initialise] – EnterpriseGroups started…

csf-unified.imp.stackManager] [IMPStackCap::StackManager::initialise] – …Initialized

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

In the output below, the jabber client notices that I did not configure any ip or dns names in the jabber client so  jabber decides that it will have to dynamically sends out a DNS service request (SRV) request to the DNS server that is configured on the local network interfaces card in order to find out the IP address of the presence server. However, before doing that, it checks whether it has any presence server  IP-addresses stored locally in its database–and because this is not the first time that jabber has found this server, it discovers a cashed copy of its presence server host-name and uses it  It then goes on to login with my user-ID of ‘ user2’. In case you are reading this and wondering how jabber manages to  find its presence/webex server without having it configured on the jabber client,  just copy the following into Google and you will find everyone talking about it :   _cuplogin._tcp

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

[AddUpdateSubItem] – Setting Status:  status of Presence to Connecting

No CUP server specified, will attempt DNS SRV with domainlist: voiceinitiate.com

[LoginMgr.dll]: LoginMgrImpl::Login, type:1, serv:, user:user2, resource:jabber_6742, jw-ver:0.9.2.4420, app-ver:9.2.6.12639

[LoginMgr.dll]: login, clear login data. deep:1

[LoginMgr.dll]: dns, cup-domain:voiceinitiate.com

[LoginMgr.dll]: CLoginContext::ChangeState now:1 auto:0

[LoginMgr.dll]: CGetProxy::Connect login, CGetProxy::Connect

[LoginMgr.dll]: CLoginContext::ChangeState now:1 auto:0

[LoginMgr.dll]: dns, login, with cached cup server:pubcup.voiceinitiate.com

[LoginMgr.dll]: CLoginCup::_connect

[LoginMgr.dll]: ha, soap-servers:pubcup.voiceinitiate.com

[LoginMgr.dll]: login, cup:pubcup.voiceinitiate.com

inCommands::SignOn] –

[csf-unified.imp.LoginCommands] [IMPStackCap::LoginCommands::SignOn] – Signing into Presence Server. Account: user2, server: , login mode: ON_PREM, result: 0

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Jabber successfully connects to presence server and then verifies the certificate of the presence server.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

[csf-unified.imp.LoginCommands] [IMPStackCap::LoginCommands::SignOn] – Dispatcher::doExecute] – LoginCommands::SignOnResult: 0

[csf-unified.imp.PresenceAdapter.SignOnState] [SignOnState::isComplete] – isComplete: 0[csf.cert.win32] [cert::Win32CertVerifier::Win32CertVerifier] – Windows CertVerifier constructor

[cert::CertVerifier::checkResult] – finalResult: SUCCESS

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

This stage of authentication and certificate verification is now over and Jabber is now engaged in full communication with the  IM and presence server: Connecting with the XMPP component of the  presence server and retrieving data about the CCMCIP (call-manager) server, TFTP server and CTI server now ensues. The client opens an XMPP stream and starts exchanging data with the IM and Presence server .

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

[IMPStackCap::Log::log] – [LoginMgr.dll]: CLoginCup::OnGetAllConfig

[LoginMgr.dll]: login, jabber, serv:pubcup.voiceinitiate.com

[ [LoginMgr.dll]: login, cup, calc 1-time token(userid:user2@voiceinitiate.com, token:1252341)

[JabberWerx] [IMPStackCap::Log::log] – [XmppSDK.dll]: #0, CXmppClient::Connect , connecting to server by TCP connection……

[JabberWerx] [IMPStackCap::Log::log] – [XmppSDK.dll]: #0, CXmppClient::onStreamEvent ,CXmppClient::onStreamEvent, SessionState_Connecting

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Jabber client retrieves its  details like ccmcip server , buddy list, tftp server etc .

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

[IMPStackCap::RetrieveConfigCommand::RetrieveConfig] – Retrieving config from Presence Server

[IMPStackCap::RetrieveConfigCommand::RetrieveConfig] – Config Retrieved from Presence Server

csf-unified.imp.BuddyListCommands] [IMPStackCap::BuddyListCommands::GetUserJid] – User jid: user2@voiceinitiate.com

[ConfigServiceImpl::OnConfigChanged] – OnConfigChanged key : [CcmcipServer2] value : [192.168.0.12] o

[ConfigServiceImpl::OnConfigChanged] – OnConfigChanged key : [CtiServer1] value : [pubcucm.voiceinitiate.com

 

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Now that that jabber client knows it’s TFTP server, it attempts to download the configuration file.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Old tftpServer1 address:

New tftpServer1 address:192.168.0.12

Old tftpServer2 address:

New tftpServer2 address:

Old tftpServer3 address:

New tftpServer3 address:

Old configurationFile:jabber-config.xml

New configurationFile:

[TftpConfigStore::onConfigAddedOrUpdated] – attemptNewDownload [true]

[attemptTftpFileDownload] – Downloading file http://192.168.0.12:6970/jabber-config.xml………

[csf.ecc] [doGet] – doGet(http://192.168.0.12:6970/user2.cnf.xml)

[csf.ecc] [doGet] – doGet(http://192.168.0.12:6970/CUPC/AppDialRules.xml)

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

The jabber client then tries to register its softphone.

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

sipio-sent—> REGISTER sip:pubcucm SIP/2.0

Via: SIP/2.0/TCP 192.168.0.9:1588;branch=z9hG4bK00005888

From: <sip:1002@pubcucm>;tag=000c29e2fc390004000060d0-00005d12

To: <sip:1002@pubcucm>

Call-ID: 000c29e2-fc390002-000070b6-00001a66@192.168.0.9

Max-Forwards: 70

Date: Sun, 01 Dec 2013 00:27:36 GMT

CSeq: 102 REGISTER

User-Agent: Cisco-CSF/9.3.2

Sent:REGISTER sip:pubcucm SIP/2.0  Cseq:102 REGISTER CallId:000c29e2-fc390002-000070b6-00001a66@192.168.0.9

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Cisco call manager accepts its registration request.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

[_SIPCCLoggerFunction] – sipio-recv<— SIP/2.0 200 OK

Via: SIP/2.0/TCP 192.168.0.9:1588;branch=z9hG4bK00005888

From: <sip:1002@pubcucm>;tag=000c29e2fc390004000060d0-00005d12

To: <sip:1002@pubcucm>;tag=833129954

Date: Sun, 01 Dec 2013 00:27:20 GMT

Call-ID: 000c29e2-fc390002-000070b6-00001a66@192.168.0.9

CSeq: 102 REGISTER

Expires: 120

Contact: <sip:6ee27b67-fbf0-5671-2759-64e50cb86304@192.168.0.9:1588;transport=tcp>;+sip.instance=”<urn:uuid:00000000-0000-0000-0000-000c29e2fc39>”;+sip.instance=””;+u.sip!devicename.ccm.cisco.com=”user2″;+u.sip!model.ccm.cisco.com=”503″;video;bfcp

Supported: X-cisco-srtp-fallback,X-cisco-sis-6.0.0

Content-Length: 0

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Ok that’s all for now; I will continue to expand this entry whenever I  find time.

For further reading please consider the following links

1)      The basics of XMPP- Envelops, Stanza, Streams etc

http://web.archive.org/web/20120815100411/http://www.adarshr.com/papers/xmpp

2)       For a step by step guide on how to read jabber call flow between two jabber soft-phones      http://www.cisco.com/en/US/partner/products/ps12511/products_tech_note09186a0080c15703.shtml

Presence status failure on Mobile connect or Single number reach.

 * Hint:Please note that some of the screenshots and outputs in this post have been recreated in a lab

This was another interesting case that was raised with me by one of our clients. This client has a PBX (Aastra Communications server) integrated with Cisco Call Manager via a Sip Trunk.

The client configured Single-number-reach or mobile connect. The way the client configured it was such that an internal CUCM number of 5737 had 07578334371 configured as one of  its remote destinations. The second  remote destination was configured as 875737. This extension is the user’s other extension that is  hosted on the SIP-PBX.

So in essence each user had three phones, a  Cisco phone, a Sip-based mobile PBX phone, and a normal mobile phone.   As you might already know, the way presence works on  mobile-connect  is that when a user calls into the company with his Sip-based mobile PBX phone or normal mobile phone, their internal line (cisco)   presence status would be updated to ‘off hook or ‘On a call’. So what I mean is that  if a user calls from his Sip PBX phone to another internal user’s internal number, everyone would be able to see the external caller’s status as on ‘ on a call’ or ‘off hook’ .

However, this was not working for my client. The presence status was triggering fine when calling into the network from mobile phones but it was not triggering from the Sip-based mobile PBX phones.

In order to test this, I told the client to call an internal   Cisco IP-phone (extension 3250) using his PBX phone (extension 785737) which is mapped to his internal number of 5737 as a remote destination or mobile connect number.

I collected the trace of the call and this is what I found:

 

:::::::::::::::

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

INVITE sip:3250@10.xx.96.x8 SIP/2.0

Via: SIP/2.0/UDP 10.xx.6.x02:5060;rport;branch=z9hG4bK2013Apr1753552443250

To: <sip:3250@10.xx.96.x8>

From: “Mark o’neil” 7@10.xx.96.x8>;tag=AI51E9A11E80AFDF6C

Call-ID: AIBD1912FE6B7F686C@10.xx.6.x02

CSeq: 1 INVITE

Max-Forwards: 70

Contact: sip:5737@10.xx.6.x02>

Accept: application/sdp

Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,UPDATE

Allow-Events: dialog,message-summary,refer

Privacy: none

Supported: timer

User-Agent: Aastra 400

Session-Expires: 1800

Min-SE: 300

Content-Type: application/sdp

Content-Length: 316

v=0

o=aastra400 442514688 442514688 IN IP4 10.xx.6.x02

s=call

c=IN IP4 10.xx.7.x01

t=0 0

m=audio 16380 RTP/AVP 0 8 18 4 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

04/17/2013 15:53:55.370 CCM|//SIP/SIPCdpc(0,0,0)/ci=0/ccbId=0/scbId=0/globalize: Performing stripAndPrependDigits — Prefix data = , Strip Data = 0|

04/17/2013 15:53:55.370 CCM|//SIP/SIPCdpc(0,0,0)/ci=0/ccbId=0/scbId=0/globalize: CallingNumber after stripAndPrependDigits 5737|

04/17/2013 15:53:55.370 CCM|SPROC getCtrlPid – callingNum=5737, inputCtrlPid=(5,100,175,1)|

04/17/2013 15:53:55.370 CCM|DbMobility: getMatchedRemDest starts: cnumber = 5737|

04/17/2013 15:53:55.370 CCM|DbMobility: getMatchedRemDest: full match case|

04/17/2013 15:53:55.370 CCM|DbMobility: can’t find remdest 5737 in map|

:::::::::::::::

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Did you notice what was wrong with that call? Did you noticed that the  in-coming caller-ID was 5737 instead of 875737?   Did you also notice that the wrong caller-ID  which   later caused a problem? If you look at this part of the trace copied below;

‘: getMatchedRemDest starts: cnumber = 5737’

‘can’t find remdest 5737 in map’

You will noticed that after the call came in and the digit manipulation that is configured on the sip trunk had been completed, the call manager was actually trying to check whether the in-coming caller-ID was actually configured as a remote destination for any user on the system. But in the end, the call manager  decided that the number was not configured as a remote destination for any user so the presence status of any internal number was never triggered.  For the internal line presence status to change, the incoming caller-ID needs to match one of the numbers already configured as a remote destination of an internal number.

I got the PBX engineer to make sure that the PBX was sending the full number and after that I collected another trace for the call. This is what I found:

:::::::::::::::

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

INVITE sip:3250@10.xx.96.x8 SIP/2.0

Via: SIP/2.0/UDP 10.xx.6.x02:5060;rport;branch=z9hG4bK2013Apr2647493143250

To: <sip:3250@10.xx.96.x8>

From: “Mark o’neil” <sip:875737@10.xx.96.x8>;tag=AIB932DDBF63C8339D

Call-ID: AIC245C802CF7BDC00@10.76.6.102

CSeq: 1 INVITE

Max-Forwards: 70

Contact: <sip:875737@10.xx.6.x02>

Accept: application/sdp

Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,UPDATE

Allow-Events: dialog,message-summary,refer

Privacy: none

Supported: timer

User-Agent: Aastra 400

Session-Expires: 1800

Min-SE: 300

Content-Type: application/sdp

Content-Length: 318

v=0

o=aastra400 1213022154 1213022154 IN IP4 10.xx.6.x02

s=call

c=IN IP4 10.xx.6.x03

t=0 0

m=audio 16386 RTP/AVP 0 8 18 4 101

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no

a=rtpmap:4 G723/8000

09:47:50.116 CCM|//SIP/SIPCdpc(0,0,0)/ci=0/ccbId=0/scbId=0/globalize: Performing stripAndPrependDigits — Prefix data = , Strip Data =

04/26/2013 09:47:50.116 CCM|//SIP/SIPCdpc(0,0,0)/ci=0/ccbId=0/scbId=0/globalize: CallingNumber after stripAndPrependDigits 87573704/26/2013 09:47:50.116 CCM|SPROC  getCtrlPid – callingNum=875737,

04/26/2013 09:47:50.116 CCM|DbMobility: getMatchedRemDest starts: cnumber = 875737

04/26/2013 09:47:50.116 CCM|DbMobility:initRemDest: device pkid [97c71d1f-24f7-1f82-107d-

04/26/2013 09:47:50.116 CCM|DbMobility: found DN association for remdest [875737]| 04/26/2013 09:47:50.116 CCM|DbMobility: found remdest cnumber = 875737, devicepkid =

-1f82-107d-4c77053bc79f found in RemoteDeviceInfo hashmap – PID(s)=2 Name=875737:RDP-marko-5737 is Active=1 Protocol=Remote Destination

:::::::::::::::

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Notice that the incoming caller-ID was sent in full and the result was that  a remote destination match was discovered by the call-manager  as be seen in the output copied below?

(‘-1f82-107d-4c77053bc79f found in RemoteDeviceInfo hashmap – PID(s)=2 Name=875737:RDP-marko-5737 is Active=1 Protocol=Remote Destination ’)

As soon as the match was made, the presence status of internal extension of 5737 was trigger and updated to ‘ off hook’ or ‘on a call’ and everyone in the company could now see extension 5737 as being on the phone even though the user  was using his remote destination phone of  875737.

. . . and that was how my client was instantly made happy and of course I was glad to have gotten to the bottom of it.

Cheers folks,

Hope it has been an interesting read

Welcome to Voice Initiate

If you are visiting for the first time then I would like to say welcome to Voice Initiate. It is a place where experiences are shared and discussed.  As we all know, working in technology is all about being introduced to new things on an almost daily basis. For me, it’s like being in a perpetual state of initiation.

If you are reading this blog then I’m sure you can relate when I say that I came into the IP telephony world not knowing that I would have to learn programming too, but working on Contact Centers dictates  that  you must- so retreat was never an option. . . it’s an endless battle but we love it anyway.

This blog is an account of the joys and challenges faced by a Unified Communications NOC Engineer. This is a  place where both failure and success is discussed openly.

Advice and contributions are always welcomed.  My hope is that this blogs brings a sense of thrill to fellow bloggers and initiates alike and a sense of nostalgia to those that have seen the joys and challenges that we now speak of .

Cheers!

maxwell.osagie@yahoo.com