understanding ip phone behavior n.
Skip this Video
Loading SlideShow in 5 Seconds..
Understanding IP Phone Behavior PowerPoint Presentation
Download Presentation
Understanding IP Phone Behavior

Understanding IP Phone Behavior

308 Vues Download Presentation
Télécharger la présentation

Understanding IP Phone Behavior

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Understanding IP Phone Behavior Skinny Client Control Protocol SCCP Prof. Yousif @ Valencia Community College

  2. 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

  3. 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???

  4. 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.

  5. From the Trace Menu, Select Trace configuration

  6. Collect the Traces for a Certain Period of Time

  7. A Sample Trace for a Call Between Two IP Phones • IP phones use the Skinny protocol to communicate with CallManager • All messages to and from a Skinny device are preceded by either the word StationInit or StationD. • StationInit means that an inbound TCP message form a Skinny station reached CallManger. • Example: StationInit: 000000004 OffHook

  8. 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=, Port=52952, Device Controller=[1,92,1]|<CLID::StandAloneCluster><NID::>

  9. 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.

  10. 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

  11. 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

  12. 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

  13. 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'

  14. 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

  15. 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),

  16. 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

  17. 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.

  18. 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 (|<CLID::StandAloneCluster><NID::><CT::1,100

  19. 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

  20. 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( remotePortNumber=24600 milliSecondPacketSize=20 compressType=4(Media_Payload_G711Ulaw64k)

  21. 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.

  22. Labs • CCM Traces • Challenge Lab: Capture The Call Setup and Media Transport Processes using Ethereal