Enterprise Video Session for CiscoLive 2013

Transcription

1

2 Enterprise Video Session for CiscoLive 2013 Session ID Start Time Title TECEVT-2981 Sunday, 08:00 Architecture for Interactive Video Communication LTREVT-2301 Sunday, 08:00 TelePresence Integration Lab - The Next Generation of Collaboration Solutions Monday, 08:00 Troubleshooting TelePresence Call Failures BRKEVT-2800 Monday, 10:00 Overview of Cisco TelePresence Solution and Deployments BRKEVT-2801 Monday, 13:00 Cisco TelePresence: best practices for call control integration LTREVT-2300 Monday, 13:00 Enterprise Medianet: Video Applications and Network Design Lab COCEVT-3431 Tuesday, 08:00 Inside Cisco IT: Offering Video as an IT Service...How to Fund, Justify and Enable BRKEVT-2311 Tuesday, 08:00 Network Design and Implementation for IP Video Surveillance BRKEVT-2807 Tuesday, 12:30 Enterprise Video Network Performance Analysis with Medianet BRKEVT-2812 Tuesday, 15:00 Bringing Webex meetings and Telepresence together - WebEx TelePresence Integration BRKEVT-2810 Wednesday, 08:00 Deploying Jabber Video for TelePresence(Movi) BRKEVT-2806 Wednesday, 13:30 Troubleshooting Network Impairments in Enterprise TelePresence Deployments BRKEVT-2803 Wednesday, 16:00 Designing and Deploying Multipoint Conferencing for TelePresence Video BRKEVT-2813 Wednesday, 16:00 Using Video Analytics to Improve Safety, Security, and Business Intelligence BRKEVT-2802 Thursday, 08:00 Deploying TelePresence and Video Endpoints on Unified Communications Manager COCEVT-3432 Thursday, 08:00 Inside Cisco IT: Do's, Don'ts and Lessons Learned during 5 Years of Video Deployment BRKEVT-2811 Thursday, 10:00 Deploying TelePresence & Video endpoints COCEVT-3430 Thursday, 10:00 Inside Cisco IT: Video Interoperability...Not Just a Dream BRKEVT-2815 Thursday, 12:30 Medianet Traffic and Device awareness for intelligent services (2) BRKEVT-2319 Thursday, 16:00 Business to Business Video 2

3 Troubleshooting TelePresence Call Failures Paul Anholt Customer Support Engineer Unified Communications Technical Leadership Team

4 A Problem well stated is a problem half solved Charles Kettering

5 Agenda Signaling Protocols Overview Media Protocols Overview Case Studies Questions and Answers 5

6 Signaling Protocols Overview

7 SIP Session Initiation Protocol (SIP) is an IETF defined protocol by RFC 3261 used for controlling voice and video sessions containing one or more media streams. SIP is an application layer protocol which runs over TCP or UDP, typically using ports 5060 (unencrypted) or 5061 (TLS encrypted). SIP is similar in design to HTTP s request/response model where every transaction consists of a client request and a server response. SIP also reuses many of the HTTP header fields, encoding, and response codes resulting in a readable text based format. SIP uses the Session Description Protocol (SDP) to negotiate media parameters such as codecs, IP addresses and port numbers. 7

8 SIP Terminology UA User Agent. A logical network endpoint used to create or receive SIP messages. A UA may perform either the UAC or the UAS role. UAC User Agent Client. A UA which sends requests and expects responses. UAS Use Agent Server. A UA which receives requests and generates responses. B2BUA Back to back user agent. A logical network element which operates between both UAs by dividing the call into two legs and mediating SIP signaling between both call legs. The B2BUA will perform the UAS role on the originating side, and the UAC role on the destination side. 8

9 SIP Requests Request Description Defined In INVITE Indicates the recipient is invited to a session RFC 3261 ACK Confirms the that the client received a final response to an INVITE request RFC 3261 BYE Terminates the session RFC 3261 CANCEL Cancels any request in progress RFC 3261 REFER Asks the recipient to issue a SIP request RFC 3515 REGISTER Registers the address in the To header with the SIP server RFC

10 SIP Requests Continued Request Description Defined In OPTIONS Queries the capabilities of servers RFC 3261 SUBSCRIBE Subscribes to events from the notifier RFC 3265 NOTIFY Notifies the subscriber of events RFC 3265 PUBLISH Publishes an event to the server RFC 3903 INFO UPDATE Send information which does not modify the session Modifies the state of a session without changing the dialogue RFC 6086 RFC

11 SIP Responses Provisional (1XX) Success (2XX) Redirection (3xx) 100 Trying The server has received and will begin processing the request. 180 Ringing The destination user agent (UA) has received the INVITE, and the user is being alerted of the call. 200 OK Indicates the request was successful. 302 Moved Temporarily Instructs the requesting client to retry the response using the address in the contact header. 183 Session Progress Used to send extra information while the call is still being set up. 11

12 SIP Responses Continued Client Failure (4XX) 400 Bad Request The client could not understand the request. 401 Unauthorized The request requires user authentication. Sent by UAS s and Registrars. 404 Not Found The user does not exist at the domain in the request URI. 405 Method not allowed The method is understood, but not allowed. 407 Proxy Authentication Required The request requires user authentication. Sent by proxy servers 422 Session Interval Too Small The session expires interval in the request is too small. 480 Temporarily Unavailable Callee is currently unavailable 481 Call/Transaction does not exist The server received a request for a call that does not exist. 482 Loop Detected The server detected a loop. 486 Busy Here Callee is busy. 487 Request Terminated The request has been terminated by a BYE 12

13 SIP Responses Continued Server Failure (5XX) 500 Server Internal Error Server encountered an unexpected error and could not process the request 503 Service Unavailable The server is not able to fulfill the request. 504 Gateway Timeout The server did not receive a timely response from another server. Global Failure (6xx) 604 Does not exist anywhere The called party does not exists anywhere within the network. 13

14 SIP Headers Header To From Description Defines the logical recipient of the request. Identifies the logical identity of the sender of the request Call-ID Contact Via A unique identifier to group a series of related messages Contains an address where the sending UA can be reached for future requests. Indicates the transport used for the session, and indicates where to send responses. 14

15 Session Description Protocol Session Description Protocol (SDP) is used by SIP to negotiate parameters of an RTP session. Parameters include IP addresses, listening ports, and codec negotiation. Codec negotiation occurs in two steps: the offer and the answer. The Offer/Answer exchange comes in two flavors: early offer where SDP is contained in the INVITE and 200 OK, and delayed offer there the SDP is contained in the 200 OK and ACK. 15

16 Session Description Protocol Session Parameters Audio Parameters Video Parameters BFCP Parameters 16

17 SIP Early Offer Call Flow INVITE (SDP Offer) Side A SIP Proxy Side B 100 TRYING INVITE (SDP Offer) 180 RINGING 200 OK (SDP Answer) 180 RINGING 200 OK (SDP Answer) ACK ACK RTP RTP 17

18 SIP Delayed Offer Call Flow Side A SIP Proxy Side B INVITE 100 TRYING INVITE 180 RINGING 200 OK (SDP Offer) 180 RINGING 200 OK (SDP Offer) ACK (SDP Answer) RTP ACK (SDP Answer) RTP 18

19 SIP B2BUA Early Offer to Delayed Offer Call Flow Side A B2BUA Side B INVITE (SDP Offer) 100 TRYING INVITE 180 RINGING 200 OK (SDP Answer) ACK (SDP Answer) 180 RINGING 200 OK (SDP Offer) ACK RTP RTP 19

20 SIP B2BUA Delayed Offer Call Flow Side A B2BUA Side B INVITE ACK (SDP Answer) 100 TRYING 180 RINGING 200 OK (SDP Offer) INVITE ACK (SDP Answer) 180 RINGING 200 OK (SDP Offer) RTP RTP 20

21 SIP Session Timers RFC 3261 does not define a keep alive interval for SIP sessions While SIP UA s may be able to determine whether a session has failed, intermediary proxies, B2BUA s, and ALGs may not be able to do so. RFC 4028 was drafted to define a keep alive mechanism for SIP sessions. RFC 4028 defines two new header fields: Session Expires and Min-SE, and a new response: 422 Session Interval too small. RFC 4028 recommends a session expires interval of 1800 seconds. 21

22 SIP Session Timer Terminology Session Interval The Maximum amount of time that can occur between session refresh requests before the session will be considered timed out. Minimum Timer The lowest session interval which a UA is willing to accept. Session Expiration - The time at which an element will consider the session timed out, if no successful session refresh transaction occurs beforehand. Session Refresh Request An Invite or an Update sent according to the rules of RFC If the request returns a 200 response, then the session expiration is increased to the current time plus the session interval contained in the response. 22

23 SIP Session Timer Operation 1. A UAC starts by sending an INVITE which includes a supported header field with the option tag timer indicating RFC 4028 support. 2. Any proxy interested in establishing a session timer may insert a Session- Expires and Min-SE header field into the request if none is present, or alter the existing values. 3. Any proxy may reject the request if the session interval is too low with a 422 response which contains it s Min-SE value, and the UAC may retry the session using this value. 23

24 SIP Session Timer Operation Continued 4. After all the Invite/422 iterations are completed the UAS will receive the Invite and may modify the session interval as if it were a proxy. 5. The final session expires interval is inserted into the Session-Expires header of 200 response, along with a refresher parameter indicating who will be responsible for refreshing the session. 6. As the 200 response travels through the proxy chain the proxies may observe, but not modify the value. 7. The UAC knows if a session timer is active from the Session-Expires header in the response, and generate an Invite or an Update to refresh the session. 24

25 H.323 H.323 is a recommendation defined by the ITU Telecommunications standards sector (ITU-T) which defines protocols to provide audio visual communications over an IP network. H.323 addresses all call signaling and control, media transport and control, and bandwidth control. The main protocols covered by H.323 are H.225, used for call setup, and H.245 used for call media. H.225 is sent over TCP Port 1720, H.245 is sent over a dynamically negotiated TCP port. 25

26 H.323 Terminology Terminal A device such as an IP Phone or Video Conferencing endpoint which implements the H.323 protocol stack. Multipoint Control Unit (MCU) An entity that is responsible for managing multipoint conferences. Gateway A device that enabled communication between H.323 networks and other networks such as ISDN. Gatekeeper An entity which provides services such as endpoint registration, address resolution, admission control, and user authentication to terminals gateways and MCUs. 26

27 H.225 Messages Message SETUP PROCEEDING ALERTING CONNECT FACILITY RELEASE COMPLETE Description Sent by caller to initiate an H.323 call. Contains callers H.245 address. Indicates that the setup message has been received and will begin to be processed. Informs the caller that the end user is being alerted of the call. Indicates the callee has accepted the call, and contains the callee s H.245 address. Used to signal call redirection (call transfer). Message sent by a terminal to indicate the release of a call. 27

28 H.245 Messages Message Description Acknowledgement TCS MSD OLC CLC Terminal Capability Set: Contains information about which codecs the terminal is capable to send and receive. Master Slave Determination: Used to elect a master and slave for a session. Open Logical Channel: Indicates the codec, listening IP, and listening RTP/RTCP port for an RTP stream. Close Logical Channel: Indicates the logical channel is to be closed. TCS ACK MSD ACK OLC ACK Contains remote IP and Port information CLC ACK 28

29 H.323 Call Flow H.225 H.245 Side A SETUP TCS TCS ACK MSD ACK MSD OLC OLC ACK RTP Side B PROCEEDING ALERTING CONNECT TCS ACK TCS MSD MSD ACK OLC ACK OLC RTP H.245 H

30 Interworking H.323 to SIP SETUP H.323 IWF SIP PROCEEDING INVITE ALERTING CONNECT 180 RINGING 200 OK (SDP Offer) TCS ACK TCS OLC ACK OLC RTP TCS (SDP Offer) TCS ACK ACK (SDP Answer) OLC OLC ACK RTP 30

31 Interworking SIP Early Offer to H.323 INVITE (SDP Offer) RTP SIP IWF H TRYING 180 RINGING SETUP TCS (SDP Offer) TCS ACK ACK (SDP Answer) OLC OLC ACK PROCEEDING ALERTING CONNECT TCS ACK TCS OLC ACK OLC RTP 31

32 Interworking SIP Delayed Offer to H.323 SIP INVITE IWF H TRYING ACK (SDP Answer) RTP 180 RINGING SETUP TCS ACK 200 OK (SDP Offer) TCS (SDP Answer) OLC ACK OLC PROCEEDING ALERTING CONNECT TCS TCS ACK OLC OLC ACK RTP 32

33 Questions

34 Agenda Signaling Protocols Overview Media Protocols Overview Case Studies Questions and Answers 34

35 TIP TelePresence Interoperability Protocol TIP was developed by Cisco and is now managed by the International Multimedia Telecommunications Consortium (IMTC). TIP was designed to allow a multiscreen endpoint to send a multiplex of video or audio sources across a single RTP stream, and allow the receiver to correctly demultiplex the stream and play the media to the intended destination. TIP support is signaled in SIP by the x-cisco-tip tag in the contact header, and is negotiated in the RTP channel via RTCP App packets. A SIP REINVITE is sent after successful TIP negotiation to reflect the correct bandwidth utilization for the session. 35

36 TIP TelePresence Interoperability Protocol Left Center Right Video RTP Multiplex Right Center Left Left Center Right Audio RTP Multiplex Right Center Left 36

37 DTMF Dual Tone Multi Frequency (DTMF) signaling comes in two flavors: in band and out of band (OOB), and a compatible method must be negotiated end to end for an optimal call experience. In band Tones are encoded into, and transported within the audio RTP stream using the negotiated audio codec. OOB Tones are carried separately from the encoded audio. The out of band DTMF signaling method is negotiated in SIP or H.245, and the methods commonly used in TelePresence calls are: H.245 Alphanumeric H.245 Signal KPML (SIP) RFC

38 Content Sharing Content sharing is accomplished by negotiating a separate shared video channel at call setup which is commonly referred to as an auxiliary or aux video channel. A separate protocol is used to manage which device may transmit onto the shared channel. SIP calls use BFCP H.323 calls use H.239 TIP endpoints use Auto Collaborate VCS can interwork H.239 to BFCP, but no interworking is available for Auto Collaborate. 38

39 Content Sharing TelePresence Server TX/CTS Software TC-Software TX/CTS Software Auto Collaborate Auto Collaborate BFCP TC-Software (H.323) H.239 BFCP Interworked H.239 to BFCP Interworked TC-Software (SIP) BFCP BFCP BFCP to H.239 Interworked 39

40 Interworking H.239 to BFCP H.239 IWF BFCP presentationtokenrequest presetationtokenresponse(ack) bfcpfloorrequest bfcpfloorrequeststatus (GRANTED) presentationtokenindcateowner OLC (Aux Video) OLC ACK miscindication (ACTIVE) RTP (Aux Video) 40

41 Interworking BFCP to H.239 BFCP IWF H.239 bfcpfloorrequest bfcpfloorrequeststatus (GRANTED) presentationtokenrequest presetationtokenresponse(ack) presentationtokenindcateowner OLC (Aux Video) OLC ACK RTP (Aux Video) miscindication (ACTIVE) 41

42 Product Protocol Support Overview SIP H.323 TIP H.239 BFCP 2833 KPML H.245 OOB DTMF TPS X CTS/TX X X X TC Software * X UCM ** ** ** VCS X CTMS X X X X *TIP Support on TC Software is limited to CTMS calls only ** Current design guides recommend against having H.323 signaling on the UCM 42

43 Questions

44 Agenda Signaling Protocols Overview Media Protocols Overview Case Studies Questions and Answers 44

45 Case study #1 Non Immersive Experience The problem: A TX9000 unit from Company A calls into a conference on an TelePresence server hosted by Company B. The call connects, but the users from Company A in the TX9000 room only see video on the center screen and the users a Company B only see the active TX9000 segment. Intercompany connectivity is achieved by Company A via a CUBE. Intercompany connectivity is achieved by Company B via a VCS-Expressway. 45

46 Case study #1 Call Flow CUBE VCS-E VCS-C UCM SIP Signaling Path TX9000 Media Path EX90 TPS 46

47 Case study #1 Expected Outcome TX9000 UCM CUBE VCS TPS Invite (SDP) Invite Invite Invite 200 OK(SDP) 200 OK(SDP) 200 OK(SDP) 200 OK(SDP) ACK (SDP) ACK (SDP) ACK (SDP) ACK TIP TIP Reinvite (SDP) 200 OK(SDP) ACK Multiplexed RTP Multiplexed RTP 47

48 Case study #1 Action Plan Potential Cause: The TX9000 is only sending a single audio and video stream rather than a multiplexed stream indicating an issue with TIP negotiation. Confirmation Plan: Review TX9000 logs for TIP related issues. 48

49 Case study #1 Data Analysis TX9000 Sysop Logs :05:41: INFO Local user dialing :05:43: INFO Main Video negotiated Frame Rate is 30fps :05:45: INFO BFCP Status: Negotiated :05:45: INFO Center Encoder Resolution is: 1280x :05:45: INFO Left Encoder Resolution is: 1280x :05:45: INFO Right Encoder Resolution is: 1280x :05:45: INFO CTS is in an interop call and is not using TIP or MUX. This confirms that TIP was not negotiated. TIP support is signaled within SIP by the x-cisco-tip tag in the contact header. Perhaps the contact header is being altered between the TX9000 and the TelePresence server. Lets inspect the SIP Signaling received by the TelePresence server. 49

50 Case study #1 Data Analysis INVITE SIP/2.0 Via: SIP/2.0/TCP :5060;branch=z9hG4bK2C146C From: To: Date: Mon, 08 Apr :22:15 GMT Call-ID: Supported: timer,resource-priority,replaces,sdp-anat User-Agent: Cisco-SIPGateway/IOS-12.x Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Contact: Expires: 180 Allow-Events: telephone-event Content-Length: 0 TX9000 SIP Invite The x-cisco-tip tag is in fact missing from the INVITE that the TPS received. This would explain the problem. The INVITE also has an interesting User-Agent field which says Cisco IOS which could indicate that the CUBE is stripping the tag from the contact header. Time to check out the CUBE. 50

51 Case study #1 Isolate the protocols On the CUBE we ran debug ccsip messages and by comparing the INVITE coming into the CUBE to the INVITE coming out of the CUBE we confirmed our suspicions that the CUBE was in fact stripping the x-cisco-tip tag. The resolution was to capture the x-cisco-tip tag if it was present in the initial INVITE and insert it back upon egress. CUBE configuration changes are below: voice class sip-profiles 1 request INVITE peer-header sip Contact copy "(;x-cisco-tip)" u01 request INVITE sip-header Contact modify "$" "\u01! voice class sip-copylist 1 sip-header Contact! voice service voip sip sip-profiles 1 copy-list 1 51

52 Case study #2 Voice calls fail to connect The symptom: Jane is hosting a video call on her EX90 and wishes to add in Bob as an audio participant. When she calls Bob s desk phone it rings, but when Bob answers the phone the call fails to connect. Jane is registered to a VCS with a neighbor zone to a UCM Cluster. Bob is registered to a separate UCM Cluster with a trunk connecting to Cluster A. The trunk between the clusters is limited to G.729 with transcoding resources available if required. Users directly registered to Cluster A are able to make calls to Cluster B. Jane can add make audio calls to phones registered to cluster A. 52

53 H.323 SIP Case study #2 Call Flow VCS UCM Cluster A UCM Cluster B SIP SIP Transcoder Transcoder G.729 SIP Working Working EX90 Cluster A Phone Not working Cluster B Phone 53

54 Case study #2 Expected Outcome EX90 VCS UCM A UCM B Phone SETUP Invite Invite Invite CONNECT TCS TCS ACK TCS TCS ACK OLC 200 OK(SDP) 200 OK(SDP) 200 OK(SDP) ACK (SDP) ACK (SDP) ACK (SDP) OLC ACK OLC Transcoder OLC ACK G.711 G.711 G.711 G.729 G

55 Case study #2 Action Plan Potential Cause: EX90 does not have native support for G.729 which is the required codec between Cluster A and Cluster B. The transcoders may not be getting invoked properly to allow the call. Confirmation Plan: Pull UCM Traces or a diagnostic log from VCS and review signaling for abnormalities. 55

56 Case study #2 Data Analysis 200 OK SDP to VCS v=0 o=ciscosystemsccm s=sip Call c=in IP b=tias:8000 b=as:8 t=0 0 m=audio RTP/AVP a=rtpmap:18 G729/8000 a=ptime:20 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp: ACK SDP from VCS v=0 o=tandberg 0 1 IN IP s=c=in IP b=as:5952 t=0 0 m=audio RTP/AVP 101 b=tias:64000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=sendrecv a=rtcp:50139 IN IP

57 Case study #2 State the problem EX90 Does not natively support G.729, therefore a transcoder must be invoked by UCM Cluster A to transcode between G.711 and G.729 to UCM Cluster B. The call is being interworked from H.323 to SIP by the VCS, so UCM Cluster A returns an offer of G.729 for audio and 2833 for DTMF. The VCS does not find a common audio codec and answers with 2833 only, which results in a call failure. How can we configure the VCS to send audio capabilities? 57

58 Case study #2 Brainstorming Solutions Place the call as SIP from the EX90. Then the VCS can send an early offer to UCM Cluster A, allowing it to invoke a transcoder to complete the call. Allow G.711 between Cluster A and Cluster B. Upgrade to TC 6.1 which supports G.729 Configure VCS to send early offer on interworked calls. *c xconfiguration Zones Zone 2 Neighbor Interworking SIP EmptyInviteAllowed: Off *c xconfiguration Zones Zone 2 Neighbor Interworking SIP Audio DefaultCodec: G711u *c xconfiguration Zones Zone 2 Neighbor Interworking SIP Video DefaultCodec: H264 *c xconfiguration Zones Zone 2 Neighbor Interworking SIP Video DefaultBitrate: 768 *c xconfiguration Zones Zone 2 Neighbor Interworking SIP Video DefaultResolution: None 58

59 Case study #3 Abnormal Disconnect The problem: Calls between Jabber for TelePresence users and CTS systems disconnect after approximately 10 seconds. During the ten seconds there is bi-directional audio and video. Jabber stays connected, but indicates that there is no incoming media from the CTS system. There is a firewall between the systems that is configured to allow media traffic. 59

60 Media Case study #3 Call Flow VCS SIP Firewall SIP UCM SIP Media SIP Jabber User CTS 60

61 Case study #3 Abnormal Disconnect Action Plan: Typically it is easier to troubleshoot abnormal disconnects by starting at the BYE and working backwards. Gather logs to determine which device is sending the BYE. Investigate logs from that device to determine the failure. 61

62 Case study #3 Signaling Analysis Jabber VCS UCM CTS INVITE (SDP) INVITE (SDP) INVITE Elapsed Time 0 Seconds 200 OK(SDP) 200 OK(SDP) 200 OK(SDP) ACK (SDP) ACK RTP ACK RTP 1 Second 200 OK INFO 7 Seconds BYE BYE 481 BYE 7 Seconds 15 Minutes 62

63 Case study #3 Data Analysis The signaling flow tells us that the call was torn down shortly after the CTS sent an INFO request. It is also significant to note that the UCM sent a BYE towards the CTS unit, but not towards the VCS side which was torn down after 15 minutes due to session timers. The UCM is not behaving as expected in this situation, so we should take a closer look at the UCM traces for the six seconds between the last ACK and the BYE message that signaled the end of the call. 63

64 Case study #3 Data Analysis UCM Traces 10:33: //SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from on port index 6360 with 863 bytes: [ ,NET] ACK SIP/2.0 10:33: //SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message from on port index 5047 with 907 bytes: [ ,NET] INFO SIP/2.0 10:33: //SIP/SIPTcp/wait_SdlSPISignal: Outgoing SIP TCP message to on port index 5047 [ ,NET] SIP/ OK The ACK from the VCS was received at 10:33: via port The INFO message was received by the UCM at 10:33:43.559, and the UCM sent the 200 OK at 10:33: Lets look to see what happens when the UCM tries to relay the INFO message to the VCS. 64

65 Case study #3 Data Analysis UCM Traces 10:33: //SIP/Stack/Transport/0x0/gConnTab=0xe391dc8, addr= , port=26084, unregistering context=0xb11b1210 2,100,63, ^ ^* 10:33: //SIP/Stack/Transport/0x0/Posting TCP conn create request for addr= , port=5060, context=0xe391dc8 2,100,63, ^ ^* 10:33: //SIP/Stack/Transport/0x0/Wait timer set for connection=0xb1b11e88,addr= , port=5060 2,100,63, ^ ^* The UCM closes the TCP connection on port and attempts to open a new connection on port The UCM then starts a connection timer of 500 milliseconds for the connection to open. Wait Conn Timer started for 5000 msec 2,100,63, ^ ^* 65

66 Case study #3 Data Analysis UCM Traces 10:33: //SIP/Stack/Transport/0x0/Posting TCP conn close for addr= , port=5060, connid=6361 2,100,63, ^ ^* 10:33: //SIP/Stack/Transport/0x0/Deleted conn=0xb1b11e88, connid=6361, addr= , port=5060, transport=tcp 2,100,63, ^ ^* The UCM fails to connect to the VCS over TCP Port 5060 and initiates a call disconnect and tears down the call on the CTS leg. 10:33: //SIP/Stack/Error/0x0/Send Error to :5060 for transport TCP 2,100,63, ^ ^* 10:33: //SIP/Stack/Info/0xb11b1210/Initiate call disconnect(127) for incoming call 2,100,63, ^ ^* 66

67 Case study #3 State the problem UCM fails to connect to the VCS over TCP Port 5060 to deliver a SIP INFO message from the CTS. The UCM then tears down the call leg on the CTS side, causing the Jabber user to stop receiving media until the session expires timer ends the call on the VCS leg. What could prevent the UCM from connecting to the VCS over TCP Port 5060? Root Cause: The firewall had a statement to allow traffic from the VCS to the UCM over TCP Port 5060, but was missing a statement to allow communication from the UCM to the VCS over port

68 Case study #4 Traversal Calls Drop After 30 Minutes The problem: Jane is attempting to make an traversal call to Bob s TX9000 using her TX9000. The call connects successfully, but after 30 minutes the call abruptly disconnects. She is able to reconnect the call, but the call will drop every 30 minutes. Jane s company uses a VCS Control and VCS Expressway for traversal calling. You have administrative access over the UCM, VCS Control, and VCS Expressway, but nothing from Bob s organization. 68

69 Case study #4 Call Flow UCM VCS-C VCS-E Jane Bob 69

70 Case study #4 Expected Result TX9000 UCM VCS-C VCS-E TX9000 Invite (SDP) Invite Invite Invite 200 OK(SDP) 200 OK(SDP) 200 OK(SDP) 200 OK(SDP) ACK Invite (SDP) ACK 200 OK(SDP) ACK (SDP) ACK (SDP) ACK (SDP) Invite (SDP) Invite (SDP) Invite (SDP) 200 OK (SDP) 200 OK (SDP) 200 OK (SDP) 15 mins ACK ACK ACK 70

71 Case study #4 Action Plan Potential Cause: Calls are disconnecting after 30 minutes with is the default session expires interval for UCM. Its possible that the session was not refreshed properly, and this is the cause of the call drop. Action Plan: Pull UCM Traces and check whether the sessions were refreshed after 15 minutes. 71

72 Case study #4 UCM Trace Analysis The UCM traces showed that the session was not refreshed on the call leg towards the VCS. After 30 minutes the error message below was logged, and then the UCM tore down the call leg towards the VCS :04: AppInfo SIPCdpc(297) - star_sipsessionexpiresrefreshtimer: SIPSessionExpiresRefreshTimer pops up at [active] :04: AppInfo SIPCdpc(297) - star_sipsessionexpiresrefreshtimer: RefreshReq not rcvd 72

73 Case study #4 Action Plan Potential Cause: The UCM traces showed that the call was dropped because the UCM did not receive a reinvite after 30 minutes from the called side to refresh the session. Now we must investigate why the UCM did not receive the refresh. Action Plan: Pull the diagnostic logs from the VCS Expressway to see whether the reinvite was received there. 73

74 Case study #4 VCS Expressway Log Analysis VCS Control VCS Expressway Bob INVITE (SDP) INVITE (SDP) 200 OK (SDP) 200 OK (SDP) ACK ACK 407 Proxy Auth Required INVITE (SDP) 15 Mins INVITE (SDP) BYE ACK 407 Proxy Auth Required BYE 15 Mins 74

75 Case study #4 VCS Expressway Log Analysis The VCS Diagnostic logs show that Bob s TX9000 did send a reinvite to refresh the session, but received a 407 Proxy Authentication Required when the VCS Expressway sent the Invite to the VCS Control. Bob s TX9000 was not able to respond to this 407, so the call was dropped after another 15 minutes by the UCM. The traversal zone on the VCS Control is set to check credentials and changing this setting is not an option, so we must figure out why the VCS Control is challenging the reinvite in the first place. 75

76 Case study #4 Action Plan Potential Cause: The zone level authentication policy on the VCS Control s traversal zone is set to check credentials, but the VCS will not challenge requests from outside of its local domains. Something in the reinvite could be causing the VCS to believe that the request is coming from a local domain. Action Plan: Compare the invite received by the VCS Control to refresh the session to the initial invite used to set up the session. 76

77 Case study #4 Initial Invite INVITE SIP/2.0 Call-ID: CSeq: 101 INVITE Contact: From: To: Expires: 180 Date: Mon, 22 Apr :15:10 GMT Session-Expires: 1800 Min-SE: 1800 P-Asserted-Identity: 77

78 Case study #4 Refresh Invite INVITE SIP/2.0 Call-ID: CSeq: 501 INVITE Contact: From: To: Supported: replaces,timer,gruu,path,outbound Require: timer Session-Expires: 1800;refresher=uac Min-SE:

79 Case study #4 State the problem Traversal calls are dropping after 30 minutes because the VCS-Control is challenging the invite sent by the called party to refresh the session. The VCS Control is challenging the invite because the called party is inserting the VCS Control s IP address in the From header of the invite based off of the To header in the initial invite. The UCM is interpreting the dial string as a telephone number because it is numeric, therefore the UCM is setting the to header based off of what is configured in the destination target of the SIP trunk to the VCS. 79

80 Case study #4 Brainstorming Solutions Change the Dial String Interpretation setting to Always treat all dial strings as URI addresses on the calling device s SIP Profile. Append some sort of alphanumeric prefix or suffix to the dial string Jane uses to call Bob, then use a transform to strip it off at the control. Change the trunk target on the UCM to the hostname of the VCS. Create a LUA script to change the To header on outgoing SIP requests to the VCS and apply it to the trunk on the UCM. 80

81 Agenda Signaling Protocols Overview Media Protocols Overview Case Studies Questions and Answers 81

82 Complete Your Online Session Evaluation Give us your feedback and you could win fabulous prizes. Winners announced daily. Receive 20 Cisco Daily Challenge points for each session evaluation you complete. Complete your session evaluation online now through either the mobile app or internet kiosk stations. Maximize your Cisco Live experience with your free Cisco Live 365 account. Download session PDFs, view sessions on-demand and participate in live activities throughout the year. Click the Enter Cisco Live 365 button in your Cisco Live portal to log in. 82

83

84 Appendix

85 DTMF Details

86 RFC 2833 RFC 2833 is negotiated as part of the capabilities exchange during a SIP or H.323 call as a second RTP Payload type, typically 101, inside the audio RTP stream. H.245 SDP 86

87 H.245 DTMF Signaling There are two methods to signaling DTMF within H.245: H.245 Alphanumeric, and H.245 Signal. Support for each method is advertised within a TCS. H.245 Alphanumeric capability Digit 1 Pressed 87

88 H.245 DTMF Signaling Continued Note that H.245 Alphanumeric only carries information on the digit pressed, and H.245 Signal includes the duration of the tone. H.245 Signal capability Digit 1 Pressed 88

89 SIP KPML DTMF Signaling Key Press Markup Language (KPML) is the method used within SIP to transmit DTMF signaling via SIP SUBSCRIBE and NOTIFY Messages. If KMPL is in use for the session, the Unified CM would send a SUBSCRIBE message to the endpoint, and the endpoint will send NOTIFY messages for each key press. 89

90 SIP KPML DTMF Subscribe 90

91 SIP KPML DTMF Notify 91

92 Data Collection

93 TX / CTS SIP Logging TX / CTS Software allows for viewing of the SIP Signaling logs directly from the GUI which has the ability to group all of the SIP signaling that occurred during a call, and allows to filter by message type. These logs are enabled by default and the steps to access these logs are below: 1. Click Log Files 2. Click the SIP Messages tab 1. Click Log Files 2. Click the SIP Messages tab 93

94 TX / CTS Software Log Collection Log onto the GUI and Press the Log Files link. 2. Select the Log Files tab 3. Select the Capture New Log Files Radio Button 4. Press the Capture New Log Files button. 94

95 TX / CTS Software Log Collection Wait for the Log Capture Status to complete. 2. Select the Download Existing Logs radio button. 3. Select the Capture New Log Files Radio Button 4. Press the Download Existing Logs button. 95

96 TX / CTS Software Directories CTS and TX series endpoints software continually logs several processes in a circular fashion onto a fixed amount of storage. The logs are download via the GUI in a tar.gz (tarball) format and a similar tarball from all secondary codecs named logfiles.tsx.local.tar.gz where X indicates the codec where the logs belong (2 = Left, 3 = Right, (4 = Presentation). The codec logs are found under the nv folder which contains the following directories: usr Holds persistent settings such as camera configuration, display temperature settings, and network settings as well as the configuration file from the UCM. bootlog Holds the persistent logs from the boot up process as well as historical upgrade logs. log Holds the log files from the individual processes. 96

97 TX / CTS Software Process Log Descriptions All of the process logs are held in nv/log in their corresponding directories. Not all of the directories are very useful for troubleshooting issues. The most useful ones are described below. bfcp logs releated to bfcp bel Logs related to peripherals. callstats A periodic dump of call media statistics. capture Logs related to the state of the system when the log bundle was collected. cca Logs related to call control. ccacfg Logs related to downloading and parsing the UCM configuration file. cma Logs related to RTP media. cmr Logs related TIP. ctsmcal Logs the communication from the scheduling device. keyexchange Logs related to DTLS. 97

98 TX / CTS Software Process Log Descriptions sip All SIP messages sent and received sysm Kernel logs. sysop Logs a high level overview of the system operations. tsps Logs midlets. uim Logs related to the Touch UI 98

99 TX / CTS Software Packet Capture Creation The TX/CTS Software has the ability to create a packet capture file directly from the admin shell. The command to create a packet capture is utils network capture the usage is shown below: utils network capture - Capture IP Packets SYNTAX: utils network capture [count NUMBER dest WORD file hex host WORD numeric page port NUMBER size NUMBER src WORD] DESCRIPTION: Full usage is available with the command help utils network capture. The capture file is included in the log file bundle under the nv/log/cli folder. 99

100 TC Software Log Collection TC Software logs can be found in the GUI under Diagnostics > Logs 100

101 TC Software Log Collection Continued From the logs section of the GUI you may download individual logs, all log files as a bundle, or historical logs from the periods between the system shuts down. The buttons to download the bundles are located at the bottom. 101

102 TC Software Log Level Adjustment Unlike the CTS/TX Software, the TC Software logging levels may be adjusted from the CLI. The command to adjust the tc software logging levels is log and the usage is shown below: usage: log COMMAND [PARAMETER]... Commands to control message production: ctx [CTX]+ debug N Enable debug level N (1..9) for the context CTX Other commands: list Lists registered contexts output <on/off> Output log to this console. help This help text Parameter: LEVEL - <off debug <level> info notice warning error> CTX - context name (as can be seen from "log list") 102

103 TC Software Log Level Adjustment Examples Example to capture SIP signaling: log ctx sippacket debug 9 Example to capture H.323 signaling: log ctx h323packet debug 9 Example to capture RTP media statistics: log ctx rtpstatistics debug 9 Example to write logging to the console: log output on It is important to only enable logging while troubleshooting an issue. Always remember to set the log level back to 0 or reboot once the desired logs are collected. 103

104 TC Software Packet Capture Collection It is possible to collect a packet capture from the TC Software root shell. The steps are as follows: 1. Enable the root shell if not already enabled by logging into the admin cli and enter the command systemtools rootsettings on password 2. Log out of the admin cli and log back in as root using the password specified in step From the root shell, enter the command tcpdump s 0 w /var/log/capture.pcap not port Capture the desired data and press control-c to stop capturing packets. Do not allow the capture to run for too long. 5. Download the packet capture file from the logs section of the GUI. 6. Remove the packet capture file once successfully downloaded with the command rm /var/log/capture.pcap 104

105 VCS Diagnostic Log Creation The VCS has the ability to start and stop a capture of logs containing signaling, interworking, or both. The logs are created on the GUI by navigating to Maintenance > Diagnostics > Diagnostic Logging 105

106 VCS Diagnostic Log Creation Continued Once in the diagnostics logging page the process is as follows: 1. Set the desired log level to debug 3. Add a marker to easily mark events (optional) Network for signaling messages 4. Press the Stop Logging button Interworking for interworking data 5. Press the Download Log button 2. Press the start new log button. 106

107 VCS System Snapshot Collection Occasionally when working with the TAC a VCS system snapshot will need to be collected. The steps to collect a snapshot are listed below. 1. Navigate to Maintenance > Diagnostics > System Snapshot 2. Click the button Create Full Snapshot, Create Status Snapshot, or Create Logs Snapshot depending upon the type of snapshot requested. 3. Wait for the snapshot to be collected. 4. Download the snapshot from the snapshot section below. 107

108 VCS System Snapshot Collection

109 UCM Trace Level Configuration Out of the box the logging levels on the Unified Communications Manager (UCM) need to be adjusted in order to capture call signaling information. The steps as are follows: 1. Select Cisco Unified Serviceability from the Navigation Dropdown on the UCM GUI. 2. Press Go 3. Enter the Admin credentials to login. 109

110 UCM Trace Level Configuration 1. Select Configuration from the Trace dropdown menu 2. Select the following Items under Server Service Group and Services:: Server: (Publisher Node) Service Group: CM Services Service: Cisco CallManager Apply to All Nodes 3. Set the following Trace Filter Settings: Debug Trace Level: Detailed Enable SIP Stack Trace Enable SIP Call Processing Trace 4. Press Save 110

111 UCM Trace Collection The easiest way to collect the trace files off of the UCM is to use the Real Time Monitoring Tool (RTMT) which is available for download under the Plugins menu off of the Applications Dropdown in the UCM Administration GUI. Press the download link to download and install RTMT for Windows or Linux. 111

112 Collecting CallManager Traces via RTMT 1. Open RTMT and login to the UCM Server. 2. Select Trace & Log Central 3. Select Collect Files 4. Select the All Servers under the Cisco CallManager UCM Service. 5. Press Next, then press next again, selecting nothing on the second page. 112

113 Collecting CallManager Traces via RTMT 1. Select either a relative range or absolute range under collection time. 2. Select a local directory to download the files to. 3. Press Finish 4. RTMT will download all of the files in the specified time range to the specified directory. 113

114 UCM Packet Capture Creation The UCM has the ability to create a packet capture file directly from the admin shell similar to the CTS/TX software. The command to create a packet capture is utils network capture the usage is shown below: utils network capture - Capture IP Packets SYNTAX: utils network capture [count NUMBER dest WORD file hex host WORD numeric page port NUMBER size NUMBER src WORD] DESCRIPTION: Full usage is available with the command help utils network capture. The capture file can be downloaded using RTMT, under the System Service named Packet Capture Logs in the collect files menu. 114

115 TelePresence Server Log Collection The TelePresence server (TPS) provides an event log is useful to provide an at a glance view of system events, as well as an H.323/SIP log to view call signaling. Both logs available for download or viewing directly from the browser under the logs menu. Additionally, the TPS has the ability to create a packet capture file via the console port. The command is nettap and the usage is below: usage: nettap [-a -l -s -h] A B -a : capture all packets (i.e. disable most of filter) -l : disable limit on number of packets captured (160000) stop with Ctrl-C -s : disable 128 byte limit on packet length -h <host> : only capture packets to from <host> Once captured, the packet capture file may be downloaded on the Status page under Network Capture File 115