Understanding IP Phone
Behavior
Skinny Client Control Protocol
SCCP
Prof. Yousif
@
Valencia Community College
Skinny Protocol
• Skinny Protocol is a lightweight
master/slave protocol
• CallManager controls every function of the
phone.
• CallManager facilitates call signaling to
other devices using different protocols
– H.323 for routers
– TAPI/JTAPI for Soft Phones/IP Communicator
Master/Slave Example
• When the Phone goes off-hook, it notifies CM
that the user has gone off-hook.
• CM sends a message to the phone notifying it
play dial tone.
• The phone can not determine when to play dial
tone on its own.
• It is important to understand the roles that both
IP phones and CM play when troubleshooting IP
phones
• Example: Where do you troubleshoot the
problem of delayed dial tone???
Call Processing Behavior
•The Call Processing Behavior can be best explained by
examining The CM trace file
•CM Traces are configured from Cisco Service
configuration.
From the Trace Menu, Select Trace
configuration
Collect the Traces for a Certain
Period of Time
A Sample Trace for a Call Between
Two IP Phones
1. IP phones use the Skinny protocol to
communicate with CallManager
2. All messages to and from a Skinny device are
preceded by either the word StationInit or
StationD.
3. StationInit means that an inbound TCP message
form a Skinny station reached CallManger.
4. Example:
StationInit: 000000004 OffHook
TCP Handle
• The TCP handle represents a unique value that identifies
a specific IP pone registered to this CM Server.
• With The TCP handle, you can follow every message
sent and received from a particular IP phone.
• The TCP handle of a device can also be found by
looking up the IP phone’s MAC Address until you find a
keep alive message to that phone.
• Example: StationInit - InboundStim - KeepAliveMessage
- Send KeepAlive to Device Controller.
DeviceName=SEP000F8F59D304,
TCPHandle=000000004, IPAddr=192.168.1.128,
Port=52952, Device
Controller=[1,92,1]|<CLID::StandAloneCluster><NID::19
2.168.1.140>
Skinny Protocol
• The OffHook message means that CallManger
received a Skinny message indicating the phone
went off-hook
• The next message in the trace file is: StationD:
000000004 StationOutputDisplayText=‘ 40000
‘
• StationD signifies that the CM server is sending
a message to the IP phone.
• Notice that the same TCP handle is listed
• The number 40000 represents the directory
number of the phone.
Other Skinny Messages
• StationD: 000000004 StartTone
tone=33(InsideDialTone) Tells the IP
phone to start plying dial tone.
• CallReference=16777225: The Call
reference ID is created by CM for each
participant in a call and can be used to
track a particular call through a CM Trace
Other Skinny Messages
• StationInit: 000000004 KeypadButton kpButton=4
• StationD: 000000004 StopTone.
• CCM|StationD: 000000004 SelectSoftKeys instance=1
reference=16777225 softKeySetIndex=6
• StationInit: 000000004 KeypadButton kpButton=0
• CCM|StationInit: 000000004 KeypadButton kpButton=0.|
• StationInit: 000000004 KeypadButton kpButton=0.
• StationInit: 000000004 KeypadButton kpButton=4
• Note: digit * shows as e and a # shows as f
• StationD: 000000004 SelectSoftKeys instance=1
reference=16777225 softKeySetIndex=8
Other Skinny Messages
• Call Manger is constantly analyzing the
digits the user dials, and once it finds an
exact match, digit analysis returns the
results for the match.
• Now is the time to ring the CIPC phone
which is configured with DN 40004.
• The Call Routing Chapter will provide
additional details on how digit analysis
wok in CM
Other Skinny Messages
• Because CM has collected all the required digits, it is
ready to notify the destination IP phone there is an
incoming call.
• StationD: 000000005 CallState callState=4
lineInstance=1
• StationD: 000000005 CallInfo callingPartyName='Wael
Yousif' callingParty=40000 cgpnVoiceMailbox=
calledPartyName='' calledParty=40004
• callReference=16777226
• StationD: 000000005 SetRinger
ringMode=2(InsideRing)
• StationD: 000000005 DisplayPriNotify
timeOutValue=10 pri=5 notify='€40000' content='From
40000'
Other Skinny Messages
• Notice that the CIPC phone has a different
TCP handle (was assigned during
registration)
• Also, notice that the CIPC phone has a
different CallReference ID
• The CIPC phone now starts to ring
displaying the calling party name and
extension number
Other Skinny Messages
• The following messages perform two functions: First,
the display on the IPP changes to indicate that the call is
in progress. Second, the phone is told to play the
ringback tone which you hear when you place a call
• StationD: 000000004 CallState callState=12
lineInstance=1
• StationD: 000000004 CallInfo callingPartyName='Wael
Yousif' callingParty=40000 cgpnVoiceMailbox=
calledPartyName='' calledParty=40004
• StationD: 000000004 StartTone tone=36(AlertingTone),
The CIPC Answers the Call
• StationInit: 000000005 SoftKeyEvent
softKeyEvent=11(Answer) lineInstance=1
• The above message is equivalent to the
“StationInit OffHook” message in the case
where the called phone is another IPP.
• The preparation is now complete for the
actual media connection
Audio Stream Setup
• Skinny uses Real Time Transport Protocol (RTP)
over User Datagram Protocol (UDP) packets to
send and receive Voice Over IP samples.
• Each RTP stream is called a logical Channel.
• A Logical Channel is a Unidirectional RTP
stream,
• To Have a two-way conversation, you must have
two logical channels opened; one from the
calling device to the called device and one from
the called device to the calling device.
Audio Stream Setup
• In the following section you can see how CM asks the IP
phone to open a connection to receive RTP streams.
• You can also see how that CM asks the IP phone for
specific parameters, including the codec and packet
size.
• StationD: 000000004 OpenReceiveChannel
conferenceID=0 passThruPartyID=1000091
millisecondPacketSize=20
compressionType=4(Media_Payload_G711Ulaw64k)
qualifierIn=?. myIP: 8001a8c0
(192.168.1.128)|<CLID::StandAloneCluster><NID::192.1
68.1.140><CT::1,100
Audio Stream Setup
• Upon receiving an OpenReceiveChannel
message, the I phone selects the UDP
port number it wants to use to receive RTP
packets and reports this information back
to the CM in an
OpenReceiveChannelAck message.
• StationInit: 000000004
OpenReceiveChannelAck Status=0,
IpAddr=0x8001a8c0, Port=17198
Audio Stream Setup
• The same handshake of “OpenReceiveChannel”
and “OpenReceiveChannelAck” is done at the
called phone.
• When CM receives the OpenReceiveChannelAck
from the CIPC phone, containing the UDP port
number, it forwards this information to the calling
phone in a StartMediaTransmission message
• StationInit: 000000005 OpenReceiveChannelAck
Status=0, IpAddr=0xf001a8c0, Port=24600
• StationD: 000000004 StartMediaTransmission
conferenceID=0 passThruPartyID=1000091
remoteIpAddress=f001a8c0(192.168.1.240)
remotePortNumber=24600
milliSecondPacketSize=20
compressType=4(Media_Payload_G711Ulaw64k)
Audio Stream Setup
• At this point the two phones are sending
RTP messages to each other.
• Notice that for the duration of this call, the
two phones never have sent nor received
any Skinny signaling to or from each other.
• This is because all the signaling goes
through CM
• The only time IP phones send packets to
each other is for the actual Voice Stream.
Labs
• CCM Traces
• Challenge Lab: Capture The Call Setup
and Media Transport Processes using
Ethereal