Search This Blog

Wednesday, July 22, 2015

Cisco AnyConnect will not start

     This isn't really Voice/UC Collab related but I wanted to take a quick minute to post this here.  Today I started up my laptop after a Windows update to find my Cisco AnyConnect Client would not start and kept giving me a "Cisco AnyConnect VPN Service is Unavailable" message or something similar and then would proceed to tell me that "I needed to exit and wait a minute then start it again".  Basically what is happening here is your computer for some reason hasn't automatically started the Cisco AnyConnect VPN service.  Mine is set to auto and after 15 minutes I had nothing.  Needing to get some work done, I had to get this working and short of uninstalling it I had no other options at the moment until I had an "aha!" moment.

     What you need to do is go in and start the service manually even though it is set to "Automatic".  I know this should be second nature to most Windows users but sometimes we forget these small things and I only use Windows 8 hours a day, the rest of my time is on OS X.  So you need to go here:

1. Click Administrative Tools


2. Click Services
 
 
     Right click on that AnyConnect Secure Mobility Agent and hit start and then try to start the VPN client.  Everything should work.  Short of uninstalling, this is the easiest way that I have found to fix this problem.  I figured I would post this here since I thought it relevant to know how to solve this issue.








Wednesday, July 15, 2015

A very basic SIP introduction

Having been using SIP for awhile now, I like to think I know enough to troubleshoot and fix the problems that arise.  Knowing when it is a provider issue and when it is the layer 8 issue (the connection between the keyboard and the floor), yes that was a joke.  I am by no means a SIP master like the Verizon guy on the Cisco forums but I still know enough to be able to tell the difference between a TX and RX and why the From and To headers don't change in relation to the message.  I figured I would post a few things here that I think are either common knowledge or something you need to know if you are getting into SIP.

To start things off, I would very highly recommend that you read RFC 3261.  It is basically a tutorial for SIP and assumes no knowledge of what SIP is and what it can do.  You can click here to read the RFC at your leisure.  I know that the RFC is long, but it does provide some good insight as to how this protocol works, the definitions, and has a very good description of the headers.

In my opinion SIP in its basic form is an evolved H.323 protocol.  The next level so to speak.  SIP essentially takes all the craziness in H.323 and makes it much more legible and easier to deal with.  Gone are the days of needing to decode the hex of H.323 and read through the TCS (Terminal Capabilities Set) if you migrate to a full SIP network.  The only problem right now is that SIP is not everywhere just yet.  Some ITSPs (Internet Telephony Service Provider) don't yet provide this service or are still new to the game.  I have had the pleasure of working both H.323 over the years as well as SIP and MGCP.  If SIP is available, why are you not using the technology? 

If you are familiar with H.323 I am going to draw some comparisons to help generate a picture that helps in understanding the SIP concept.  In H.323 you have your slow start and fast start.  Basically, slow start deals with sending the H.245 separately after the H.225 call control and signalling setup.  H.225 is basically your layer 2 while H.245 is your media negotiations.  H.323 fast start takes the H.245 and embeds it within the H.225 call setup message.  This allows the remote endpoint to choose fast start if it is capable and negotiate the media faster.

With SIP, the same concept exists.  SIP has delayed-offer and early-offer.  SIP also has something called early-media but we will get into that in another post.  With SIP early offer, call setup proceeds like normal and the terminating end sends it's capabilities to us, the calling party.  We then send a message back showing what we want to use and, in a perfect world, everything works out.  Early-offer takes the capabilities of us, the caller and sends them in the initial call setup message.  This allows the remote end to pick what it wants and send it back to us.

By now, if you know anything about SIP you are probably wondering why I haven't included any terminology.  The reason behind this is that I want those with little to no experience in SIP to grasp the concept before I start throwing out tech jargon that they may or may not understand.  SIP is a very easy protocol to grasp but a very difficult one to master.

When dealing with SIP messages, the best thing about them is that they are all in plain text and follow the HTTP protocol.  You will see things like 404 Not Found when something bad happens as well as a myriad of other messages both good and evil.  SIP has three main parts:
  1. The Start Line
    1. This includes the intial  portion (i.e. INVITE, 200 OK, PRACK, etc.)
  2. The Header
    1. Things like Via, From, To, Contact, Max-Hops, Call-ID, etc.
  3. The SDP
    1. This is basically the media negotation portion.  You will see codecs, DTMF, IP addresses, p-times, bit-rates, etc.
Given those three main parts, they are all completely necessary to setup a call.  I will go over each of the three parts in summary before I go into detail in a later post.  If I went into detail here, this post would be a mile long, much like it almost already is!

The start line with something like a INVITE is one of the first things you would see on a debug or call trace from RTMT.  This start line indicates what is going on with a call leg or call at that point in time.  Below are a list of common start lines:
  1. INVITE
    1. This is typically a request to setup a connection or call
  2. 200 OK
    1. This is an acknowledgement to a request such as the INVITE above
    2. Note that this can contain SDP (more on that later)
  3. PRACK
    1. This is a provision acknowledgement, hence PRACK
    2. This basically gurantees that a provisional message, like INVITE is acknowledged
  4.  BYE
    1. Call teardown in its simplest form
  5. CANCEL
    1. Generally means a request was canceled mid-negotation/setup
    2. Note that this is different than a BYE as this was initiated to cancel a call/request
  6. Ringing
    1. Provisional response to let the requesting station know the phone is "ringing"
  7. Trying
    1. Provisional response to show the INVITE was sent and the distant end is "trying" to set up the call
  8. REFER
    1. This is essentially a gateway transferring the call elsewhere for one reason or another
The above are the most common ones, there are of course others out there.  Again, I didn't go into detail as I want to save that for another post.  This is purely for an introduction into SIP.  Headers in SIP are also in plain text and mean what they are shown as.  See below for a small list of headers:
  1.  Via
  2. From
  3. To
  4. Contact
  5. Max-Hops
  6. Expires
  7. Cseq
  8. Call-ID
  9. Content-Length
These will also be covered in greater detail.  For now, just become familiar and try to think about what they could mean.  Finally, SIP has an SDP element in which it uses to negotiate media.  For instance, if I want to speak G.711u-law, I would advertise PCMU/8000.  This is Pulse Code Modulation Unit 8000.  Basically 8kHz sample with 8 bits per sample for a total of 64kbps in bandwidth, seem familiar?  There is also PCMA/8000 for G.711a-law.  So, I would offer this in my SDP.  I could also offer G.729 and iLBC or whatever other codecs I wanted as well.  Basically, the SIP will negotiate the best quality codec that it can support.  See below for a better illustration of this.


Basically, with humor I described how SIP works with media negotiations.  I just substituted codecs for languages since that analogy seems a bit easier to understand.  One person says "I can speak these codecs" while the other says "I have this codec out of that list".  Keeping it simple stupid, that is how it works.  I will make another post and take things to another level on this later.

I hope that this very very VERY basic SIP introduction has been helpful.  I try to break things down to a third grade level because it makes understanding things easier as well as more entertaining.  Reading a Cisco book is great but can be (usually is), very dry and your head ends up on the keyboard or desk. 


Thursday, July 9, 2015

The Cisco CIUS

So I have had one of these little tablets for awhile now as it was a spare/demo that we were not using anymore.  I know Cisco discontinued this tablet since it was essentially a piece of crap that an iPad superseded in every way possible.  I had some time on my hands yesterday and wanted to register this thing to our CUCM 11 lab.  I ended up getting it registered and noticed that the Android version on it is dirt old, 2.2.2 old. 

One thing led to another and I realized that thing had Jabber on it but it was called "Chat" or something of the sort without the Jabber name.  Now the CIUS already comes with a built in call control system where you can easily dial with the touch of a button but I wanted to use Jabber since that is how things are done these days when using soft clients and tablets.  I went into the "Chat" client and tried to log in and kept getting a "Invalid username/password".  Ok, not possible, I just reset the password to something I couldn't fat finger and tried a few more times and got the same message.

At this point, I'm getting confused as to how this could be possible.  I put in the username@IP and nada.  It just keeps giving me that error.  After some research online, I found out that Jabber "Chat" program demands a URI of username@domain, in this case user@GTWON.TFE.COM (my special little domain inside the lab).  I hit login and bam, it worked...  Why?  Why did I "HAVE" to put that in there versus the IP which works fine on regular Jabber clients on windows and iPads?

So I was excited, I could make phone calls and chat with my other lab jabber clients and see their presence.  I went back into the call screen and noticed the users were not populating presence status yet the chat client was.  This can't be right, the subscribe CSS is correct and everything is allowed to pass through by default.  I still haven't figured this one out yet.

So leaving that behind, I went back into the "Chat" client and realized that this is all the application could really do, chat.  This tablet was made in an era where the call control and chat were separate still.  I tried to upgrade the application and couldn't.  I figured Google Play store might have been out of date, and it was.  I logged back in after the updates and couldn't find the "Cisco Jabber" application on the store front.  Again, I was like huh?

At this point I was confused but did some more reading and found out that the processor is intel based and not ARM based, not sure if that makes a difference, but still.  So no new Jabber client can be installed on this piece of garbage.  I tried to find out how to update the OS on the CIUS, again, nothing.  4.0 was promised as a free update for the CIUS but it never came to light since the tablet as dumped years ago. 

So there you have it, a tablet that is both outdated and worthless other than for lab use.  I wanted to try the camera out but don't have another video or telepresence device hooked up to the lab just yet.  Other than for looks, this tablet will sit there as a pure lab phone since I can do nothing with it for the time being. 

For those of you wondering how to register the CIUS, there is both a wireless and a 3g/wireless version.  The best way is to let it auto-register but you can also pick the right model based on what you have.  Also, do NOT use the wireless MAC to register, use the "Ethernet" MAC to register as the wireless one is not driving the system to CUCM apparently.  Not sure how that works but I found that out after some research too.  Well I hope this article on antiquated equipment gave you a chuckle.