Friday, August 20, 2010

CTS System - Device names and numbers

TelePresence systems contains different components in the system board to process Video signals, when you go through the logs you will find reference to them, here is the device name and number used:

Video Encoder
Device 0 - Main Camera
Device 2 - PC Video Input (VGA)
Device 4 - Document Camera

At any time only one either Device 2 or Device 4 are active, never both.

Video Decoder
Device 1 - Plasma
Device 3 - Projector Display

Scope ID 15: Primary Video Encoder
Scope ID 16: Primary Video Decoder

Thanks to Shankar  for sharing this 

Tuesday, August 17, 2010

CTS System - SNMP Decode dateandTime

We have a value in our MIB for notifying when an specific call started:

Object ctpcStartDateAndTime

"This object specifies the value of local date and time when a call is started.
 
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&typeName=DateAndTime

This Object has variable type as "DateAndTime". DateAndTime is a standard Textual Convention which is defined in the SNMPv2-TC. DateAndTime is resolved to base data type OCTET STRING. The DISPLAY-HINT format for DataAndTime is given as follows.

DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"

The date-time specification is as follows.


"A date-time specification.

field octets contents range
----- ------ -------- -----
1 1-2 year 0..65536
2 3 month 1..12
3 4 day 1..31
4 5 hour 0..23
5 6 minutes 0..59
6 7 seconds 0..60
(use 60 for leap-second)
7 8 deci-seconds 0..9
8 9 direction from UTC '+' / '-'
9 10 hours from UTC 0..11
10 11 minutes from UTC 0..59

For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
displayed as:

1992-5-26,13:30:15.0,-4:0

Note that if only local time is known, then timezone information (fields 8-10) is not present."


Valid Usage

SnmpVar snmpvar = syntax.CreateVariable("'07:D2:09:03:0C:14:20:03:2B:07:00'");//hex format, length 11 bytes
SnmpVar snmpvar = syntax.CreateVariable("'07:D2:09:03:0C:14:20:03'");//hex format, length 8 bytes
SnmpVar snmpvar = syntax.CreateVariable("2002-9-21,13:53:32.3,-7:0");//string format, length 11 bytes
SnmpVar snmpvar = syntax.CreateVariable("2002-9-21,13:53:32.3");//string format, length 8 byte

Example:

07 DA 08 09 0E 13 31 00 
 
07DA = 2010
08   = August
09   = 9th
0E   = 14
13   = 13 minutes
31   = 31 seconds
00   = deciseconds


The value of year is in network-byte order.

Saturday, August 14, 2010

CTS system - Basic Video quality troubleshooting

High level description


1. Obtain an accurate problem description:
  • Display flickering, snowy
  • Pinkish,greenish,blueish
  • Black Display during loopback as well as during the call
  • Half image, zoom in

  • Other....

Obtain pictures or video when problem is happening
2. Problem details:
• New install, upgrade?
• Reproducible, random
• Start of the call, end of the call, after display is idle?
• Point to point calls?, Multi-point calls?
• Do we have a video or a picture when problem occurs.

• Problem only with one type of unit? Interop ?
• Problem appears after firmware upgrade? Any network changes? 
• Any message during the failure (i.e Network congestion etc.)
• Verify type of Display and generation (CTS 500 GEN2 37", CTS 1000 GEN2 65", etc)
• Obtain app code and boot code:
  - App code, boot code and firmware must be the same on all three displays


Isolating the problem


  • We can try first a loopback with encoder enabled, this will confirm codec itself is not dropping packets
From SSH CLI:
diag display loopback full enable

  • If ICMP is enabled across the path we can use mtr to see which device may be introducing delay, packet loss, etc. 
 utils network mtr count 100 tos  160

Replace 160 for your current QoS marking:

  • Verify Packets sent/receive show proper QoS value and proper policy maps are matched
  • Network devices:
Verify SRND guide to make sure we meet network requirements:



1) ‘show run’ output

In addition, I would suggest collecting the following information to further isolate network traffic:

1)  Interf type x/y <- WAN interface
2) ‘load-interval 30
3) Reproduce problem and keep call up for perhaps 5 mins and then collect
the following information while the call is still up and while packet loss is being seen:

a) ‘show interf intftype x/y’
b) ‘show policy-map interf intftype x/y
c) ‘show queue intftype x/y’

The above should allow us to (a) determine what our guaranteed bandwidth really is (b) determine where we are seeing drops (ex: interface drops vs software queuing drops).

 

Thursday, August 5, 2010

CTS System - DTLS Call analysis

As of now CTS codecs supports 2 methods for securing Media traffic: SRTP and DTLS, in this section we are going to describe DTLS protocol and the way it works with CTS units. This article refers what is needed to enable DTLS it does not cover other security protocols used by CUCM, CTMS or CTS, to obtain more information consult TelePresence security guide in CCO.
http://www.cisco.com/en/US/docs/solutions/Enterprise/Video/telepresence.html#wp41946

DTLS
Datagram Transport Layer Security (DTLS) provides communication security for datagram protocols. DTLS is based on Transport Layer Security (TLS) protocol. This datagram-compatible version of the protocol is specifically designed to be similar to TLS with the minimal amount of changes needed to fix problems created by the reordering or loss of packets. There are two main areas that unreliability creates problems for TLS:
  • The traffic encryption layer does not allow individual packets to be decrypted, there are two inter-record dependencies:


    • Cryptographic context is chained between records
    • A Message Authentication Code (MAC) that includes a sequence number provides anti-replay and message reordering protection, but the sequence numbers are implicit in the records
  • The handshake layer breaks if messages are lost because it depends on them being transmitted reliably for these two reasons:


    • The handshake is a lockstep cryptographic handshake requiring messages to be transmitted and received in a defined order, causing a problem with potential reordering and message loss
    • Fragmentation can be a problem because the handshake messages are potentially larger then any given datagram
The first problem caused by the inter-packet dependencies can be solved by using a method employed in the Secure Internet Protocol (IPsec) by adding explicit state to each individual record.
To solve the issue of packet loss DTLS employs a simple retransmission timer. Figure 1 below illustrates the basic concept. The client is expecting to see the HelloVerifyRequest message from the server. If the timer expires then the client knows that either the ClientHello or the HelloVerifyRequest was lost and retransmits.


In TelePresence solution it does not matter the number of codecs in the system only primary codecs will perform dTLS handshake, IP Phones are not associated in the process. In every TelePresence call two dTLS handhsakes occur, one for each stream (video and audio)

DTLS reuses almost all the protocol elements of TLS with minor but important modifications for it to work properly with datagram transport,

A TLS client initiates the handshake by sending the ClientHello message. This message contains the TLS version, a list of algorithms and compression methods that the client will accept and a random nonce used for anti- replay.
The server responds with The Server- Hello contains the server’s choice of version and algorithms and a random nonce. The Certificate contains the server’s certificate chain. The ServerHelloDone is sim- ply a marker message to indicate that no other messages are forthcoming. In more complicated handshakes other messages would appear between the Certificate and the ServerHelloDone messages.
Then send the ChangeCipherSpec message to indicate that it is changing to the newly negotiated protection suite.