TANDBERG and H.323

SIP

D50444 revision 1.1

May 2008

TANDBERG and SIP

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/800...... 24 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

TANDBERG and SIP

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

TANDBERG and SIP

DOCUMENT REVISION HISTORY

Initial Version Rev 1.0

Minor Revision; Added References Rev 1.1

D50444 Page 4

TANDBERG and SIP

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 IP- based 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

TANDBERG and SIP

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

TANDBERG and SIP

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 3261. 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 RTP: A Transport protocol for Real-time Applications RFC 2190 RTP Payload Format for H.263 Video Streams RFC 2327 SDP: Session Description Protocol RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) RFC 2617 Digest Authentication RFC 2782 DNS RR for specifying the location of services (DNS SRV) RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RFC 2976 The SIP INFO Method RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1 RFC 3261 SIP: Session Initiation Protocol RFC 3262 Reliability of Provisional Responses in SIP RFC 3263 Locating SIP Servers RFC 3264 An Offer/Answer Model with SDP

D50444 Page 7

TANDBERG and SIP

RFC 3311 UPDATE method RFC 3327 SIP Extension Header Field for Registering Non-Adjacent Contacts RFC 3361 DHCP Option for SIP Servers RFC 3420 Internet Media Type message/sipfrag RFC 3515 Refer method RFC 3550 RTP: A Transport Protocol for Real-Time Applications RFC 3581 Symmetric Response Routing RFC 3605 RTCP attribute in SDP RFC 3711 The Secure Real-time Transport Protocol (SRTP) RFC 3840 Indicating User Agent Capabilities in SIP RFC 3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services RFC 3890 A Transport Independent Bandwidth Modifier for SDP RFC 3891 The SIP "Replaces" Header RFC 3892 Referred-By Mechanism RFC 3944 H.350 Directory Services RFC 3960 Early Media RFC 3984 RTP Payload Format for H.264 Video RFC 4028 Session Timers in SIP RFC 4145 TCP-Based Media Transport in the SDP RFC 4566 SDP: Session Description Protocol RFC 4568 SDP: Security Descriptions for Media Streams RFC 4574 The Session Description Protocol (SDP) Label Attribute RFC 4582 The Binary Floor Control Protocol RFC 4583 Format for Binary Floor Control Protocol (BFCP) Streams RFC 4585 Extended RTP Profile for RTCP-Based Feedback RFC 4587 RTP Payload Format for H.261 Video Streams RFC 4629 RTP Payload Format for ITU-T Rec. H.263 Video RFC 4796 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

TANDBERG and SIP

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 The UPDATE method is used to modify the state of a session with out changing the state of the dialog (RFC 3311)

SIP Responses

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 180 Call Is Being Forwarded 181 Queued 182 Session Progress 183

D50444 Page 9

TANDBERG and SIP

2xx Successful Responses 200 Ok Accepted 202 3xx Redirection Responses 300 Multiple Choices Moved Permanently 301 Moved Temporarily 302 Use Proxy 305 Alternative Service 380 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 Too Many Hops 483 Address Incomplete 484 Ambiguous 485 Busy Here 486 Request Terminated 487 Not Acceptable Here 488

D50444 Page 10

TANDBERG and SIP

5xx Server Failure Responses Server Internal Error 500 Not Implemented: The SIP request method is not implemented 501 Bad Gateway 502 Service Unavailable 503 Server Time-out 504 SIP Version Not Supported 505 Message Too Large 513 Precondition Failure 580 6xx Global Failure Responses Busy Everywhere 600 Decline 603 Does Not Exist Anywhere 604 Not Acceptable 606 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

TANDBERG and SIP

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

TANDBERG and SIP

TANDBERG MXP Endpoints

Software F2-F6 SIP Server Interaction

5060 5060

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)

TANDBERG VCS Endpoint A 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 2326 2327 N/A Media (Audio) UDP/RTCP N/A 2327 2328 N/A Media (Video) UDP/RTP N/A 2328 2329 N/A Media (Video) UDP/RTCP N/A 2329 2330 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 2332 2333 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

TANDBERG and SIP

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 2326-2333 or 2334-2341, 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 2326-2333 for the first call. Whether or not that call disconnects prior to the next call being connected, call 2 will utilize ports 2334-2341. 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 Audio IP UDP RTP Total (ms) size Header Header Header G.711 20ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G.722 20ms 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.728 20ms 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

Video Video IP UDP RTP Total size Header Header Header (max) (max) H.261 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/++ 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.264 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes * The dataport command ‘h323mtu <500…1400>’ can be used to change the maximum video payload size to any value between 500 and 1400 bytes.

D50444 Page 14

TANDBERG and SIP

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 IPLRTF (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: ’ (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

TANDBERG and SIP

RFC Support

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

D50444 Page 16

TANDBERG and SIP

RFC 4582 The Binary Floor Control Protocol RFC 4583 Format for Binary Floor Control Protocol (BFCP) Streams RFC 4585 Extended RTP Profile for RTCP-Based Feedback RFC 4587 RTP Payload Format for H.261 Video Streams RFC 4629 RTP Payload Format for ITU-T Rec. H.263 Video RFC 4796 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

TANDBERG and SIP

TANDBERG MXP Personal Series Endpoints

L2-L5 SIP Server Interaction

5060 5060 5060 5060

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 2326 2327 N/A Media (Audio) UDP/RTCP N/A 2327 2328 N/A Media (Video) UDP/RTP N/A 2328 2329 N/A Media (Video) UDP/RTCP N/A 2329 2330 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 2332 2333 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

TANDBERG and SIP

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 2326-2333 or 2334-2341, 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 2326-2333 for the first call. Whether or not that call disconnects prior to the next call being connected, call 2 will utilize ports 2334-2341. 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

L2-L5 Video

Video Video IP UDP RTP Total size Header Header Header (max) (max) H.261 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/++ 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.264 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes * for L1 – L5 software, the API command ‘xconfig rtp mtu: <400…1400>’ can be used to change the maximum video payload size to any value between 400 and 1400 bytes.

Jitter and Latency

D50444 Page 19

TANDBERG and SIP

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 RTP: A Transport protocol for Real-time Applications RFC 2190 RTP Payload Format for H.263 Video Streams RFC 2327 SDP: Session Description Protocol RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) RFC 2617 Digest Authentication RFC 2782 DNS RR for specifying the location of services (DNS SRV) RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RFC 2976 The SIP INFO Method RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1 RFC 3261 SIP: Session Initiation Protocol RFC 3262 Reliability of Provisional Responses in SIP RFC 3263 Locating SIP Servers RFC 3264 An Offer/Answer Model with SDP RFC 3311 UPDATE method RFC 3361 DHCP Option for SIP Servers RFC 3420 Internet Media Type message/sipfrag RFC 3515 Refer method RFC 3550 RTP: A Transport Protocol for Real-Time Applications RFC 3581 Symmetric Response Routing RFC 3605 RTCP attribute in SDP RFC 3711 The Secure Real-time Transport Protocol (SRTP) RFC 3840 Indicating User Agent Capabilities in SIP RFC 3890 A Transport Independent Bandwidth Modifier for SDP RFC 3891 The SIP "Replaces" Header RFC 3892 Referred-By Mechanism RFC 3960 Early Media

D50444 Page 20

TANDBERG and SIP

RFC 3984 RTP Payload Format for H.264 Video RFC 4028 Session Timers in SIP RFC 4145 TCP-Based Media Transport in the SDP RFC 4566 SDP: Session Description Protocol RFC 4568 SDP: Security Descriptions for Media Streams RFC 4574 The Session Description Protocol (SDP) Label Attribute RFC 4582 The Binary Floor Control Protocol RFC 4583 Format for Binary Floor Control Protocol (BFCP) Streams RFC 4585 Extended RTP Profile for RTCP-Based Feedback RFC 4587 RTP Payload Format for H.261 Video Streams RFC 4629 RTP Payload Format for ITU-T Rec. H.263 Video RFC 4796 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

TANDBERG and SIP

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

TANDBERG and SIP

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

TANDBERG and SIP

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

5060 5060

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 2328 2327 N/A Media (Video) UDP/RTCP N/A 2329 2328 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 2326 2331 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 2326-2333). 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

TANDBERG and SIP

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 2326-2333 for the first call. Whether or not that call disconnects prior to the next call being connected, call 2 will utilize ports 2334-2341. 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

J3-J4 Video

Video Video IP UDP RTP Total size Header Header Header (max) (max) H.261 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/++ 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.264 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes * with all versions of the MPS software, the dataport command ‘xconfig RTP MTU: <1200…1400>’ can be used to change the maximum video payload size to any value between 1200 and 1400 bytes.

Jitter and Latency

D50444 Page 25

TANDBERG and SIP

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: ’ (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 RTP: A Transport protocol for Real-time Applications RFC 2190 RTP Payload Format for H.263 Video Streams RFC 2327 SDP: Session Description Protocol RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) RFC 2617 Digest Authentication RFC 2782 DNS RR for specifying the location of services (DNS SRV) RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RFC 2976 The SIP INFO Method RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1 RFC 3261 SIP: Session Initiation Protocol RFC 3262 Reliability of Provisional Responses in SIP RFC 3263 Locating SIP Servers RFC 3264 An Offer/Answer Model with SDP RFC 3311 UPDATE method RFC 3420 Internet Media Type message/sipfrag RFC 3515 Refer method RFC 3550 RTP: A Transport Protocol for Real-Time Applications RFC 3581 Symmetric Response Routing RFC 3605 RTCP attribute in SDP RFC 3840 Indicating User Agent Capabilities in SIP RFC 3890 A Transport Independent Bandwidth Modifier for SDP RFC 3891 The SIP "Replaces" Header RFC 3892 Referred-By Mechanism RFC 3960 Early Media

D50444 Page 26

TANDBERG and SIP

RFC 3984 RTP Payload Format for H.264 Video RFC 4028 Session Timers in SIP RFC 4145 TCP-Based Media Transport in the SDP RFC 4566 SDP: Session Description Protocol RFC 4574 The Session Description Protocol (SDP) Label Attribute RFC 4582 The Binary Floor Control Protocol RFC 4583 Format for Binary Floor Control Protocol (BFCP) Streams RFC 4585 Extended RTP Profile for RTCP-Based Feedback RFC 4587 RTP Payload Format for H.261 Video Streams RFC 4629 RTP Payload Format for ITU-T Rec. H.263 Video RFC 4796 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

TANDBERG and SIP

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 49152 to 65535. 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

5060 5060

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 VCS Protocol Type VCS Site A 4500 49152:65535 5060 SIP Request UDP/TCP VCS Defined 5060 49152:65535 5060 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

TANDBERG and SIP

For SIP registration and call setup/control signaling, the Codian 4500 will use a random port within the range of 49152 to 65535. 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 Header Header Header G.711 20ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G.722 20ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes G.723.1 30ms 48 bytes 20 bytes 8 bytes 12 bytes 88 bytes G.729 20ms 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.722.1 Annex 20ms 120 bytes 20 bytes 8 bytes 12 bytes 160 bytes C

Software 2.2(1.0) Video

Video Video IP UDP RTP Total size Header Header Header (max) (max) H.261 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/++ 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.264 1400 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

TANDBERG and SIP

Jitter and Latency

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 RTP Payload Format for H.263 Video Streams RFC 2327 SDP: Session Description Protocol RFC 2617 Digest Authentication RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RFC 2976 The SIP INFO Method RFC 3261 SIP: Session Initiation Protocol RFC 3264 An Offer/Answer Model with SDP RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification RFC 3555 MIME Type Registration of RTP Payload Formats RFC 3984 RTP Payload Format for H.264 Video RFC 4573 MIME Type Registration for RTP Payload Format for H.224 draft-levin- mmusic-xml-schema-media-control

D50444 Page 30

TANDBERG and SIP

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 49152 to 65535. 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

5060 5060

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 VCS Protocol Type VCS Site A 4200 49152:65535 5060 SIP Request UDP/TCP VCS Defined 5060 49152:65535 5060 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

TANDBERG and SIP

For SIP registration and call setup/control signaling, the Codian 4200 will use a random port within the range of 49152 to 65535. 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

Software 2.2(1.0) Video

Video Video IP UDP RTP Total size Header Header Header (max) (max) H.261 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/++ 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.264 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes * with 2.2(1.0) software, the maximum mtu used for vi deo 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

TANDBERG and SIP

Jitter and Latency

RFC Support

The following RFC’s are supported in the Codian 4200 MCU product line as of software version 2.2(1.0). RFC 2190 RTP Payload Format for H.263 Video Streams RFC 2327 SDP: Session Description Protocol RFC 2617 Digest Authentication RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RFC 2976 The SIP INFO Method RFC 3261 SIP: Session Initiation Protocol RFC 3264 An Offer/Answer Model with SDP RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification RFC 3555 MIME Type Registration of RTP Payload Formats RFC 3984 RTP Payload Format for H.264 Video RFC 4573 MIME Type Registration for RTP Payload Format for H.224 draft-levin- mmusic-xml-schema-media-control

D50444 Page 33

TANDBERG and SIP

TANDBERG Codian 3500 Series IP Gateway

The TANDBERG Codian 3500 Series of IP Gateways are stand alone appliances supporting up to 40 calls per chassis. Multiple chassis can be combined 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 49152 to 65535. 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 1.1(1.1) SIP Server Interaction

5060 5060

Codian 3500

Function Port Type Direction SIP Messages 5060 UDP/TCP 3500 ↔ SIP Registrar/Proxy Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time.

Software 1.1(1.1) Call Flow

TANDBERG VCS

3500 Site A

Codian VCS Protocol Type VCS Site A 3500 49152:65535 5060 SIP Request UDP/TCP VCS Defined 5060 49152:65535 5060 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 34

TANDBERG and SIP

For SIP registration and call setup/control signaling, the Codian 3500 will use a random port within the range of 49152 to 65535. 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 1.1(1.1) Audio

Software 1.1(1.1) Video

Video Video IP UDP RTP Total size Header Header Header (max) (max) H.261 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/++ 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.264 1400 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 35

TANDBERG and SIP

Jitter and Latency

RFC Support

The following RFC’s are supported in the Codian 3500 IP Gateway product line as of software version 1.1(1.1). RFC 2190 RTP Payload Format for H.263 Video Streams RFC 2327 SDP: Session Description Protocol RFC 2617 Digest Authentication RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RFC 2976 The SIP INFO Method RFC 3261 SIP: Session Initiation Protocol RFC 3264 An Offer/Answer Model with SDP RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification RFC 3555 MIME Type Registration of RTP Payload Formats RFC 3984 RTP Payload Format for H.264 Video RFC 4573 MIME Type Registration for RTP Payload Format for H.224 draft-levin- mmusic-xml-schema-media-control

D50444 Page 36

TANDBERG and SIP

TANDBERG 3G Gateway

The TANDBERG 3G Gateway is designed to be a service-provider grade H.324M to H.323/SIP gateway.

R2-R3 SIP Server Interaction

5060 5060

TANDBERG 3G Gateway

Function Port Type Direction SIP Messages 5060 UDP/TCP Gateway ↔ SIP Registrar/Proxy SIP Messages 5061 TLS (TCP) Gateway ↔ SIP Registrar/Proxy Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time.

R2-R3 Call Flow (Gateway calls Site A – call initiated from 3G side)

TANDBERG VCS

GW Site A

3G GW VCS Protocol Type VCS Site A GW Defined 5060 SIP Request UDP/TCP VCS Defined 5060 GW Defined 5061 SIP Request TCP (TLS) 5061 Endpt Defined 25000 N/A Media (Audio) UDP/RTP N/A 2326 25001 N/A Media (Audio) UDP/RTCP N/A 2327 25002 N/A Media (Video) UDP/RTP N/A 2328 25003 N/A Media (Video) UDP/RTCP N/A 2329 25004 N/A Media (Duo) UDP/RTP N/A 2330 25005 N/A Media (Duo) UDP/RTCP N/A 2331 25006 N/A Media (FECC) UDP/RTP N/A 2332 25007 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.

For SIP registration and call setup/control signaling, the TANDBERG 3G Gateway 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 TANDBERG 3G Gateway software uses a pool of 2001 UDP ports (25000:27000) 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 25000- 25007). After the first call is connected, the 3G Gateway 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.

D50444 Page 37

TANDBERG and SIP

R1-R3 Audio

Audio Length Audio IP UDP RTP Total (ms) size Header Header Header G.711 20ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes

R1-R3 Video

Video Video IP UDP RTP Total size Header Header Header (max) (max) H.263 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes * the dataport command ‘xConfiguration RTP MTU: <1200-1400>’ can be used to adjust the maximum video payload size to any value between 1200 and 1400 bytes.

Jitter and Latency

D50444 Page 38

TANDBERG and SIP

TANDBERG Video Portal

Paired with the TANDBERG 3G Gateway, the TANDBERG Video Portal is designed to provide advanced services to an H.324m to H.323/SIP service provider.

V2-V3 SIP Server Interaction

5060 5060

TANDBERG Video

Function Port Type Direction SIP Messages 5060 UDP Video Portal ↔ SIP Registrar/Proxy SIP Messages 5061 TLS (TCP) Video Portal ↔ SIP Registrar/Proxy Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time.

V2-V3 Call Flow (Video Portal calls Site A – call initiated from 3G side)

TANDBERG VCS

TVP Site A

TVP VCS Protocol Type VCS Site A TVP Defined 5060 SIP Request UDP/TCP VCS Defined 5060 TVP Defined 5061 SIP Request TCP (TLS) 5061 Endpt Defined 25000 N/A Media (Audio) UDP/RTP N/A 2326 25001 N/A Media (Audio) UDP/RTCP N/A 2327 25002 N/A Media (Video) UDP/RTP N/A 2328 25003 N/A Media (Video) UDP/RTCP N/A 2329 25004 N/A Media (Duo) UDP/RTP N/A 2330 25005 N/A Media (Duo) UDP/RTCP N/A 2331 25006 N/A Media (FECC) UDP/RTP N/A 2332 25007 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.

For SIP registration and call setup/control signaling, the TANDBERG Video Portal 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 TANDBERG Video Portal software uses a pool of 2001 UDP ports (25000:27000) 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 25000- 25007). After the first call is connected, the Video Portal 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.

D50444 Page 39

TANDBERG and SIP

V2-V3 Audio

Audio Length Audio IP UDP RTP Total (ms) size Header Header Header G.711 20ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes

V2-V3 Video

Jitter and Latency

D50444 Page 40

TANDBERG and SIP

TANDBERG Content Server

The TANDBERG Content Server is an appliance-based streaming and archiving server for use within any enterprise or educational deployment.

S3 SIP Server Interaction

5060 5060

Content Server

Function Port Type Direction SIP Messages 5060 UDP TCS ↔ SIP Registrar/Proxy SIP Messages 5061 TLS (TCP) TCS ↔ SIP Registrar/Proxy Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time.

S3 Call Flow (Content Server calls Site A)

TANDBERG VCS

TCS Site A

TCS VCS Protocol Type VCS Site A TCS Defined 5060 SIP Request UDP/TCP VCS Defined 5060 TCS Defined 5061 SIP Request TCP (TLS) 5061 Endpt Defined 3230 N/A Media (Audio) UDP/RTP N/A 2326 3231 N/A Media (Audio) UDP/RTCP N/A 2327 3232 N/A Media (Video) UDP/RTP N/A 2328 3233 N/A Media (Video) UDP/RTCP N/A 2329 3234 N/A Media (Duo) UDP/RTP N/A 2330 3235 N/A Media (Duo) UDP/RTCP N/A 2331 3236 N/A Media (FECC) UDP/RTP N/A 2332 3237 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.

For SIP registration and call setup/control signaling, the TANDBERG Content Server, S3 version of 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). The TANDBERG Content Server uses a pool of 40 UDP ports (3230:3269) for all media connections (both RTP and RTCP). The ports are divided up in increments of 8 for each of the 5 possible calls on the Content Server. For example, the first call to connect to the Content Server will allocate the first eight ports within the UDP pool for the media connections (e.g. 3230 – 3237). The second call will then occupy the next eight UDP ports (e.g. 3238 – 3245) and so on.

D50444 Page 41

TANDBERG and SIP

Similar to the MXP endpoints running F2 or later, the TANDBERG Content Server uses bi-directional UDP ports, so the number of ports required is reduced in comparison to older versions of the TANDBERG endpoints software.

S3 Audio

S3 Video

Video Video IP UDP RTP Total size Header Header Header (max) (max) H.261 1400 bytes 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/++ 1400 bytes 20 bytes 8 bytes 12 bytes 1440 bytes H.264 1400 bytes 20 bytes 8 bytes 12 bytes 1440 bytes

Jitter and Latency

RFC Support

The following RFCs are supported in the TCS as of software version S3.0. RFC 1889 RTP: A Transport protocol for Real-time Applications RFC 2190 RTP Payload Format for H.263 Video Streams RFC 2327 SDP: Session Description Protocol RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) RFC 2617 Digest Authentication RFC 2782 DNS RR for specifying the location of services (DNS SRV) RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

D50444 Page 42

TANDBERG and SIP

RFC 2976 The SIP INFO Method RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1 RFC 3261 SIP: Session Initiation Protocol RFC 3262 Reliability of Provisional Responses in SIP RFC 3263 Locating SIP Servers RFC 3264 An Offer/Answer Model with SDP RFC 3311 UPDATE method RFC 3361 DHCP Option for SIP Servers RFC 3420 Internet Media Type message/sipfrag RFC 3515 Refer method RFC 3550 RTP: A Transport Protocol for Real-Time Applications RFC 3581 Symmetric Response Routing RFC 3605 RTCP attribute in SDP RFC 3711 The Secure Real-time Transport Protocol (SRTP) RFC 3840 Indicating User Agent Capabilities in SIP RFC 3890 A Transport Independent Bandwidth Modifier for SDP RFC 3891 The SIP "Replaces" Header RFC 3892 Referred-By Mechanism RFC 3960 Early Media RFC 3984 RTP Payload Format for H.264 Video RFC 4028 Session Timers in SIP RFC 4145 TCP-Based Media Transport in the SDP RFC 4566 SDP: Session Description Protocol RFC 4568 SDP: Security Descriptions for Media Streams RFC 4574 The Session Description Protocol (SDP) Label Attribute RFC 4582 The Binary Floor Control Protocol RFC 4583 Format for Binary Floor Control Protocol (BFCP) Streams RFC 4585 Extended RTP Profile for RTCP-Based Feedback RFC 4587 RTP Payload Format for H.261 Video Streams RFC 4629 RTP Payload Format for ITU-T Rec. H.263 Video RFC 4796 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 43

TANDBERG and SIP

TANDBERG Codian 2200 Series IPVCR

The TANDBERG Codian 2200 Series of IP video conference recorders are stand alone appliances supporting up to 10 recording ports and 20 playback ports per chassis. Multiple chassis can be combined throughout the network, 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 49152 to 65535. 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

5060 5060

Codian 2200

Function Port Type Direction SIP Messages 5060 UDP/TCP 2200 ↔ SIP Registrar/Proxy SIP Messages 5061 TLS (TCP) 2200 ↔ 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

3500 Site A

Codian VCS Protocol Type VCS Site A 3500 49152:65535 5060 SIP Request UDP/TCP VCS Defined 5060 49152:65535 5061 SIP Request UDP (TLS) 5061 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 44

TANDBERG and SIP

For SIP registration and call setup/control signaling, the Codian 2200 will use a random port within the range of 49152 to 65535. 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 an 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

Software 2.2(1.0) Video

Video Video IP UDP RTP Total size Header Header Header (max) (max) H.261 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.263/+/++ 1400 bytes* 20 bytes 8 bytes 12 bytes 1440 bytes H.264 1400 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 45

TANDBERG and SIP

Jitter and Latency

RFC (Request for Comment) Support

The following RFC’s are supported in the Codian 2200 Series IPVCR product line as of software version 2.2(1.0). RFC 2190 RTP Payload Format for H.263 Video Streams RFC 2327 SDP: Session Description Protocol RFC 2617 Digest Authentication RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RFC 2976 The SIP INFO Method RFC 3261 SIP: Session Initiation Protocol RFC 3264 An Offer/Answer Model with SDP RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification RFC 3555 MIME Type Registration of RTP Payload Formats RFC 3984 RTP Payload Format for H.264 Video RFC 4573 MIME Type Registration for RTP Payload Format for H.224 draft-levin- mmusic-xml-schema-media-control

D50444 Page 46

TANDBERG and SIP

TANDBERG Video Communication Server

The TANDBERG Video Communication Server (VCS) delivers three unique applications in one centralized device. It features innovative video call forwarding capabilities through TANDBERG FindMe™, extends SIP support to network administration, and firewall traversal.

TANDBERG SIP Server Traversal Interaction

1719 7001

TANDBERG VCS Control TANDBERG VCS Expressway

VCS Control Protocol Type VCS Expressway 1719 SIP Messages TCP/TLS 7001 Note: Only one of the transport types (TCP or TLS) is used at any one time.

TANDBERG SIP Server Non-Traversal Interaction

5060/ 5060/ 5061 5061

VCS Control/Expressway VCS Control/Expressway

VCS Control Protocol Type VCS Expressway 5060 SIP Messages UDP/TCP 5060 5061 SIP Messages TCP(TLS) 5061 Note: Only one of the transport types (UDP, TCP or TLS) is used at any one time.

D50444 Page 47

TANDBERG and SIP

TANDBERG VCS Control to VCS Expressway Traversal Interaction

TANDBERG VCS Control TANDBERG VCS Expressway

VCS Control Protocol Type VCS Expressway 1719 SIP Requests TCP 7001 1719 SIP Responses TCP 7001 50000:51999 Media (Audio) UDP/RTP 2776 50000:51999 Media (Audio) UDP/RTCP 2777 50000:51999 Media (Video) UDP/RTP 2776 50000:51999 Media (Video) UDP/RTCP 2777 50000:51999 Media (Dual Streams) UDP/RTP 2776 50000:51999 Media (Dual Streams) UDP/RTCP 2777 50000:51999 Media (FECC) UDP/RTP 2776 50000:51999 Media (FECC) UDP/RTCP 2777 Note: all ports illustrated in the above example can be administratively configured. SIP ports will start at configured port and increment by 1 for every new traversal server zone.

To increase the security of a traversal connection, the SIP connection between the traversal proxy (e.g. TANDBERG VCS Control) will require the manual configuration of the port used for connectivity in addition to the previous methods used for authentication. This change in the functionality does not increase the ports required for a traversal connection through a firewall, but does modify the requirements.

D50444 Page 48

TANDBERG and SIP

TANDBERG VCS Control to VCS Expressway Call Flow

VCS Control VCS Expressway

SIP Type VCS Protocol Type VCS Type SIP UA Control Expressway UA Endpt. TCP 5060 SIP Messages TCP 5060 TCP Endpt. Defined Defined Endpt. TCP 5060 SIP Messages TCP 5060 TCP Endpt. Defined Defined Endpt. UDP/RTP 50000 - 51999 Media (Audio) UDP/RTP 2776 UDP/RTP Endpt. Defined Defined Endpt. UDP/RTCP 50000 - 51999 Media (Audio) UDP/RTCP 2777 UDP/RTCP Endpt. Defined Defined Endpt. UDP/RTP 50000 - 51999 Media (Video) UDP/RTP 2776 UDP/RTP Endpt. Defined Defined Endpt. UDP/RTCP 50000 - 51999 Media (Video) UDP/RTCP UDP/RTCP Endpt. Defined Defined Endpt. UDP/RTP 50000 - 51999 Media (Dual UDP/RTP 2776 UDP/RTP Endpt. Defined Streams) Defined Endpt. UDP/RTCP 50000 - 51999 Media (Dual UDP/RTCP 2777 UDP/RTCP Endpt. Defined Streams) Defined Endpt. UDP/RTP 50000 - 51999 Media (FECC) UDP/RTP 2776 UDP/RTP Endpt. Defined Defined Endpt. UDP/RTCP 50000 - 51999 Media (FECC) UDP/RTCP 2777 UDP/RTCP Endpt. Defined Defined Note: all ports illustrated in the above example can be administratively configured. SIP ports will start at configured port and increment by 1 for every new traversal server zone.

To increase the security of a traversal connection, the SIP connection between the traversal proxies (e.g. TANDBERG VCS Control) will require the manual configuration of the port used for connectivity in addition to the previous methods used for authentication. This change in the functionality does not increase the ports required for a traversal connection through a firewall, but does modify the requirements.

D50444 Page 49

TANDBERG and SIP

STUN Client-to-VCS Expressway Interaction

The TANDBERG VCS Expressway can be configured to provide two types of STUN services to traversal clients. These services are STUN Binding Discovery and STUN Relay. The STUN Binding Discovery service provides information back to the client about the binding allocated by the NAT firewall being traversed. The STUN Relay service (formerly known as TURN) allows a client to ask for data to be relayed to it from specific remote peers via the relay server and through a single connection between the client and the relay server.

STUN Binding Discovery This technology works based on establishing an outbound STUN discovery request via the firewall to the VCS Expressway, which has been configured as a STUN discovery server. Upon receipt of the message, the VCS Expressway responds to the client with information about the allocated NAT binding, i.e. the public IP address and the ports being used. The client can then provide this information to other systems which may want to reach it, allowing it to be found even though it is not directly available on the public internet.

RND UDP 3478

RND UDP/RTP 60000 - 61200

RND UDP/RTCP 60000 - 61200

STUN Client TANDBERG VCS Expressway

Function Port Type Direction STUN Request 3478 UDP Client → VCS Expressway RTP Media 60000 - 61200 UDP Client → VCS Expressway RTP Media 60000 - 61200 UDP Client → VCS Expressway Note: all ports illustrated in the above example can be administratively configured.

D50444 Page 50

TANDBERG and SIP

STUN Relay

This technology works based on establishing an outbound a STUN Allocate request to the VCS Border Controller which is acting as the STUN relay server. The sending of this request opens a binding on the firewall. Upon receipt of the request, the VCS Border Controller opens a public IP port on behalf of the client, and reports back to the client this IP address and port, as well as details of the firewall binding. The client can then provide this IP address and port to other systems which may want to reach it. The client can restrict the remote address and ports from which the relay should forward on media. Any incoming calls to this IP address and port on the VCS server are relayed via the allocated binding on the NAT to the client.

RND UDP 4678

RND UDP/RTP 60000 - 61200

RND UDP/RTCP 60000 - 61200

STUN Client TANDBERG VCS Expressway

RFC (Request for Comment) Support

The following RFC’s are supported in the TANDBERG VCS as of software version X2.0. RFC 3261 SIP: Session Initiation Protocol RFC 3263 Locating SIP Servers RFC 3264 An Offer/Answer Model with SDP RFC 3327 SIP Extension Header Field for Registering Non-Adjacent Contacts RFC 3581 Symmetric Response Routing RFC 3880 Call Processing Language (CPL): A Language for User Control of Internet Telephony Services RFC 3944 H.350 Directory Services RFC 4028 Session Timers in SIP

D50444 Page 51

TANDBERG and SIP

LIST OF TERMS

IETF: The Internet Engineering Task Force (IETF) develops and promotes Internet standards. Jitter: Jitter is the variation in network latency. Typically, video systems should be able to accommodate jitter up to at least 100ms. LAN: Local Area Network. Latency: The time between a node sending a message and receipt of the message by another node. Typically any latency is supportable, providing it is constant, but large latencies may result in a poor videoconference. Packet Loss: Occurs when data is lost from the bit-stream, typically on public networks such as the Internet. Packet Loss can occur when passing through a router and has a higher chance of occurring as the hop count is increased. Packet loss can also occur at the receiver end when the transmitter sends data too quick. Proxy: a proxy server is a server which services the requests of its clients by forwarding requests to other servers. Port: In TCP and UDP IP networks, an endpoint to a logical connection. The port number identifies what type of port it is. For example, port 80 is used for HTTP traffic. RFC: Request for Comments (RFC) documents are a series of memoranda encompassing new research, innovations, and methodologies applicable to Internet technologies. RTCP: Real Time Control Protocol. RTCP provides a mechanism for session control and has four main functions: quality feedback, participant identification, RTCP packet transmission rate control and session control information transmission. The primary function of RTCP is to provide feedback. RTP (Real Time Protocol): Described by H.225 on how to handle packetization of audio and video data for H.323. RTP does provide information to reconstruct real time data such as: payload type identification, sequence numbering and time stamping. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. SIP: Session Initiation Protocol (SIP) is an application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. TCP (Transport Control Protocol): A connection oriented Layer 4 protocol. UA: User Agent is a SIP entity that interacts with the user. UDP (User Datagram Protocol): A connectionless protocol used in transmission of data over IP. While it does not require as much overhead as TCP, it is not as reliable in delivering data. .

D50444 Page 52

TANDBERG and SIP

D50444 Page 53

TANDBERG and SIP

REFERENCES

Camarillo, Gonzalo (2002) SIP Demystified, McGraw-Hill Gregory, Peter (2006) SIP Communications for Dummies: Avaya Custom Ed., Hoboken, NJ, Wiley Publishing Inc Banerjee, K. (2006) Introduction to Internet Multimedia http://geocities.com/intro_to_multimedia/SIP/ The Internet Society (2002) RFC 3261 http://geocities.com/intro_to_multimedia/RFC/RFC3261.htm Magalhaes, Ricky M. (2005) Articles & Tutorials: General Networking http://www.windowsnetworking.com/articles_tutorials/Session-Initiation-Protocol-Functions.html Ludlow, David (2002) RTFM: How does SIP work? http://ivory.vnunet.com/vnu/networkitweek/features/2059672/rtfm-does-sip-work http://en.wikipedia.org/wiki/Session_Initiation_Protocol http://www.telecomspace.com/vop-sip.html http://www.codian.com./support/viewfaqentry.php?id=84&topic=&product

D50444 Page 54