The Cisco TelePresence displays and cameras natively support 1080p resolution and utilize digital media interfaces to connect to the Cisco TelePresence codecs. This ensures the integrity of the video signal from end to end by eliminating the need for any digital/analog conversion.
Inside the Cisco TelePresence codecs an onboard array of Digital Signal Processors (DSPs) encode the digital video signal from the cameras into Real-Time Transport Protocol (RTP) packets using the H.264 encoding and compression standard. The Cisco TelePresence codecs can encode the video from the cameras at 1080p or 720p.
The quality of the video enjoyed by the meeting participants is a function of three variables:
•Resolution (i.e., number of pixels within the image)
•Frame rate (how often those pixels are re-drawn on the display)
•Degree of compression applied to the original video signal
CTS-1000 and CTS-500 systems send only one audio and one video stream (excluding auxiliary audio and video inputs for the moment). On the other hand, CTS-3000 and CTS-3200 primary codecs process three separate audio and three separate video streams. However, these codecs do not send three separate audio streams and three separate video streams over the network. Rather, CTS-3000 and CTS-3200 primary codecs multiplex the three audio streams into one RTP stream and three video streams into one RTP stream, and hence send only a single audio and a single video stream over the network. These streams, in turn, are de-multiplexed by the receiving codec. The multiplexing of audio and video streams performed by the CTS-3000 primary codecs is illustrated below. Auxiliary audio and video inputs are also multiplexed into the same audio and video streams. Therefore, in the case of the CTS-1000 or CTS-500, the primary video and auxiliary video are multiplexed into one outgoing video stream; likewise the primary audio and auxiliary audio are multiplexed into one outgoing audio stream. In the case of the CTS-3000 or CTS-3200, the auxiliary video is treated as the 4th video channel and multiplexed in with the rest of the video; likewise the auxiliary audio is treated as the 4th audio channel and multiplexed in with the rest of the audio.
Cisco TelePresence systems, use for media multiplexing the RTCP extension mechanism, in specific the APP packet, that allows private uses.
For more information of MUX protocol you need to contact Cisco Systems, Inc directly as that information is still not public.
This document allows you to understand the architecture inside a Cisco TelePresence Point to Point call to help you identify the network components that delay or drop RTP or MUX RTP Control Protocol (RTCP) packets..
We define an RTCP APP packets to informs the remote peer of what we are capable of doing with respect to media multiplexing. This includes the number of media streams that an endpoint is willing to transmit and willing to receive for a given media channel of a particular type (audio or video). It also allows the receiver to specify which media positions it is willing to transmit and receive
Most of the RTCP APP extensions described in this document benefit from having an explicit acknowledgment from the receiver. In this section, a generic ACK packet is defined for use with these extensions and any future extensions that may require it. The most significant bit of the RTCP APP subtype is defined to represent an ACK bit. The least significant nibble (4 bits) of the subtype is used to carry the extension identifier of the packet being acknowledged.
The captures you will find in this document show 1 CTS-1000 calling a CTS-500 number (3005 to 3006)
In order to decode the RTCP, decode UDP streams using even port numbers as RTCP.
Use rtcp.app.subtype == (Subtype number in table below) to filter in Wireshark,
sip or ((rtcp.app.subtype == 1) and ( udp.port == rtpport +1 )) (Look for SDP rtp video or audio port and add 1, take a look at RTCP report "Stream setup by SDP packet number to find correct port)
sip or ((rtcp.app.subtype == 1) and ( udp.port == 32543))
Subtypes within the 'xcts' namespace
Contact Cisco for more information about TIP (MUX protocol)
| Subtype | Extension |
| 0 | Reserved |
| 1 | MUXCTRL |
| 2 | Deprecated (Version 2 REFRESH) |
| 3 | Deprecated (Version 2 CONFID) |
| 4 | ECHO |
| 5 | TXFLOWCTRL |
| 6 | RXFLOWCTRL |
| 7 | MEDIAOPTS |
| 8 | REFRESH |
| 9 | Deprecated (Version 3 TUNNEL) |
| 10 | PAUSE |
| 11 | SKIP |
| 12 | SPIMAP |
| 13 | SRVLOC |
| 14 | RETRANSMIT |
| 15 | Unused |
| 16 | Reserved |
| 17 | MUXCTRL ACK |
| 18 | Reserved |
| 19 | Deprecated (Version 2 CONFID ACK) |
| 20 | Reserved for ECHO ACK |
| 21 | TXFLOWCTRL ACK |
| 22 | RXFLOWCTRL ACK |
| 23 | MEDIAOPTS ACK |
| 24 | REFRESH ACK |
| 25 | Unused |
| 26 | PAUSE ACK |
| 27 | SKIP ACK |
| 28 | SPIMAP ACK |
| 29 | SRVLOC ACK |
| 30 | Reserved for RETRANSMIT ACK |
| 31 | Reserved for ACK of subtypes 15 |
Subtypes within the 'xtp1' namespace
Please obtain CTS logs and packet capture (it is included in each logs from here)
Packet captures exist under /nv/log directory.( name will show inverted , 3005.pcap is 3006.pcap and viceversa)
Information:
3005 - 172.16.181.142
3006 - 172.16.181.140
From 3005 log files:
sysop00001.log
2010-05-26 23:34:47: INFO Local user dialing 3006
2010-05-26 23:34:49: INFO Connected to 3006
This is an screenshot of packet capture which contains the first RTCP messages that are negotiated at the beginning of the call.
Note that the sequence of MUXCTRL and MEDIAOPTS exchanges is just an example; several other possibilities exist as each peer’s exchange is independent. It is required that a successful MUXCTRL occur before any other CTS MUX extension, including MEDIAOPTS, is sent
From CMR logs:
cmr00002.log
You will be able to find MUX control messages logged here:
2010-05-26 23:34:49.708: SendRTCPMUXCTRL streamID 57 Xmit RTCP APP MUXCTRL ver 6 profile 0 ntp 14963260998691229330
2010-05-26 23:34:49.708: SendRTCPMUXCTRL streamID 59 Xmit RTCP APP MUXCTRL ver 6 profile 2 ntp 14963260998707030515
2010-05-26 23:34:49.959: ProcessInboundPacket streamID 57, rcv RTCP APP MUXCTRL
2010-05-26 23:34:49.960: ProcessInboundPacket streamID 59, rcv RTCP APP MUXCTRL
In next chapter you will be able to understand every of those message in more detail.
No comments:
Post a Comment