SIP. D50444 revision 1.1

Transcription

1 SIP D50444 revision 1.1 May 2008

2 TABLE OF CONTENTS INTRODUCTION...5 WHAT IS SIP?...6 Components...6 User Agent...6 Proxy Server...6 Registrar...7 Redirect Server...7 Requests for Comments...7 SIP Messages...9 SIP Requests...9 SIP Responses...9 Session Description Protocol (SDP)...11 TANDBERG SIP TERMINALS...12 TANDBERG MXP Endpoints...13 Software F2-F6 SIP Server Interaction...13 F2-F6 Call Flow (Site A calls Site B)...13 F2-F6 Audio...14 F2-F6 Video...14 Jitter and Latency...15 RFC Support...16 TANDBERG MXP Personal Series Endpoints...18 L2-L5 SIP Server Interaction...18 L2-L5 Call Flow (Site A calls Site B)...18 L2-L5 Audio...19 L2-L5 Video...19 Jitter and Latency...19 RFC Support...20 TANDBERG SIP INFRASTRUCTURE...22 TANDBERG MPS 200/ J3-J4 SIP Server Interaction...24 J3-J4 Call Flow (MPS calls Site A)...24 J3-J4 Audio...25 J3-J4 Video...25 Jitter and Latency...25 RFC Support...26 TANDBERG Codian 4500 Series MCU...28 Software 2.2(1.0) SIP Server Interaction...28 Software 2.2(1.0) Call Flow...28 Software 2.2(1.0) Audio...29 Software 2.2(1.0) Video...29 Jitter and Latency...30 RFC Support...30 TANDBERG Codian 4200 Series MCU...31 Software 2.2(1.0) SIP Server Interaction...31 Software 2.2(1.0) Call Flow...31 Software 2.2(1.0) Audio...32 Software 2.2(1.0) Video...32 Jitter and Latency...33 RFC Support...33 D50444 Page 2

3 TANDBERG Codian 3500 Series IP Gateway...34 Software 1.1(1.1) SIP Server Interaction...34 Software 1.1(1.1) Call Flow...34 Software 1.1(1.1) Audio...35 Software 1.1(1.1) Video...35 Jitter and Latency...36 RFC Support...36 TANDBERG 3G Gateway...37 R2-R3 SIP Server Interaction...37 R2-R3 Call Flow (Gateway calls Site A call initiated from 3G side)...37 R1-R3 Audio...38 R1-R3 Video...38 Jitter and Latency...38 TANDBERG Video Portal...39 V2-V3 SIP Server Interaction...39 V2-V3 Call Flow (Video Portal calls Site A call initiated from 3G side)...39 V2-V3 Audio...40 V2-V3 Video...40 Jitter and Latency...40 TANDBERG Content Server...41 S3 SIP Server Interaction...41 S3 Call Flow (Content Server calls Site A)...41 S3 Audio...42 S3 Video...42 Jitter and Latency...42 RFC Support...42 TANDBERG Codian 2200 Series IPVCR...44 Software 2.2(1.0) SIP Server Interaction...44 Software 2.2(1.0) Call Flow...44 Software 2.2(1.0) Audio...45 Software 2.2(1.0) Video...45 Jitter and Latency...46 RFC (Request for Comment) Support...46 TANDBERG Video Communication Server...47 TANDBERG SIP Server Traversal Interaction...47 TANDBERG SIP Server Non-Traversal Interaction...47 TANDBERG VCS Control to VCS Expressway Traversal Interaction...48 TANDBERG VCS Control to VCS Expressway Call Flow...49 STUN Client-to-VCS Expressway Interaction...50 STUN Relay...51 RFC (Request for Comment) Support...51 LIST OF TERMS...52 REFERENCES...54 D50444 Page 3

4 DOCUMENT REVISION HISTORY Rev 1.0 Rev 1.1 Initial Version Minor Revision; Added References D50444 Page 4

5 INTRODUCTION Session Initiation Protocol (SIP) is an application layer protocol for creating, terminating, and modifying of multimedia sessions with one or more participants, developed by the Internet Engineering Task Force (IETF). SIP is independent of the multimedia session handled and of the mechanism used to describe the session. The IETF also designed SIP to be independent of the underlying transport layer. SIP is similar to H.323 and shares some of the same protocols, such as TCP, UDP, and others. With the ascent of the Internet as a rival to the circuit-switched telephony network, a signaling protocol was needed to set up and terminate connections, in order to assimilate telephony services with the technology of IP. A motivating goal for SIP was to provide a signaling and call setup protocol for IPbased communications that can support some of the call processing functions and features present in the public switched telephony network. This document is intended to discuss SIP from both a general and TANDBERG-specific point of view. Varying levels of depth will be included within the document in order to provide a complete view of the technology and how it is implemented. In addition, deployment scenarios will be discussed, such as firewall traversal, and how those deployments will interact with other IP network components (e.g. firewalls). D50444 Page 5

6 WHAT IS SIP? Session Initiation Protocol (SIP) is an application layer IETF standard protocol for initiating interactive user sessions that involve multimedia elements such as video, voice, chant, and others. SIP can establish multimedia sessions, and modify, or terminate them. SIP is based on the Web protocol HTTP, and like HTTP, SIP is a text-based, request-response protocol, utilizing TCP and/or UDP as the transport mechanism for the session messages. The SIP protocol itself is only responsible for establishing a session between two end points of a conversation, utilizing several other protocols to establish the communication services over that connection. Session Description Protocol (SDP), for example, describes the media content of the session, including the audio, video and data capabilities of the endpoint, media ports to be used for connections as well as any other information that would be pertinent to the media connections between the end points Components The SIP protocol defines several entities. Each entity has a specific function and participates in SIP communication as a client (initiates requests), as a server (responds to requests), or as both. One physical device can have the functionality of more than one logical SIP entity. An example, is a network server working as a Proxy server, can also function as a Registrar at the same time. User Agent A User Agent (UA) is an application that interfaces between the user and he SIP network. User Agents initiate and terminate sessions by exchanging requests and responses. User Agents operate in two fashions, but also may function as both. When send SIP messages, the UA acts as a User Agent Client (UAC), and when receiving messages, it acts as a User Agent Server (UAS). User Agent Client (UAC) A User Agent Client (UAC) is an application that initiates SIP requests to a User Agent Server (UAS). A UAC can be a program or a device that interacts with a user. The UAC determines the information essential for the request; the protocol, the port, and IP address of the UAS to which the request is being sent. User Agent Server (UAS) The User Agent Server (UAS) is a server application that accepts the request from a UAC and generates accept, reject, or redirect responses on behalf of the user. Proxy Server SIP Proxy servers are elements that route SIP requests to UAS and SIP responses to UAC. A SIP Proxy server acts as both a UAC and UAS. A request may travel several Proxy servers before it reaches the far end UAC. Each Proxy server will make routing decisions, modifying the request before forwarding it to the next Proxy. Responses will route through the same set of Proxy servers by the requests in reverse order. SIP defines 3 types of Proxy servers: Call Stateful Proxy Call Stateful proxies need to be informed of all SIP transactions and therefore are always in the path taken by SIP messages traveling between users. These Proxy servers store state information from the moment the session is established until the moment it ends. D50444 Page 6

7 Stateful Proxy A Stateful proxy stores state related to a given transaction until the transaction concludes. Forking proxies are good examples of stateful proxies as they send SIP messages to several places and store state about the SIP message transaction until all location have returned a response. Stateless Proxy A Stateless Proxy forgets all information once a request or response has been processed. A stateless proxy forwards every request it receives downstream and every response it receives upstream. Registrar A SIP Registrar contains the location of all UA s within a domain. A Registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents on REGISTER requests. This location service is then queried by a Proxy server that is responsible for that domain. A Registrar is usually co-located with a Proxy server or a Redirect server. Redirect Server A Redirect Server accepts a SIP request, maps the address and returns a list of possible locations to the client that initiated the request. Unlike Proxy Servers, Redirect Servers do not pass the request on to others. Proxy Servers will make subsequent attempts for the user rather than sending new contact info to the user. Requests for Comments Requests for Comments (RFC) documents are a series of memoranda encompassing new research, innovations, and methodologies applicable to Internet technologies. Many RFC s are the standards on which the Internet is formed. The first proposed version of SIP was defined in RFC 2543 and was further defined in RFC Besides the basic specifications, a number of extensions to SIP have been defined in other RFC s and internet drafts. Below are several examples of SIP RFC s and drafts. RFC 1889 RFC 2190 RFC 2327 RFC 2396 RFC 2429 RFC 2617 RFC 2782 RFC 2833 RFC 2976 RFC 3016 RFC 3047 RFC 3261 RFC 3262 RFC 3263 RFC 3264 RTP: A Transport protocol for Real-time Applications RTP Payload Format for H.263 Video Streams SDP: Session Description Protocol Uniform Resource Identifiers (URI): Generic Syntax RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) Digest Authentication DNS RR for specifying the location of services (DNS SRV) RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals The SIP INFO Method RTP Payload Format for MPEG-4 Audio/Visual Streams RTP Payload Format for ITU-T Recommendation G SIP: Session Initiation Protocol Reliability of Provisional Responses in SIP Locating SIP Servers An Offer/Answer Model with SDP D50444 Page 7

8 RFC 3311 RFC 3327 RFC 3361 RFC 3420 RFC 3515 RFC 3550 RFC 3581 RFC 3605 RFC 3711 RFC 3840 RFC 3880 RFC 3890 RFC 3891 RFC 3892 RFC 3944 RFC 3960 RFC 3984 RFC 4028 RFC 4145 RFC 4566 RFC 4568 RFC 4574 RFC 4582 RFC 4583 RFC 4585 RFC 4587 RFC 4629 RFC 4796 UPDATE method SIP Extension Field for Registering Non-Adjacent Contacts DHCP Option for SIP Servers Internet Media Type message/sipfrag Refer method RTP: A Transport Protocol for Real-Time Applications Symmetric Response Routing RTCP attribute in SDP The Secure Real-time Transport Protocol (SRTP) Indicating User Agent Capabilities in SIP Call Processing Language (CPL): A Language for User Control of Internet Telephony Services A Transport Independent Bandwidth Modifier for SDP The SIP "Replaces" Referred-By Mechanism H.350 Directory Services Early Media RTP Payload Format for H.264 Video Session Timers in SIP TCP-Based Media Transport in the SDP SDP: Session Description Protocol SDP: Security Descriptions for Media Streams The Session Description Protocol (SDP) Label Attribute The Binary Floor Control Protocol Format for Binary Floor Control Protocol (BFCP) Streams Extended RTP Profile for RTCP-Based Feedback RTP Payload Format for H.261 Video Streams RTP Payload Format for ITU-T Rec. H.263 Video The Session Description Protocol (SDP) Content Attribute draft-ietf-xcon-bfcp-connection-04.txt draft-levin-mmusic-xml-media-control-03.txt draft-ietf-sipping-cc-transfer-06.txt draft-kristensen-avt-rtp-h264-extension-00.txt D50444 Page 8

9 SIP Messages SIP is a text based protocol; and has well defined messages that are used for communications. There are two types of messages. A SIP message can be either a request from a UAC to an UAS, or a response from a UAS to a UAC. SIP Requests There are several types (methods) of SIP Requests. The most commonly used are listed below. INVITE Indicates a client is being invited to participate in a session (RFC 3261) ACK Confirms that the client has received a final response to s request (RFC 3261) BYE Terminates a session (RFC 3261) CANCEL Cancels any pending searches but does not terminate any sessions accepted (RFC 3261) OPTIONS Queries the capabilities of servers (RFC 3261) REGISTER Registers the address listed in the To header field with a SIP server (RFC 3261) PRACK Provisional Acknowledgement (RFC 3262) SUBSCRIBE Subscribes for an event of Notification from the Notifier (RFC 3265) NOTIFY Notify the subscriber of a new Event (RFC 3265) PUBLISH Publishes a Event to the server (RFC 3903) INFO Sends mid-session information that does not modify message state (RFC 2976) REFER Ask recipient to issue SIP request (call transfer) (RFC 3515) MESSAGE The MESSAGE is used to transport instant messages using SIP (RFC 3428) UPDATE SIP Responses The UPDATE method is used to modify the state of a session with out changing the state of the dialog (RFC 3311) SIP Response messages contain numeric response codes. The SIP response code set is partly based on HTTP response codes. There are six classes of response: 1xx Informational Responses 100 Trying: Extended search being performed Ringing Call Is Being Forwarded Queued Session Progress D50444 Page 9

10 2xx Successful Responses 200 Ok 202 Accepted 3xx Redirection Responses 300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 305 Use Proxy 380 Alternative Service 4xx Client Failure Responses 400 Bad Request 401 Unauthorized 404 Not Found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout 409 Conflict 412 Conditional Request Failed 413 Request Entity Too Large 414 Request URO Too Long 415 Unsupported Media Type 420 Bad Extension 480 Temporarily Unavailable 481 Call/Transaction Does Not Exist 482 Loop Detected 483 Too Many Hops 484 Address Incomplete 485 Ambiguous 486 Busy Here 487 Request Terminated 488 Not Acceptable Here D50444 Page 10

11 5xx Server Failure Responses Server Internal Error Not Implemented: The SIP request method is not implemented Bad Gateway Service Unavailable Server Time-out SIP Version Not Supported Message Too Large Precondition Failure 6xx Global Failure Responses Busy Everywhere Decline Does Not Exist Anywhere Not Acceptable Session Description Protocol (SDP) SDP (RFC 4566) is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP does not provide the content of the media form itself but simply provides a negotiation between two end points to allow them to agree on a media type and format. An SDP description contains session-level information and media-level information. The session-level information applies to the whole session; for instance, the originator of the session or the session name. The media-level information applies to a particular media stream; for instance, the codec used for encoding the audio stream or the port number the video stream is headed. An announcement consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a `v=' line and continues to the first media-level section. The media description starts with an `m=' line and continues to the next media description or end of the whole session description. In general, session-level values are the default for all media unless overridden by an equivalent media-level value. D50444 Page 11

12 TANDBERG SIP TERMINALS TANDBERG provides a wide variety of form factors based upon the same software and hardware platform. The products range from the personal space, to set tops, up to the executive boardroom plasma-based systems. There are even form factors available for the healthcare industry, distance education, judicial market and first responders. While these form factors may look quite different, they all share the same core technology that makes TANDBERG endpoints the most feature rich in the world. MXP Platform Software Version Released Release Notes F2 February 2005 D50327 F3 July 2005 D50359 F4 January 2006 D50402 F5 July 2006 D50443 F6 May 2007 D50476 Personal Series Software Version Released Release Notes L2 April 2005 D50343 L3 October 2005 D50388 L4 April 2006 D50433 L5 November 2007 D50505 Please consult the appropriate section for details on a particular version of software. D50444 Page 12

13 TANDBERG MXP Endpoints Software F2-F6 SIP Server Interaction Function Port Type Direction SIP Messages 5060 UDP/TCP Endpoint SIP Registrar/Proxy SIP Messages 5061 TLS (TCP) Endpoint SIP Registrar/Proxy Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time. F2-F6 Call Flow (Site A calls Site B) Endpoint A TANDBERG VCS Endpoint B EndptA VCS Protocol Type VCS EndptB Endpt Defined 5060 SIP Request UDP/TCP 5060 Endpt Defined Endpt Defined 5061 SIP Request TCP (TLS) 5061 Endpt Defined 2326 N/A Media (Audio) UDP/RTP N/A N/A Media (Audio) UDP/RTCP N/A N/A Media (Video) UDP/RTP N/A N/A Media (Video) UDP/RTCP N/A N/A Media (Dual UDP/RTP N/A 2330 Streams) 2331 N/A Media (Dual UDP/RTCP N/A 2331 Streams) 2332 N/A Media (FECC) UDP/RTP N/A N/A Media (FECC) UDP/RTCP N/A 2333 Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time. D50444 Page 13

14 For SIP registration and call setup/control signaling, TANDBERG F2-F6 software listens for SIP Requests and SIP Responses on the default trusted SIP ports (5060 for TCP and UDP or 5061 for TLS over TCP). TANDBERG F2-F5 software uses a pool of 160 UDP ports (2326:2485) for all media (both RTP and RTCP). When connecting to far end systems that support symmetrical RTP, the ports are used in increments of 8 per call (e.g. the first call will use either ports or , depending on call direction). All calls with systems that do not support symmetrical RTP, however, will require 16 ports per call. After the first call is connected, the endpoint will use the next consecutive 8 ports for the subsequent call and so on until all calls are disconnected. Once all calls are disconnected, the ports will reset to the beginning. The port allocation behavior has changed a bit in F6. While the same port range is used (UDP ports 2326:2485 inclusive), the port range will continue to increment once all active calls are disconnected. Only when the top of the range is reached will the ports to be allocated for the next call reset to the beginning of the range. For example, upon startup, the MXP will allocate ports for the first call. Whether or not that call disconnects prior to the next call being connected, call 2 will utilize ports This incremental allocation will continue until port 2485 is reached, at which time the ports will reset to the beginning of the range. The TANDBERG endpoint also uses symmetrical RTP ports, thereby reducing the number of ports needed per call. Symmetrical RTP functionality allows the same port to be used for both incoming and outgoing audio streams. However, when the logical channels are opened, the start range for the UDP ports could begin at 2326 or 2334, depending on who initializes the open logical channel commands. F2-F6 Audio Audio Length (ms) Audio size IP UDP RTP G ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G.722.1_24 20ms 60 bytes 20 bytes 8 bytes 12 bytes 100 bytes G.722.1_32 20ms 80 bytes 20 bytes 8 bytes 12 bytes 120 bytes G ms 40 bytes 20 bytes 8 bytes 12 bytes 80 bytes AAC-LD 20ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes F2-F6 Video Total Video Video size (max) IP UDP RTP Total (max) H bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/ bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H bytes* 20 bytes 8 bytes 12 bytes 1440 bytes * The dataport command h323mtu < > can be used to change the maximum video payload size to any value between 500 and 1400 bytes. D50444 Page 14

15 Jitter and Latency Latency can be defined as the time between a node sending a message and receipt of the message by another node. The TANDBERG systems can handle any value of latency, however, the higher the latency, the longer the delay in video and audio. This may lead to conferences with undesirable delays causing participants to interrupt and speak over each other. Jitter can be defined as the difference in latency. Where constant latency simply produces delays in audio and video, jitter can have a more adverse effect. Jitter can cause packets to arrive out of order or at the wrong times. TANDBERG systems can manage packets with jitter up to 100ms; packets not received within this timeframe will be considered lost packets. If excessive packet loss is detected, the TANDBERG systems will make use of IPLR TF (see document D50165, TANDBERG and IPLR, for more information) or downspeeding (flow control) to counteract the packet loss. F2 software introduced a new dynamic jitter buffer that can increase in value depending on the performance of the network. To minimize introduced latency, this buffer will begin at 20ms and continue to 100ms if sufficient packet loss is occurring. F3 software introduced RTP time stamping into the audio packets in order to help reduce lip sync issues that may occur over an SIP call. This operation has also been slightly modified to improve as much as possible within the F4, F5 and F6 software releases. To further improve lip sync with high resolution images (including XGA, w720p and other high resolution video formats), F3 software has changed the behavior of image buffering prior in order to attempt to place information on the wire as fast as possible. Prior to this adjustment in behavior, the MXP endpoint would attempt to maintain a consistent packet size when placing the information on the wire, which would result in video being buffered internally to ensure that the entire packet could be filled prior to transmission. This potential buffering created a potential lip sync issue at the far end of the SIP call as the time between the actual capture of the visual image and placing the information on the wire was not a constant and, therefore, the far end system cannot adjust for any time differences between the arrival of the video information and the arrival of the audio information. The endpoint will now, by default, not buffer the high resolution images prior to transmission, which will ensure a constant time delta between the arrival of the video and audio information to the far end, allowing for an adjustment as necessary and improved lip sync. This change in behavior, though, can cause the MXP to send out consecutive packets that have a relatively large difference in size. For example, one packet can come out at 1400 bytes while the packet behind that can be sent out at 800 bytes followed by a 1200 byte packet and so on. Some QoS configurations improperly handle the large adjustments in packet size, thereby dropping packets within the QoS buffer and causing packet loss in the call. If, for any reason, it is necessary to disable this behavior, it can be done through the API command xconfiguration AllowLatency: <On/Off> (requires the latest minor release of F4 software, at a minimum). When this setting is On, the MXP will buffer the traffic prior to placing it on the wire; Off (default) will not buffer any video internally. D50444 Page 15

16 RFC Support The following RFC s are supported in the MXP product line as of software version F6.3. RFC 1889 RFC 2190 RFC 2327 RFC 2396 RFC 2429 RFC 2617 RFC 2782 RFC 2833 RFC 2976 RFC 3016 RFC 3047 RFC 3261 RFC 3262 RFC 3263 RFC 3264 RFC 3311 RFC 3361 RFC 3420 RFC 3515 RFC 3550 RFC 3581 RFC 3605 RFC 3711 RFC 3840 RFC 3890 RFC 3891 RFC 3892 RFC 3960 RFC 3984 RFC 4028 RFC 4145 RFC 4566 RFC 4568 RFC 4574 RTP: A Transport protocol for Real-time Applications RTP Payload Format for H.263 Video Streams SDP: Session Description Protocol Uniform Resource Identifiers (URI): Generic Syntax RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) Digest Authentication DNS RR for specifying the location of services (DNS SRV) RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals The SIP INFO Method RTP Payload Format for MPEG-4 Audio/Visual Streams RTP Payload Format for ITU-T Recommendation G SIP: Session Initiation Protocol Reliability of Provisional Responses in SIP Locating SIP Servers An Offer/Answer Model with SDP UPDATE method DHCP Option for SIP Servers Internet Media Type message/sipfrag Refer method RTP: A Transport Protocol for Real-Time Applications Symmetric Response Routing RTCP attribute in SDP The Secure Real-time Transport Protocol (SRTP) Indicating User Agent Capabilities in SIP A Transport Independent Bandwidth Modifier for SDP The SIP "Replaces" Referred-By Mechanism Early Media RTP Payload Format for H.264 Video Session Timers in SIP TCP-Based Media Transport in the SDP SDP: Session Description Protocol SDP: Security Descriptions for Media Streams The Session Description Protocol (SDP) Label Attribute D50444 Page 16

17 RFC 4582 RFC 4583 RFC 4585 RFC 4587 RFC 4629 RFC 4796 The Binary Floor Control Protocol Format for Binary Floor Control Protocol (BFCP) Streams Extended RTP Profile for RTCP-Based Feedback RTP Payload Format for H.261 Video Streams RTP Payload Format for ITU-T Rec. H.263 Video The Session Description Protocol (SDP) Content Attribute draft-ietf-xcon-bfcp-connection-04.txt draft-levin-mmusic-xml-media-control-03.txt draft-ietf-sipping-cc-transfer-06.txt draft-kristensen-avt-rtp-h264-extension-00.txt D50444 Page 17

18 TANDBERG MXP Personal Series Endpoints L2-L5 SIP Server Interaction Function Port Type Direction SIP Messages 5060 UDP/TCP Endpoint SIP Registrar/Proxy SIP Messages 5061 TLS (TCP) Endpoint SIP Registrar/Proxy Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time. L2-L5 Call Flow (Site A calls Site B) TANDBERG VCS Endpoint A EndptA VCS Protocol Type VCS EndptB Endpt Defined 5060 SIP Request UDP/TCP VCS Defined 5060 Endpt Defined 5061 SIP Request TCP (TLS) 5061 Endpt Defined 2326 N/A Media (Audio) UDP/RTP N/A N/A Media (Audio) UDP/RTCP N/A N/A Media (Video) UDP/RTP N/A N/A Media (Video) UDP/RTCP N/A N/A Media (Dual UDP/RTP N/A 2330 Streams) 2331 N/A Media (Dual UDP/RTCP N/A 2331 Streams) 2332 N/A Media (FECC) UDP/RTP N/A N/A Media (FECC) UDP/RTCP N/A 2333 Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time. D50444 Page 18

19 For SIP registration and call setup/control signaling, TANDBERG L2-L5 software listens for SIP Requests and SIP Responses on the default trusted SIP ports (5060 for TCP and UDP or 5061 for TLS over TCP). TANDBERG L2-L4 software uses a pool of 32 UDP ports (2326:2357) for all media (both RTP and RTCP). When connecting to far end systems that support symmetrical RTP, the ports are used in increments of 8 per call (e.g. the first call will use either ports or , depending on call direction). All calls with systems that do not support symmetrical RTP, however, will require 16 ports per call. After the first call is connected, the endpoint will use the next consecutive 8 ports for the subsequent call and so on until all calls are disconnected. Once all calls are disconnected, the ports will reset to the beginning. The port allocation behavior has changed a bit in L5. While the same port range is used (UDP ports 2326:2485 inclusive), the port range will continue to increment once all active calls are disconnected. Only when the top of the range is reached will the ports to be allocated for the next call reset to the beginning of the range. For example, upon startup, the MXP will allocate ports for the first call. Whether or not that call disconnects prior to the next call being connected, call 2 will utilize ports This incremental allocation will continue until port 2485 is reached, at which time the ports will reset to the beginning of the range. All versions of L software use bi-directional UDP ports, thereby reducing the number of ports required to connect an SIP call. L2-L5 Audio Audio Length (ms) Audio size IP UDP RTP G ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G.722.1_24 20ms 60 bytes 20 bytes 8 bytes 12 bytes 100 bytes G.722.1_32 20ms 80 bytes 20 bytes 8 bytes 12 bytes 120 bytes L2-L5 Video Total Video Video size (max) IP UDP RTP Total (max) H bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/ bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H bytes* 20 bytes 8 bytes 12 bytes 1440 bytes * for L1 L5 software, the API command xconfig rtp mtu: < > can be used to change the maximum video payload size to any value between 400 and 1400 bytes. Jitter and Latency Latency can be defined as the time between a node sending a message and receipt of the message by another node. The TANDBERG systems can handle any value of latency, however, the higher the latency, the longer the delay in video and audio. This may lead to conferences with undesirable delays causing participants to interrupt and speak over each other. Jitter can be defined as the difference in latency. Where constant latency simply produces delays in audio and video, jitter can have a more adverse effect. Jitter can cause packets to arrive out of order or at the wrong times. TANDBERG systems can manage packets with jitter up to 100ms; packets not received within this timeframe will be considered lost packets. If excessive packet loss is detected, the TANDBERG systems will make use of IPLR TF (see document D50165 for more information) or downspeeding (flow control) to counteract the packet loss. D50444 Page 19

20 Introduced in L2, the 150MXP software supports a dynamic jitter buffer that can increase in value depending on the performance of the network. To minimize introduced latency, this buffer will begin at 20ms and continue to 100ms if sufficient packets are arriving outside the current jitter buffer range. L3 software introduced RTP time stamping into the audio packets in order to help reduce lip sync issues that may occur over an SIP call. RFC Support The following RFCs are supported in the MXP Personal Series product line as of software version L5.0. RFC 1889 RFC 2190 RFC 2327 RFC 2396 RFC 2429 RFC 2617 RFC 2782 RFC 2833 RFC 2976 RFC 3016 RFC 3047 RFC 3261 RFC 3262 RFC 3263 RFC 3264 RFC 3311 RFC 3361 RFC 3420 RFC 3515 RFC 3550 RFC 3581 RFC 3605 RFC 3711 RFC 3840 RFC 3890 RFC 3891 RFC 3892 RFC 3960 RTP: A Transport protocol for Real-time Applications RTP Payload Format for H.263 Video Streams SDP: Session Description Protocol Uniform Resource Identifiers (URI): Generic Syntax RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) Digest Authentication DNS RR for specifying the location of services (DNS SRV) RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals The SIP INFO Method RTP Payload Format for MPEG-4 Audio/Visual Streams RTP Payload Format for ITU-T Recommendation G SIP: Session Initiation Protocol Reliability of Provisional Responses in SIP Locating SIP Servers An Offer/Answer Model with SDP UPDATE method DHCP Option for SIP Servers Internet Media Type message/sipfrag Refer method RTP: A Transport Protocol for Real-Time Applications Symmetric Response Routing RTCP attribute in SDP The Secure Real-time Transport Protocol (SRTP) Indicating User Agent Capabilities in SIP A Transport Independent Bandwidth Modifier for SDP The SIP "Replaces" Referred-By Mechanism Early Media D50444 Page 20

21 RFC 3984 RFC 4028 RFC 4145 RFC 4566 RFC 4568 RFC 4574 RFC 4582 RFC 4583 RFC 4585 RFC 4587 RFC 4629 RFC 4796 RTP Payload Format for H.264 Video Session Timers in SIP TCP-Based Media Transport in the SDP SDP: Session Description Protocol SDP: Security Descriptions for Media Streams The Session Description Protocol (SDP) Label Attribute The Binary Floor Control Protocol Format for Binary Floor Control Protocol (BFCP) Streams Extended RTP Profile for RTCP-Based Feedback RTP Payload Format for H.261 Video Streams RTP Payload Format for ITU-T Rec. H.263 Video The Session Description Protocol (SDP) Content Attribute draft-ietf-xcon-bfcp-connection-04.txt draft-levin-mmusic-xml-media-control-03.txt draft-ietf-sipping-cc-transfer-06.txt draft-kristensen-avt-rtp-h264-extension-00.txt D50444 Page 21

22 TANDBERG SIP INFRASTRUCTURE TANDBERG provides several infrastructure products aimed at addressing different needs. These products include a distributed MCU, centralized MCU, gateway, gatekeeper and firewall traversal technology. While these form factors may look quite different, they all share the same core technology that makes TANDBERG infrastructure the most feature-rich solution available on the market today. TANDBERG MPS Software Version Released Release Notes J3 January 2006 D50414 J4 July 2007 D50489 TANDBERG Codian 4500 MCU Software Version Released Release Notes 2.2(1.0) December 2007 N/A TANDBERG Codian 4200 MCU Software Version Released Release Notes 2.2(1.0) December 2007 N/A TANDBERG Codian IP Gateway 3500 Software Version Released Release Notes 1.1(1.1) December 2007 N/A TANDBERG Entrypoint Software Version Released Release Notes EP1 March 2007 D50477 TANDBERG 3G Gateway Software Version Released Release Notes R2 April 2006 D50436 R3 June 2007 D50495 D50444 Page 22

23 TANDBERG Video Portal Software Version Released Release Notes V2 April 2006 D50437 V3 June 2007 D50496 TANDBERG Content Server Software Version Released Release Notes S3 January 2008 D50510 TANDBERG Codian IPVCR 2200 Software Version Released Release Notes 2.2(1.0) December 2007 N/A TANDBERG Video Communication Server Software Version Released Release Notes X1 August 2007 D50491 Please consult the appropriate section for details on a particular version of software. D50444 Page 23

24 TANDBERG MPS 200/800 The TANDBERG MPS is a card-based chassis ideal for medium to large enterprise needs or centralized deployment architecture. J3-J4 SIP Server Interaction Function Port Type Direction SIP Messages 5060 UDP/TCP MPS SIP Registrar/Proxy SIP Messages 5061 TLS (TCP) MPS SIP Registrar/Proxy Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time. J3-J4 Call Flow (MPS calls Site A) TANDBERG VCS MPS Site A MPS VCS Protocol Type VCS Site A MPS Defined 5060 SIP Request UDP/TCP VCS Defined 5060 Endpt Defined 5061 SIP Request TCP (TLS) 5061 Endpt Defined 2326 N/A Media (Video) UDP/RTP N/A N/A Media (Video) UDP/RTCP N/A N/A Media (Dual UDP/RTP N/A 2330 Streams) 2329 N/A Media (Dual UDP/RTCP N/A 2331 Streams) 2330 N/A Media (Audio) UDP/RTP N/A N/A Media (Audio) UDP/RTCP N/A 2327 Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time. For SIP registration and call setup/control signaling, the MPS listens for SIP Requests and SIP Responses on the default trusted SIP ports (5060 for TCP and UDP or 5061 for TLS over TCP). All SIP traffic will flow between the System Controller card on the MPS and the far end system. The MPS uses a pool of 4626 UDP ports (2326:6951) for all media (both RTP and RTCP). The ports are used in increments of 8 per call (e.g. the first call will use ports ). After the first call is connected, the MPS will use the next consecutive 8 ports for the subsequent call and so on until all calls are disconnected. Once all calls are disconnected, the ports will reset to the beginning. All UDP Media content will flow directly between the specific media blade on the MPS and the endpoint connected. D50444 Page 24

25 The port allocation behavior has changed a bit in J4. While the same port range is used (UDP ports 2326:6951 inclusive), the port range will continue to increment once all active calls are disconnected. Only when the top of the range is reached will the ports to be allocated for the next call reset to the beginning of the range. For example, upon startup, the MPS will allocate ports for the first call. Whether or not that call disconnects prior to the next call being connected, call 2 will utilize ports This incremental allocation will continue until port 6951 is reached, at which time the ports will reset to the beginning of the range. Similar to the MXP endpoints running F2 or later, the TANDBERG MPS (all versions of software) uses bi-directional UDP ports, so the number of ports required is reduced in comparison to older versions of the TANDBERG endpoints software. J3-J4 Audio Audio Length (ms) Audio size IP UDP RTP G ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G.722.1_24 20ms 60 bytes 20 bytes 8 bytes 12 bytes 100 bytes G.722.1_32 20ms 80 bytes 20 bytes 8 bytes 12 bytes 120 bytes G ms 40 bytes 20 bytes 8 bytes 12 bytes 80 bytes AAC-LD 20 ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes J3-J4 Video Total Video Video size (max) IP UDP RTP Total (max) H bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/ bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H bytes* 20 bytes 8 bytes 12 bytes 1440 bytes * with all versions of the MPS software, the dataport command xconfig RTP MTU: < > can be used to change the maximum video payload size to any value between 1200 and 1400 bytes. Jitter and Latency Latency can be defined as the time between a node sending a message and receipt of the message by another node. The TANDBERG systems can handle any value of latency, however, the higher the latency, the longer the delay in video and audio. This may lead to conferences with undesirable delays causing participants to interrupt and speak over each other. Jitter can be defined as the difference in latency. Where constant latency simply produces delays in audio and video, jitter can have a more adverse effect. Jitter can cause packets to arrive out of order or at the wrong times. TANDBERG systems can manage packets with jitter up to 200ms; packets not received within this timeframe will be considered lost packets. If excessive packet loss is detected, the TANDBERG systems will make use of IPLR TF (see document D50165 for more information) or downspeeding (flow control) to counteract the packet loss. To further improve lip sync with high resolution images (including XGA, w720p and other high resolution video formats), J3 software has changed the behavior of image buffering prior in order to attempt to place information on the wire as fast as possible. Prior to this adjustment in behavior, the MPS would attempt to maintain a consistent packet size when placing the information on the wire, which would result in video being buffered internally to ensure that the entire packet could be filled prior to transmission. This potential buffering created a potential lip sync issue at the far end of the SIP call as the time between the actual capture of the visual image and placing the information on the wire was not a constant and, therefore, the far end system cannot adjust for any time differences between the arrival of the video information and the arrival of the audio information. D50444 Page 25

26 The MPS will now, by default, not buffer the high resolution images prior to transmission, which will ensure a constant time delta between the arrival of the video and audio information to the far end, allowing for an adjustment as necessary and improved lip sync. This change in behavior, though, can cause the MPS to send out consecutive packets that have a relatively large difference in size. For example, one packet can come out at 1400 bytes while the packet behind that can be sent out at 800 bytes followed by a 1200 byte packet and so on. Some QoS configurations improperly handle the large adjustments in packet size, thereby dropping packets within the QoS buffer and causing packet loss in the call. If, for any reason, it is necessary to disable this behavior, it can be done through the API command xconfiguration SystemUnit TrafficShaping: <On/Off> (requires the latest minor release of J3 software, at a minimum). When this setting is On, the MPS will buffer the traffic prior to placing it on the wire; Off (default) will not buffer any video internally. RFC Support The following RFCs are supported in the MPS as of software version J4.2. RFC 1889 RFC 2190 RFC 2327 RFC 2396 RFC 2429 RFC 2617 RFC 2782 RFC 2833 RFC 2976 RFC 3016 RFC 3047 RFC 3261 RFC 3262 RFC 3263 RFC 3264 RFC 3311 RFC 3420 RFC 3515 RFC 3550 RFC 3581 RFC 3605 RFC 3840 RFC 3890 RFC 3891 RFC 3892 RFC 3960 RTP: A Transport protocol for Real-time Applications RTP Payload Format for H.263 Video Streams SDP: Session Description Protocol Uniform Resource Identifiers (URI): Generic Syntax RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) Digest Authentication DNS RR for specifying the location of services (DNS SRV) RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals The SIP INFO Method RTP Payload Format for MPEG-4 Audio/Visual Streams RTP Payload Format for ITU-T Recommendation G SIP: Session Initiation Protocol Reliability of Provisional Responses in SIP Locating SIP Servers An Offer/Answer Model with SDP UPDATE method Internet Media Type message/sipfrag Refer method RTP: A Transport Protocol for Real-Time Applications Symmetric Response Routing RTCP attribute in SDP Indicating User Agent Capabilities in SIP A Transport Independent Bandwidth Modifier for SDP The SIP "Replaces" Referred-By Mechanism Early Media D50444 Page 26

27 RFC 3984 RFC 4028 RFC 4145 RFC 4566 RFC 4574 RFC 4582 RFC 4583 RFC 4585 RFC 4587 RFC 4629 RFC 4796 RTP Payload Format for H.264 Video Session Timers in SIP TCP-Based Media Transport in the SDP SDP: Session Description Protocol The Session Description Protocol (SDP) Label Attribute The Binary Floor Control Protocol Format for Binary Floor Control Protocol (BFCP) Streams Extended RTP Profile for RTCP-Based Feedback RTP Payload Format for H.261 Video Streams RTP Payload Format for ITU-T Rec. H.263 Video The Session Description Protocol (SDP) Content Attribute draft-ietf-xcon-bfcp-connection-04.txt draft-levin-mmusic-xml-media-control-03.txt draft-ietf-sipping-cc-transfer-06.txt draft-kristensen-avt-rtp-h264-extension-00.txt D50444 Page 27

28 TANDBERG Codian 4500 Series MCU The TANDBERG Codian 4500 series of MCUs are stand alone appliances supporting up to 40 ports per chassis. Multiple chassis can be combined through cascading either in a distributed or centralized architecture if an increase in capacity is required. Note: The Codian products allocate random ports in the range of to It is possible to change the fixed ports on which the Codian products receive and establish connections under the Network > Services portion of the management interface. Software 2.2(1.0) SIP Server Interaction Codian 4500 Function Port Type Direction SIP Messages 5060 UDP/TCP 4500 SIP Registrar/Proxy Note: Only one of the transport types (UDP or TCP) is used at any one time. Software 2.2(1.0) Call Flow TANDBERG VCS 4500 Site A Codian 4500 VCS Protocol Type VCS Site A 49152: SIP Request UDP/TCP VCS Defined : SIP Request UDP/TCP 5060 Endpt Defined 49152:65535 N/A Media (Video) UDP/RTP N/A Endpt Defined 49152:65535 N/A Media (Video) UDP/RTCP N/A Endpt Defined 49152:65535 N/A Media (Dual UDP/RTP N/A Endpt Defined Streams) 49152:65535 N/A Media (Dual UDP/RTCP N/A Endpt Defined Streams) 49152:65535 N/A Media (Audio) UDP/RTP N/A Endpt Defined 49152:65535 N/A Media (Audio) UDP/RTCP N/A Endpt Defined Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time. D50444 Page 28

29 For SIP registration and call setup/control signaling, the Codian 4500 will use a random port within the range of to Because the same port range is shared by multiple services (i.e. FTP data, H.323 media/call signaling/control and SIP media/call signaling/control), ports are allocated at the time they are needed for each particular service; ports used for logical channels are only allocated when necessary. Logical channels and signaling channels are opened up at different times of a SIP call; ports may or may not be consecutive within a single call. For example, a standard SIP call (media only) may occupy ports 49172/49173 TCP and 49166/49167 and 49160/49161 UDP due to the number of connections that are opened up around the same time. All random ports are allocated from the top of range down, beginning with the ports in the 65xxx grouping. Software 2.2(1.0) Audio Audio Length (ms) Audio size IP UDP RTP G ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G ms 48 bytes 20 bytes 8 bytes 12 bytes 88 bytes G ms 20 bytes 20 bytes 8 bytes 12 bytes 60 bytes AAC-LC_48 20ms 180 bytes 20 bytes 8 bytes 12 bytes 220 bytes AAC-LC_56 20ms 210 bytes 20 bytes 8 bytes 12 bytes 250 bytes AAC-LC_64 20ms 240 bytes 20 bytes 8 bytes 12 bytes 280 bytes AAC-LC_96 20ms 400 bytes 20 bytes 8 bytes 12 bytes 440 bytes AAC-LD_48 20ms 120 bytes 20 bytes 8 bytes 12 bytes 160 bytes AAC-LD_56 20ms 140 bytes 20 bytes 8 bytes 12 bytes 180 bytes AAC-LD_64 20ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes AAC-LD_96 20ms 240 bytes 20 bytes 8 bytes 12 bytes 280 bytes Siren14 20ms 120 bytes 20 bytes 8 bytes 12 bytes 160 bytes G Annex C 20ms 120 bytes 20 bytes 8 bytes 12 bytes 160 bytes Software 2.2(1.0) Video Total Video Video size (max) IP UDP RTP Total (max) H bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/ bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H bytes* 20 bytes 8 bytes 12 bytes 1440 bytes * with 2.2(1.0) software, the maximum mtu used for video payload can be adjusted between 400 and 1400 bytes through the web interface control under Settings > Conferences > Maximum transmitted video packet size. D50444 Page 29

30 Jitter and Latency Latency can be defined as the time between a node sending a message and receipt of the message by another node. The TANDBERG systems can handle any value of latency, however, the higher the latency, the longer the delay in video and audio. This may lead to conferences with undesirable delays causing participants to interrupt and speak over each other. Jitter can be defined as the difference in latency. Where constant latency simply produces delays in audio and video, jitter can have a more adverse effect. Jitter can cause packets to arrive out of order or at the wrong times. The TANDBERG Codian 4500 MCU incorporates variable, independent jitter buffers for the audio and video streams of the call. The audio stream has a dynamic jitter buffer of 40ms up to and including 240ms, while the dynamic jitter buffer used for the video stream begins at 30ms and can increase when deemed necessary by an increase in jitter for the active SIP call. The maximum size of the jitter buffer is determined by the bandwidth of the call in question; for a call connected at 384kbps, the jitter buffer can equate to a full 2 seconds, while a 2Mbps call will equate to a jitter buffer of approximately 350ms. The Codian 4500 MCU utilizes RTP time stamping between the audio and video streams to ensure they remain synchronized throughout the call. RFC Support The following RFC s are supported in the Codian 4500 MCU product line as of software version 2.2(1.0). RFC 2190 RFC 2327 RFC 2617 RFC 2833 RFC 2976 RFC 3261 RFC 3264 RFC 3265 RFC 3555 RFC 3984 RFC 4573 RTP Payload Format for H.263 Video Streams SDP: Session Description Protocol Digest Authentication RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals The SIP INFO Method SIP: Session Initiation Protocol An Offer/Answer Model with SDP Session Initiation Protocol (SIP)-Specific Event Notification MIME Type Registration of RTP Payload Formats RTP Payload Format for H.264 Video MIME Type Registration for RTP Payload Format for H.224 draft-levinmmusic-xml-schema-media-control D50444 Page 30

31 TANDBERG Codian 4200 Series MCU The TANDBERG Codian 4200 series of MCUs are stand alone appliances supporting up to 40 ports per chassis. Multiple chassis can be combined through cascading either in a distributed or centralized architecture if an increase in capacity is required. Note: The Codian products allocate random ports in the range of to It is possible to change the fixed ports on which the Codian products receive and establish connections under the Network > Services portion of the management interface. Software 2.2(1.0) SIP Server Interaction Codian 4200 Function Port Type Direction SIP Messages 5060 UDP/TCP 4200 SIP Registrar/Proxy Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time. Software 2.2(1.0) Call Flow TANDBERG VCS 4200 Site A Codian 4200 VCS Protocol Type VCS Site A 49152: SIP Request UDP/TCP VCS Defined : SIP Request UDP/TCP 5060 Endpt Defined 49152:65535 N/A Media (Video) UDP/RTP N/A Endpt Defined 49152:65535 N/A Media (Video) UDP/RTCP N/A Endpt Defined 49152:65535 N/A Media (Dual UDP/RTP N/A Endpt Defined Streams) 49152:65535 N/A Media (Dual UDP/RTCP N/A Endpt Defined Streams) 49152:65535 N/A Media (Audio) UDP/RTP N/A Endpt Defined 49152:65535 N/A Media (Audio) UDP/RTCP N/A Endpt Defined Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time. D50444 Page 31

32 For SIP registration and call setup/control signaling, the Codian 4200 will use a random port within the range of to Because the same port range is shared by multiple services (i.e. FTP data, H.323 media/call signaling/control and SIP media/call signaling/control), ports are allocated at the time they are needed for each particular service; ports used for logical channels are only allocated when necessary. Logical channels and signaling channels are opened up at different times of a SIP call; ports may or may not be consecutive within a single call. For example, a standard SIP call (media only) may occupy ports 49172/49173 TCP and 49166/49167 and 49160/49161 UDP due to the number of connections that are opened up around the same time. All random ports are allocated from the top of range down, beginning with the ports in the 65xxx grouping. Software 2.2(1.0) Audio Audio Length Audio IP UDP RTP Total (ms) size G ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G ms 48 bytes 20 bytes 8 bytes 12 bytes 88 bytes G ms 20 bytes 20 bytes 8 bytes 12 bytes 60 bytes AAC-LC_48 20ms 180 bytes 20 bytes 8 bytes 12 bytes 220 bytes AAC-LC_56 20ms 210 bytes 20 bytes 8 bytes 12 bytes 250 bytes AAC-LC_64 20ms 240 bytes 20 bytes 8 bytes 12 bytes 280 bytes AAC-LC_96 20ms 400 bytes 20 bytes 8 bytes 12 bytes 440 bytes AAC-LD_48 20ms 120 bytes 20 bytes 8 bytes 12 bytes 160 bytes AAC-LD_56 20ms 140 bytes 20 bytes 8 bytes 12 bytes 180 bytes AAC-LD_64 20ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes AAC-LD_96 20ms 240 bytes 20 bytes 8 bytes 12 bytes 280 bytes Siren14 20ms 120 bytes 20 bytes 8 bytes 12 bytes 160 bytes G Annex C 20ms 120 bytes 20 bytes 8 bytes 12 bytes 160 bytes Software 2.2(1.0) Video Video Video IP UDP RTP Total size (max) (max) H bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/ bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H bytes* 20 bytes 8 bytes 12 bytes 1440 bytes * with 2. 2(1.0) softwa re, the maximum mtu used for video payload can be adjusted between 400 and 1400 bytes through the web interface control under Settings > Conferences > Maximum transmitted video packet size. D50444 Page 32