SIP. D50444 revision 1.1

54 

Loading....

Loading....

Loading....

Loading....

Loading....

Full text

(1)

SIP

D50444 revision 1.1

(2)

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

(3)

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

(4)

TANDBERG and SIP

DOCUMENT REVISION HISTORY

Rev 1.0 Initial Version

(5)

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).

(6)

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.

(7)

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

(8)

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

(9)

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

180 Ringing

181 Call Is Being Forwarded

182 Queued

(10)

TANDBERG and SIP 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

(11)

TANDBERG and SIP

5xx Server Failure Responses

500 Server Internal Error

501 Not Implemented: The SIP request method is not implemented

502 Bad Gateway

503 Service Unavailable

504 Server Time-out

505 SIP Version Not Supported

513 Message Too Large

580 Precondition Failure 6xx Global Failure Responses

600 Busy Everywhere

603 Decline

604 Does Not Exist Anywhere

606 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.

(12)

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

(13)

TANDBERG and SIP

TANDBERG MXP Endpoints

Software F2-F6 SIP Server Interaction

5060 5060

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

Streams) UDP/RTP N/A 2330

2331 N/A Media (Dual

Streams)

UDP/RTCP N/A 2331

2332 N/A Media (FECC) UDP/RTP N/A 2332

2333 N/A Media (FECC) UDP/RTCP N/A 2333

(14)

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 (ms) Audio size IP Header UDP Header RTP Header Total

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 size (max) IP Header UDP Header RTP Header Total (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.

(15)

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: <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.

(16)

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

(17)

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

(18)

TANDBERG and SIP

TANDBERG MXP Personal Series Endpoints

L2-L5 SIP Server Interaction

5060 5060 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.

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

Streams)

UDP/RTP N/A 2330

2331 N/A Media (Dual

Streams)

UDP/RTCP N/A 2331

2332 N/A Media (FECC) UDP/RTP N/A 2332

2333 N/A Media (FECC) UDP/RTCP N/A 2333

(19)

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

Audio Length (ms) Audio size IP Header UDP Header RTP Header Total

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

L2-L5 Video

Video Video size (max) IP Header UDP Header RTP Header Total (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

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 for more information) or

(20)

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

(21)

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

(22)

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

(23)

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

(24)

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

Streams)

UDP/RTP N/A 2330

2329 N/A Media (Dual

Streams) UDP/RTCP N/A 2331

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.

(25)

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

Audio Length (ms) Audio size IP Header UDP Header RTP Header Total

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 20 ms 160 bytes 20 bytes 8 bytes 12 bytes 200 bytes

J3-J4 Video

Video Video size (max) IP Header UDP Header RTP Header Total (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

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

(26)

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: <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 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

(27)

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

(28)

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 4500

VCS Protocol Type VCS Site A

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

Streams) UDP/RTP N/A Endpt Defined

49152:65535 N/A Media (Dual Streams)

UDP/RTCP N/A Endpt Defined

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.

(29)

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 (ms) Audio size IP Header UDP Header RTP Header Total

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

C

20ms 120 bytes 20 bytes 8 bytes 12 bytes 160 bytes

Software 2.2(1.0) Video

Video Video size (max) IP Header UDP Header RTP Header Total (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.’

(30)

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. 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 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

(31)

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 4200

VCS Protocol Type VCS Site A

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

Streams)

UDP/RTP N/A Endpt Defined

49152:65535 N/A Media (Dual

Streams) UDP/RTCP N/A Endpt Defined

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.

(32)

TANDBERG and SIP

For SIP registration and call setup/control signaling, the Codian 4200 will use a random port within the

ly)

Software 2.2(1.0) Audio

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 on 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.

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

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)

Header Header Header (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.

interface

2(1.0) softwa mtu deo payloa adjusted be nd 1400 the web

control und onfer aximum tr video packe

re, the maximum er ‘Settings’ > ‘C used for vi ences’ > ‘M d can be ansmitted tween 400 t size.’ a bytes through

(33)

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. The TANDBERG Codian 4200 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 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 4200 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 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

(34)

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 3500

VCS Protocol Type VCS Site A

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

Streams) UDP/RTP N/A Endpt Defined

49152:65535 N/A Media (Dual Streams)

UDP/RTCP N/A Endpt Defined

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.

(35)

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

Audio Length (ms) Audio size IP Header UDP Header RTP Header Total

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

C

20ms 120 bytes 20 bytes 8 bytes 12 bytes 160 bytes

Software 1.1(1.1) Video

Video Video size (max) IP Header UDP Header RTP Header Total (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.’

(36)

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. The TANDBERG Codian 3500 Gateway 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 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 3500 Gateway 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 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

Figure

Updating...

Related subjects :