Polycom Group Series with Skype for Business Server

May 10, 2017 by · 4 Comments 

Earlier this year the Polycom RealPresence Group Series video conferencing platform received official qualification for use with on-premises Lync Server 2013 and Skype for Business Server 2015 deployments.  Note that this does not yet include Skype for Business Online which is a separate qualification process that is nearing completion.  When support for direct registration to Skype for Business Online accounts in Office 365 is achieved then look for a newer article covering that simple configuration.

Background

For anyone familiar with these devices or the previous generation HDX platform then much of the configuration outlined in this article may look familiar.  These devices are commonly referred to by a host of various names, like “Standards-Based Video Systems” or “Endpoints”, or more simply a VTC (VideoTeleConfering systems).  Another common nickname is “codec” in reference to one of the unit’s primary functions as a media encoder/decoder.

Whatever they are called though the general idea is that the systems only work within other standards-based SIP and H.323 video conferencing platforms.  While this is true of most legacy systems from manufacturers like Cisco/Tandberg, LifeSize, and even older Polycom units to name the most common of them, the more recent generations of Polycom VTCs also have supported direct, native registration to Microsoft’s SIP-based communications platforms like Office Communications Server, Lync Server, and most recently Skype for Business Server.  Specifically the older HDX models were originally supported with OCS 2007 all the way up to Lync Server 2013.  The newer Group Series platform was supported originally on Lync Server 2010 and now with Lync Server 2013 and Skype for Business Server 2015.

It is important to understand that for Skype for Business Server environments the Group Series can be involved in one of two ways.  Either natively, as this article discusses, or via an interoperability solution like RealConnect which was outlined in this article from a few years ago.  Also keep an eye out for an upcoming article on the new interoperability service provided in Skype for Business Online known as RealConnect for Office 365, or more generically as Cloud Video Interop (CVI).

When the Group Series system is leveraging the native support model it will register as a Skype for Business account and do most of the things one would expect a registered client to do: support presence states, peer calling, join Skype Meetings directly to the AVMCU, etc.  But when coming through an interoperability solution the VTC is only able to call into Skype Meetings, there is no presence or peer calling support as the VTCs are not able to actually register to the Skype for Business environment.

Prerequisite Configuration

One of the most important concepts to understand when dealing with solutions like the Group Series or VVX phones which support multiple different platforms is that entering information as basic as user credentials may not always be entirely straightforward.  As explained in this previous article Windows user credentials can be used in different formats which do not always use the same names, depending on how the account was originally setup.  As more organizations move to Office 365 then the opportunities are reduced for scenarios where SMTP and SIP addresses do not match a User Principal Name (UPN).  But knowing and not just guessing the proper format to enter a set of user credentials is paramount.  This is the single most common problem seen in the field with failures to successfully register anything to Lync or Skype for Business.

When dealing with on-premises Lync and Skype for Business deployments typically both the legacy NetBIOS format as well as the newer UPN format can be used.  That being said it has long been a recommended practice to use the UPN format when possible as moving away from older methods help prepare for scenarios in which these methods no longer are applicable, as in dealing with a standard Office 365 tenancy.  So, while both formats may work in a given environment the guidance seen throughout this (and all recent articles on this blog) focuses on using the UPN format throughout all examples.

The Group Series firmware contains an embedded web server which can be used to remotely administer the device, also similar to VVX and Trio phones.  Most configuration steps shown throughout this article can be accessed using the on-screen menu system and supplied remote control, or by using the Administration menu on a RealPresence Touch (RPT) control panel.  For continuity all configuration steps outlined in this article use the web interface.

One of the unique aspects of the Group Series platform (which was carried over from the HDX) is that the configuration for SIP registration and calendaring registration is separate.  Comparatively every other native Lync or Skype for Business client or endpoint uses the same single set of credentials to access both Lync/SfB and Exchange services. 

Firmware Update

Qualification and official support for on-premises Lync Server 2013 and Skype for Business Server 2015 requires the use of at least the 6.1.0 version of the RealPresence Group Series software.  The most recent firmware can be downloaded directly from the Polycom Support site from any of the available models listed here.  The firmware package is identical between the 300, 310, 500, and 700 models.  Note that the RealPresence Medialign packages are powered by a standard Group Series 500 and thus uses the same firmware.  The RealPresence Centro product, although also powered by Group Series technology, uses a unique firmware version and thus is not currently qualified or supported with Lync/SfB.

Updating the device firmware can easily be performed from either the web interface or by using a USB flash drive.  The latest Administrator Guide can be referenced for detailed steps on each of the available formats.  Also be aware that when upgrading to any major release a new license key will need to be generated which is provided as part of the product’s purchased maintenance agreement.  What denotes a ‘major’ upgrade is any version in which either the first or second digit in the version number has been incremented.  So while moving from version 6.0.0 to 6.0.1 is a minor upgrade and does not require a new license key upgrading from 6.0.1 to 6.1.0 is a major upgrade and will require an upgrade license key, just as would an upgrade from 5.1.4 to 6.0.0.

  • To perform a system firmware upgrade over the Internet using the hosted Polycom server simply connect to the Group Series IP address (e.g. https://192.168.1.188) from a web browser via HTTPS on any computer with local network access to it.

image

  • Navigate to the Admin Settings > General Settings > Software Updates menu. Alternatively simply type “update” in the Search bar above the menu to quickly jump to the Software Updates menu.

image

  • Under the Software Server section click Check for Software Updates.

image

  • If a newer software version is available then the following screen will appear. 

image

Compare the Current Software Version to the New Software Version to determine if an upgrade license key is required.  As this example is going from 6.1.0 to 6.1.1 then a key is not required and the Group Series will not prompt for one to be entered.

  • Click Start Update to begin the upgrade process.

The browser window can be left open during the upgrade to keep track of the initial progress.  The Group Series will reboot itself several time and the entire upgrade process will take about 45 minutes to complete.  Progress throughout can also be seen on the codec’s main monitor as shown in the image below.

image

Once the upgrade has finished and the codec has returned to the main home screen the following configuration steps can be performed.

Options Key

Various additional value added capabilities of the Group Series platform are unlocked in the software by the use of special Options Keys.  These keys can be provided by the Polycom reseller when the associated add-on license has been purchased.  All of the native Microsoft capabilities of a Group Series codec are included in the Skype for Business Interoperability License.  This license was originally referred to as the “RTV Options Key” and then later the “Lync Interoperability License”.  Even though it is now referred to as “Skype for Business” it is the same options key and used for registration to both Lync 2013 and Skype for Business 2015 server platforms.

Technically this license is not required in order to perform a successful registration to a Lync or Skype for Business server.  Yet without the Options Key installed usage will be limited to peer to peer audio calls only, based on the few industry standard audio codecs that the Group Series has in common with various Lync and SfB clients.  The rest of the native capabilities hinge on support for multiple Microsoft protocols and codecs like X-H264UC, RTV, CCCP, RDP, and so on.  Without the Options Key applied no video calls or content sharing sessions can be established, and Skype for Business meetings cannot be joined. So in essence the Options Key is required to get any meaningful usage out of the system with Lync or Skype for Business.

But why allow the system to register without the options key enabled in the first place, yet limiting the functionality so much?  This is a common question and to understand the reasoning behind the behavior a brief history lesson is in order.  This options key was originally introduced in the Polycom HDX platform back in 2011 and was simply called the Real-Time Video (RTV) options key. And that was all that it provided at the time: the ability to support RTV video streams with other Office Communicator or Lync 2010 clients.  Without that license then peer-to-peer video calls with those older Microsoft Windows clients still worked as they both supported the standard H.263 video codec, limited to CIF resolution.  So at that point in time the RTV options key was truly ‘optional’ as it was simply a value-add, providing for an improved video experience by adding support for additional resolutions including up to 720 high definition.

Then Lync 2013 came along and changed everything by dropping support for the legacy H.263 video codec in the Windows clients, leaving RTV support, and adding the new X-H264UC implementation of SVC video.  This meant that an HDX could not negotiate a video session with a Lync 2013 client, unless it had the RTV options key installed as otherwise there would be no common video codecs between the two endpoints.  This change made the options key pretty much mandatory and no longer an optional purchase as deployments upgraded to Lync 2013.

Eventually additional capabilities were added to the platform by way of including more protocols and codecs from the Microsoft platform.  Support for the Centralized Conference Control Protocol (CCCP) was added to allow the HDX to allow it directly join Lync Meetings hosted on the AVMCU.  The support for CCCP was embedded into the RTV options key, but the key was not yet renamed.  Then the HDX platform was replaced by the newer Group Series platform which carried over the same options key behavior.  Soon additional features were added to this options key for the Group Series only, like support for the X-H264UC video codec.  The options key was then aptly renamed to the more descriptive Lync Interoperability License as it was now handling a lot more than just support for the legacy RTV codec.  Even more recently this was further updated to Skype for Business Interoperability License on the Group Series, but regardless of the name used the Group Series still supports both Lync 2013 and Skype for Business 2015 servers and clients.

Given the changes over time to incorporate the various, now required, protocols and codecs then it is clear why this options key is no longer optional.  The ability to register to a Lync or Skype for Business server has not been changed so that it cannot register without the license though.  So when performing tests if only a peer call can be established with a Lync/SfB client and only the audio works then this is a red flag that the options key is most likely missing from the system.  Understand that a call between two Group Series registered to Lync/SfB will work across all modalities (audio, video, content sharing) even if one or both do not include the options key because they will negotiate those streams over more preferred standards-based codecs (like H.264-High Profile for video or H.239 for content sharing).

To enable all supported features retrieve the Options Key from the purchased licensing paperwork and apply it to the codec.

  • Using the web management interface navigate to the Admin Settings > General Settings > Options menu, or simply search for “options” and then select the Options result. 

  • Enter the appropriate options key and then click Save to apply.  The Skype for Business Interoperability License should then show a checkmark icon next to it to indicate that it is successfully installed and the features are enabled.

image

Note that the example codec shown used in this article currently has a few additional licenses enabled, some of which may not be applicable to Skype for Business but can still be used with H.323 calls.

  • The Multipoint Video Conferencing option is used to enable an on-board software MCU which can only be used on standard SIP or H.323 calls.  When registered to Lync or SfB any multiparty calling scenarios are always escalated to and handled by the Lync/SfB server and this onboard MCU capability is automatically disabled during those calls anyway.

  • The Telepresence Interoperability Protocol (TIP) option is only applicable to standards-based calls involved with a certain type of Cisco endpoint family. 

  • The Advanced Video 1080p license is applicable to any platform, including Lync/SfB, and is required if attempting to send or receive RTV or SVC video streams above 720p resolution.

SIP Registration

Another uncommon facet of the Group Series codec is that it can support two separate concurrent signaling platform registrations; one via SIP and the other via H.323.  Only the SIP registration capability is applicable for use with Lync and Skype for Business .  If the system is simultaneously registered to some H.323 platform this does not adversely affect its capabilities as a native Lync/SfB endpoint but some additional attention should be paid to things like which registration ‘arm’ is used by default when manually placing outbound calls.  It would not be successful to attempt calling another standards-based system by sending a SIP dial string to a Lync or Skype for Business registrar, for example.

The Lync or Skype for Business account being used to register the Group Series can be either a standard user account or a meeting room account, as explained in detail by this recent blog article.

Automatic Discovery

To configure the Group Series to register with a Lync or Skype for Business server it is recommended to use the automatic settings by default which are outlined below.  In the event that registration is not successful then manually configuring additional settings can help troubleshoot any automatic discovery issues which may be preventing the registration.  Currently the Group Series firmware performs the legacy discovery process that leverages DNS SRV and A records pointing directly to the registrar which was commonly used by Lync 2010 and older clients (like Lync Phone Edition for example).  Support for the newer Lyncdiscover process will be introduced in a future update.

  • Using the web management interface navigate to the Admin Settings > Network > IP Network menu, or simply search for “sip” and then select the SIP result. 

  • Expand the SIP section click Enable SIP if it is not already enabled.

  • Leave SIP Server Configuration set to the default value of Auto.

  • Leave BFCP Transport Preference set to the default of Prefer UDP.

  • In the Sign-In Address field enter the SIP URI of the desired Lync or Skype for Business user account (e.g. gs500@jdskype.net). 

  • In the User Name field enter the User Principal Name (UPN) of the same account (e.g. gs500@jdskype.net).  In most deployments the user account’s SIP URI and UPN are identical, but is not always be the case.  This field also supports the legacy NetBIOS format of “DOMAIN\username” but it is a best practice to utilize the modern UPN format.

  • Click the Password box to expand the Enter Password and Confirm Password fields.  Enter the user account’s password in each field.

  • Leave the Proxy Server field blank as auto discovery process will be used to locate the proper registrar.

  • Select Microsoft from the pull-down menu in the Registrar Server Type menu.

  • Finally click Save to attempt to sign-in.

The Registration Status will always immediately report “Registration Failed” as the sign-in process is still happening, but within 30 seconds or less the registration should complete and change to  “Registered”.

Automatic Configuration Example

image

Manual Configuration

If initial registration attempts fails then manually pointing the Group Series directly to the desired registrar is one of the first troubleshooting steps which can help identify potential automatic discovery issues which may be causing the problem.

The Lync/SfB registrar pool FQDN will be needed for the desired user account .  Follow the steps outlined in this article to identify the appropriate SIP registrar FQDN to use with the Group Series.  Make sure to note if the targeted registrar is an internal Front End server or an external Edge Server as the Group Series configuration will differ slightly.  On an internal network registering to a Lync or Skype for Business Front End pool the destination listening port will be TCP (TLS) 5061, where as an externally placed system attempting registration to an Edge pool will need to be configured to connect over TCP (TLS) 443.

The behavior of the Group series when specifying the registrar manually is to attempt connections by default to the well know service ports for SIP communications.  If either by automatic discovery or manual configuration when a TCP connection is attempted it will use port 5060, or for TLS communications port 5061.  In the event that a different port needs to be contacted then the port number needs to be entered after the registrar FQDN using a colon separator, as in host.domain.com:port.

To manually configure the Group Series to register to a Lync or Skype for Business server then use the same steps as attempted above in the Automatic Discovery section, but perform the following alterations:

  • Change the SIP Server Configuration to Specify.

  • Change the Transport Protocol to TLS.  (This is not mandatory as TLS will still eventually be used when set to Auto but setting it specifically to TLS simply removes one more discovery step that is performed during registration.)

  • In the Registrar Server field enter the FQDN of the Lync or Skype for Business Server or Pool.  If this is an internal Front End Server/Pool then enter only the FQDN (e.g. fepool.jdskype.net) but if this is an Edge Server or Pool then enter the FQDN as well as the destination listening port (e.g. sip.jdskype.net:443).

  • In the Proxy Server field enter the exact same information that was placed into the Registrar Server field above.  Unlike some standard SIP platforms the Microsoft SIP platform contains the proxy and registrar services in the same server roles.  (Note that this field is not used for pointing to a web proxy server.)

  • Click Save to start the registration process.

As before the Registration Status will immediately be reported as “Registration Failed” as the sign-in process starts but within 30 seconds or less the registration should hopefully change to  “Registered”.

Manual Configuration Example

image

If registration is now successful then it can be assumed that the Group Series was either unable to find the desired legacy DNS lookup records or was possibly not able to handle potential redirection scenarios in a hybrid deployment configuration.  At this point it is suggested to reach out to product support channels for further assistance.

Directory Servers

Now that the SIP registration process has been successful using one of the approaches above the next step is to insure that the Directory Server integration is complete.  Just like with SIP the Microsoft platform differs from traditional SIP platforms in terms of address books and directories.  The Group Series needs to manually be configured to used the Microsoft Address Book Service, although other LDAP or Global Directory Services (GDS) could be utilized in place of the Microsoft address book if desired.

    • Using the web management interface navigate to the Admin Settings > Servers > Directory Servers menu, or simply search for “directory” and then select the Directory Servers result. 

    • Change the Server Type to Microsoft.

    • In the Domain Name field enter the SIP domain for the the currently registered user’s environment (e.g. jdskype.net).

    • Click Save to connect to the Address Book service.

The Registration Status will  initially continue to be displayed as “Registration Failed” but within 30 seconds or less the status should update to  “Registered”.

image

Once configured to use the Microsoft directory service option then the Group Series will adhere to the in-band AddressBookAvailability configuration as controlled by the Set-CsClientPolicy cmdlet in Lync and Skype for Business.  When the parameter is set to either FileDownloadOnly or WebSearchOnly then the Group Series will utilize only the option allowed by the defined policy.

If the default WebSearchAndFileDownload value is configured then the Group Series will use the Address Book file download model by retrieving the address book files from the server via HTTPS.  These are the same files that the standard Lync and Skype for Business clients download to respond to searches immediately by using a cached copy (galcontacts.db) of the entire Skype for Business Address Book.

Yet in environments with a large amount of data stored in the address book files these can reach a size too large (roughly more than 2MB)or contain too many entries (approximately more than 20,000) for the Group Series to successfully download, expand, and store in memory.  In the events where this happens the Group Series will then automatically fall back to leveraging the Address Book Web Query (ABWQ) service and then all directory searches performed on the Group Series will immediately be forwarded to the ABWQ service for the server to perform and return any results.

Calendar Registration

The final registration step is to configure the Calendaring Service to connect to the registered account’s Exchange mailbox.  Any version of Exchange which includes Exchange Web Services is supported with the Group Series, which includes all versions of Exchange Server 2007 through 2016 as well as Exchange Online.  Note that while official support for Skype for Business Online is not yet available the Group Series has supported connecting to Exchange Online mailboxes for several releases now.

  • Using the web management interface navigate to the Admin Settings > Servers > Calendaring Service menu, or simply search for “calendar” and then select the Calendaring Service result. 

  • Check Enable Calendaring Service if it is not already enabled.

  • In the Email field enter the primary SMTP address of the desired mailbox (e.g. gs500@jdskype.net).  This is typically the same as the currently registered Skype for Business user account, as shown in this example, but it can be a completely different user or resource mailbox if desired.

  • Leave the Domain field blank.

  • In the User Name field enter the User Principal Name (e.g. gs5000@jdskype.net) of the account which has at least reviewer permissions to the mailbox supplied in the Email field above.  Again this is typically the same account as used for SIP registration but this could be a different account in the event that a delegated-rights ‘service’ account is to be used to access the mailbox instead of the mailbox’s primary AD user account itself.

  • In the Password field enter the password associated with the provided user account in the previous field.

  • Verify that the Auto Discover Using parameter is set to E-mail Address and then click the Auto Discover button.

At this point the Microsoft Exchange Server field should automatically be populated with the FQDN of the appropriate Exchange Server for the supplied mailbox.  Depending on the location of the mailbox the value will either be an Exchange Server FQDN (if the mailbox is stored on an on-premises Exchange Server) or outlook.office365.com (if the mailbox is stored in Exchange Online).

  • Leave the Secure Connection Protocol set to Automatic.

  • The remaining fields are optional and can either be left at the default value or customized as desired to control Meeting Reminder and Private Meeting behaviors.

  • Click Save to attempt to register to Exchange and access calendaring information stored in the targeted mailbox.

The Registration Status will  initially continue to de displayed as “Not Connected” but within 30 seconds or less the status should update to  “Registered”.

image

Verification

To validate that the Group Series is successfully working with Skype for Business a number of tests can be attempted to confirm several capabilities in addition to simply checking the System Status for general health.

System Status

  • Using the web management interface navigate to the Diagnostics > System > System Status menu, or simply search for “status” and then select the System Status result.

The three sections to focus on are the Microsoft Server (for the Directory Server), the SIP Registrar Server, and the Calendaring Service.  Verify that all three services are green and do not report any errors.

image

Peer Calls

To initially validate that the registration was indeed successful a simple test is to check the advertised presence of the registered Group Series and then start a video call with it.

  • Open the Skype for Business client on a workstation and look for the Group Series user by either searching the directory or directly typing in the account’s SIP URI.

image

  • Start a Video Call to the Group Series to test a peer call scenario and then answer the incoming call on the Group Series.

image

  • While the call is still established return to the web management interface for the Group series and note the additional call control buttons which are now displayed across the top of the window.

image

  • Click the Call Statistics button to bring up the following menu displaying some technical details on the current call.

image

In a peer call a pair of audio channels and video channels are displayed.  Outbound streams are denoted by Tx (Transmit) and inbound streams are labeled as Rx (Receive).

Note that based on the default Skype for Business window size the Group Series is sending (VIDEO TX) 640p video at around 800 Kbps using SVC.  (The Group Series will report the Microsoft-specific implementation of SVC (X-H264UC) generically as SVC-HP.)  Because this Group Series unit includes the 1080p options key and the Skype for Business Windows workstation in the call is a quad-core PC capable of encoding 1080p video then the codec is also receiving (VIDEO RX) a 1080p video stream from the SfB client.

  • Manually resize the Skype for Business client’s video session window to the smallest possible dimensions on the receiving workstation.

image

  • Refresh the Call Statistics on the Group Series and check the statistics reported for the Video Tx line again and notice that Group Series is now sending lower resolution video to the SfB client at around only 375 Kbps.

image

  • Now maximize the SfB video window on the workstation as shown below.

image

  • Refresh the Call Statistics again and note that the codec should no be sending a much higher resolution video stream then either of the previous arrangements. Based on the screen resolution and size of the window on this specific workstation the SfB client is now asking the Group to send a 720p high definition video stream at around 2.5 Mbps.

image

  • Increase the SfB video window one more time by selecting the Full Screen View option (the little opposing diagonal arrows in the upper right hand corner of the window.  This will increase the video window to the largest possible size.  The inclusion of the Skype logo watermark is an indicator that the full screen view has been enabled.

image

  • Refresh the Call Statistics again to see that now the SfB workstation has requested the maximum supported 1080p high definition video resolution at around 4 Mbps to be sent by the Group Series.  On less powerful workstations this would be limited to 720p, or if the Group Series is not licensed to support 1080p video streams.

image

  • From the SfB client select the Share Your Desktop option to add an RDP application sharing session to the existing video call.

  • Refresh the Call Statistics one last time to see the inclusion of the inbound content sharing session (CONTENT RX)

image

Skype Meetings

This take this one step further the Group Series can join a Skype Meeting hosted on a Lync or Skype for Business Server AVMCU.  If calendaring has not been enabled on this codec then to join a meeting the unit must be invited by another SfB participant currently in a scheduled or Meet Now meeting.

If calendaring has been enabled then using either the remote control, a paired RPT panel, or a supported touch screen select the Join button displayed inside any Skype Meeting invitation which has been sent to the Group Series account’s mailbox.  The Group Series will automatically dial the Conference URI to join the Skype Meeting.  Once in the meeting various features like presenter muting will operate in the same fashion as it does on native Skype clients.

Additional Settings

This section covers various optional configuration settings which may be applicable to the Lync or Skype for Business environment.

Touch Control Panel

If a RealPresence Touch (RPT) control panel is to be used with the Group Series the capability must first be enabled and then the RPT can alternatively be configured to use a Skype for Business-specific user interface instead of the default interface.

  • Using the web management interface navigate to the Admin Settings > General Settings > Pairing  menu, or simply search for “pair” and then select the Pairing result. 

  • Check Enable Polycom Touch Device if it is not already enabled.

  • From the RPT itself select Manually Pair and enter the IP address of the Group Series and initiate the pairing process.

Once pairing is successful the Status should be displayed as “Connected” as shown below.

image

To enable the alternative Skype for Business user interface perform the following steps.

  • Using the web management interface navigate to the Admin Settings > General Settings > Home Screen Settings menu, or simply search for “skype”, and then select the Skype Mode result. 

  • Select the Enable Skype Mode checkbox.

The screenshot below shows a touch panel that is paired with the Group Series with the Skype Mode UI enabled, as well as the Calendaring Service successfully registered to Exchange and displaying the next five meetings.

image

About Jeff Schertz
Site Administrator

Comments

4 Responses to “Polycom Group Series with Skype for Business Server”
  1. James Frost says:

    Hi Jeff,

    Nice article. Regarding the MS qualification process, does this cover the use of a Group series as a telephony endpoint when connected to Skype for Business enterprise voice ? This is a fairly common scenario, and whilst it works, I’m interested in the official support.

    Thanks James

    • Jeff Schertz says:

      Yes, basic PSTN calling capabilities are part of the qualification. You can place PSTN outbound calls from the GS if the registered account is Enterprise Voice enabled and is properly configured with PSTN connectivity. The GS does not support client-side number normalization though, so all dialed numbers are sent unnormalized and server-side normalization is applied by the Lync/SfB Front End. Advanced scenarios like E911 or RGS are not supported though, for example.

  2. Jo says:

    Hello Jeff

    Thank you for this incredible useful website!
    Working in this domain, it has been a huge help for me.

    I begin with interoperability between Skype and Group Series.

    Do you know which ports are used for that?
    I guess 5060 and 5061 because of the SIP
    And I saw 16384-32764 en UDP for RTP/RTCP Video and Audio.

    But is it everything we need for a call with an external skype?

    Thank you in advance and it is ok if there is no answer 😉

    Best Regards

    • Jeff Schertz says:

      The Group Series will utilize ICE with the Edge Server over the same port ranges that Lync/SfB client use, so there are no additional ports or protocols to address. Signaling is only over 5061 (TLS) when registered to an internal Front End or 443 (TLS) when registered externally to an Edge Server, as the same as Lync/SfB clients. Port 5060 is never used as TCP is not generally supported in Lync/SfB for unencrypted signaling.

Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!