Application Note

Transcript

Application Note Polycom Video Conferencing and SIP in VSX Release 7.0 Presented by Mike Tucker Tim O’Neil Polycom Video Division July 2004 This document describes the SIP functionality in Version 7.0 of the VSX family of Polycom video endpoints. This family includes the VSX 8000 Series, VSX 7000 Series, the VSX 3000 and the V500.  2004, Polycom, Inc. All rights reserved. Polycom and the Polycom logo design are registered trademarks. ViewStation, iPower, VSX, Vortex, People+Content, Siren 14 are all trademarks of Polycom, Inc. in various countries. All other trademarks and registered trademarks are the property of their respective owners. Introduction Polycom is the market-leading open-standards collaboration company. Polycom's strategy affords customers the widest range of choices. The freedom that standards provide lets you, the customer make the best choices to meet your requirements. Migrating from TDM to H.323 or SIP is a natural progression. There are standards based choices, dependent on individual requirements; SIP and H.323 are not mutually exclusive. Customers and manufactures can easily migrate from H.323 to SIP; this is a value decision that is becoming easier to justify as collaboration and IP-based communication converge to SIP. Stop the madness surrounding any talk about proprietary solutions! Customers have been paying too much for proprietary solutions for too long. Conferencing and collaboration infrastructure need to connect and standards are the unifying connection point of your infrastructure. Working with industry leaders, we are creating new solutions for our customers with partners like Avaya, Cisco, Juniper, Microsoft and Nortel. With Polycom's strategy, customers can be in the sweet spot of any new emerging protocol implementation while simultaneously providing both greater choices and the highest possible quality. Why Standards? The freedom that standards provide lets you, the customer; make the best choices to meet your requirements. And it will ensure that as your partner, Polycom will be there for you when needed. Polycom collaborative solutions, deployed on leading-edge IP and telephony networks, equal the best of breed solution for Unified Collaborative Communications (UCC). Polycom continually participates and provides leadership in international and technical standards committees. The time for converged collaborative solutions is now! The communications standards, media protocols, and multilayer routing and switching networks are converging to a point that unified collaboration is a reality. Standards are leading the way, and Polycom’s open-standards and alliances strategy promotes the greatest value for customers. Polycom’s strategy provides its customers with the greatest flexibility and cost-effectiveness demonstrating the best-ofbreed in UCC. Why SIP? SIP is protocol with the greatest promise for the convergence of IP based collaboration architectures. SIP by virtue of its providing for both session connection and session management independent of application allows for its use by multiple applications. Polycom manufactures products for the Unified Collaborative Communications market place and SIP is the protocol that is bringing the widest spread interoperability to this marketplace. Today Polycom manufactures SIP IP telephones, SIP group video conferencing systems, SIP voice conferencing media servers for the service provider market, and will ship a H.323 and SIP interoperable voice & video conferencing multipoint control unit by the end of 2004. Application convergence and Unified Collaborative Communications go hand and hand, and Polycom and SIP are leading the way. The Polycom OfficeTM With integrated video, audio, data, and Web capabilities, The Polycom Office is the only solution that offers an easy way to connect, conference, and collaborate any way you want. Work faster, smarter, and better with The Polycom Office. Polycom, Inc. develops, manufactures and markets a full range of high-quality, easy-touse and affordable voice and video communication endpoints, video management software, web collaboration software, multi-network gateways, and multi-point conferencing and network access solutions. Its fully integrated end-to-end solution, The Polycom Office, is supported by the Polycom accelerated communications architecture and enables business users to immediately realize the benefits of integrated video, voice data and web collaboration over rapidly growing converged networks. 1.0 Overview of SIP Support in VSX Version 7.0 VSX Version 7.0 includes support for the Session Initiation Protocol (SIP). SIP is a signaling protocol used for establishing sessions in an IP network. A session could be a two-way telephone call, a videoconference call or a collaborative multimedia conference. SIP is being developed by the SIP Working Group, within the Internet Engineering Task Force (IETF). The protocol currently has the status of a proposed standard and is published as IETF RFC 3261. SIP closely resembles other Internet protocols such as HTTP, consequently, SIP works well with Internet applications. Like H.323, SIP is designed to address the functions of signaling and session management within a packet-based telephony and/or video network. SIP provides the capabilities to: • • • • • Determine the location of the target end point. Determine the media capabilities of the target end point. Determine the availability of the target end point. Establish a session between the originating and target end point. Handle the forwarding, transfer and termination of calls. SIP also supports many other features and advanced calling and conferencing functions. A SIP network is composed of four types of entities: 1) a User Agent, 2) a Proxy Server, 3) a Redirect Server and 4) a Registrar Server. Each entity serves a specific role in a SIP communications network. A SIP client is an entity which initiates requests and a SIP server is an entity which responds to requests. A single entity can function as both a client and a server. Sometimes, one physical device has the functionality of more than one logical SIP entity. For example, a single server may act as both a Proxy Server and Registrar Server. In SIP, a video endpoint such as the VSX is known as a User Agent (UA). Some examples of User Agents in a SIP network are: IP-phones, video endpoints (such as VSX), PC-based soft clients such as Windows Messenger, telephony gateways, call agents and automated answering services. The Proxy Server is a call-control device that that receives SIP requests from a client and then forwards the requests to other server entities, or to a terminating UA endpoint. Proxy servers can provide functions such as authentication, authorization, network access control, routing, reliable request retransmission, and security. A Redirect Server is a SIP server that accepts a SIP request directed toward a particular user agent and returns an alternate URI to the initiating UA client. Redirect servers form the basis of sophisticated forwarding and follow-me services. A Registrar Server processes SIP registration requests from User Agent clients (such as VSX) for registration of their current location. Registrar servers are often co-located with a redirect or proxy server. Typically, a User Agent will send a SIP REGISTER message to the Proxy/Registrar server which contains information about the User Agent’s SIP URI and current IP address. The Registrar server maintains a database to associate SIP URI’s with IP addresses. When the Proxy/Registrar Server receives an incoming SIP request to a particular SIP URI, it uses that database to resolve the actual IP address of the User agent and sends the request to that IP address. Figure 1.1 shows call set-up between two User Agents with the help of a Proxy server which is co-located with a Registrar server. The recipient of the call ([email protected]) has registered with the Registrar server prior to the call and Fred’s current location is stored in the location database. The caller ([email protected]) has a means to discover the location of the proxy/registrar server for Company 2, this is typically accomplished using DNS. Once the INVITE has reached Company 2’s Proxy server, the Proxy server uses the location database to determine the current address of Fred’s User Agent. Figure 1.1 – SIP Call Flow Example with Proxy Example SIP Call Flow 1. The UAC ([email protected]) wants to make a call to [email protected]. First, the UAC makes a DNS query to comp2.com and looks at the SIP service record, which is the address of the SIP Proxy for Company 2. The UAC sends the SIP INVITE message to the Proxy for [email protected]. Note that there are other means by which the SIP INVITE can be routed to comp2’s SIP Proxy server. For example, the UAC may send the INVITE to its own provisioned outbound proxy and that proxy then determines how to forward the INVITE (possibly doing a DNS query). 2. The Proxy server immediately responds with a 100 (Trying) provisional response. 3. The Proxy server looks-up Fred’s current location in the Location Database (which it knows because Fred previously registered with the Registrar server co-located with the Proxy). 4. The Location Database returns Fred’s current location: SIP address [email protected] and its IP address. 5. The Proxy server creates a new INVITE message based on the original INVITE message, but with the request URI in the start line changed to [email protected]. The Proxy server sends this request to the UAS at [email protected]. 6. The UAS responds first with a 100 (Trying). 7. The UAS responds with a 180 (Ringing) response. 8. The Proxy server forwards the 180 (Ringing) response back to the calling UA. 9. When the call is accepted by the user (for example, by picking up the handset) the UAS at [email protected] sends a 200 (OK) response. In this example, Fred’s UAS inserts a Contact header into the response with the value [email protected]. If the proxy decided to take itself out of the route by not specifying itself in the record-route header field, further SIP communication will be sent directly between the endpoints and not via the Proxy Server. This action is optional. 10. The Proxy forwards the 200 (OK) response back to the calling UAC. 11. The calling UA sends an ACK directly to Fred’s UA (according to the Contact header it found in the 200 (OK) response). VSX Version 7.0 enables the VSX video endpoint to participate as a User Agent in a SIP video network. It enables the VSX to: 1. Set its SIP use name (i.e. its URI in the SIP network). 2. To designate a Registrar Server and send SIP REGISTER messages to that Registrar server. 3. To designate a Proxy Server and to route all outgoing SIP requests to that Proxy Server. 4. To initiate outgoing, or answer incoming, SIP calls. 2.0 SIP Functionality Overview Version 7.0 for the VSX-7000, VSX-3000 and the V500 includes “Basic” SIP support. “Basic” SIP supports focuses on the ability to make point-to-point calls through a SIP Proxy server and the ability to register with a SIP Registrar server (with no authentication). Only specific portions of RFC 3261 are supported in this version and some video conferencing functionality is supported using techniques which are not yet standardized. “Basic” SIP support in VSX 7.0 provides the following capabilities: 1. It enables the VSX family products to operate in the Microsoft Live Communication Server SIP infrastructure and provides video/audio interoperability with the Windows Messenger 5.0 client. 2. It enables the VSX family products to operate in the Nortel MCS SIP infrastructure and provides video/audio interoperability with the Nortel PC Multimedia client. 3. It utilizes high-quality H.264 video and wideband (Siren 14) audio when calling between two VSX family endpoints. 4. It enables the use of far-end camera control (FECC) when calling between two VSX family endpoints. It is important to note that videoconferencing support in SIP is in an early stage and many aspects of SIP videoconferencing are “pre-standard”. Therefore, this SIP release is not intended for use for general videoconferencing as an alternative to H.323-based videoconferencing. Rather, it is intended to enable SIP field trials and interoperability testing. Specifically, the following SIP functionality in this release is pre-standard and may therefore be modified, or eliminated, in future releases. FastUpdate (Intraframe) Requests: The output of a video codec is an image frame. The frame can carry complete information about a picture. These frames are known as Intra frames. In order to save bandwidth, other frames can carry only changes relative to previously sent frames. Frames carrying relative information are known as Inter frames. In an IP videoconferencing session, media packets may be dropped due to packet loss in the network. Thus in the H.245 control protocol, which is used in H.323, there is a command called the Video fast update command which is used by the receiver to request updates for video frames from the transmitter. When a transmitter receives a fast update command, it responds by sending a video intraframe which does not require any information from previous frames to decode. SIP currently has no mechanism for fast update and there are competing proposals for adding this capability to SIP. In this release, Polycom has implemented fast update requests using the SIP INFO message as per the IETF draft “draft-levin-mmusic-xmlschema-media-control-03.txt”. Far-end Camera Control: In H.323 conferencing, the protocol described in Annex Q is used by one endpoint to control the camera at the far endpoint. Annex Q is based on the H.281 far end camera control (FECC) protocol. In Annex Q, H.281 signaling is carried using H.224 in an RTP channel. Currently there is no standardized method to implement FECC in SIP. In this release, Polycom has implemented SIP FECC in a manner very similar to H.323 Annex Q by signaling the RTP channel for FECC using the following lines in the SDP: m=data 49138 RTP/AVP 100 a=rtpmap:100 H224 where 49138 is a dynamic port number and 100 is a dynamic RTP payload number. Specification of Video Framerates, Resolutions and Annexes: Currently there is no standard mechanism in SIP for signaling the frame rate, frame resolution, maximum bitrate or video annexes to be used in a video channel in the Session Description Protocol (SDP) message body. In this release, Polycom is using the syntax described in IETF draft “draft-ietf-avt-rfc2429-bis-01” (for H.263) and “draft-ietf-avt-rfc2032-bis-01” (for H.261) to enable this support. The syntax uses the "a=fmtp" attribute to carry codec specific parameters. An example SDP body which uses this syntax is shown here: m=video 49156 RTP/AVP 34 96 31 a=rtpmap:34 H263/90000 a=rtpmap:96 H263-1998/90000 a=fmtp:96 SQCIF=1 QCIF=1 CIF=1 CIF4=2 CUSTOM=352,240,1 CUSTOM=704,480,2 F J T a=rtpmap:31 H261/90000 a=fmtp:31 CIF=1 QCIF=1 3.0 Setting up SIP Operation The VSX is a multi-protocol videoconferencing endpoint. It can be configured to use H.323, H.320 and SIP and the priority order of these protocols can be specified. Thus for example, if the VSX is configured to enable H.323 and SIP and if H.323 is given priority, then when a call is attempted, an H.323 call will be attempted first, if that call fails, then a SIP call will be attempted. In order to utilize SIP in VSX Version 7.0, two primary setup functions must be performed: 1. The SIP protocol must be enabled and its priority must be established. 2. SIP parameters such as transport protocol, proxy server, registrar server must be set. In order to enable the SIP protocol, the user must enter the “Call Preferences” screen (System Æ Admin Settings Æ IP Æ Network Æ Call Preferences) and enable SIP as shown in Figure 3.1. Then, the user can set the protocol priority by selecting “Next” and setting the relative priorities by using the drop-down lists as shown in Figure 3.2. Due to the complexities of routing calls in a mixed H.323 and SIP network, at this time, it is recommended that either SIP or H.323 be selected, but not both. Figure 3.1 Enabling SIP on the Call Preference Screen To set the SIP parameters, the user must enter the SIP Settings screen (System Æ Admin Settings Æ IP Æ Network Æ SIP) as shown in Figure 3.3. The user may configure the system to use a proxy and registrar server using this screen. Note that SIP does not require the use of a proxy server and registrar server, so these fields can be left blank. SIP Proxy Server – the user may enter the DNS name or IP address of the SIP Proxy Server. If this field is left blank, no proxy server will be used. If no port is entered, then SIP signaling is sent to the proxy server on port 5060. In order to specify a port, the user enters an IP address (or DNS name) and the port as follows: 216.54.150.112:5070 In this case, all SIP signaling will be sent to Port 5070 of the SIP Proxy Server at IP address 216.54.150.112. SIP Registrar Server – the user may enter the DNS name or IP address of the SIP Registrar server. In some cases the SIP Proxy server and SIP Registrar server will be the same, but they can be different. If this field is left blank, no registrar server will be used. If no port is entered, then SIP signaling is sent to the registrar server on port 5060. In order to specify a port, the user enters an IP address (or DNS name) and the port as follows: 216.54.150.112:5070 In this case, all SIP registration messages will be sent to Port 5070 of the SIP Registrar Server at IP address 216.54.150.112. SIP User Name – the user may enter the SIP user name for the system. If this field is left blank, the system’s IP address will be used as the SIP user name. SIP Password – the user may enter a password which is used to generate a response to a Digest or NTLM challenge from a Registrar server or peer endpoint. Since authentication in not implemented in this release, this field is currently ignored. Transport Protocol – the user must choose either TCP or UDP as the transport protocol used for SIP signaling (the Microsoft LCS requires TCP and the Nortel MCS requires UDP). Only one transport protocol can be selected, so selecting UDP, unselects TCP and vice versa. Figure 3.2 Setting SIP Protocol Priority Figure 3.3 SIP Settings Screen Note that the VSX will only register with the SIP Registrar Server when it starts (i.e. reboots). Navigating to the SIP Settings screen and entering information in the SIP Proxy Server field or the SIP Registrar Server field will not cause the VSX to re-register. The user must re-start the system to initiate the registration process. 4.0 SIP Operation Placing a SIP call is accomplished in a manner identical to placing a H.323 call or an ISDN call. From the “Place a Call” screen shown in Figure 4.1, the user enters the SIP URI (which is routable by the SIP Proxy server, or the IP address of another endpoint and then presses the call button on the remote. Figure 4.1 – Placing a SIP Call Important Notes: 1. On the VSX 8000, VSX 7000 and the VSX 3000, the user can manually designate the protocol to be used for the call by using the drop-down list shown in Figure 4.1. By manually selecting the protocol, the user overrides the protocol preferences which where designated on the “Network Dialing” screen (see Section 3). 2. On the V500, the protocol selection drop-down list is not present on the “Place a Call” screen. Thus, the user cannot override the protocol preference order set on the “Network Dialing” screen. 3. Due to the complexities of routing calls in a mixed H.323 and SIP network, at this time it is recommended that either the SIP or H.323 protocol be selected, but not both. Selecting only one protocol will simplify SIP, or H.323 testing. Operating the VSX with the Live Communication Server and Windows Messenger 5.0 In order to operate the VSX in the Microsoft LCS SIP infrastructure, four primary setup operations must be performed: 1. The LCS must be configured to trust any SIP signaling or registrations on a port other than 5060 (e.g. 5070). This must be done because the VSX does not currently support NTLM authentication. The steps required to set up this trusted port are described in the Appendix A. 2. The LCS server must be configured with an account with a SIP user name to be assigned to the VSX. The steps required to do this are described in Appendix B. 3. The VSX must be configured to operate with the LCS. This requires the following steps: • SIP must be enabled on the Call Preferences screen. • The proxy server must point to the trusted port of the LCS (eg. 216.54.150.112:5070). • The registrar server must point to the trusted port of the LCS (eg. 216.54.150.112:5070). • TCP must be selected as the SIP transport protocol. • The user name must be configured to match the account set up on the LCS. • The password must be configured to match the account set up on the LCS (this field is actually ignored in VSX Release 7.0 because the VSX does not perform authentication. In future releases, the password in this field will be required to match the account password on the LCS). 4. The account used by the VSX must be configured to enable the LCS to send presence information to all the Windows Messenger clients which are registered to the LCS and which have added the VSX account to their contact list. The steps required to do this are described in Appendix C. Operating the VSX with the Nortel MCS SIP Infrastructure and the Nortel PC Multimedia Client Setting up the Nortel Multimedia Communication Server (MCS) to enable SIP Proxy services is outside the scope of this document. That information is available from the Nortel website. Once the MCS is configured, two primary setup operations must be performed to enable the VSX to operate in this SIP infrastructure: 1. The MCS must be configured with a trusted SIP account. The account must be trusted because the VSX does not support authentication in this release. 2. The VSX must be configured to operate with the MCS. This requires the following steps: • SIP must be enabled on the Call Preferences screen. • The proxy server must point to the MCS (eg. 216.54.150.112). • The registrar server must point to the MCS (eg. 216.54.150.112). • UDP must be selected as the SIP transport protocol. • The user name must be configured to match the account set up on the MCS. • The password must be configured to match the account set up on the MCS. • The steps required to setup the MCS PC client are described in Appendix D. Appendix A – Configuring a Trusted Port on the LCS There are two steps which must be accomplished. First a static route to a port other than 5060 (e.g. 5070) must be set up using the LCS management console, then this route must be set as trusted using the Windows Management Instrumentation (WMI) Tester, also called WBEMTest. Configuring Static Routes To configure a static route, perform the following steps: 1. Open the Computer Management console. 2. In the console tree, double-click Services and Applications. 3. Right-click Real-Time Communications Server and then click Properties. 4. Click the Routing tab. 5. Click Add to create a static route to the VSX. 6. Enter wildcards in the User and Domain boxes. 7. Select the Phone URI check box. 8. Click IP Address. 9. Enter any IP address. 1 10. In the Transport dropdown list box, click TCP. 11. In the Port box, enter the TCP trusted listening port (5070). 12. Select the Replace host in request URI check box. 13. Click the OK button to save your settings. Figure A.1 Sample Route Configuration Configure Connection Settings Windows Management Instrumentation (WMI) Tester, also called WBEMTest, is the tool used to view and modify the settings for the connections between the LCS Server and SIP user agents. Due to the limitations of authentication capabilities of the VSX, trust settings must be applied to the listening address. WARNING Configuring trust allows messages sent on the specified trusted connections to be unchallenged for authentication. For example, setting up a static route with wildcards in both the User and Domain fields and then setting that static route as trusted will stop the server from presenting authentication challenges for all calls from all users and all domains on the specified transport type because all these settings have been marked “trusted.” Trusted connections may be abused as a way to bypass authentication and other security mechanisms that are otherwise in place. Administrators should take care to minimize the potential risks associated with trust relationships. It is required that administrators configure a separate host for interacting with the gateway. In addition, the trusted listening address on the server must be secured using: a. A firewall b. Internet Protocol security (IPSec) c. Or other means as described in the Microsoft® Windows Server™ 2003 administration documentation In addition to configuring trust, the server must be configured to throttle the connection as a server connection, drop route headers and allocate the appropriate resources accordingly. To apply settings to a listening address and port combination and a static route in order to enable IP-PSTN connectivity, perform the following steps: 1. On the taskbar, click Start, and then click Run. 2. In the Open text box, type Wbemtest. 3. Click Connect. 4. In the Namespace box, type root\cimv2, and then click Connect. Figure A.2 The WBEMTest Connect dialog box 5. Under IWbemServices, click Enum Classes. Figure A.3 The Windows Management Instrumentation Tester dialog box 6. Select Recursive and then click OK. Figure A.4 The Superclass Info dialog box 7. Double-click MSFT_SIPListeningAddressData to open the Object Editor dialog box. Figure A.5 The Recursive Classes Query Result dialog box 8. Click Instances to open the Query Result dialog box. Figure A.6 The Object Editor dialog box for MSFT_SIPListeningAddressData 9. Double-click each instance ID until you have chosen the one for transport type TCP. Figure A.7 The Instances Query Result dialog box for MSFT_SIPListeningAddressData 10. The window shown in Figure A.8 will appear when you click on one of the listening address instances. To determine if it is the correct one, look in the Properties window and verify that Port is 5070 and TransportType is TCP. If you have opened the wrong instance, click Close and select the other listening address instance. If there are more than two listed, search through the instances until you find the appropriate one. If you have more than one IP address, use the IPAddress property to ensure you are configuring the appropriate listening address. 11. Highlight the TreatAllConnectionsAsServer property and click the Edit Property button. Figure A.8 The Object Editor dialog box for the TCP instance of MSFT_SIPListeningAddressData 12. Select Not NULL and type TRUE in the Value text box. 13. Click Save Property. Figure A.9 The Property Editor dialog box for the TreatAllConnectionsAsServer property 14. Highlight the TreatAllConnectionsAsTrusted property and click Edit Property. Figure A.10 The Object Editor dialog box for the TCP instance of MSFT_SIPListeningAddressData 15. Select Not NULL and type TRUE in the Value text box. 16. Click Save Property. Figure A.11 The Property Editor dialog box for the TreatAllConnectionsAsTrusted property 17. Highlight the DropRouteHeaders property and click Edit Property. Figure A.12 The Object Editor dialog box for the TCP instance of MSFT_SIPListeningAddressData 18. Select Not NULL and type TRUE in the Value text box. 19. Click Save Property. Figure A.13 The Property Editor dialog box for the DropRouteHeaders property 20. Click Save Object in the Object Editor for MSFT_SIPListeningAddressData dialog box for this instance. 21. Click Close to close the Query Result dialog box.. 22. Click Close to close the Object Editor for MSFT_SIPListeningAddressData dialog box. Appendix B – Setting up a SIP Account on the LCS In order to set up a SIP account on the LCS and use it on the VSX, three major steps must be performed: 1. A user account must be set up in the domain on which the LCS is running, 2. The user account must be enabled to use Live Communication Services 3. The VSX must be configured with the same user name and password (note: the password field is currently ignored, but will be used in future releases). To set up a user account in the domain on which the LCS is running, use the following steps. First open up the “Manage Your Server” dialog and click on “Manager users and computers in Active Directory” as shown in Figure B.1. Figure B.1 – Manage Your Server Dialog Then right click on “Users”, select “New” and then “User” as shown in Figure B.2. Figure B.2 – Creating a new User Then follow the steps to create a new user as shown in Figures B.3 through B.5. Figure B.3 – Creating a new User Figure B.4 – Creating a new User Figure B.5 – Creating a New User Then right-click on the new user and select “Properties” as shown in Figure B.6. Figure B.6 – Selecting the new User In the dialog box, click on the “Live Communication Server” tab, enable LCS services for the user, enter a SIP user name (URI) and select the home server for this user as shown in Figure B.7. Figure B.7 – Enabling LCS for the new user The LCS server may need to be stopped and restarted before this user is recognized by the LCS. That is accomplished through the LCS management console. Appendix C – Enabling LCS to Send Presence Information about the VSX’s SIP Account The account used by the VSX must be configured to enable the LCS to send presence information to all the Windows Messenger clients which are registered to the LCS and which have added the VSX account to their contact list. The simplest way to do this is to sign on using the VSX’s SIP account using a Windows Messenger client. Then, open the Options Dialog by selecting “Tools Æ Options” from the main Messenger menu as shown in Figure C.1. Figure C.1 – Opening the Options Dialog Next select the Privacy Tab in the Options Dialog. For new accounts, “Alert me when other people add me to their contact list” will normally be selected as shown in Figure C.2. This option should be unchecked as shown in Figure C.3. Figure C.2 – Select Privacy Tab on the Options Dialog Figure C.3 – Deselect “Alert me when other people….” Click on “OK” to close the Options Dialog and then sign out from the VSX’s account. Appendix D – Setting up the Nortel MCS PC Client The MCS PC client software is provided by Nortel. Version 3.0 of the client is required since it is the first version which supports H.263 video. The PC client is typically used with a Logitech camera, and can be set up to use the Nortel i2004 IP phone for all audio. The most reliable manner for the client to produce video in a multipoint call is to set it for H.263 QCIF, and to set the video settings to a custom bandwidth setting as described here. Figure D.1 – Nortel PC Client Toolbar The operation of MCS client is modified using the “Preferences” toolbar. The following options should be set under “Video”: 1. Select “Custom Setting” and “Configure” 2. Set the video codec to H.263 3. Set the Video bit rate to 320kbps, 4. Set the frame rate to 15 fps 5. Set the resolution to 176x144 (QCIF) These are settings which are known to work. There are other settings which will also enable calls to be successfully placed between the VSX and PC multimedia clients. Figure D.2 – Nortel PC Client Video Preferences Dialog At this point, the endpoints should successfully register with the MCS5100 server and it will be possible to place calls between Nortel PC clients, and to VSX endpoints. However, on some occasions the MCS client will not send video to the far end. This appears to be quickly resolved by toggling the “Start Camera” and “Stop Camera” function. The MCS client can also be configured to use the Nortel i2004 IP phone. However, this should only be used in multipoint calls, as it appeared that the phone does not work in point-to-point calls with VSX endpoints (perhaps due to the audio and video streams coming from two separate IP addresses). Figure D.3 – Nortel PC Client i200x Preferences Dialog