Tag Archive: jabber



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!

Advertisements

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

 


This is another attempt to share what I’ve researched in my personal time with other Engineers simply because  I have benefited  a lot  from reading  other people’s blogs also.  My  hope is that this post is useful to someone out there.

Not too long ago, I wrote a post about  the boot process of Cisco jabber for windows which can be found    here.  In continuation of this entry, I thought I’d add share some more  information on how to read the logs that are generated  when  two people who are  on  Cisco Jabbber clients start chatting or sharing screenshots with each other.

Knowing what to expect in these logs could prove very important if a client complains to you that when he sends chat message to someone the message is never delivered.  Anyway, before I start talking too much, lets begin.

Lets starting of by talking about the trace file  that should be  used when looking into the chat messages or picture exchange between tw0 people on jabber clients.   In this regard, the best trace to collect is the XCP Connnecton Manager traces.  It is also advisable to set the trace level to detailed before attempting to collect the trace file. So the question is,  ‘why the XCP Connection manager trace’ ? Well the XCP Connection Manager  helps jabber clients to connect to the IM and Presence Server. It is sort of like an intermediary.

Now that we have that under our belt, the nex thing to know is how to differnciate one chat message for another in a massive pile of traces.

There are several things unique to every chat conversation:

1)   The sender and the receiver’s jabber ID  (JID)

2)  Every message has a Unique ID which is used to identify a message as it is transported across multiple  IM and presence servers en-route to it’s destination or jabber user.

When reading jabber traces, the same rule that applies to phones and call-manager applies here too:  and that is, you will mostly only find the logs for a given jabber client on the server that it is registered to.  This is true for the XCP Connection Manager traces.  What I’m trying to say here is that sometimes you have to collect logs from multiple IM and presence servers but most of the interesting logs will piled up in one server.

Now that we understand that, let talk briefly about the message flow.

For every chat message/ conversation there are several  messages that are exchanged  in the following order.

1) One of the very first messages is the   “IN FROM CLIENT” message. This is the trace line that tells us that someone has sent a message via the XCP Connection Manager  to the IM and presence server using a jabber client.

2)   “OUT TO SERVER” message. This means that the message has now been transferred to the IM and Presence server’s internal processes so that  a destination for the message can be calculatated or derived. It is at this stage that components like the XCP Router kicks in.

3) ” IN FROM SERVER” message. This is the message that  instructs an IM and presence node to deliver a message to a particular XMPP client. i.e jabber.  Please note that if jabber clients are chatting with each other but they are not registered to the same IM and Presence node, you will never see an  “OUT TO SERVER” and an ” IN FROM SERVER” message together on any single node for one conversation going in one direction (i.e from sender to receiver).

4)   Then there is the  “OUT TO CLIENT ” message. This is one of the final messages you will see in the logs when a message is about to be  delivered to  a recipient jabber client.

Ok now that we’ve discussed this matter at length, let take a look at some logs.

In the logs below, user2@voiceinitiate.com sends a message to  User1@voiceinitiate.comand a message ID of 52a46470:00000990:0000010c is assigned to the message

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

[IN FROM CLIENT state:6]: <message id=’uid:52a46470:00000990:0000010c to=’user1@voiceinitiate.com’ type=’chat’><body>hello this is maxwell. i am having a cup of tea so feel free to play your xbox at work</body><thread>connect23313xmlns=’http://jabber.org/protocol/xhtml-im’&gt;hello this is maxwel. i am having a cup of tea so feel free to play your xbox at work

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

The Jabber session manager  (cm-1_jsm-1) that is running on server “subcup.voiceinitiate.com”,  informs us that this  message is being sent out to the server’s internal processes for analysis and message delivery

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

cm-1_jsmcp-1.subcup-voiceinitiate-com [OUT TO SERVER(3)]: from=‘user2@voiceinitiate.com/jabber_22990 id=’uid:52a46470:00000990:0000010c to=’user1@voiceinitiate

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

In the  output below, the  Jabber session manager  (cm-1_jsm-1) that is running on server “pubcup.voiceinitiate.com”,  informs us that it has received a request to deliver   message to user1@voiceinitiate.com to user2@voiceinitiate.com

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

cm-1_jsmcp-1.pubcup-voiceinitiate-com [IN FROM SERVER]: from=’user2@voiceinitiate.com/jabber_22990′ id=’uid:52a46470:00000990:0000010c’ to=’user1@voiceinitiate.com’ type=chat’ xml:lang=’en’><body>hello this is maxwell. i am having a cup of tea so feel free to play your xbox at work</body>connect23313xmlns=’http://jabber.org/protocol/xhtml-im’&gt;hello this is maxwel. i am having a cup of tea so feel free to play your xbox at work

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

In the logs below, we see that the  message is delivered to the recipient jabber client.

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

cm-1_jsmcp-1_xmppd-1 [OUT TO CLIENT]: <message from=’user2@voiceinitiate.com/jabber_22990′ id=’uid:52a46470:00000990:0000010c’ to=’user1@voiceinitiate.com type=chat xml:lang=’en’>hello this is maxwell. i am having a cup of tea so feel free to play your xbox at workconnect23313xmlns=’http://jabber.org/protocol/xhtml-im’&gt;hello this is maxwel. i am having a cup of tea so feel free to play your xbox at work

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

Ok so now that we know how text/ chat messages flow within the server(s), how about when we send a screen-shot to someone via jabber? Well  the snapshot below shows me sending a picture from one jabber client to another . I will not show you the full message follow because we already have a general idea of what to expect. However, what  I will show here is the actual traces that showed what was happening in the background as the picture  was being sent.

Let me first of show you the  actual screen-shot  that I took while the picture was being transferred between jabber clients. Pay special attention to the name of the file and see if you can see  that same file name in the the logs below.

jabber

cm-1_jsmcp-1_xmppd-1 [OUT TO CLIENT]: <iq from=’user1@voiceinitiate.com/wbxconnect’ id=’uid:52a45b16:00004d03:000001a7‘ to=user2@voiceinitiate.com/jabber_22990′ type=’set’ xml:lang=’en’>Successfully sent file user1@voiceinitiate.com_20131208_150328.png(13613 bytes)’.</x></jingle></iq>

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

The logs above withe XCP Connections Manager logs. Now the presence Engine logs are even more interesting. Check out the logs below that even tells you were the file was saved on the computer hard-drive.

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

system.pe.jabber 1308670 INFO ClientEmComponent::onPacket() – PACKET RECEIVED::  <message from=’user1@voiceinitiate.com/wbxconnect’ to=’user2@voiceinitiate.com type=’chat’ xml:lang=’en’> xmlns=’http://webex.com/connect/imcmd’/>Subject&lt;body xmlns=’http://www.w3.org/1999/xhtml’>&lt;img alt=’Screen capture contenteditable=’false’ id=user1@voiceinitiate.com_20131208_150328.png’ name=‘connect_screen_capture src=’file:///C:/Documents%20and%20Settings/user1/My%20Documents/MyJabberFiles/user1@voiceinitiate.com/user1@voiceinitiate.com_20131208_150328.png/></body></html></message>

Anyway, I hope that what has been shared here today will come in handy to someone down the line.

All the best

Maxwell


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

%d bloggers like this: