The skinny Client Control Protocol is a Cisco proprietary signaling protocol.
That means it sort of fits the same place in voice over IP that sip and H.R. 3 2 3 2 now. Skinny is also very proprietary. So you’re not going to see skinny implemented on anything but a Cisco. And so immediately you sort of say well why would I engage in a proprietary protocol is dangerous to do and that’s true. But I have for you here a quote from a voice over IP cameras that we did here at RMIT millions of installed Cisco phones would argue for the continued use of skinny as a protocol.
So if you’ve got lots and lots of skinny gear and you have lots and lots of skinny phones and you’re going to use Cisco phones in the future then there’s nothing really wrong with going forward is skinny it’s highly effective and really really easy to read and to troubleshoot.
Reserved for skinny
Now it’s called Skinny and if you compared it to Asia three two three if you’ve ever looked or tried to debug in Asia three to three data stream it’s extraordinarily painful to go through. And so from that perspective skinny is certainly a lot easier to read than H.R. 3 2 3 but SIP is also pretty easy to read to and understand what’s going on. So if you’re comparing the two. You know if you’ve got Cisco stuff go skinny. If you don’t have Cisco stuff goes up when you’ve got skinny implemented the signaling protocol is going to connect on port two thousand. So that’s the one is reserved for skinny when phones are registered they have what we call a pervasive connection with the call manager. So they’ve got this keep alive with the call manager. And actually, it can be sort of a pain to move Cisco phones from one number to another because of that connection. Now like all voice over IP implementations use the signaling protocol in this case as CCP or skinny.
And then you drop into RTP for voice transport. One of the big differences in a Cisco implementation is that there’s no RTP. So from that perspective, this is not a standard sort of VoIP implementation. So if you’re looking for our DCP package you’re not going to see him at all. Cisco has some other things that it uses instead. And we’ll take a peek at those later on another difference is that we don’t see RTP use for anything but voice transport. So as I mentioned skinny messages are really really simple the message header for all of them is exactly the same you have a header data length version and then the message I.D. as you can see here in this register message.
Example depending on the message type then the then the header expands or the packet expands to include different kinds of information depending on the message type or the message I.D.. But all of them share this sort of common header format very easy to read and you can see that with the wire Shard the sector the name and the message sort of tells you the whole thing. Now what I wanted to be clear about is that even though we’re switching between some of the other typologies we’ve talked about device topology is Polycom topology is all voice over IP implementations share a bunch of common items or common components in the demolishing and the Cisco is no different.
So you’ve got your interconnections there and this view via the switch and I’ve got a couple of monitors in this particular image you got your phones and then you’ve got a call manager connected in there somewhere. The difference here is that in our lives our students are dealing with call manager Express so this is the sort of entry-level call manager for Cisco. And when you do this deployment it’s very simple to put the TFT server and the DCP server right on the router, in fact, things get a little confusing if you put the TFC piece or anywhere else. So everything’s right there on the router so you don’t have additional servers laying around all in one box. Of course, the difficulty is if anything goes wrong with that one box you’re toast.
Basic header format
We have the same operational stages. So when you plug phones in the first thing that they do is they try and do the HDP. And from DCP they learn where the TFT P server is and this is maybe one of those places that Cisco departs a little bit Cisco phones discover the call manager through a different mechanism normally VOIP phones will pull down from the CFP server the location of the call server and the how we might configure the interfaces things like that or they might pull this from the DCP server call manager things like that
Cisco we do this with CnF files that you see FCP directly from the router. And that’s one of the reasons why it’s nice to put the TPP server or is important to put the TTP server in the same place as your call manager Express box because of that CnF file. And this is just a graphic that shows you the tremendous number of different skinny messages. I mean there are just piles and piles and piles of them. And again you can see that from there. Descriptions there the info that. The Cisco message or the skinny message tells you exactly what this message is trying to do. So we’ve got button pushes and know line status and time and date registration all that kind of stuff is right in the title.
And so there’s lots and lots of skinny messages and you can see that in this particular case the phones were going right up to the call manager and all of these messages were coming in one direction well after we JCP and T FCP and register with the call server we’re going to start doing something. And so we’re gonna go off-hook here and this is one of the places where Cisco implementations differ from a lot of them.
We tell the phones to play a particular tone. This is different than a lot of implementations because what we see on a VIE is, for example, is that we’re sending RTP packets that include dial tone and we don’t have that on a Cisco implementation. And the bottom part of the screen here we see our address signaling again is very clear what’s going on here we’ve got a keypad button message and then the number that was dialed when you hit that particular key. So very straightforward very easy to troubleshoot if you can see inside the packet and here is our tear down.
We’ve got a couple of things that are going on. We’ve got to stop media transmission which tells us that we are no longer going to be sending RTP packets and then we close the channel or what we might call the session between the two endpoints. So very graceful sort of tear down but again very clear on what’s going on here you might guess from these messages that the beginning of this we had to start media transmission message and the last thing that I wanted to point out here is that as we throughout the course of the conversation instead of getting our packets and if you recall that RTP is there for quality of service measurements packets latency bytes things like that.
We’ve got connection statistics requests and response on the Cisco implementation with CCP. So these are the packet that says Tell me about the packets and the architects and the timing that you’ve got on these particular packets instead of our DCP. And this is I think I pointed out at the beginning of this video this is one of the big places that Cisco differs from what we might call a standard voice over IP implementation.