Stretto Platform 340 Admin Guide CP-Hosted

Stretto Platform Administration
Guide
CounterPath-hosted - Version 3.4.0
About this document
Stretto Platform Administration Guide - CounterPath-hosted - Version 3.4.0
Publication date: 2022-11-16
Copyright ©2022 CounterPath an Alianza Company. All rights reserved.
This document contains information proprietary to CounterPath, and shall not be used for engineering, design, procurement, or
manufacture, in whole or in part, without the consent of CounterPath. The content of this publication is intended to demonstrate
typical uses and capabilities of Stretto Platform from CounterPath. Users of this material must determine for themselves whether
the information contained herein applies to a particular IP-based networking system. CounterPath makes no warranty regarding
the content of this document, including—but not limited to—implied warranties of fitness for any particular purpose. In no case will
CounterPath, its employees, officers or directors be liable for any incidental, indirect or otherwise consequential damage or loss
that may result after the use of this publication.
CounterPath®, Bria®, X-Lite®, and the ® logo are registered trademarks of CounterPath Corporation.
Stretto™ and the Stretto Platform™ are trademarks of CounterPath Corporation.
Android and Google Play are trademarks of Google Inc. Eclipse is a trademark of Eclipse Foundation, Inc.
CentOS is a trademark of Red Hat, Inc.
Intel, the Intel logo, Intel Core and Core Inside are trademarks of Intel Corporation in the U.S. and/or other countries.
iOS is a trademark or registered trademark of Cisco in the U.S. and other countries and is used under license.
iPhone, iPad, iPod, Mac, mac OS, App Store, Objective–C, and Xcode are trademarks of Apple Inc., registered in the U.S. and
other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
Microsoft, Active Directory, Office, Excel, Outlook, and Windows are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
Oracle and Java are registered trademarks of Oracle and/or its affiliates.
All other products and services are the registered trademarks of their respective holders.
CounterPath an Alianza Company

1064 S North County Blvd,
Pleasant Grove, Utah 84062,
United States
[email protected]
www.CounterPath.com
Contents
Overview of Stretto administration 1

Related documentation 1
Supported browsers 1
Stretto components 2
Associations 5
Synchronizing your systems 6
Designing your Stretto framework 8
Rules for the order in which you create entities 8
Case sensitivity for Stretto entities 8
Case sensitivity for provisioned data 9
Known Stretto attributes 9
Setting up Stretto entities 10
How Stretto entities work at runtime 20
Administrators 24
Entity naming conventions 33
Masked, encrypted, and hidden data 34
Assigning values to attributes 36
Subgroup attributes inheritance and locking 37
Template inheritance 40
Setting up for login and provisioning 42
Login authentication 42
Login-related features 42
Provisioning 43
Overview of provisioning 43
Provisioning-related features 44
How login and provisioning works 45
Authenticating user logins via LDAP 46
Authenticating user logins via external configuration server 58
Provisioning Bria desktop licenses 62
Re-provisioning the Bria clients (refresh) 65
Testing your provisioning setup 68
Limiting user and device counts 73
Tracking device usage 87
Working with the Stretto Admin web interface 90
Logging into Stretto Admin 90
Managing administrators 91
Working with groups 97
Working with attributes 116
Working with provisioning templates 133
Working with profiles 142
Working with users 149
Setting preferences 171
Using Stretto Platform optional features 173
Bria Push for client notifications 173
Collaboration (Virtual Meeting Rooms) 191
Messaging and presence (XMPP) 201
Setting up Stretto Sync 248
Setting up Call History Sync 251
Configuring SMS API integration 254
Setting up email notifications 259
Stretto notification service (SNS) 263
Setting up user traces 264
Setting up enhanced Client Traces 264
Royalty-bearing codecs tracking 269
Setting up User Experience Metrics 270
Setting up The End User Portal 272
Help Desk Assistant (HDA) 285
Setting up remote upgrade of Bria desktop 300
SIP server failover using DNS or NAPTR 307
Customizing and translating login error messages 308
Viewing logs and reports 312

Viewing Event Logs 312
Viewing User Traces 317
Viewing Enhanced Client Traces (device logs) 320
Viewing a list of all devices in a group 334
Viewing Stretto reports 335
Viewing User Experience Metrics (UEM) 356
Reference 398
Administrator privileges 398
Login error messages 403
Building a search query to fetch LDAP entries 406
Ports, IP addresses, firewall rules to allow on your network 410
Stretto attributes and data elements 416
Stretto template formats 420
Stretto URLs 434
What's new in Stretto 3.4.0 - November 2022 438
Stretto Sync improvements 438
Changes - Service level limits to be copied over for Domain admins 438
Previous releases 439
Stretto Platform Administration Guide Overview of Stretto administration
Overview of Stretto administration
This document describes the provisioning of CounterPath® softphones using Stretto

Platform™.
This manual is intended for:

l Carriers who are deploying Stretto Platform in order to provision their own end
users. For example, a carrier who provides a phone service to residential end users
and is using Stretto to provision CounterPath softphones for these users.
l Resellers who are deploying Stretto Platform as a hosted service to their
customers.
Related documentation
You may find these documents helpful:
l Stretto Platform Administration Guide for CounterPath an Alianza Company-hosted
installations - This document.
l Stretto Platform API Developer's Guide describes how to access Stretto Platform
through the API.
l Branding Portal User Guide explains the customization requirements for branded
softphones.
l The Bria settings spreadsheet lists Bria softphone settings. There is one for
Desktop, and another for Mobile. Contact CounterPath to acquire a copy.
Supported browsers
Stretto Admin supports these browsers:
l Most browsers that are newer than two years old support all the features of Stretto
Admin. Supported browsers include Firefox®, Chrome™, Safari™, and Opera™.
CounterPath an Alianza Company 1

l Internet Explorer® 11 or newer is supported. The older versions of Internet Explorer

support most features but do not show values in the profile that are “inherited” from
the group, or values in the user that are “inherited” from the group or profile.
Stretto components
Platform and discriminator
A platform is a CounterPath softphone:
l Bria desktop
l Bria mobile ("iOS Edition", "Android Edition")
Each platform is identified in Stretto by a “discriminator”. For example, for Bria mobile on
iOS, the discriminator is mob.*iP.*. A discriminator may include a build number of the
client, such as desk.*69231.*.
Settings
Settings configure the behavior of the softphone. Settings can be separated into:
l Global settings: The same setting value applies to each user.
l User-specific settings: Each user has an individual value.
In addition, Bria desktop has its own list of settings (setting names) and Bria mobile has
its own list (all Bria mobile applications use the same settings, with some minor
exceptions).
Group
A Stretto group is the container for a set of attributes, templates, profiles, and users.
A group cannot share any attributes, templates, profiles, or users except through
inheritance, which permits child groups to use templates and attributes belonging to a
parent group in a hierarchical tree structure. Groups can also share an administrator, as
one administrator can handle several groups.

SPID
The SPID is a unique “service provider ID” that is branded into a Bria client at build time.
Typically, it matches the domain name of the company that has purchased the softphone
from CounterPath. In some situations, the SPID is used as the group name. See How
Stretto entities work at runtime.
Stretto administrators
Stretto administrators manage groups and the content of groups: the attributes,
templates, profiles, and users.
Provisioning templates
A Stretto provisioning template is a file that defines the format and content of the
provisioning response body — that is, the settings that will be provisioned to client
applications. In the template, the values for settings may be represented by Stretto
attributes. There are currently two provisioning file formats used by CounterPath clients:
l Bria desktop uses a format that is similar to a Microsoft Windows .ini file
l Bria mobile uses XML format
Each group contains one or more templates. Typically, you need at least one template for
Bria desktop and at least one template for Bria mobile. If a group has inherited templates,
the group may not have any local template, and it just refers to the inherited templates.
Stretto also uses templates for purposes other than provisioning, such as notification
emails, vCards, and User Portal pages. See Stretto template formats.
Attributes
Stretto attributes are variables that contain information for a group and its profiles and
users. Each attribute name has a corresponding value. For example, a group's SIP
server domain could be stored in an attribute named account1.domain with the value
sip1.acphone.com.
In the provisioning of Bria clients, a provisioning template specifies what kind of data is
sent to the client by listing attribute names. At runtime, Stretto sends the values that
correspond to each of those attributes.

Attributes belong to a group. The profiles and users in a group are automatically
populated with the group’s attributes. The value of each attribute can be either inherited
from a parent group or defined at the group level, profile level, or user level.
l Group-attributes. When an attribute's value is assigned at the group level, it is
referred to as a "group-attribute". You set the values at the group level for attributes
values that are shared by every profile and user in the group and subgroup.
l Profile-attributes. When an attribute's value is assigned in a profile (overriding the
group-attribute), it is referred to as a "profile-attribute". You set the values at the
profile level where you want to create categories of user types with shared values.
For example, you may want to have region-based values.
l User-attributes. When an attribute's value is assigned for an individual user
(overriding the group-attribute or profile-attribute), it is referred to as a "user-
attribute". You set these values when there is a case for individuals to have settings
that differ from the rest of the users in their profile or group.
The attribute value that is defined closest to the user level takes precedence over those
attributes defined higher up.
Profiles
Each profile in a group contains a different set of possible attribute values. Each user is
assigned to a profile — an association that determines which set of attribute values are
provisioned to the user.
For example, in Profile_A, the attribute g711_enabled has a value of true. In Profile_B,
g711_enabled has a value of false. Assigning a user to Profile_A or Profile_B then controls
whether g711_enabled is true or false.
A profile can contain an attribute without a value if that value is to be set at the user level.
Each profile must be associated with at least one provisioning template.
Profile-templates
Each profile contains a list of profile-templates, each of which associates this profile with
a specific provisioning template for a specific platform (discriminator). Each profile has at
least one profile-template.

In other words, a profile-template defines a rule “for this profile, use provisioning template
X when a user logs in from Bria mobile but use provisioning template Y when a user logs
in from Bria desktop.
Users
Each Bria user who logs in to the Bria client must be set up as a Stretto user. The user
automatically contains the attributes of the group. The user must be associated with one
profile.
Associations
A group owns a set of attributes, templates, profiles and users. Those attributes,
templates, profiles and users belong to that group and cannot belong to other groups. To
be useable, a group must have at least one attribute, one template, one profile. If a group
is missing any of these, the users in that group are not provisioned.
l An attribute belongs to a group and therefore belongs to that group’s profiles and
users.
l A template belongs to a group. It can be associated with one or more of the profiles
in the group. A template cannot be associated with profiles in another group.
l A profile belongs to a group. It is associated with one or more templates in the
group. A profile cannot be associated with a template in another group.
l A user belongs to a group. It is associated with one of the profiles in the group. A
user cannot be associated with a profile in another group. Typically, several users
are associated with one profile.

Synchronizing your systems

If you have a customer care system, you must plan to maintain synchronized data
between that system and Stretto, and to ensure data does not remain unsynchronized for
too long.
Shared data
You should identify the data that the two systems share. Most of this shared data is user
data: SIP credentials, user login credentials, and so on. This data is represented in
Stretto by attributes and their values.
How data becomes unsynchronized

You must think about how data can become unsynchronized between the customer care
system and Stretto. The change could happen on either side. For example:
If an administrator makes a change on Stretto, a data discrepancy obviously occurs.
If you have clients that write to your customer care system, a data discrepancy occurs.
For example, you may allow your end users to change their Bria login password by going
to a webpage that writes to your customer care system. In this case, the password in the
customer care system and in Stretto become unsynchronized.

Which system is the "master"?

You must decide which system shall be considered the “master” for shared data.
Typically, you want your customer care system to be the master. Therefore, when data in
the customer care system and data in Stretto become unsynchronized, you must make
sure that the update (to synchronize) goes in the desired direction: from the customer
care system over to Stretto.

Stretto Platform Administration Guide Designing your Stretto framework
Designing your Stretto framework
Your Stretto framework should be planned extensively to be sure that it encompasses all
of your needs. This section assists you in the specifics of planning this framework.
Rules for the order in which you create entities

Here are some general guidelines about the order in which to create entities.
l Create the group first.

l Create attributes in the group.
l Create templates. It make sense to create templates before creating profiles
because each profile includes references to one or more templates.
l Create the profile or profiles.
l Create users.
Case sensitivity for Stretto entities

The values of Stretto entity names and Stretto data (Stretto administrator credentials and
Stretto user login credentials) are case sensitive. So, for example, a group named
“ACphone” is different form one named “acphone”. Keep this in mind for Stretto
Administrator names and make sure your Stretto Administrators know that logging into
Stretto as “Ewilding” is not the same as logging in as “ewilding”.
We strongly recommend that you decide ahead of time whether you will enter names as
lowercase (acphone) or mixed case (Acphone).

Case sensitivity for provisioned data

For the data that is being provisioned, in other words the content of the templates and the
values of attributes:
l The keywords are case insensitive. For example, the names of settings.
l The case of the data values within the settings is respected by the CounterPath
softphone. The client that ultimately consumes the value may be case sensitive. For
example, in Bria, the value of an LDAP username is provisioned down to the
softphone. The softphone client does not change the case in any way but passes it
on to the LDAP server. The LDAP server may or may not be sensitive to the case of
the username.
Known Stretto attributes

In these procedures, there are references to attribute names. Attributes that start with the
following are attributes that are known to Stretto:
l std:
l ccs:
l msg:
l smtp:
l xmpp:
For “known” attributes, the notation is std:xx:yy:zz or ccs:xx:yy:zz. In other words, the
punctuation is colons. Except:
l The upgrade attributes use the notation std:xx.yy.zz (colons and dots).
l The email attributes use the notation smtp:xx.yy.zz (colons and dots).
Note: Do not confuse Stretto attributes (which use the various notations above) with Bria
settings, which always use the format aa:bb:cc.

Setting up Stretto entities

This section provides an aid to planning your Stretto entities to match your needs. For
best results, follow these procedures in the order they appear.
Identify settings and their combinations

These steps can help you identify settings and combinations.
To identify settings and their combinations
1. Identify the softphone platforms you are deploying: Bria desktop and/or the Bria
mobile.
2. Go through the settings documentation for each softphone platform and identify
which settings you want to provision. If you do not provision a setting, the factory
setting (default) for your brand for the given platform is used.
3. Identify the settings that can share the same attribute. These are “shared
attributes”.
The SIP and/or XMPP account credentials settings should always share the same
attribute: so Bria desktop and Bria mobile should use the same attribute for the
settings (even though the setting names are a bit different) because the two settings
represent the same “data”.
There may be other settings that should be shared. Settings can only be shared if
they are the same type, for example, both booleans.
4. Assign an “attribute name” for each of these provisionable settings. Settings are
represented in Stretto by “attributes”. Some naming guidelines:
l Use names that incorporate the setting name. In some cases, you may want
to include the platform in the attribute name, particularly for a feature that
applies to both Bria desktop and Bria mobile, but specified in a different way.
For example, “dtmf_mobile” and “dtmf_desktop_2833” and “dtmf_desktop_force”.
l You may want to include an indicator for settings that are Bria desktop only or
Bria mobile only, for example, “desk_” or “mob_”.
l Do not re-use attribute names among different settings, even if the settings
are related. For example, do not create an attribute named “codec_enabled”.

Instead, create one called “codec_g722_enabled” and another called “codec_

speex_enabled”.
l The prefix “ccs:req:” is reserved for internal use (for internal data elements).
You cannot create attributes with this prefix.
5. Go through the attributes and identify which are user-specific and which are not
user-specific. Include both shared and non-shared attributes in this analysis.
6. For an attribute that is not user-specific, determine if the attribute value can be the
same for all users or if there are different possible values. For example:
l An attribute may be the same for all users (Attrib W below.)
l An attribute must be different depending on the user’s region. (Attrib X below.)
l An attribute must be different depending on the user’s level of service: gold
service vs silver service. (Attrib Y below.)
You end up with three types of attributes:
l Attributes that are user-specific: user-attributes
l Attributes that may be different: profile-attributes
l Attributes that are the same for all users: group-attributes.
7. Identify the different combinations of attributes (do not include user-specific
attributes). Each combination becomes a profile. For example, you might need four
“global configurations”:
Attrib W (Mobile only, constant) Attrib X (local to region) Attrib Y (per user) Attrib Z (local to region)
Configuration A 0 stunserverA.com false false
Configuration B 0 stunserverB.com false true
Configuration C 0 stunserverA.com true false
Configuration D 0 stunserverB.com true true
8. Identify attributes that you want to protect (lock), so that their values can only be
changed by a special administrator.

9. You may want to make a plan of all your information. For example:
Determine the number of groups

These points can help you decide how many groups you need to create.
More than one real group?
Decide if you need more than one group. Groups are a way of dividing the workload
among two or more administrators. So you might choose to create several groups if you
want different administrators to handle different regions of users (Europe versus Asia, for
example) and you do not want the Europe administrator to see the Asia profiles and
users, and vice versa.
However, if you are happy with all your administrators working with the same pool of
users, and letting the administrators dividing the workload based on user’s last name (of
something similar), then you probably do not need to create several groups.
Keep in mind:
l Groups should not be used to separate different platforms. For example, do not
create one group for Mobile users and another for Desktop users. The distinction
between platforms is instead handled by templates within the group, not by creating
separate groups.
l Groups should not be used to separate different deployments. For example, do not
create one group for your “silver service” and another for your “gold service”. Or do
not create one group for users accessing one STUN server or proxy server, and
another for users accessing another set of servers. The distinction between

different deployments is instead handled by profiles within the group, not by

creating separate groups.
A top-level group?
If you determine that you need more than one group, then you must decide if you want to
create a top-level group. If you create a top-level group, then you can implement
inheritance among all your groups.
l Attribute inheritance: you set up group-attributes in one place and have the “real
groups” inherit the value. This saves you having to set the attribute value in several
different groups, and allows you to change the value (if this is ever necessary) in
only one place and have the value inherited in the real groups. See Subgroup
attributes inheritance and locking.
l Template inheritance: you set up templates in one place, and let subgroups use
those templates instead of each subgroup creating local/duplicate templates. This
is an efficient way to maintain templates if all the subgroups need to use the same
template. See Template inheritance.
If you do not have any group-attributes (all your attributes are profile or user-attributes),
then there is no advantage to creating a top-level group.
Determine the number of templates and profiles

The number of templates and profiles you need can vary based on the following factors.
Templates
Typically, you need to create one template for each platform (Bria desktop, Bria mobile).
There is no requirement to create separate templates within Bria mobile (for example, for
iOS edition versus Android edition).
There is no need to create separate templates for different software versions of the phone
or for different customer offerings. Instead of using templates to manage differences
between different deployments, try to manage them through the profiles.
Profiles
Typically, you create several profiles, as described below, in order to support different
“levels of service” and different types of users. Typically, groups and templates are not

used to differentiate between deployments: this is the purpose of profiles.
When creating multiple profiles, you do not have to worry that some profiles do not use an
attribute that is in the group. If the profile does not need an attribute, you can simply
ignore the attribute in that profile. For example, profileX and template01 are for Bria
desktop and for users of your gold service. AttributeA is for Bria mobile and for users of
silver service. The attribute appears in the profile (because the attribute is part of the
group) but so long as you do not use the attribute in template01, you do not have to assign
a value for it in profileX.
Recommended procedure
Scenario A
For example, you support only Bria desktop and all your users use the same global
settings. You need one template, in the format for Bria desktop, containing the settings to
configure. You need one profile containing values for the global settings.
Alternatively, you support Bria mobile. You need one template, in the format for Bria
mobile, containing the settings to configure. You need one profile containing values for
the global settings.

Scenario B
For example, you support only Bria mobile but some users use one STUN server while
others use another STUN server. You need one template, in the format for Bria mobile,
containing the settings to configure. You need two or more profiles, one for each “global
configuration” you identified in Identify settings and their combinations.
Scenario C
For example, you support Bria desktop and Bria mobile. For the settings that the two
applications share (for example, the user SIP credentials — username, domain,
password), you use the same attribute values, so both applications can use the same
profile. You need two templates, one for desktop and one for mobile.
In this setup, attributes for both Bria desktop and Bria mobile are in the same profile. If a
particular attribute applies only to a setting used by Bria desktop and not to one used by
Bria mobile (or the reverse), there is no issue: it is not a problem to combine attributes for
different platforms in the same profile.
Create the entities in Stretto

When you are finished planning and are ready to create the entities.
To create Stretto entities
1. Log into Stretto.

Obtain your Stretto administrator account credentials from the person in your
organization who has the superadmin account credentials.
If you are the person with the superadmin account credentials, log in using those
credentials. Then create a Normal administrator account and log in with those
regular credentials. In general, it is a good idea to log in as superadmin only to
perform actions that normal administrators cannot perform (see Administrator
privileges).
2. Create the groups. If you create a top-level group, give it a name such as
“acphone.com” and give your “real groups” names like “asia.acphone.com” and
“euro.acphone.com”.
3. Create the attributes you identified in Identify settings and their combinations.

4. Create the templates you identified in Determine the number of templates and
profiles. Omit the template body at this point and just create an empty template (the
template name and the group it belongs to). You add the content later.
5. Create the profiles you identified in Determine the number of templates and
profiles.
At this point, you have created the group or group, and its attributes, profiles and
templates. There is not yet any relationship between the attributes, profiles, and
templates.
Modify the templates

Modify each template to include the template body, in the correct format for the platform.
In the body, include the settings for which you created attributes, and include that
attribute as the value. For example, in a Bria desktop template:
.
.
.
[SETTINGS]
proxies:proxy1:username="{{SipUserName}}"
proxies:proxy1:password="{{SipPsw}}"
In a Bria mobile template:

.
.
.
<account_list>
<account>
<data name="userName" value="{{SipUserName}}"
<data name="password" value="{{SipPsw}}"
For template formats, see Stretto template formats.
Modify the profiles

Modify each profile to add a profile-template that maps the profile to its template. For
example, map the profile P_NA to the template T_desk using the discriminator “desk.*”.
Note that the profile template IDs are not explicitly shown in Stretto Admin, but they are
like the glue between a profile and templates.
Assign values to group-attributes

1. In the appropriate groups, assign a value to attributes that you identified as “group-
attributes”.
If you created a top-level group, you will probably assign these values in the top-
level group.

If you did not create a top-level group, make sure you assign the value in each
group.
2. Decide if you want to lock the value of any group-attributes. Locking a value can
prevent your day-to-day administrators from changing the value.
Assign values in profiles

In each profile, assign a value to attributes you identified as “profile-attributes”. Also
assign values in the profile if you want the attribute to have a default (that may get
overridden at the user level). Do not assign values in the profile if each user needs an
individual value.
Set up more Stretto administrators

Now that you have set up the general Stretto framework, you may want to create more
Stretto administrator accounts for the group, to handle the regular day-to-day work of
creating users on Stretto.
Create users
1. Create each user. For each user:
Assign the Stretto user credentials: the username and password. These are the
login username and password to contact Stretto, not the SIP account username
and password. The user’s attempt to log into the CounterPath softphone fails if this
information is not present.

Assign a profile to the user. This profile is the particular feature configuration that
applies to this user.
2. Assign values to “user-attributes”. For example, the SIP username and SIP
password.
Error-checking
You can use the Test tool to verify that your setup is valid. See Testing your provisioning
setup.
Make sure every attribute for a user has a value. If an attribute has no value, then at
runtime (when the provisioning file is created from the template), attributes with no value
are replaced by a blank. This may result in undesirable behavior on the softphone or may
result in the softphone failing to start.
The result
Read these login examples to understand the flexibility of this setup
l When [email protected] logs into Bria mobile, Stretto determines that she
uses the profile P_euro, then goes to P_euro to determine that for the device,
template 3 is used (T_mobile). Stretto picks up the profile-attributes that are defined
for the P_euro profile and plugs them into the T_mobile template. Stretto then picks
up the user-attributes defined for this user and plugs them into the T_mobile
template.
l When [email protected] logs into Bria desktop, Stretto selects profile P_euro,
the template T_desk, the profile-attributes for P_euro and the user-attributes for this
user.

So at every login, decisions are made that result in the values appropriate to this user’s
location being sent down in the format that is appropriate to the device the user is using in
this particular login attempt.
How Stretto entities work at runtime

This section describes how Stretto entities work together for provisioning. When a user
requests for a login, Stretto does the following:
l Find the user

l Load the profile and find the template
l Create the provisioning file
l Softphone applies the information
Step 1: Find the user

When the user logs into Bria desktop or Bria mobile, their login username and password
(for Stretto) are sent to Stretto.

Stretto authenticates the request as follows, depending on the format you are using for
group names and usernames:
l Format 1: If your usernames are in the format <username>.
Stretto extracts the username and the SPID from the information that is sent in
every POST login request. It then looks for a group name that matches this SPID. It
then looks for a user with the matching username in this group. It then checks that
the password (also sent in the POST) matches the user’s password in Stretto.
For example, in the POST the SPID is acphone.com and the username is fchan.
Stretto looks for a group named acphone.com, then looks in that group for a user
named fchan, and finally validates that user’s password to the password in the
POST.
l Format 2: If your usernames are in the format <username>@<groupname>:
Stretto extracts the username from the information that is sent in every POST login
request. It then looks for a group name that matches the group portion of the
username. It then looks in this group for a username that matches the user portion
of the username. It then checks that the password (also sent in the POST) matches
the user’s password in Stretto.
For example, in the POST the username is [email protected]. Stretto looks for a
group named acphone.com, then looks in that group for a username fchan, and finally
validates that user’s password to the password in the POST.
If the group or user cannot be found or if the password check fails, the login request fails
and a failure response is sent down and displayed on the user’s softphone.
Step 2: Load the profile and the template

Stretto then looks in the user information for the profile associated with this user. Stretto
reads the POST again to obtain the device the user connected from (for example,
desktop or iPhone). The profile includes a mapping that matches that device to the
template to use for that device. For example, profile A maps the iPhone to template X.
Stretto then looks for that template.

If any of these steps fails (for example, there is no template discriminator matching the
user’s device), then the login request fails and a failure response is sent down and
displayed on the user’s softphone.
Example: Assume user [email protected] is set up in the group acphone.com. Frank

logged in from his Bria desktop softphone.
Step 3: Create the provisioning file

Stretto now starts collecting values. Stretto goes through the group and collects the
attributes that have a value assigned, then it goes through the profile and collects the
attributes that have a value assigned. It then goes through the information for the specific

user and collects the attributes that have a value assigned. Stretto then goes back to the
template and replaces the attribute with the collected values.
If the group, template, profiles and users have been set up correctly, every attribute in the
template is replaced by a value.
The completed provisioning file is then sent down to the softphone.
If any of these steps fail, the login request fails and a failure response is sent down and
displayed on the user’s softphone.
Step 4: The softphone applies the information

Bria reads the information and applies it internally.
Keep in mind that provisioned settings override user settings. A user may complain that
they change a value on the user interface (for example, they disable an account) but each
time they restart Bria, their changes are lost: you are probably overwriting their value
when you provision.

Be aware of this behavior when deciding which settings to provision.
Provisioning example
In their Stretto deployment, AC phone has one group called “acphone.com”. There are
two templates, one called “T_desktop” for Bria desktop and another called “T_mobile” for
the iOS and Android editions of Bria mobile. The group also has two profiles, one for
North American users, another for Asian users. Some settings (for example, the STUN
server) are set in each profile as profile-attributes. The North American profile uses one
URL for the STUN server, the Asian uses another. Other settings (for example, the SIP
username and password) are set in each individual user as user-attributes.
User Frank Chan starts his Bria desktop and automatically connects to the Stretto server.
Stretto finds the user “[email protected]”, who is assigned with the profile “P_Asia”. For
Bria desktop, this profile is associated with the template “T_desktop”.
Stretto collects the profile-attributes defined in the profile “P_Asia” and the user-attributes
defined in the user “[email protected]”, and plugs them into the “T_desktop” template, to
create a provisioning file for Frank Chan. This file is sent down to Frank’s device.
Administrators
One or more operators must be set up as an administrator in order to work in Stretto
Admin. When an administrator is created, it is assigned two properties:
l It is assigned a parent administrator. The parent administrator has the ability to
control the administrator’s privileges, including deleting the administrator. The
creating administrator is usually the parent administrator, but it does not have to be.
l It is associated with a group or groups. An administrator has control over the
content of these groups and their subgroups: an administrator has access to users,
attributes, profiles and so on in their associated groups. An administrator can also
create more groups under the associated groups.
When you are set up on Stretto, you are given account credentials for one administrator.
Log in as this administrator and create more administrators.

Stretto administrator privileges

A Stretto administrator is assigned (at creation) to a specific group or groups. The
administrator can access those groups and all the subgroups (if any) of those groups.
Whether the administrator can create, modify, or delete an entity in the groups it has
access to depends on the administrator type.
For more information on administrator types and privileges, see Administrator privileges.
Creation of Stretto administrators

When a Stretto administrator is created, it must be:
l Given a parent administrator who can control it (modify its groups and so on). The
parent can be the administrator who is creating the new administrator or it can be a
different administrator.
l Associated with a group or groups.
Administrator types
Stretto Platform categorizes administrators into the following types according to the
privileges they are afforded within the system.
Lite administrators includes: Domain admin, Users&Profiles admin, Users admin,

Support admin, and Read-only admin.
Normal admin
The Normal admin is a high-level administrator who configures groups and

administrators below them in the hierarchy (child administrators).
l Associated with one or more groups.

l Access to all functions within the groups (including subgroups) the administrator is
associated with.
l Ability to create child administrators of any type.
l Privileges over its own child administrators: view, modify, delete its child
administrators.

Domain admin
The Domain admin is designed for a reseller or service provider who requires more
access than Users&Profiles admins for setting up groups for their customers.
Contact CounterPath if you are interested in this admin type.
For a list of Domain admin tasks, see Domain Admins.

l Ability to create, modify, view and delete subgroups the administrator is associated
with.
l Ability to add, modify, view and delete profiles, users, attribute pools.
l Ability to create child administrators, but can create only Users&Profiles admin,
User admin, and Support admin.
l Privileges over its own child administrators: view, modify, delete its child
administrators.
Users&Profiles admin
The Users&Profiles admin is designed for setups where a reseller or site administrator
has performed most of the setup and wants to restrict their customer administrators or
day-to-day administrators so that they can only set up profiles and users.
l Ability to add, modify, view and delete profiles.
l Ability to add, modify, view and delete users.
l Ability to add, modify, view and delete attribute pools.
l Ability to set a value to “Lite-admin-viewable” attributes (but not other attributes) at
the user or profile level.
l No privileges over administrators, apart from being able to change and reset their
own password.

Users admin
The Users admin is designed for setups where a reseller or site administrator has
performed most of the setup and wants to restrict their customer administrators or day-to-
day administrators so that they can only set up users.
l Associated with only one group (they are not associated with that group’s
subgroups).
l Ability to add, modify, view and delete users
l Ability to set a value to “Lite-admin-viewable” attributes, but only at the user level
(not at the profile level).
own password.
Support Admin
The Support Admin has access to the standard “administrator” features: About, and Log
out, and can optionally be allowed to:
l Change and reset own password
l View Enhanced Client Traces (device logs)
l View Reports (including Client-side Performance reports)
l Use the Help Desk Assistant.
Read-only admin
The Read-only admin can view more than a Users or Users&Profiles admin but cannot
make any changes.

l Can view groups, attributes, attribute pools, templates, profiles, and users within
the groups the administrator is associated with.
own password.
For information about controlling the ability for administrators to change attribute values,
see Assigning values to attributes.

Administrator privileges
This section identifies the privileges of Stretto admins.
Access to groups
Read-
Users&Profiles Users Support
Feature Normal Admin Domain Admin only
Admin Admin Admin
Admin
View all groups
View assigned groups

and subgroups no
subgroups
Create a group
only within the Only within the assigned
assigned groups.
groups The new group is a copy of a
source group; not a blank
group.
View group information
Modify group information

Only the subgroups.
View Max users and

Group Limits for a group
Modify the Max users or

Group Limits for a only within the only the subgroups.
subgroup assigned
groups
Suspend a group
only within the only the subgroups.
assigned
groups
Move a group
only within the assigned
groups
Move a group to the root
Delete a group
assigned
groups
Upload and download

groups

Access to attributes and attribute pools
Normal Users&Profiles Users Read-only Support

Feature Domain Admin
Admin Admin Admin Admin Admin
View attributes
Add, modify, delete attributes
Modify encryption property of an

attribute
Lock an attribute
Lock an attribute with a Super

Final lock
Set attribute values at the group

level
Set attribute value at the profile

level
Set attribute value at the user level
View attribute pools
Create and delete attribute pools

only the
subgroups.
View pool entries
Add pool entries to attribute pools
Enable an attribute pool for user
Unassign pool entries
Access to Stretto templates, profiles, users
Normal Domain Users&Profiles Users Read-only Support

Feature
Admin Admin Admin Admin Admin Admin
View templates
Add, modify, delete, upload, download

templates
View profiles
Add, modify, delete profiles Optional Optional

(admin option = Add/delete profiles)
View users


Feature
Add users Optional Optional Optional

(admin option = Add users)
Upload users and Download users Optional Optional Optional

(admin option = Upload/download users)
Modify user’s provisioning username and

password
Send email notifications to end users
Suspend and unlock users
Delete user's device Optional Optional Optional

(admin option = Delete user devices)
Delete users Optional Optional Optional

(admin option = Delete users)
Access to Stretto features

Feature
Test setup (Group Validation)

only the
subgroups.
Test provisioning response (in Users section)
Test LDAP server connection
View event logs
View user traces
View and download a list of devices
View Stretto reports (in Reports tab) (admin Optional Optional Optional Optional Optional
option = View reports)
Receive email reports Optional Optional Optional Optional Optional Optional
View enhanced client traces (device logs) (in Optional Optional Optional Optional Optional
Client Traces tab) (admin option = View
client traces)
Receive notification every time new device Optional Optional Optional Optional
log is uploaded (admin option = Client
Traces notification)
Help Desk Assistant (admin option = Help Optional Optional Optional Optional Optional
Desk Assistant)


Feature
Messaging and presence (XMPP) Optional Optional Optional Optional

(admin option = Messages option) The
XMPP tab
appears
for each
user.
End User Portal (admin option = Portal Optional Optional Optional

Settings)
Virtual Meeting Rooms (Collaboration Optional Optional Optional

meeting) (admin option = Meetings)
Privileges over admins

Feature
Privileges over Group Associations
Automatically associated with all groups
Can be associated with any number of Optional Optional

groups (and their subgroups) Only one
(admin option = Multi-group admin) group
Privileges over Administrators
View their own administrator privileges
View child administrators
Create an administrator
as a as a
descendant descendant
of itself of itself. Can
create only
certain admin
types 1
Associate a group with an administrator

only the only the
groups they groups they
are are
associated associated
with, with,
and only their and only their
child admins. child admins
of certain
types2
Move an administrator


Feature
only their only their

child admins child admins
Unlock an administrator
of certain
types3
Suspend an administrator
of certain
types4
Modify setup to receive email reports

themselves only their
and their child child admins
admins of certain
types5
Modify admin options

admins of certain
types6
Modify groups itself is associated with
Reset the password of another

administrator only their only their
Reset its own password (admin option = Optional Optional Optional Optional Optional
Change own password)
Delete an administrator
1The Domain admin has access to only the following admin types: Users&Profiles, Users,
and Support.
and Support.
and Support.

and Support.
and Support.
and Support.
Entity naming conventions

We recommend you follow these naming conventions. For information on how domain
names affect the user login to Stretto, see Enabling Auto-manage Usernames for an
existing group.
For groups
l Generally, group names should match your domain name, all in lowercase. For
example, acphone.com.
l If you are creating the top group for each of your Stretto customers, name each
group with the customer’s domain name. For example, acphone.com and
abccorp.com.
l If you plan to create more than one group, use URL-like names. For example,
northamerica.acphone.com and europe.acphone.com.
l The names “top” and “all” are not allowed.
l Group names must not contain a colon (:).
For users
There are two recommended formats for usernames: <username>@<groupname> and
<username>. You can use the format <username> only if the following conditions apply:
l You have installed Stretto at your organization (you are not a tenant on Stretto
provided by an OEM).
l You are deploying to your own end users.
l You are using a brand of Bria softphones that was built specifically for you, so that

the SPID matches your domain name.

l You are creating only one group on Stretto.
Otherwise, use the <username>@<groupname> format. (Using the <username> format when all
the above conditions do not apply means that your user attempts to log into Stretto will all
fail.)
Usernames must not contain a colon (:).
For templates and profiles

It may be useful to prefix all templates with T_ and all profiles with P_.
For attributes
For the attributes you create, we recommend you establish a convention and follow it
carefully. Remember that the attribute names you assign are case sensitive.
In the examples in this manual, we use this convention:

l attributeName: initial lower cap, then capitalize the first letter in each word.
l _attributeName: for an attribute that is used only by Stretto, not by the softphone
client. For example, the _emailAddress attribute.
You cannot start an attribute name with ccs:, ccs:req, or req:.
Masked, encrypted, and hidden data

For sensitive data, you can use the Masked, Encrypted, and Hidden properties for
attributes.
Masking of data
Masking hides the value of data in Stretto Admin and the Stretto CLI so that the
administrators do not see the value, which provides some protection for sensitive data.
However, the value of data is stored as plain text in the Stretto database.
Masking applies to the value of attributes set at the user level. Values set at the group or
profile level are never masked, even if the attribute is set up for masking.

You can set up any attribute as masked by checking its Masked property on the Groups
screen. You can clear the property at any time to unmask the value.
Encryption
Encryption encodes a value, and the encoded value is stored in the Stretto database,
providing another layer of security over masking.
Encryption applies to the value of attributes set at the user level. Values set at the group
or profile level are never encrypted, even if the attribute is set up for encryption.
You can set up any attribute as encrypted by checking its Encrypted property on the
Groups screen.
Note: You cannot clear the Encrypted property in Stretto Admin in order to change the value
from encrypted to unencrypted.
Fine points
l Data values that are encrypted are unencrypted at the moment they are sent from
Stretto to Bria. But typically this transmission is performed over a secure
connection.
l The user’s Stretto login password is initially entered by the user on Bria login screen
and sent to Stretto in unencrypted form (but over HTTPS, which protects the data).
The password is then masked and encrypted, and stored on the computer or
device.
l Provisioned data is protected on the computer or device: In Bria desktop, the data
file (including the login credentials) is encrypted on the computer or device. In Bria
mobile, the operating system protects the data file and ensure it is accessible only
to Bria mobile.
Hiding attributes
You can hide an attribute so that Lite administrators cannot see it. Lite administrators
includes: Domain admin, Users&Profiles admin, Users admin, Support admin, and Read-
only admin.

When an attribute is hidden, the entire attribute (its name and its value) are hidden to
those administrators on the Profile, and User screens.
You can set up any attribute as hidden by setting its Visibility property on the Groups
screen.
Assigning values to attributes

An attribute value can be set at:
l The group level, thereby creating a group-attribute. This value applies to all users in
the group unless it is overridden at the profile or user level.
l The profile level, thereby creating a profile-attribute. This value applies to all users
in the profile unless it is overridden at the user level.
l Or the user level, thereby creating a user-attribute.
User-attributes take precedence over profile-attributes. And user-attributes and profile-

attributes take precedence over group-attributes.
Skipping levels: deriving values

If you omit a value at the profile level, the profile derives its value from the group. If you
omit a value at the user level, the user derives its value from the profile or group.
For example
In this example, the final result is:
User Attribute X Attribute Y
Bob “dog” (derived from the profile) “false” (derived

from the profile)
Frank “rabbit” (from the user-attribute) “false” (derived

from the profile)
Emily No value (neither group nor profile nor user has a value defined. This may not be an error; the attribute “false” (from the
may not apply to the user. For example, it may be an attribute for a feature that is not offered to this user-attribute)
user.
Joseph Value “horse” (from the user-attribute) “true” (derived

from the group-
attribute)

Embedding attributes in values

The value can include another attribute. For example, if you are customizing the wording
of the login error messages, you could include the value of another attributes as part of
the wording. The referenced attribute can be an attribute you have created or special
attribute or internal data element.
You can embed one attribute in one setting or attribute. But you cannot, for example,
embed one attribute in a second attribute in a third attribute.
For example
Three related attributes have been created: msg:device:limit, support.contact.admin and
support.contact.admin.email. The value for msg:device:limit embeds the other two
attributes.
In this profile, the value of msg:device:limit resolves at runtime to “Device activate limit
reached. Contact Emily Wilding at [email protected]”.
Subgroup attributes inheritance and locking

In a setup with subgroups, attributes in a subgroup may be inherited from the parent
group. Setting up for inheritance is an effective way to set a value for an attribute once (in
a parent group) instead of having to set it up individually in each subgroup.
Attributes that are inherited are separated in Stretto Admin from attributes that were
created in the subgroup.

Keep in mind that your group may be inheriting attributes from a group that you do not
manage.
How subgroups inherit the attribute

Subgroups inherit the attribute from the parent (so the attribute appears in the Inherited
Attribute Values section) as follows:
l If the attribute is Open in the parent, the subgroup inherits it only if the attribute has
a value at the group level in the parent.
l If the attribute does not have a value in the parent, then the attribute does not
appear in the subgroup.
l If the attribute does not have a value in the parent and is set to Empty Root, then the
subgroup inherits an empty attribute that can be modified in the subgroup.
l If the attribute is Locked, Final or SuperFinal in the parent, the subgroup always
inherits the attribute.
How subgroups inherit attribute values

Subgroups only inherit values that are set in the parent at the group-level in the parent.
Subgroups never inherit values from the profile or user level in the parent. Instead, the
subgroup profile and user derive their values from their own group level or else have
“local” values (values right in the profile or user).

Locking of attributes in a subgroup setup

In a setup with subgroups, locking applies to the group where the attribute gets a lock
applied and to all the subgroups of that group.
Overriding inherited locks in a subgroup setup

In the parent group, the lock can be changed to make the lock weaker or stronger or to
remove it (that is, in the group where the lock was initially set).
In a subgroup, the lock can be overridden but only to make the subgroup lock stronger
than the parent lock.
If the lock is set in the parent and then overridden in the subgroup, then changing the lock
in the parent does not change it in the subgroup: the subgroup override still applies. For
example, the lock is Locked in the parent and then overridden to Final in the subgroup. In
the parent, you then change the Locked to Open. The lock changes in the parent. But it
remains as Final in the subgroup.
If the lock is set in the parent and not overridden in the subgroup, then changing the lock
in the parent also changes it in the subgroup.
Overriding attribute values in a subgroup setup

An inherited value can be overridden in the subgroup if the lock type permits it. The lock
type determines where the attribute can be overridden, as shown in the following table.
For example, a Medium lock type allows an administrator in a subgroup to change the
attribute's value for their entire subgroup, but not for profiles or individual users.
Parent group Child group (subgroup)

Strength Lock type Group Purpose
Profile or user level Group level Profile or user level
level
Strong Final Yes No No No Prevent the

attribute value
being set or
changed anywhere
except at the group
level.
The difference
between Locked
and Final only
becomes clear in a

Parent group Child group (subgroup)

Strength Lock type Group Purpose
Profile or user level Group level Profile or user level
level
subgroup setup.
Medium Locked Yes No Yes No Prevent profile or

user overrides
being set.
Weak Open Yes Yes Yes Yes Let the value be

set in any level in
the group.
Template inheritance
Templates in a subgroup may be inherited from the parent group. When a template in the
parent group is set for template inheritance, the subgroups can map the inherited
template to their profiles without creating a copy of the parent's template. Setting up for
template inheritance is an effective way to maintain templates; the administrator needs to
modify only one template as opposed to all the templates in the subgroups.
How inherited templates appear in subgroups

Administrators see a set of inherited templates regardless of the type of administrator
such as Support Admin, User, and Profile Admin.
The inherited template does not appear in the tree of the subgroups. The inherited
templates appear in the Profile screen, under the Template Mappings section.
The view of the parent admin:

Inheriting from non-visible upper-level group

If you are a subgroup admin, your group may be inheriting templates from a group that
you do not manage or see in Stretto Admin. In this case, you only see the name of the
inherited templates under the Template Mapping section.
The view of the subgroup admin:
l The subgroup admin cannot edit or view the content of the inherited templates.
Note in the above example that the inherited template does not have a hyperlink.
l To view actual content of inherited templates, use the Test button on the User
screen; it displays the template with user-specific values populated.
l The validate function in subgroups does not validate the inherited template. The
parent admin must validate it in the upper level group before allowing inheritance.
l The subgroup admin does not know which attributes are embedded in the inherited
templates. The parent admin must configure attributes for the subgroup before
allowing inheritance.
Rules on template names

To set up a template for inheritance, the template name must be unique in the group tree.
This rule has the following impacts:
l If the subgroups already have a template with the same name as the inherited
template, the matching templates in the subgroups are removed, and the profiles
are updated to refer to the newly-added inherited template. If you, as a parent
admin, are sure that all subgroups should use the same template, this is a good
way to clean up the duplicate local templates of the subgroups. If you are not sure
how subgroups use local templates, rename the inherited template so that
subgroups can choose which template to use.
l The subgroup admin must name a template differently from the inherited templates
when creating a local template in a subgroup.

Stretto Platform Administration Guide Setting up for login and provisioning
Setting up for login and provisioning
The Stretto Platform (Stretto) authenticates users and provisions the CounterPath
softphone clients.
Login authentication
Stretto authenticates users and handles login from the softphone clients. Read this page
for how login works. Or you can configure Stretto so that another server authenticates
end user logins instead of Stretto. For example, if your organization has an LDAP server
that holds data about your end users, you can configure Stretto to use LDAP to perform
user authentication.
See the respective section for details:

l Authenticating user logins via LDAP
l Authenticating user logins via external configuration server
Login-related features
End users might forget their password for logging into Bria clients. They get locked out
after five failed login attempts in a row, and they need to wait for 10 minutes to try a next
login.
The following features are available to manage login issues:

l A Forgot password link can be included in End User Portal if you are using Stretto
Platform to authenticate users. This allows your end users to reset their password
without your assistance. This requires you to store the end user's email address in
Stretto.
This feature does not work with your situation if you are using LDAP or other
servers to authenticate users.

l Use Stretto Admin's Notify button to email an end user with a temporary access
code, then the user uses the code to reset their password in End User Portal. This
requires you to store the end user's email address in Stretto. See this page for
details.
This feature does not work with your situation if you are using LDAP or other
servers to authenticate users.
l If an end user is locked out, they can simply wait for 10 minutes to try a next login.
Or you, as an admin, can unlock them by using Stretto Admin.
Provisioning
Provisioning allows a Stretto administrator to remotely configure the CounterPath
softphone client instead of manually setting up the client for each user. End user logs into
Stretto, and Stretto configures the softphone client for that user. All configuration is done
in the background; end users can start using the softphone client without worrying about
setting it up.
Examples of items you can provision include:

l The user’s SIP username (the “6045551000” in [email protected]) and
SIP password.
The domain may also be provisioned, or it may have already been hard-coded into
your brand.
l The Desktop license key. See Provisioning Bria desktop licenses for important
information about licenses. For Bria mobile, license keys are generally built into the
client before it is put on App Store or Google Play.
l Softphone features. Feature provisioning allows you to configure some aspects of
the softphone after deployment, rather than when you specify the brand. For
example, for the Bria mobile softphones, you can provision the URL for your help
page. You can provision the URL differently for different users, for example,
sending some users to your Asian website and others to your European website.
Overview of provisioning
This section provides a high-level description of how provisioning works with Stretto.

1. Your brand of the CounterPath softphone must be branded to support the Stretto
login setup you want:
l For Bria desktop: You have two choices: you can hard-code the Stretto URL
into your brand, or you can let the end-user enter the URL manually.
l For Bria mobile: You provide the initial provisioning server URL to include in
your brand.
2. You set up your Stretto framework on Stretto to support the desired provisioning
features. Setting up the framework involves setting up provisioning templates,
variables and profiles.
3. As the final step of this setup, you add your users to Stretto. Each user is identified
by a Stretto username and password. The user enters these credentials to log into
their Bria softphone.
Optionally, Stretto can be configured to connect to an external server (such as
LDAP) and the user can enter their LDAP credentials to log into their Bria
softphone.
4. You provide the user with their login credentials outside of Stretto, for example, by
email.
5. The user starts Bria on their computer or device and enters their login credentials
on the login screen. The softphone contacts Stretto over HTTPS.
6. Stretto finds the user, authenticates the request using the provided credentials,
creates the provisioning file using the latest data, and sends the file down to the
user. The user’s softphone starts.
From now on, each time the user logs into Bria, this login procedure is followed and the
latest information for that user is sent down.
Provisioning-related features
In addition to configuring basic provisioning, you can also configure the following
features;
l Updating configuration while end users remain logged in the softphone client: Re-
provisioning the Bria clients (refresh)

l Desktop: Provisioning softphone client upgrade (to a new version): Setting up

remote upgrade of Bria desktop
l Controlling user and device counts: Limiting user and device counts
l Error message translation: Customizing and translating login error messages
How login and provisioning works

Login and provisioning takes place in the following sequence:
1. When the Bria softphone starts, a login screen appears and the user enters their
Stretto login credentials.
2. The Bria softphone sends an HTTPS request to Stretto. Stretto reads the HTTPS
request and verifies the login credentials.
3. If the login credentials are known to Stretto, then Stretto creates a provisioning
response and sends it down to the Bria softphone. (If the login credentials are not
known or if the user is not set up correctly on Stretto, then Stretto sends down a
failure response with an error message. “Login failed” plus the error message will
appear on the user’s softphone.)
4. The Bria softphone applies the data in the response and the softphone starts up
with the configured behavior.
The softphone clients are built with default values for settings. So if you do not include a
given setting in the template (and hence in the provisioning response), then the client still
works using the default value. In some cases the default is an explicit value – a string,

number, or boolean. In some cases the default is “null” or the setting is not actually in the
build, which either means the setting has no effect or that it is explicitly disabled.
The very first time you send down a response, each setting is applied as follows:
l For each setting in the response that already exists in the client, the new value
replaces the current value.
l If a setting is in the response but not in the client, the new setting is added to the
client.
l If a setting is not in the response but is in the client, there is no change to the client.
Note: Removing a setting from the template (provisioning response) does not remove it from
the softphone client. To disable or change a setting, you must leave the setting in the template
and set its value to disabled or “null”.
Authenticating user logins via LDAP

If your organization has an LDAP server that holds data about your end users, you can
configure Stretto to use your LDAP server to perform user authentication. The advantage
of this feature is that you, a Stretto administrator, do not need to create separate
credentials for Stretto users. End users can use their LDAP credentials that they use
elsewhere to log into the softphone client.
Requirements
Your LDAP server must allow access from the CounterPath-hosted Stretto Platform.
Make sure to:
l Make your LDAP server publicly available.

l Whitelist CounterPath servers in your network.
CounterPath has two sites for geographic redundancy. See this page for the
IP addresses of the CounterPath-hosted Stretto Platform.
l Set up a DNS name to address your LDAP server instead of using an IP address.
This is optional.

Add-on
In addition to user authentication, you can configure Stretto to automatically create
Stretto users upon successful LDAP authentication. With this add-on, a Stretto
administrator does not even need to create a Stretto user. See below for details.
The "add-on" requires for user authentication to be configured first.
How end user authentication works

You can configure Stretto to push the “user login authentication” decision onto an LDAP
server. When user authentication is being done by LDAP, it works as follows:
1. The user enters their Stretto username and password on the softphone client login
screen, in the usual way. The client passes the username and password to Stretto.
2. Stretto finds the Stretto username in Stretto and determines the group that the user
belongs to. Stretto also finds the LDAP server address and other LDAP information.
3. Stretto creates an LDAP bind request and sends it to the LDAP. It binds to the
LDAP using the information in the bindDN attribute (which you set up) and using the
individual user’s Stretto password as the LDAP password. The LDAP authenticates
the username and password and sends a success response to Stretto.
4. Stretto then creates the provisioning response as usual and sends it down to the
softphone.
Note: Note that when the LDAP is performing user authentication, the user’s login password
(Stretto password) is never stored on Stretto; instead, the password received from the
softphone is passed through to the LDAP.
Configuring LDAP authentication

1. Configure LDAP properties
2. Set up users for LDAP authentication
3. Test your LDAP configuration

A variation: Applying to a subset of end users

LDAP end user authentication can be selectively applied to users within a group; for
example, some users use Stretto for authentication while the rest use LDAP. This is
controlled by profiles. See Apply LDAP authentication to a subset of users for more
details.
Auto-creation of users in Stretto

Read this section if you want to configure Stretto to automatically create a user upon a
success authentication response from the LDAP.
List of tasks to be completed in order to auto-create users in Stretto:

l Determine the login credentials of end users. See below.
l Provide end users with their login credentials to Stretto.
l Make sure you have configured templates and a profile.
l Set the attributes for LDAP user authentication. Note the following:
l Configure Stretto with the fetch mode.
l Set a default profile to be used when creating a user.
l Configure data retrieval for the data you want to provision to end users such as SIP
credentials. Contact CounterPath about data retrieval mappings configured on our
hosted Stretto server to see our attribute extraction settings work for your LDAP
server. You will likely want to retrieve SIP username/password from LDAP to
Stretto.
l No need to create a user in Stretto.
User credentials
For Stretto to automatically create users, the login credentials must be as follows:
l Username:
The username portion must match the LDAP username used by the LDAP to
authenticate users. Stretto passes the username portion onto the LDAP without
altering.

The domain portion must be the Stretto group name, which is replaced with the
value set to {{std:ldap:domain}} by Stretto if configured when it sends a login
request to the LDAP.
l Password
The password to log into the LDAP. Stretto passes the password onto the LDAP
without altering. This password is never stored on Stretto.
Example:
The end user enters these credentials on the client.
Username: [email protected]
Password: LDAPpassword
Stretto receives the request, replaces the domain portion with the value set to
{{std:ldap:domain}}, and sends a request to the LDAP with the following credentials:
Username: kperera@ac_corporation.com
Password: LDAPpassword
Configure LDAP properties

Once the LDAP server is set up in the Stretto Platform, configure Stretto to bind to the
LDAP server.
To configure LDAP properties
1. Use Stretto Admin to create the attributes shown in the following table. Set the type
as “String” in all cases.
2. Assign a value to each attribute by following the table below. If assigning a value to
a profile because you have multiple LDAP servers for example, remember to assign
it in every profile.
The LDAP attributes are set.

List of LDAP attributes
Where to
Attribute Description
Set Value
Location of LDAP
std:ldap:server The hostname or IP address of the LDAP server (e.g., At the

ldap://x.x.x.x:389,ldaps://x.x.x.x:636). group or
You can configure multiple LDAP servers for failover so that the LDAP service profile
continues even when one of the LDAP servers is not reachable. To configure multiple level.
LDAP servers, separate them with a comma (,).
This attribute can be used to enforce secure LDAP over TLS by ensuring that the
entries are in the format ldaps://<domain>:<port> (the port number is
usually 636).
std:ldap:baseDN The distinguished name (DN) of an entry in the LDAP directory tree where the search At the
starts. Must be the full DN. Also known as root DN. This entry is the starting point of group or
the search for users to authenticate, and for the data to pull into Stretto. The entire profile
subtree under the base DN is used for searching. level.
For example, dc=acphone, dc=local
std:ldap:ignoreError Typically set to false. At the

group or
When true, validation of the user's login credentials is skipped if no LDAP servers
profile
(configured in std:ldap:server) are reachable. The user logs into the softphone without
level.
having their credentials validated; you must therefore assess the risk in setting
std:ldap.ignoreError to true.
When false, the user's login attempt fails if no LDAP servers (configured in
std:ldap:server) are reachable.
Binding in Order to Authenticate
std:ldap:bindDN The username to use when binding to the LDAP server. In other words, the LDAP At the
username of the softphone users to be authenticated for softphone logins as well as group or
data retrieval (if setup). The LDAP server uses this value to find a user in the directory profile
and authenticate them. Often an LDAP server uses the username plus domain format level.
such as [email protected] and [email protected].
When you set a value to std:ldap:bindDN, use a variable instead of typing out
each user's name so that the variable is replaced with a real value for each user.
{{ccs:userName}} is recommended for most cases. Or enter
Entering
{{ccs:userName.User}}@{{std:ldap:domain}} if your Stretto
group differs from the LDAP domain.
See Binding: Mapping the Stretto username to the LDAP username to assess this
suits your setup.
std:ldap:domain May not be required; see Binding: Mapping the Stretto username to the LDAP At the
username for information on its usage. group or
The domain name of your LDAP server. In other words, the domain portion of end profile
user's LDAP username, such as [email protected]. Stretto replaces Stretto level.
group name in the login username with this value and send the username to the
LDAP server when requesting user authentication.
std:ldap:user May not be required; see Binding: Mapping the Stretto username to the LDAP At the user
username for information on its usage.

Where to
Set Value
level, so
the value
is different
for each
user.
Auto Creation of Users
std:ldap:fetchMode When set to true, Stretto creates a user (if not already exist) upon receiving a success At the
authentication response from the LDAP server. Stretto also retrieves data from the group
LDAP as configured via data mapping, and stores it in Stretto. level.
When set to false, Stretto does not create a user; it returns the “User not found” error
to the softphone client. This means that the users must exist in Stretto before anyone
starts using their softphones. In this mode, Stretto retrieves data from the LDAP only
when the user already exists in Stretto.
Regardless of std:ldap:fetchMode, the LDAP server authenticates end
users for login.
std:default:profile This setting is used when std:ldap:fetchMode is true. At the

group
Specify a name of the profile to be used for creating a user in case the user does not
level.
exist in Stretto after successful authentication by the LDAP.
The profile must exist in the group in Stretto.
Binding: Mapping the Stretto username to the LDAP username

In order for Stretto to bind to the LDAP, you must provide the LDAP with the user’s LDAP
username. You provide this data in different ways, depending on how both Stretto
usernames and LDAP usernames are formatted, as described in the following table.
Keep in mind that Stretto automatically uses the user’s Stretto login as the password for
the bind. You do not have to set up for this password, beyond making sure that the user’s
Stretto login is the same as the bind password.
Note: In order to make this mapping as easy as possible, you may want to try to establish the
rule that your Stretto usernames exactly match the LDAP username (assuming that the LDAP
username already exists). In this way, you can follow the simplest format: bindDN =
{{ccs:userName}}.

Formats of usernames in Stretto and LDAP
Format of LDAP
Format of Stretto Username How to Set up the DN Bind
Username
“fchan” in the group fchan bindDN = {{ccs:userName}}

“acphone.com”
[email protected] bindDN = {{ccs:userName}}@acphone.com
or
bindDN = {{ccs:userName}}@{{std.ldap.domain}}
std:ldap:domain = acphone.com
fchan@ac_ bindDN = {{ccs:userName}}@ac_corporation.com
corporation.com
or
bindDN = {{ccs:userName}}@{{std.ldap.domain}}
std:ldap:domain = ac_corporation.com
[email protected], where fchan bindDN={{std:ldap:user}}
acphone.com is the Stretto
std:ldap:user= fchan
group name
[email protected] bindDN = {{ccs:userName}}
fchan@ac_ bindDN={{std:ldap:user}}@{{std.ldap.domain}}
corporation.com
std:ldap:user = fchan
std:ldap:domain = ac_corporation.com
or
bindDN={{std:ldap:user}}@ac_corporation.com
std:ldap:user = fchan
(Both methods do the same thing. The first makes it harder to ever add more
LDAP domains; the latter does not require the ldap domain to be entered
when assigning std:ldap:user)
fchan in the group frank_chan bindDN={{std:ldap:user}}

“acphone.com”
std:ldap:user= frank_chan
or
[email protected], where frank_ bindDN={{std:ldap:user}}
acphone.com is the Stretto [email protected]
group name std:ldap:user= [email protected]
or
bindDN={{std:ldap:user}}@acphone.com
std:ldap:user= frank_chan
(Both methods do the same thing. The first makes it harder to ever add more
LDAP domains; the latter does not require the ldap domain to be entered
when assigning std:ldap:user)
frank_chan@ac_ Same as previous, except use ac_corporation.com instead of
corporation.com
acphone.com

Example:
Five attributes have been created for LDAP configuration. Four of these attributes
are defined at the profile level, while one is defined for each user. Note in the profile,
how the value for std:ldap:bindDN is set to another attribute! Make sure you include
the double curly braces {{}} around the attribute name.
Set up users for LDAP authentication

When creating users, make sure you do not set their Stretto password. This is the only
case where the Provisioning Password field should be blank.

Note: The Stretto password field must be blank in order for LDAP user authentication to work
for this user.
Test your LDAP configuration

Once you have set up your LDAP server, you can test if the LDAP setup is done correctly.
l The Test tool lets you test if your LDAP server can be reached from Stretto.
l If you provide a user's password in the test, the Test tool verifies if the user can log
into the softphone using the LDAP credentials, and if the bindDN can be
authenticated against LDAP.
What the test entails

The Stretto LDAP Test tool lets you verify:
l Connectivity - to verify if the LDAP server can be reached. Equivalent to a ping test.
If this fails, check the IP address or host name of your LDAP server in the
std:ldap:server attribute.
l Admin Authentication - to verify admin credentials to load a roster and vCards from
your LDAP server. Applicable to a Stretto Platform with XMPP enabled, and an
LDAP server has been configured to supply a roster and vCards.
If this fails, check the values of the std:ldap:adminDN and std:ldap:adminPW
attributes.
l Provisioning Authentication - to verify the user's credentials for softphone logins.
If this fails, check the response code and troubleshoot accordingly. Until then, the
user cannot log into the softphone.
Tip: The difference between this LDAP provisioning authentication and the
regular provisioning test is that the LDAP provisioning authentication attempts
to directly log into the LDAP server without going through the Stretto
templates/profiles, while the regular provisioning test verifies the Stretto
templates/profiles setup.

l BindDN Authentication - to verify the bindDN is correct. The tool attempts to

authenticate against the LDAP server using the LDAP username specified in the
std:ldap:bindDN attribute.
If this fails, check the value of std:ldap:bindDN. See Binding: Mapping the Stretto
username to the LDAP username for an example of bind DN.
l User Information Retrieval (vCards) - This test uses the admin credentials and
retrieves the user's vCard information from LDAP. You can also review what
information the vCard stores for this user. This matches what is presented to all
users in a roster.
Applicable to a Stretto Platform with XMPP enabled. Also assumes that an LDAP
server has been configured to supply a roster and vCards, as well as a vCard
template has been configured in the Stretto group.
If you do not see the expected results, check the vCard template if it uses a correct
LDAP field name. See Configuring vCards for XMPP buddies.
Response code
Response code Description
OK success
URL_SYNTAX LDAP URL syntax is incorrect.
CONNECTION_REFUSED Valid host, but a connection is not allowed (valid host but invalid port for example)
EXPIRED Time out connecting (set at 10 seconds)
INVALID_HOSTNAME Unable to translate the hostname to an IP address
NO_ROUTE_TO_HOST Cannot reach host
USER_NOT_FOUND User not found on the LDAP server
UNAUTHORIZED Authentication refused (incorrect password for example)
SUSPENDED User is suspended on the LDAP server, therefore could not verify authentication against the LDAP server.
LOCKED_OUT User is locked out on the LDAP server, therefore could not verify authentication against the LDAP server.
SSL_HANDSHAKE Authentication failed (mainly due to an certificate issue)

Testing the LDAP setup

Follow these recommended steps to test your LDAP setup:
To test your LDAP setup
1. Create at least one test user.

2. Run the test on each test user. Select one user and click Test > Ldap Test.
3. Enter the user's LDAP password. If omitted, it tests only the LDAP connectivity and
the admin credentials.
4. Click Test.
Example:
Sample result
In this example, there are two LDAP servers configured.

When clicking details for vCard, a pop-up window opens and displays a list of LDAP
fields and their values. These LDAP fields are the ones configured in the vCard
template.
Apply LDAP authentication to a subset of users

When you configure an LDAP server, typically all users in your group use LDAP
authentication. However, it is possible to configure Stretto so that only a subset of your
users use LDAP authentication.
This section describes how to configure Stretto to apply LDAP authentication to only a
subset of users within a group.
l Set up two profiles: one with LDAP and another without.

l Go through the attributes in the table in Configure LDAP properties, and assign a
value in the profile used for LDAP authentication. There are exceptions; some
attributes should only be assigned at the user level.
l When creating a user, make sure to set the correct profile to the user.
l For users with LDAP authentication, the Stretto password field must be empty.

l For users without LDAP authentication, you must assign a password by entering a
value.
l There is no need to separate users into sub groups; all users are allowed to stay
within a single Stretto group.
l Do not configure the auto creation of users feature.
Here is a comparison of configuration.
Item Users with LDAP Authentication Users with Stretto Authentication
Attributes: These attributes must be configured at the profile level, These attributes must be empty for the user (no
particularly std:ldap:server. value set at any level - group, profile, user).
std:ldap:server
Do not set a value to these attributes at the group level.
std:ldap:baseDN
std:ldap:domain
std:ldap:bindDN
Stretto password on the Must be empty; do not set a value to the Stretto You must assign a Stretto password to the user
User page password field when creating a user on Stretto. by entering a value or a nesting attribute when
creating a user.
Auto Creation of Users Do not configure this feature. You can use this feature in Do not apply.
the group where LDAP authentication is applied to a
subset of users.
The attributes (fetchmode and default profile) must be
configured at the group level.
The std:default:profile attribute must be
set to the profile you created for LDAP authentication.
Authenticating user logins via external

configuration server
If your organization has an external configuration server (ECS) that holds data about your
end users, such as Broadworks DMS, you can configure Stretto so that the ECS performs
user authentication. The advantage of this feature is that you, a Stretto administrator, do
not need to create separate credentials for Stretto users. End users can use their ECS
credentials that they use elsewhere to log into the softphone client.

Add-on
In addition to user authentication, you can configure Stretto to automatically create
Stretto users upon a successful authentication response from the ECS. With this add-on,
a Stretto administrator doesn’t even need to create a Stretto user. See below for details.
The "add-on" requires for user authentication to be configured first.
How end user authentication works

User authentication works in the following sequence:
1. The user enters their Stretto username and the ECS password on the softphone
client login screen, in the usual way. The client passes the username and password
to Stretto.
2. Stretto finds the username in Stretto and determines the group that the user
belongs to. Stretto finds the ECS address.
3. If a domain is configured by the Stretto administrator, Stretto removes the domain
entered by the end user, and appends the configured value.
4. Stretto sends a login request to the ECS along with the user’s login credentials to
Stretto.
5. The ECS authenticates the username and password and sends a success
response to Stretto.
6. If a mapping is configured by the administrator, Stretto retrieves data from the ECS
response, and stores it in Stretto.
7. Stretto creates a provisioning response using the Stretto template, along with the
mapped data (if configured), and sends the provisioning response down to the
softphone client.
8. The client is loaded with the provisioned settings.
Auto-creation of users in Stretto

Read this section if you want to configure Stretto to automatically create a user upon a
success authentication response from the ECS.

A list of tasks to be completed in order to auto-create users in Stretto

l Determine the login credentials of end users. See below.
l Provide end users with their login credentials to Stretto.
l Make sure you have configured templates and a profile.
l Complete the initial configuration.
l Set true for the std:ecs:authentication:mode attribute.
l Set a default profile to be used when creating a user.
l Contact CounterPath about data retrieval configurations on our hosted Stretto
server to see which ECS data can be pulled into Stretto. You will likely want to
retrieve SIP username/password from the ECS to Stretto.
l No need to create a user in Stretto.
User credentials
For Stretto to automatically create users, the login credentials must be as follows:
l Username: The username portion must match the ECS username used by the ECS
to authenticate users. Stretto will pass the username portion onto the ECS without
altering.
l The domain portion must be the Stretto group name, which will be replaced with the
ECS domain name by Stretto when it sends a login request to the ECS.
l Password: the password to log into the ECS. Stretto will pass the password onto the
ECS without altering. This password is never stored on Stretto.
Example:
The end user enters these credentials on the client.
Password: ECSpassword
Stretto receives the request, replaces the domain portion, and sends a request to the
ECS with the following credentials:
Password: ECSpassword

Configure external configuration server properties

Once the external configuration server (ECS) is set up, configure Stretto to connect to the
ECS.
1. Using Stretto Admin, create the attributes shown in the following table.
2. Set the type as “String” in all cases.
3. Assign a value to each attribute.
Attributes and their descriptions

All attributes listed here are set at the group level.
std:ecs:server Deprecated. Use the following attributes instead.
std:ecs:urlDesk The URL where the softphone clients hit to log into the ECS. Stretto has two properties:
one for desktop, the other for mobile. These must be defined separately even if the ECS
std:ecs:urlMob uses the same URL for both clients.
std:ecs:domain Configure this value if the domain of the ECS is different from the Stretto group name.
When sending the credentials to the ECS, Stretto removes the domain entered by the
end user on the softphone login screen, and appends the value configured for this
property. If the property is not specified, Stretto uses the Stretto group name as the ECS
domain name.
std:ecs:httpAuth Stretto supports the following modes for an ECS:
l 1: Digest authentication (default)
l 2: Basic authentication
l 3: Stretto (this method is used to pass the authentication to another Stretto

instance)
std:ecs:authentication:mode When set to true, Stretto automatically creates users upon a successful response from
the ECS if the user does not exist in Stretto. Stretto creates the user with the username
returned by the ECS, along with the profile defined in std:default:profile.
When set to false, Stretto does not create users automatically. If you set this to false,
you must create users in Stretto before a user logs in; otherwise, user authentication
does not work.
Regardless of the std:ecs:authentication:mode attribute, the ECS
performs user authentication, and Stretto pulls values from the ECS response as long
as mappings are defined in Stretto.
std:ecs:ignoreError Optional. Set to true to instruct Stretto to send a success provisioning response to the
softphone client if the ECS is not reachable for authentication/data retrieval. Stretto
sends cached values to the softphone clients without retrieving the latest values from
the ECS. This allows end users to continue using the softphone clients. The user must

exist in Stretto, which means that the user must have been authenticated at least once.
If the user has never logged into Stretto/ECS, the login fails until the ECS becomes
available.
Set to false to send an error to the softphone client if the ECS is not reachable. Whether
or not the softphone client stays logged in depends on the client settings. The client has
other settings to control its behavior on provisioning errors (such as logout on refresh
failure in Bria mobile).
std:default:profile This setting is used when std:ecs:authentication:mode is true.

Specify a name of the profile to be used for setting up a user in case the user does not
exist in Stretto after successful login to the ECS.
The profile must exist in the group in Stretto.
Creating users
This section applies if you use the ECS in the fetch mode, that is if you decide not to
automatically create users in Stretto upon a success authentication response from the
ECS.
When creating users, make sure you do not specify their Stretto password. The Stretto
password field must be blank in order for ECS user authentication to work for this user.
Provisioning Bria desktop licenses

This section supplements the procedures in How Stretto entities work at runtime and
should be read in conjunction with that section.
When you obtain Bria desktop, you purchase a license or licenses. The executable does
not include a license key. You can provision the license key via Stretto, as described
below. (You can also let the user enter the key manually via Help > Enter License Key).

Setting up for license provisioning

Setting up for license provisioning involves specifying the type of key, setting up the key
in a template, and setting up a service.
Which type of key?

When you purchased Bria desktop, you would have specified which type of key to use:
l A pool of individual license keys, one key per user. Each key has a count of one,
meaning that the key can be used in one installation of the softphone.
l A group license that all users share. The key has a specific count and can be used
on all installations until the count is used up.
Setting up Stretto
Typically, you include the license key in the data you send down when provisioning user
data or when provisioning features.
To provision the license key
1. Create an attribute for the key, for example, LicenseKey.

2. Include a line for the license key in the Stretto template that references the attribute.
For example:
[DATA]
Success=1
LicenseKey="{{LicenseKey}}"
[SETTINGS]
3. Set up the attribute value:

If you have individual license keys: Create an attribute pool that holds all the license
keys you obtained from CounterPath. Each time a new user logs on, a license key is
taken from the pool and assigned to the user. Your license key count (maintained
on your CounterPath Store account) is automatically adjusted.
If you have a group key: Do not create an attribute pool. Instead, in the group or in
the profile (or profiles), enter that one key as the value for the license key attribute.

Setting up your service

Periodically, Bria desktop connects to CounterPath’s license server in order to verify that
a valid license is being used. Therefore, at all times, Bria desktop needs to have an
internet connection.
To set up your service
1. Bria desktop connects to https://secure.counterpath.com via port 443. Users must

make sure their firewall allows this HTTPS traffic to this URL.
2. In addition, if Bria desktop has explicitly set a web proxy in Microsoft Windows
(Start > Control Panel > Internet Options > Connections) then Bria desktop uses
this proxy. Network administrators must make sure the proxy allows this traffic.
License tracking
License tracking includes how licenses are tracked and managing the license count.
How individual licenses are tracked

An individual license key has a count of one, meaning that it can be installed on only one
computer. An individual license key is tracked in two ways: in Stretto and on the
CounterPath license server, which is separate from Stretto.
When an individual Bria desktop obtains a key from Stretto, that key is tagged as
“assigned” on Stretto (see How pool entries are assigned and managed).
Once the license key has been obtained from Stretto and installed in the individual Bria
desktop, Bria desktop connects to the license server in order to register the key. Bria
desktop does not start until registration has succeeded.
If the user later installs Bria desktop on another computer, then when it connects to
Stretto, it obtains the same license key. But when it connects to the license server, the
license server refuses the registration (because the key is already registered on another
computer). The login attempt fails on this second instance of Bria desktop.
How group licenses are tracked

A group license key has a multiple count, meaning that it can be installed on multiple
computers. A group license key is tracked only on the CounterPath License Server, which
is separate from Stretto.

Once the license key has been obtained from Stretto and installed in the individual Bria
desktop, Bria desktop connects to the license server in order to register the key and
increment the license usage count. If the count is at its maximum, registration fails. An
error message appears for that user and Bria desktop does not start.
You can re-assign and revoke particular seats (counts) of a group license key; see the
CounterPath documentation for the license server.
Managing the license count

When the license usage count reaches the maximum on the license server, new users
are no longer be able to start Bria desktop. You can increase your licenses.
Increasing your licenses

Contact your CounterPath Sales Account manager.
If you purchase more individual licenses, CounterPath will send you an email containing
the new keys. Add them to Stretto (see Step 2: Populating an attribute pool with values).
If you increase your group license count, CounterPath will send you a confirmation email
when the count has been increased. You do not have to take any further action; new
users will simply be able to register successfully on the license server, and the license
count will continue to increment.
Re-provisioning the Bria clients (refresh)

Stretto Platform supports re-provisioning or refresh, which means that Bria clients
connect to Stretto at regular intervals to retrieve any changes to settings since the user
last logged in. Re-provisioning proceeds silently; the Bria users will probably not notice
that it is happening.
Re-provisioning (or refresh) is enabled by default. You can:

l Change the refresh interval, or
l Disable re-provisioning.
To manually refresh the end users' devices, see Sending the most recent configurations
to end users' devices (Refresh Devices).

How it works
When the Bria client logs into Stretto for the first time, it gets provisioned with the refresh
interval (8 hours by default, configurable). When the refresh interval expires, the client
contacts Stretto for re-provisioning and gets provisioned with any new or updated
settings.
If re-provisioning did not occur, for example, due to a network problem, the Bria client
keeps working for a grace period of 3 days. After the grace period, the Bria client
automatically logs out and end users must log in again to use Bria. A grace period starts
over every time Bria gets a successful provisioning response from Stretto.
Changing the refresh interval

Make sure the interval is shorter than the grace period of 3 days (259200 seconds).
Desktop template
Include the following lines under [SETTINGS] of the applicable Stretto templates for Bria
desktop:
For example:
[SETTINGS]
feature:auto_update:periodic_check_in_required="true"
feature:auto_update:check_in_interval_s="86400"
Mobile template
Include the following lines in the login_response section of the applicable Stretto
templates for Bria mobile:
<data name="refreshTimeValue" value="<time>"/>
where <time> is the number of seconds (e.g. “86400” for refreshing every 24 hours).
For example:
<?xml version="1.0" encoding="UTF-8"?>

<cpc_mobile version="1.0">

<login_response>

<status success="true"/>
<data name="refreshTimeValue" value="86400"/>
</login_response>
Either include the values of the settings right in the template (as shown above), or create
Stretto attributes for these settings and set the values in Stretto at the group, profile or
user level.
Disabling re-provisioning
Desktop template
To stop Bria desktop connecting to Stretto with refresh requests, set the feature:auto_
update:periodic_check_in_required setting to false.
For example:
[SETTINGS]
feature:auto_update:periodic_check_in_required="false"
Mobile template
To stop Bria mobile connecting to Stretto with refresh requests, set the refreshTimeValue
to "" or "0".
For example:

<login_response>
</login_response>
What happens next

Now, the next time the user logs in or the next time Bria contacts Stretto for provisioning
refresh, the refresh time will be set to null. From then on, Bria will not connect to Stretto
for refresh.

To re-enable refresh for Bria mobile, set the refreshTimeValue to a positive number. For
Bria desktop, set the feature:auto_update:periodic_check_in_required setting to true.
Keep in mind that the users will be provisioned with this new value (and will therefore
start connecting to Stretto again) only after they have manually logged onto Bria
clients.
Testing your provisioning setup

Once you have set up the group, attributes, provisioning templates, and profiles, and you
have created at least one user, you can validate and test the setup.
l The Validate tool lets you verify that your intended “structure” is good and
everything is “hooked up” correctly: you don’t have orphaned templates for
example.
l The Test tool lets you verify that the individual entities used by one user (the
attributes, profiles, and templates for that user) have been set up with good data.
Validating the setup

You can validate the setup of an entire group to identify missing data and missing
relationships by going to the Group screen and click Validate.
The setup of the current group is checked as follows:

l Profiles: Unmapped profiles (profiles that do not have at least one profile-template).
l Templates:
l Unknown attributes: Attributes that are referenced in the template but do not
exist in the group.
l Unknown settings: These errors can also be detected by the Template
Validation feature.
l Desktop setting name that is not known to Stretto or is in the wrong
section.
l Mobile templates that do not follow the schema (for example, setting is
in wrong section).

l Desktop templates missing [DATA] or [SETTINGS] sections.

l Desktop templates that do not have a “success” line.
l Attributes:
l Unused attributes: Attributes that are not used in any template.
l Empty attributes: Attributes that do not have a value set for a given user at
either the group, template, or user level.
Testing the setup

You can test your setup to determine whether Stretto generates a valid provisioning
response (this is the response that is sent down to an end user in response to their login
request). For more on provisioning, see How Stretto entities work at runtime.
The Stretto Test tool lets you verify that:

l Stretto is set up correctly. Each profile maps to a provisioning template and the
template can be used to generate a valid provisioning response.
l A successful provisioning response contains the information that you expect it to
contain.
l A user can log in successfully from a given device, using the Stretto password that
you enter on the test dialog.
Follow these recommended steps to test your provisioning:
1. Create enough test users to test each platform (Bria desktop or Bria mobile), profile
and provisioning template at least once. Give each user a descriptive name such as
“test_desk_P_NA” or “test_iphone_P_Asia”.
2. Run the test on each test user. In the Users screen, select one user and click Test.

3. Select the device type to test.

4. Typically, you leave the default parameters.
5. Click Test.
Sample result: Provisioning request is generated with all data

In these examples, a profile and a template were successfully selected and a response
was generated. Scan through the response to make sure every setting has a value.


Sample result: Provisioning response is generated but data is

missing
In these examples, a provisioning response is generated but, as you see, it is missing the
username and password (the SIP username and password), meaning that this user has
empty attribute values. It is possible for a setting to be missing for a specific user, for
example, if the setting corresponds to a feature that is not offered to this user.

Sample result: Login fails

In these examples, the login attempt fails for the specified reason. Also note whether the
test results show that a profile and a template were both selected.
Limiting user and device counts

You can control the number of users that can log in, as well as the number of devices
(platforms) that each user can log in from. There are three controls: Max Users, Max
Devices, and Group Device Limit.
Note: Note that Max Users is a “setup time” limit – if you are setting up users and you hit the
limit, you are not able to create any more users. Max Devices and Group Device Limit are
“runtime” limits – these limits are hit when users are already set up and try to log in.
Your group is set up on the Stretto following either setup A (with Group Device Limit) or
setup B (with Max Users).

Setup A
Setup A consists of the following
l Max Users is empty (so, no limit).
l Max Devices is set to 2.
l Group Device Limit is set as per your instructions when you were set up by
CounterPath.
Example
With this setup, there is no limit on the number of users you can create. However, there is
a limit on the number of devices that can be logged on. This limit is controlled by the
Group Device Limit and the Max Devices.

In this example, a group limit of 1000 is set on the number of devices. Each user can log
on with up to 2 devices. This could work out to:
l 1000 users each logging on with 1 device each
l 300 users logging on with 2 devices each and 400 logging on with 1 device each
l 500 users logging on with 2 devices each.
What you can do

l You cannot set a Max Users limit in your group. You could theoretically set a limit in
any subgroups you create, but there is no advantage to doing so.
l You can change the initial value of std:maxDevices. But you must not delete this
attribute and you must not set the value to 0 or blank (because none of your users
would be able to log in at all). See Limiting the number of devices per user
(maxDevices and deviceAgeDays).
l You can ask CounterPath to change your Group Device Limit in your top-level
group.
If you have subgroups, you could allocate the limit from your top-level group among
those subgroups. See Limiting the number of devices per group (Group Device
Limit).
Setup B
Setup B consists of the following
l Max Users is set as per your instructions when you were set up by CounterPath.
l Max Devices is set to 2.
l Group Device Limit is not set up.
Example
With this setup, there is a limit to the number of users you can create and to the number of
devices that each user can use to log on.

In this example, the Max Users is 5000 and the Max Devices is 2. This could work out to:
l 5000 users logging in with 2 devices each
l 10,000 devices being used to log on
l 3000 users loging in with 2 devices each and 2000 users logging in with 1 device
each
8000 devices are used to log on.

What you can do

l You cannot change the Max Users limit in your group (but you can ask CounterPath
to change it for you). In addition, if your have subgroups, you could allocate the limit
from your top-level group among those subgroups. See Limiting the number of
users per group (Maximum users).
l You can change the initial value of std:maxDevices. But you must not delete this
attribute and you must not set the value to 0 or blank (because none of your users
would be able to log in at all). See Limiting the number of devices per user
(maxDevices and deviceAgeDays).
l You cannot set a Group Device Limit in your top-level group. You could theoretically
set a limit in any subgroups you create. However, you must be careful when
combining Max Users and Group Device Limit. You may run into the situation where
you cannot add users but you still have “unused” device allocation, or where you
have reached the limit on devices but have room left in your Max Users limit. See
Limiting the number of devices per group (Group Device Limit).
Limiting the number of users per group (Maximum users)

As described in Limiting user and device counts, a user limit is either set by CounterPath
for your top-level group or else is not applicable to your deployment.
l If the Max Users is set and if you have subgroups, you can set Max Users in
subgroups in order to allocate the Max Users among your subgroups (see Max
Users in parent and subgroups below) or you can leave the subgroups limits empty
(see Limiting the number of users per group (Maximum users) below).
l If the Max Users is set and if you do not have subgroups, there is no setup for you to
do. You can ask CounterPath to change the limit if needed.
Setting Max Users

Set the limit in the Max Users field on the Group screen.
Max Users in parent and subgroups

Each subgroup has its own Max Users. The Max Users in the parent (already set by
CounterPath) acts as a “grand maximum”: the combined Max Users of all the subgroups

plus the actual users created in the parent (if any) cannot exceed the Max Users of the
parent.
The parent might look like this:
l Number of users is calculated by the Stretto. The number of users you have
created in this parent group (so this number does not include subgroups).
l Maximum users for this group and all subgroups are set by CounterPath.
l Allocated to subgroups is calculated by the Stretto. The combined total of all
subgroups, where each subgroup contributes its Max Users (if the subgroup has a
Max Users) or its Number of users (if the subgroup does not have a Max Users).
A subgroup might look like this:

Rules:
l When you set a Max Users in a subgroup, part of the parent’s Max Users is
allocated and is no longer available for creating users in the parent group itself.
l A calculation that is not shown but that must be kept in mind is the “Total Users” in
the hierarchy:
Total users = parent Number of Users + parent Allocated to subgroups
In the above example, the Total Users for acphone.com is 2000 + 30 = 2030.
You will get a “Maximum users exceeded” error message if you try to increase the
Max Users in a subgroup such that the Total Users is greater than the Max Users in
the parent group. For example, in the above scenario, if you set Max Users in the
subgroup to 2071, you will get the error because the desired new Total Users would
be:
30 + 2071 = 2101
And 2101 > 2100 (the parent Max Users).
Max Users in parent, no Max Users in subgroups

The parent group (if it contains users) and all the subgroups share this maximum equally.
With this setup, it is possible for one group to grab more than its “fair share” of the
allocation. On the other hand, you do not waste entries by pre-allocating them to a
specific group.
The parent might look like this:

In this example, the number is made up of the Number of users in the-small-

business.com, which is the only subgroup.
l Number of users is calculated by the Stretto. The number of users you have
created in this parent group (so this number does not include subgroups).
l Allocated to subgroups is calculated by the Stretto. The combined total of all
subgroups, where each subgroup contributes its Max Users (if the subgroup has a
Max Users) or its Number of users (if the subgroup does not have a Max Users).
A subgroup might look like this:
An empty Maximum users means that there is no maximum in this group.

If you were to change this setup and add a Max Users to a subgroup, you would have to
make sure that adding this Max Users does not make the Allocated to subgroups (of the
parent) too high. The formula is:
Total users = parent Number of Users + parent Allocated to subgroups
In the above example, the parent has 88 users and a Max Users of 2100. The Max Users
you enter in the subgroup would have to be 2012 or less.
Limiting the number of devices per user (maxDevices and

deviceAgeDays)
Setting maximum devices
Max Devices is already set by CounterPath for your top-level group, via the
std:maxDevices attribute. The initial value is usually set to 2, meaning the user cannot log
in with the third device. You can change this value but you must not delete the attribute.
To set a max device per user
1. Assign a value at the group level. If desired, the value can also be overridden in
individual profiles or users.
2. Click the Device Limits tab to make sure a Device Limits section appears with a
Registered devices line.
The device limit is updated for the users.
Registered devices is automatically calculated by Stretto. Initially 0. As users log in, this
number increments to show the total number of unique devices that have logged in.

Tip:
To set no limit, enter a large number or enter 0 (meaning unlimited) which results in
allowing the user to log in from as many devices as they want.
To restrict users to 0 device, suspend the user.
Setting a maximum device age

You can set a device age (for example, 90 days) so that if the device list is full, the next
time the user logs on, old devices (devices that have not been used in the specified
number of days) are removed from the list and the login request succeeds.
Keep in mind that the device is only removed if the removal is required in order to register
another device.
In the group Attributes page, create an attribute called std:deviceAgeDays (case sensitive)
and assign a time period (in days). If desired, create individual overrides in the profile or
user.
Limiting the number of devices per group (Group Device Limit)

Device limits can be established on a per-group basis.
Subgroups inherit limits of their parent group (or groups higher up in the group hierarchy)
so that the sum of devices in all subgroups must be less than the limits established in the
parent group or groups. So for example, if group ABC has a limit of 100 devices the total
number of devices in its subgroups DEF and GHI never exceeds 100. Similarly, if groups
DEF or GHI have subgroups, the devices in those subgroups contribute to the total of
100.
Limit types
Devices limits can be applied to a group by choosing one of these limit types
Limit types
l None - This group has no limit to the number of devices except any limits that might
be inherited from parent groups.

l All - This limits the combined total number of devices in this group and its
subgroups, regardless of device type.
l Per type - This limits the combined total number of each device type in this group
and its subgroups. Device types include: desktop, phone, and tablet.
l Per user - This limits the combined total number of each device type that each user
can have in this group.

Rules for applying limits

When setting device limits, keep in mind these rules:
l The Group Device Limit is either set by CounterPath for your top-level group, or
else is not applicable to your deployment,
l If the Group Device Limit is set and if you have subgroups, you can set the
limit in subgroups in order to allocate the limit among your subgroups, if
desired.
l If the Group Device Limit is set and if you do not have subgroups, there is no
setup for you to do. You must ask CounterPath to change the limit, if desired.
l The limit type is inherited by subgroups. That is, if you set a limit in a parent group,
its subgroups must use that limit type also.
l If a group has no device limit (a limit of None), then subgroups can each have their
own limit type.
l When setting device limits on existing groups, you must set the subgroup limits
before setting the parent group limits.
l If you create a subgroup of a parent group that already has device limits, the
subgroup already has the same limit type as its parent but a limit of 0. You’ll need to
increase the subgroup’s limit if you want to allow devices in that group.
Setting the device limits

To set the group’s device limits
1. In the Groups page, select a group, click Device Limits, and click Edit. If the Limit
Type selection is gray, then you don’t have the administrative permissions to set

device limits in this group.
2. From the Limit Type box, choose which type of limit to apply to the group:
l None - Remove device limits for this group. Limits applied to parent groups
are still inherited.
l All - Enter the combined maximum number of devices allowed in this group
and its subgroups.
l Per type - Enter the combined maximum number of each device allowed in
this group and its subgroups.
l Per user - Enter the maximum number of each devices allowed per user. The
limit is inherited by any subgroups.
3. Click Save.
The new device limits appear in the group.

Group device limit scenario A: Allocating limits to subgroups
In this scenario, you want to set up device limits so that your group has a limit on the total
devices used, and you want to allocate limits to each of the subgroups. As with all
scenarios, you need to be administrator of the parent of the group you’re editing.
Setup
Group A - Limit type: All. Limit: 100.

l Subgroup A1 - Limit type: All. Limit: 40.

As a result, each subgroup has its own device limit, and the combined total devices in all
subgroups plus Group A can’t be more than 100.
Group device limit scenario B: Setting different limit types in subgroups
In this scenario, the parent group has no device limits, but you want to establish limits in
each subgroup. Furthermore, you want to limit devices by devices type in one group, but
not in the others.
Setup
Group A - Limit type: None.
l Subgroup A1 - Limit type: Per type. Desktops: 50. Phones: 25. Tablets:
25.
As a result, each subgroup is limited to 100 devices, but Subgroup A1 further specifies
the maximum number of each. The total combined number of devices in all of the
subgroups can’t be more than 300. If Group A has users, those users have no device
limit.
Group device limit scenario C: Inherited device limits
In this scenario, you have a three-level hierarchical group structure in which the top-level
group (the grandparent) has no device limits and no users.
Subgroups of that parent group have device limits applied. Each of their subgroups must
apply the same limit type — as well as the limits inherited from their parent.
Setup
Group A - Limit type: None.

l Subgroup A1a - Limit type: All. Limit: 100.
l Subgroup A1b - Limit type: All. Limit: 100.

l Subgroup A1c - Limit type: All. Limit: 100.

l Subgroup A2 - Limit type: Per device. Desktops: 100. Phones: 50.
Tablets: 25.
l Subgroup A2a - Limit type: Per device. Desktops: 40. Phones: 20.
Tablets: 15.
l Subgroup A2b - Limit type: Per device. Desktops: 40. Phones: 20.
Tablets: 5.
l Subgroup A2c - Limit type: Per device. Desktops: 20. Phones: 10.
Tablets: 5.
l Subgroup A3a - Limit type: All. Limit: 0.
l Subgroup A3b - Limit type: All. Limit: 0.
l Subgroup A3c - Limit type: All. Limit: 0.
As a result, subgroups of A1 may each allow 100 devices, but if the sum of the three
subgroups’ devices exceeds 200, no more devices can be registered — A1 has a limit of
200 devices.
Subgroups of A2 must have a device limit type of “Per device” as that’s inherited from A2.
Subgroups A2a, A2b, and A2c have per-device limits that do not exceed the limits
established by the parent for a combined total allocation of 200 devices in A2.
In the case of A3, although it has a device limit of 200, the limits have not been set in A3a,
A3b, and A3c. Users in A3 can register devices up to a total of 200, users in each of its
subgroups cannot register any devices.
Tracking device usage

Your group has a user or device limit set up by CounterPath.
You can track the device usage on Stretto by using:

l The Devices column in the Users page. This page shows the current count and the
maximum limit such as 1/4.

l Stretto reports. These reports provide the device counts per group.
l The Devices list in the Group page. This page lists all the active devices along with
the username.
Removing an unused device

When a user reached their device limit, the Stretto administrator can delete the unused
device for the user. This frees up space.
Tip: If Allow end users to view and delete their devices is selected in the End User Portal
Settings, a user can delete their own devices.
To remove an unused device
1. Under the group, select Users. The group's user list opens.
2. Select a user.
3. Click Edit on Details for User:.
4. Select the Devices tab.

5. Locate the any devices and click Delete. The device entry turns gray.
6. Click Save.
The device is removed. Stretto Platform also attempts to log the user out of the deleted
device if the SNS feature is configured for the group.

Stretto Platform Administration Guide Working with the Stretto Admin web interface
Working with the Stretto Admin web

interface
Stretto Admin is a web page that provides the tools necessary to manage the
administrative tasks of Stretto. Using any compatible web browser and an Internet
connection, you can open and log into Stretto Admin using administrator credentials.
Logging into Stretto Admin

To access Stretto Admin, go to https://strettoadmin.cloudprovisioning.com/stretto/.
Note: Some web browsers may offer to save your Administrator ID and password. It is more
secure not to save login credentials.
Getting access after being locked out

If you enter your password incorrectly more than five times, you get locked out. Ask your
parent administrator to unlock and reset your password. Optionally you can unlock
yourself via a lockout email sent by Stretto. To do so, your parent administrator must set
up email notifications and give you the privilege to change own password. Your email
address must also be configured in the Stretto administrator account.

Getting access with a forgotten password

The Stretto login screen now has a link for I forgot my password…. You can reset your
password via email without logging into Stretto. To do so, your parent administrator must
set up email notifications and give you the privilege to change own password. Your email
address must also be configured in the Stretto administrator account. If this link does not
work for you, ask your parent administrator to change your password.
Changing your password

You can change your own password so long as you know the current password. You
need your parent administrator to give you the privilege to change own password.
To change your password
1. Select the Change password tab.

2. Type your existing password into Old password.
3. Type your new password into New password and Reenter password.
4. Click Change password.
Your password is updated and you are logged out of Stretto Admin. Use your new
password to log back in.
Managing administrators
This section describes how to create, edit, suspend and delete an administrator using
Stretto Admin. Not all administrators have the ability to manage other administrators. See
Administrators for details.
Administrators can change some (but not all) settings on their own, such as setting up for
receiving reports by email, modifying admin options, their email address, and their
password; however, it depends on their admin type and admin options.
Creating an administrator
Create administrators in the Admins tab in Stretto Admin.

To create an administrator
1. Click the Admins tab to open the Administrator Logins screen. Only you and your
child administrators appear in this list.
2. Select an admin to be the parent admin and click New Admin.
The New Admin dialog opens
3. Complete the admin information. Some options shown may not be available to all
admin types.
New Admin settings

l Admin name - The login name.
l Password - A random password is suggested, but you can enter a different
one.

l E-mail address - This email is required to receive notifications and logs.

l Admin Type - Choose the type of admin.
l State - Usually choose Active. If you are creating an admin but want to
prevent from logging in at the moment, choose Suspend. You can later
unsuspend the admin.
l l Add/delete profiles - Admin can add, copy, and delete profiles.
l Add users - Admin can create users.
l Change own password - Admin can change the password they use to
log into Stretto Admin.
l Client Traces Notification - Admin is notified by email when a client
trace log is uploaded.
l Conferences - Admin has access to the Conferences screen for
managing the Collaboration feature.
l Delete users - Admin can delete users.
l Delete user devices - Admin can remove devices that have been used
to log into a client app (for example, to reduce the device count for a
user or group).
l Help Desk Assistant - Admin has access to Help Desk Assistant for
diagnosing client app issues.
l Messaging options - Admin has access to the Messaging Options
screen for managing messaging and chat.
l Multi-group admin - Admin can manage their group as well as its
subgroups in Stretto Admin. This option must be on in order to receive
all of the Stretto reports. When this is off, the administrator does not
receive reports that are captured group-wide.
l Portal settings - Admin has access to the Portal Settings screen for the
End User Portal.
l Upload & download users - Admin can upload and download user
records as CSV files.
l View Client Traces - Admin has access to the Client Traces tab to view
diagnostic logs (client traces) that were uploaded from client apps.

l View Reports - Admin has access to the Reports tab to view diagnostic
and statistical reports from Stretto usage data.
l Admin Options - This section allows you to fine-tune the admin privileges.
Most options do not appear when you are creating a Normal admin.
l Groups - Associate the administrator with one or more groups. Only groups
you are associated with appear in this list. The first group you select will be
considered the administrator’s default group and will be displayed in bold.
Default groups are important when you have set up email notifications only on
some groups but not all, or when using the Stretto API (rather than Stretto
Admin).
Tip: You can search for a group by typing the name of the group you're looking
for in the text box. Click one of the suggestions to locate the group in the tree.
Then select the group (or its parent group).
l E-mail Reports - Configure the frequency by which this administrator is

emailed reports and logs.
4. Click Save to close the New Admin dialog.
The new administrator appears under its parent.
Finding an administrator
If you are working with a long list of administrators, use the admin search filter. Use the
search filter to find an admin by their login name, email address, or group name.
Setting up email reports for the administrator

You can set up to receive some reports via email. This setup can be done by the
administrator’s parent as well as by the administrator themselves, depending the admin
type.
To set up report emails
1. In the Administrator Logins screen, select an administrator and click Edit to open
the Edit Admin dialog.
2. Enter an email address if none exists.

3. Enter the frequency with which you want to receive reports. For reports that have a
time period, the period will be set to match this frequency. For example, if you
choose Weekly, the report period will be for the last 7 days.
4. Select the reports that the administrator should receive and click Save.
Modifying administrator accounts

The administrator’s parent can make any changes to the administrator, including admin
options and the groups that the administrator is associated with.
To edit an administrator account
1. In the Administrator Logins screen, select the administrator and click Edit on the
toolbar.
2. Change the fields.
3. Click Save.
You have edited the administrator account.
Moving an administrator (Changing their parent admin)

By moving an administrator, you change their parent admin. If the administrator you are
moving has child admins, their child admins follow the move.
To move an administrator
1. In the Administrator Logins screen, select the administrator and click Move on the
toolbar.
2. Select a new parent for the administrator.
3. Click Move.
You have moved the administrator.
Resetting a password for an administrator

Normal administrators can reset a password for themselves as well as for their child
admins. Administrators of other types cannot reset their own password unless the
Change own password admin option is enabled for them.

To reset a password for an administrator
1. In the Administrator Logins screen, select the administrator and click Edit
Password on the toolbar.
2. Enter the old and the new password.
3. Click Change password.
You have reset the password for the administrator.
Unlocking an administrator
Stretto administrators will get locked if they enter their password incorrectly more than
five times. A parent or grandparent administrator must unlock that administrator.
To unlock an administrator
toolbar.
2. Uncheck the Locked out (GUI) field or the Locked out (API) field.
3. Click Save.
You have unlocked the administrator.
Tip: You may also want to change the administrator’s password.
Suspending an administrator
You can suspend an administrator to prevent from logging into the Stretto Admin web
interface. Suspending an admin does not suspend their child admins.
To suspend an administrator
toolbar.
2. In the State field, change from Active to Suspended.
3. Click Save.
You have suspended the administrator.

Deleting an administrator
By default, Stretto does not delete an admin who has child admins. You need to either
move the child admins to keep them in Stretto, or select a checkbox to delete their child
admins.
Deleting an administrator does not delete the group they are associated with.
To delete an administrator
1. In the Administrator Logins screen, select the administrator and click Delete on the
toolbar.
2. If you are sure to delete their child admins, click Also delete all child admins.
3. Click Delete.
You have deleted the administrator.
Working with groups

A Stretto group is the container for a set of attributes, templates, profiles, and users.
A group cannot share any attributes, templates, profiles, or users except through
inheritance, which permits child groups to use templates and attributes belonging to a
parent group in a hierarchical tree structure. Groups can also share an administrator, as
one administrator can handle several groups.
Stretto Admin provides the tools to manage groups and their subgroups. Each
administrator sees only the groups to which they have access.
Finding a group
If you are working with a long list of groups with many subgroups, or you do not
remember the group name for a particular user, you can search groups by group name or
username.

To find a group by group name
1. In the Group tree, click the Find Group or User... button . The search page
opens.
2. Start typing a group name. A list of matches appears.
3. Click a group name to go to that group.
To find a group by user name or user email address

You can find a group by a provisioning name, email address or XMPP username of a
Stretto user.
1. In the Group tree, click the Find Group or User... button . The search page
opens.
2. Select the search by username/email checkbox
3. Start typing one of the three items of the user. Stretto Admin searches all the groups
that you have access to, and shows a list of groups where this user belongs.
4. Click a group name to go to that group.

Creating a group
Read Creating groups.
Editing group information

You can edit the information for a specific group.
To edit group information
1. In the left pane tree, select the group you want to edit.
2. Select the Information tab.
3. Click Edit at the top of the page.
4. Make your changes to the group information and attributes.
5. Click Save.
The changes made display in the Information tab on Stretto Admin.
List of group information fields and descriptions
Field Description
Group Information
Created The date the group was created. Automatically completed by Stretto.
Number of The current number of users in this group and all its subgroups. Calculated by Stretto.
users
Maximum The maximum number of users allowed in this group and all its subgroups. Can be set. 0 means there is no maximum for
users the group.
If you are a Normal administrator you can only change this number on your subgroups, not on your top-level groups.
Allocated to The portion of the Number of users that is being used by the subgroups of this group. 0 means there are no subgroups or
subgroups there are subgroups but none of them have users yet.
State Choose Suspended to suspend the group; users in this group cannot log into your softphone service. You can still
work with anything in the group (users, attributes, and so on). A Suspended status also indicates the date and time on
which the group was suspended.
Choose Active to unsuspend all users (except for individual users who are suspended via the Users page).
You can also suspend or unsuspend a group from the menu tree.
Auto- We recommend that you check this box.

manage
username

Enabling Auto-manage Usernames for an existing group
Note: Turn on Auto-manage usernames only if your usernames are in the format
<name>@<domain>.
Typically, you turn on Auto-manage usernames when you create the group. However,
you can still turn it on after group creation.
To turn on Auto manage on an existing group
4. Select Auto-manage usernames.
5. Click Save. Username Update appears.
6. Select Skip or Update.

If the group does not have any users yet, click Skip or Update.
If the group does have users, click the desired option:
l Skip: No changes are made to the existing users. You can (and should) run
the update later by unchecking the Auto-manage field and then checking it
again, and then choosing Update on this dialog.
l Update: All usernames are modified as described below.
Impact on existing users

If you turn Auto-manage on and choose Update, the usernames are displayed into two
sections: <name> and <domain>.

In the database:
l The <domain> is added to any usernames that are missing the <domain>. So, for
example, “jsantos” would become “[email protected]”
l The correct domain is added to any usernames that have the wrong domain. So, for
example, “[email protected]” would be corrected to “[email protected]”
Impact on new users

From now on:
l When you create a new user using Stretto Admin, enter usernames as <name> only.
l When you enter users via the Stretto API, enter the username as <name>@<domain>.
The Auto-manage feature only manages the formatting of usernames that are
entered via Stretto Admin.
l If you chose Skip (above) then if you later edit one user, the username for this one
user is converted when you click Save (because Stretto sees that the Auto-
manage field is checked).
Turning off Auto-manage

If you clear Auto-manage usernames in the Group, the domain portion of existing
usernames is not modified in the database: users are stored as <user>@<domain>.
To turn off Auto-manage

4. Clear Auto-manage usernames.

5. Click Save.
Auto mange is turned off for the group. The display in the Edit User dialog changes. From
now on, you must enter usernames in the full format.
Changing or removing the domain name for one or more users

When Auto-manage is enabled, the Edit User dialog shows the user’s domain on a
separate, read-only line — for example, “@acphone.com”. If you need to change or remove
the domain name, turn off Auto-manage for the group as described under “Turning off
Auto-manage” and follow these steps.
To change or remove the domain name:
1. In the left pane tree, select the group and click Edit.
2. Clear Auto-manage and click Save.
3. In the users list, select one or more users and click Edit.
4. Select the User’s Domain checkbox, and enter a new domain in the format
@<domain_name> or leave it blank to remove the domain.
5. Click Save.
Moving a group
You can move any group except your own top-level groups.

To move a group
1. In the left pane tree, right-click on the group and choose Cut.
2. Move to the new location (the new parent for the group), right-click, and choose
Paste.
Renaming a group
You need to be very careful of renaming a group after it has been deployed — that is, after
users have been added and have started to log into Bria. In most cases, if you rename
such a group, existing users are not able to log in until they change their login name to
include the new group name.
For example, changing group acmephone.com to acmephoneCorporation.com requires all

users to log in as (for example) [email protected]. It also requires that you
rename each user in the group, from (for example) [email protected] to
[email protected].
If the auto-manage usernames option is enabled, you can automatically update all the
existing users with the new group name so that you do not need to manually update each
user as mentioned above.
To rename a group
1. In the left pane tree, right-click on the group.

2. Click Rename.
3. Type the new group name.
4. In Warning, select Rename.
If Auto-manage usernames is enabled, Username Update appears.
If Auto-manage usernames is not enabled, Warning appears.
5. Username Update
Select Skip or Update.
Skip: No changes are made to the existing users. The domain portion of the
usernames are different from the current group name you just changed to. You
must change the existing usernames manually; otherwise the end users are not
able to log into Bria.

Update: All existing usernames are updated with the new group name. With the
above example, this option changes [email protected] to
[email protected] in Stretto.
Warning
Click Rename. The domain portion of the usernames are different from the current
group name you just changed to. You must change the existing usernames
manually; otherwise the end users are not able to log into Bria.
The group is renamed.
Suspending a group
You can choose to supsend a group. Users are not able to log in to the softphone service
when the group is suspended but you can still work with anything in the group (users,
attributes, profiles, templates).
To suspend a group

2. Click Suspend group.
The group is suspended. In Group Information, the State changed to Suspended and the
Suspended Since date is added.
To unsuspend a group

2. Click Unsuspend group.

The group and all users except for individual users who are suspended via the Users
screen are unsuspended.
Deleting a group
You can delete any group except your own top-level group; only your parent admin can
delete the top-level group.
Before deleting a group, Stretto checks if:

l a group contains profiles, templates, users, or its subgroups, and
l an administrator is associated with this group as their default group.
By default, Stretto does not delete a group in the above cases. You need to enable
additional options in order to proceed.
To delete a group
1. In the left pane tree, right-click on the group you want to delete.
2. Click Delete. A confirmation dialog appears.
3. Select additional options if desired.
l Also delete profiles, templates, users, or subgroups
l Also delete all admins using these groups as their default group
This option does not delete the admins using with the group as their extra
groups (instead of default group).
4. Click Delete.
The group is deleted.
Creating groups
This section describes how to create groups in Stretto Admin.
Creating groups
This method creates an empty group under a parent group.

To create a group
1. In the left pane tree, select the group that will be the new group's parent.
2. Right-click and select New Group. The New Group dialog opens.
3. Complete the fields and click Save.
Field Description
Name We recommend group names in the format <companyname>.com. For example, acphone.com.
Maximum users You can set a maximum number of users for any group.
Auto manage username We recommend that you check this box.
Enabling username auto-management

Turn on Auto-manage only if your usernames are in the format <name>@<domain>.
If your Stretto is set up so that usernames are in the format <name>@<domain>, then you can
set up Stretto Admin to handle username entry in one of two ways:
l Auto-manage on: Recommended. You enter only the name portion, for example
“kperera”. The domain will automatically be appended both in the display and in the
database.
l Auto-manage off: You enter the entire name, for example, [email protected].
If auto-manage is on
In Stretto Admin, enter usernames in the format <name>. The domain will automatically be
appended and will appear in the Users dialog as a read-only field.
If you accidentally enter a username in the format <name>@<domain>, the format will be
corrected so that it is displayed in the correct way.
Users entered via the Stretto API are saved as entered. In other words, this Auto-manage
feature only manages the formatting of usernames that are entered via Stretto Admin.
If auto-manage is off
In Stretto Admin, enter usernames in the format that applies to your setup: either as
<username> or <name>@<domain>. The username will be saved and displayed as entered.

Creating groups by copying

When creating a group, you can save time by copying another group’s attributes, profiles,
and templates. The copy of the group contains no users or attribute pools.
Only a Normal Admin can copy groups in this way.
Pay attention to inheritance of attributes and/or templates. You might break the
inheritance depending on where you paste the new group in the group tree.
To create a group by copying
1. In the left pane tree, select the group that you want to copy, right-click, and choose
Copy.
2. Select the group that will be the new group’s parent, right-click, and choose Paste
group.
3. Enter a name for the new group and press ENTER.
Tip: You can also create a group by downloading an existing group and then uploading its
entities into the new group.
Downloading and uploading groups

You can download a group to a .zip file. You can upload a .zip file back to Stretto. These
two features are useful for:
l Backing up a group and all its entities. Use Download only.
l Backing up users. Use Download only.
l Copy (move) a group to another Stretto server.
l Copy a group in order to merge it with another group.
l Copy a basic “boilerplate” group that you have created to use as the base for “live”
groups. This usage is useful if you are deploying a hosted Stretto and want to
provide a base setup for each of your customers (groups).
l Copy users for import into another group.

Downloading a group
Follow these steps to download a group to a file.
To download a group
1. In the left pane tree, choose the group you want to download.
2. Choose Download from the Group menu. If Download is disabled, then your
organization has decided not to support downloading and uploading of groups.
The Download Group popup appears.
3. Complete the fields:
l Download options
Attributes (and their group-level values) are always copied. You can specify
which other entities to copy:
l Profiles and Templates: The profiles and any attribute values in the
profile level (profile-attributes). All the template mappings in the profile.
The templates and all their contents.

l Users: Users and any attribute values in the user level (user-attributes).
l Attribute Pools: Attribute pools, if any, and all the entries in the pools.
l XMPP Avatars: The image data encoded in the binary format.
l Conference Configuration: The conferences available to the group and
their settings.
Table of useful combinations of options
Entities to
Options to Select Description
Download
Attributes ☑ Attributes To copy attributes in order to paste them into another group.
☑ Group Attributes
☐ Attribute Pools
☐ Profiles
☐ Profile-attributes
☐ Profile-templates
☐ Templates
☐ Users
☐ User-attributes
Users ☑ Attributes To copy users for backup.

☑ Group Attributes To copy users for import into another group.
☐ Attribute Pools
☐ Profiles
☐ Profile-attributes
☐ Profile-templates
☐ Templates
☑ Users
☑ User-attributes
Profiles ☑ Attributes To copy a basic “boilerplate” group that you have created to use as the base
Templates ☑ Group Attributes for “live” groups.
☐ Attribute Pools This usage is useful if you are deploying a hosted Stretto and want to provide a
☑ Profiles base setup for each of your customers (groups).
☑ Profile attributes
Typically, you do not want to copy attribute pools because pool entries can
☑ Profile templates
only be assigned once; you may create problems for yourself if you reuse the
☑ Templates
attribute pool in the new group.
☐ Users
☐ User-attributes
Users ☑ Attributes To copy the group in order to merge it with another group.
Profiles ☑ Group Attributes Typically, you do not want to copy attribute pools because pool entries can
☐ Attribute Pools only be assigned once; you may create problems for yourself if you reuse the
Templates
☑ Profiles attribute pool in the new group.
☑ Profile-attributes
☑ Profile-templates
☑ Templates
☑ Users

Entities to
Options to Select Description
Download
☑ User-attributes
All ☑ Attributes To back up the group and all its entities.

☑ Group Attributes To copy (move) the group to another Stretto server.
☑ Attribute Pools
☑ Profiles
☑ Profile-attributes
☑ Profile-templates
☑ Templates
☑ Users
☑ User-attributes
l Decryption password
Required only if you are moving the downloaded data to a different Stretto
server and the entities you are downloading includes users – see Contents of
the downloaded .zip file. Get the password of the source Stretto from the
Stretto administrator and enter it in this field.
The options are:
Users Are Being Downloaded Moving to a Different Stretto Action
Yes Yes Obtain and enter the password
Yes No Skip this field
No Either Skip this field
l If you enter the password, then when the download is performed, the
encrypted data gets unencrypted. Later, when you upload the data to
the new Stretto, the data may or may not be re-encrypted: It is encrypted
if the target Stretto is set up to encrypt data (and is encrypted using the
target Stretto key).
l If you do not enter a password and the data actually is encrypted, the
data is copied to the new files in encrypted format. You can upload the
data to the same Stretto without problem. But you cannot upload the
data to a different Stretto.
l Zipfile password

If you enter a decryption password, you may want to enter a .zip file password
that will be applied to the .zip file containing the downloaded data, in order to
protect the data. If you open the .zip file, you will be prompted (by your .zip file
reader) to enter this password. Later, when you upload the .zip file to the
target, you must enter this password on Upload Group.
4. Click Download.
A zip file group_<group name>.zip is created in the regular location for downloads on your
computer.
Contents of the downloaded .zip file
The .zip file contains several different file types.
File When Created
group.xml Always created. The contents include:
l Group information (such as the suspended status).
l Attributes and their group values, if applicable.
l Group defaults (group-attribute values).
l Profile information.
l XMPP roster information, if applicable.
l XMPP chat room configurations, if applicable.
templates\<name of If templates and profiles were downloaded. One file is created for each template (including email and
template>.tem vCard templates) in the group. Profile information is included in the group.xml file.
If templates and profiles were not downloaded, these files are not created and furthermore, the group.xml
file contains no information about profiles.
user.csv Not included when the Attributes or Profiles Templates useful combinations are selected.
This does not include XMPP avatar photos.
vcards\<username>.vcard If XMPP avatars were downloaded. One file is created for each user.
Uploading users to a group

You can upload users to an existing group. Keep in mind that the target group is the
group that is selected as destination and the source group is the zip file.
Follow these steps to upload users to an existing group.

To upload users to a group
1. In the left pane tree, select your target group. You can:
l merge the downloaded file into the selected group
l or create a new subgroup under the selected group
2. Choose Upload from the Group menu. The Upload Group dialog appears:

3. Complete the fields and click Submit.
Field to complete
l Files to Upload: Choose the zipfile to upload.
l Zipfile Password: Enter this only if a password was specified when the file
was downloaded.
l Destination Options: Choose the first option in order to merge the file into the
group you selected. Choose the second option in order to create a subgroup
under the selected group.
l Update user domains with new group name. Typically, you want the
usernames to be updated. For example, if you are copying from zippy-
phone.com into acphone.com, you want to convert kperera@zippy-
phone.com to [email protected].
One scenario where you may not want this option is if your usernames are in
the format kperera (rather than [email protected]) because you
probably want to preserve the original format.
l Error handling:
l Rollback: For example, you are performing an upload that involves
uploading group information, then uploading profiles and templates, and
finally uploading users. If there is a problem with one of the profiles, then
the entire operation is canceled, including the group upload portion that
was already performed and had no problems.
l Skip: Only the current portion of the operation is canceled.
For example, you are performing an upload that involves uploading
group information, then uploading profiles and templates, and finally
uploading users. If there is a problem with one of the profiles, then just
that one profile is skipped and the activity continues. If there is a
problem with one user, just that one user is skipped and the activity
continues. Each entity that causes a problem is skipped.
See Resolving conflicts and Error handling for more information.
The data is copied to the target group.

Results
This table outlines the results of uploading various entities.
Entity Property Rule
Groups Created From the source.
Number of Total from source + total from target

users
Maximum The value is recalculated. If the new value exceeds the Max users for the target, an error occurs.
users
Allocated to The Allocated to subgroups count for the parent of this group is recalculated.
subgroups
State From the target.
Auto-manage The value from the target is used.

usernames During the upload, conversion of usernames from the source is handled as specified by the Update user
domains field on the Upload Group dialog.
After that, modifications to a user that came from the source are handled as they are for any user:
according to the value of the Auto-management field for the target group.
RBC PAYG Value from the target is used. (Typically, the value of the source and the target are the same anyway.)
mode
Attributes Attribute list Attributes from the source are added to the target.
Group- Group-attributes from the source are copied with their attributes, except with Download Option D. See
attributes below for resolving conflicts.
Attribute Pool and its Note that we do not recommend downloading attribute pools and then uploading them in order to merge
Pools entries two groups. Doing so creates a management problem with the pools.
The download attribute pools ability is provided only to let you back up a group or move a group to
another Stretto.
Profiles Profile list All profiles from the source are added to the target.
See below for resolving conflicts.
Templates Template list All templates from the source are added to the target.
Rosters XMPP roster All rosters from the source are added to the target.
list
Chat Rooms XMPP chat All chat rooms from the source are added to the target.
room list
Users User list All users from the source are added to the target.
Take from User from the source who has "Take from pool" checked: after copying to the target, the user retains
pool? their existing pool value (from the source Attribute Pool).
User from the source who has "Take from pool" unchecked and has a value: after copying to the target,
the user retains their existing "local" value.

Entity Property Rule
User from the source who has "Take from pool" unchecked but does not have a value: after copying to
the target, the user still does not have a value.
Referenced User U is being copied via Download Option D and the referenced profile does not exist in the target. An
profile error occurs.
Resolving conflicts
The following table shows show Stretto resolves conflicts between uploaded data and
existing data.
Entity Source Target Result
Attributes Attribute A exists Attribute A does not exist Attribute A is added to the target
Attribute A with Attribute A with different The property value of the target is used.
specific values for values for type, masked,
type, masked, visibility exist
visibility, lock exist
Group- Attribute A with a Attribute A with a different The value of the target is used
attributes specific default value default value
(groupattribute) (groupattribute) exists
exists
Attribute A with Group-attribute A does Group-attribute A is added to the target. This attribute now has a
default value (group- not exist group value that applies globally.
attribute) GA exists
Attribute A with no Attribute A with default The value of GA in the target applies to A
default value exists value GA exists
Profiles Profile-attribute PA Profile-attribute PA does PA is added to the target. For this profile, the attribute now has
exists not exist profile-level value.
Profile-attribute PA Profile-attribute PA exists Value of the target is used

exists
Profile-template Profile-template maps Target mapping is used.

maps profile P to profile P to template T2
template T1
Templates Template T1 exists Template T1 does not Template T1 is added to the target.
exist
Template T1 exists Template T1 exists Contents of target is used
Rosters Roster R1 exists Roster R1 does not exist Roster R1 is added to the target.
Roster R1 exists Roster R1 exists Contents of target is used
Users User kperera@zippy- User If "Update user domains" is on, this situation is an error: duplicate
phone.com exists [email protected] username. See below. If "Update user domains" is off, two users
exists now exist ([email protected] and

[email protected]).
User kperera@zippy- User kperera exists Two users now exist ([email protected] and
phone.com exists
kperera)
User kperera exists User If "Update user domains" is on, this situation is an error: duplicate
[email protected] username. See below. If "Update user domains" is off, two users
exists now exist exist (kperera and [email protected])
User kperera exists User kperera exists If "Update user domains" is on, two users now exist
([email protected] and kperera).
Error handling
In the event of an error, you have these options.
Error Handling
Max users exceeded: Merging the source and target Skip: As many users as possible are loaded, then uploading stops. Other
causes the maximum users for the target or the target's entities succeed (keep in mind that uploading of users is the last activity that
parent to be exceeded. is performed).
Rollback: The entire upload is canceled.
User U is being copied via Download Option D and the Skip: The problem users are skipped.
referenced profile does not exist in the target. Rollback: The entire upload is canceled.
To resolve the problem, determine what profiles are being referenced by the
users either:
l Copy those profiles into the target group.
l Create "dummy" profiles (with the expected names) in the target

group and try the upload again. Then modify the users to point to
valid profiles and then delete the dummy profiles.
Duplicate username Skip: The problem users are skipped but other users are uploaded.
Rollback: The entire upload is canceled.
Working with attributes

What is an attribute?
Stretto attributes are variables that contain information for a group and its profiles and
users. Each attribute name has a corresponding value. For example, a group's SIP
server domain could be stored in an attribute named account1.domain with the value
sip1.acphone.com.

In the provisioning of Bria clients, a provisioning template specifies what kind of data is
sent to the client by listing attribute names. At runtime, Stretto sends the values that
correspond to each of those attributes.
Attributes belong to a group. The profiles and users in a group are automatically
populated with the group’s attributes. The value of each attribute can be either inherited
from a parent group or defined at the group level, profile level, or user level.
l Group-attributes. When an attribute's value is assigned at the group level, it is
referred to as a "group-attribute". You set the values at the group level for attributes
values that are shared by every profile and user in the group and subgroup.
l Profile-attributes. When an attribute's value is assigned in a profile (overriding the
group-attribute), it is referred to as a "profile-attribute". You set the values at the
profile level where you want to create categories of user types with shared values.
For example, you may want to have region-based values.
l User-attributes. When an attribute's value is assigned for an individual user
(overriding the group-attribute or profile-attribute), it is referred to as a "user-
attribute". You set these values when there is a case for individuals to have settings
that differ from the rest of the users in their profile or group.
The attribute value that is defined closest to the user level takes precedence over those
attributes defined higher up.
Attributes are either inherited from a parent group or created locally within the group. The
Attributes tab in the Groups page of Stretto Admin shows attributes as follows:
l Having only a Group Attributes section indicates that the group has not inherited
any attributes from the parent group. All the existing attributes have values that are
defined locally in this group.
l If the group also has an Inherited Group Attributes section, it means that your
group inherits attributes from the parent group. See Overriding an inherited attribute
value in a subgroup to override an inherited attribute value.
You can create attributes on the group page and assign values to each attribute in:
l The group page
l The profile page - read this section
l The user page - read this section

See Assigning values to attributes.
Or instead of assigning a value at one of the above mentioned levels, you can create an
attribute pool and take a value from it. Read Understanding attribute pools for more
details.
Creating an attribute
You can create attributes either by manually entering the attribute properties or by
copying a list of attributes from another group.
To create an attribute manually
1. In the Group page, click Attributes. The Group Attributes list opens.
2. Click Edit.
3. At the top of the list of Group Attributes, enter the name of the new attribute in the
New Attribute box.
4. Click Save.
The attribute is added to the list of Group Attributes with default properties. You can now
edit the properties if necessary.

To create attributes by copying from another group

You can also create attributes in a group by copying existing attributes from another
group.
Use the Upload/Download Group feature and choose the option to download only
attributes (by deselecting all the download options). This feature copies all the attributes
from the source group. See Downloading and uploading groups.
Editing attribute properties

An attribute has properties such as Type, Masked, Value lock.
To edit attribute properties
1. In the Group page, click Attributes. The Attributes list opens.
2. Locate the attribute you want to change. You can search by attribute name using
the attribute filter at the top of the Attributes list.
3. Click Edit.
4. Make your changes to the attribute. See the following table for details on each
property.
5. Click Save.
List of attribute properties
Field Description
Star Click to make the attribute a Favorite. When you save the screen, the attribute will automatically move to the top of the
screen with other starred attributes, rather than being sorted in strict alphabetical order by attribute name.
On the Profile and Users screens, Favorites will appear at the top, but without the star symbol.
You can make as many attributes as you want into Favorites.
Lite admins can view Favorites on the Profile and Users screens as long as attributes are set to Visible.

Field Description
Attribute The attribute name. Names are case sensitive.
Type Boolean, Integer, String, or Pooled.
Masked If checked, the value is masked at the user level. See Masked, encrypted, and hidden data for more details.
Encrypted If checked, the value is encrypted at the user level. Only encrypt if the value is always set at the user level. If you encrypt,
do not lock the attribute. See Masked, encrypted, and hidden data for more details.
Visibility You can set the visibility to control the types of administrators who can view and work with the attribute.
l Visible: Everyone can see the attribute
l Hide from Lite: Lite administrators cannot see the attribute (either its name or its value) but Normal
administrators can. Lite administrators includes: Domain admin, Users&Profiles admin, Users admin, Support
admin, and Read-only admin.
See Administrator types for information on administrator types.
Default The value you want to assign at the group level. You can leave it blank if you want values to be assigned only at the profile
Value or user level. If desired, you can enter a group-level value by entering a value in the Default Value field. (See Assigning
values to attributes for general information on where to assign attribute values.)
If the attribute is Locked, the attribute is inherited by any subgroups regardless of whether the parent group has a value.
If the attribute is Open, it is only inherited by any subgroups only if it has a value in the group level.
Value Lock See Locking of attributes in a subgroup setup.
Renaming or deleting an attribute

To rename or delete an attribute
1. In the Group page, click Edit.

2. In the Group Attributes section, make your changes.
An empty field in an attribute line means that the attribute is locked. See Locking of
attributes in a subgroup setup.
3. Click Save.

Note: Renaming or deleting an attribute renames or deletes it in all profiles and users, but it
does not rename or delete it in the templates. Review the templates for lines that use the
renamed or deleted attribute and make changes as required.
Overriding an inherited attribute value in a subgroup
Note: Read this section if your group has both a Group Attributes section and an Inherited
Group Attributes section.
The attributes in the Inherited Attribute Values section were created in the parent (or
grandparent) group and inherited by the current group. These attributes apply to the
current group and are used if they are not overridden.
Related: Subgroup attributes inheritance and locking.
Overriding an inherited attribute value

You can override the values of Open or Locked attributes.
To set a value to an inherited attribute
1. In the Group page, select the Attributes tab.

2. Click Edit.
3. In the Inherited Attribute Values section, enter a value you want to assign to the
current group.
4. Click Save.
The overridden attribute no longer appears in the Inherited Attribute Values section. It
appears in the Group Attributes section.

You can now set a lock that is equal to or stronger than the lock in the parent. So if the
lock in the parent is:
l Open: set to Open or Locked
l Locked: you cannot change the lock
Modifying missing inherited attributes

There may be an attribute that you know has been created in the parent group, but you do
not see it in the Inherited Attributes section. This can occur if the attribute has no value in
the parent group.
To solve this problem, take one of these actions:
l Create an attribute of the same name in the subgroup and enter a value.
l Assign a group-level value in the parent to allow subgroups to inherit the attribute
and value.
Understanding attribute pools

You can set up a pool of values for any attribute. A value is taken from the pool and
assigned to a user the first time the user logs into Stretto. Attribute pools can be set up in
three ways depending on how values are assigned.
One use case of attribute pools is when your SIP provider requires an unique pair of
username and password per device. An attribute pool allows you to assign a pair of
username and password to each device the user logs in from. See Setting up attribute
pools for multiple SIP registrations for step-by-step instructions.
Pool types
There are three types of attribute pools for different uses.
Group-wide user values

Group-wide user: A pool that all users draw from. Each user takes only one value.
This option sets up a pool that all users take from and that is independent of the user’s
device.

When the user logs on, Stretto checks if the user has a value for this attribute. If not,
Stretto takes any unused value from the pool and assigns it to the user.
This type of pool is useful for values that can be assigned to a user independent of which
device they are logging in with.
Group-wide per device values

Group-wide device: A pool that all users draw from. Each user takes a value for each
device they log in from.
When the user logs in from a specific device, Stretto checks the pool to see if a value has
been assigned to that device for the associated attribute.
If there is no assigned value for this specific device, Stretto takes one of the unused
values from the group-wide per device pool and assigns it to the user for use with this
device.
This type of pool is useful when you want to assign different values for an attribute
depending on which device is used to log in, independent of which user is logging in.
User-specific per device values

User-specific device: An individual pool for each user. Each user takes a value (from
their own pool) for each device they log in from.
When the user logs in from a specific device, Stretto checks the pool to see if a value has
been assigned to that specific user device combination for the associated attribute.
If there is no assigned value for this specific user device, Stretto takes one of the unused
values from the user's pool and assigns it to the user's device.
One of the differences between group-wide per device and user-specific per device is
that the user-specific per device pool allows you to have an individual pool for each user.
When the user is deleted from the group, the pool entries associated with the deleted
user are also deleted from the pool, instead of going back to the pool for reuse, which can
be an option for group-wide per device type.
This type of pool is useful when you want to assign different values for an attribute
depending on which device a user is currently using. You want to associate a specific

group of values with one user, but within that user, you don’t care which device gets
which value.
Use this type if you have the requirement to provide different provisioning data for a
particular setting depending on the particular device that a user logs in from. For
example, if you need a user to be registered on your SIP proxy with a different SIP
address (SIP line) depending on the device being used. You may then have logic on your
SIP proxy for setting up the user differently depending on the SIP address currently being
used. You can use user-specific per device to set up the user to support this requirement,
without the user having to do anything. See an example.
More about pools and pool entries

l An attribute pool contains a list of pre-configured values that can be assigned to
users as needed. Each value in the list is an attribute pool entry.
l An attribute pool belongs to the group where it was created; the pool cannot be
inherited by subgroups. You must create the attribute pool locally in each applicable
group.
l Attribute pool entries can be assigned only at the user level; not at the profile level.
l Each entry can be assigned to one user at a time until the entry is freed. See
Unassigning an entry.
l Attribute pool entries are assigned in the order that they were created in Stretto.
This allows you to create pools of matching pool entries and have them assigned
together to the same user as long as you create the entries for both pools in the
same order.
Note: Make sure to choose the same pool type for both pools. Stretto Admin might not
display pool entries in the order they were created. Use a CSV file to create pool entries
if it is important for you to know the order in which the entries were created.
l Use of an entry from the pool is optional. So for each user, you can instruct Stretto
to either use one of the entries from the pool, or set a value that is not in the pool.
This gives the Stretto administrator a flexibility to control what value to be
provisioned in a specific case.
Setting up an attribute pool

To set up an attribute pool in a group, you need to:

1. Create an attribute pool.

2. Add entries to the attribute pool.
3. Enable the attribute pool for each user.
Step 1: Creating an attribute pool
This is the first step for setting up an attribute pool for your group.
Make sure that the attribute that will have the pool meets the following requirements:
l The attribute must be created locally in each group. You cannot create the attribute
in the top-level group and rely on inheritance.
l The attribute must have an Open lock. You cannot assign an attribute pool to a
locked attribute.
To create an attribute pool
1. In the left pane tree, right-click the group that has the attribute and choose New
attribute pool. If the group has no attributes, this menu item is unavailable.
The Add New Attribute Pool dialog opens.
2. Complete the fields and click Save.
l Add pool for attribute - Select the attribute you are creating a pool for.
l Recycle pool entries - Select the check box if you want entries to go back into
the pool after it gets unassigned.
More details
With Recycle pool entries selected, entries go back into the pool
l When the user the entry is assigned to is deleted.
l When the device the entry is assigned to is deleted.
l Pool Type - Select a type that fits your needs.
l Group-wide user: A pool that all users draw from. Each user takes only
one value.
l Group-wide device: A pool that all users draw from. Each user takes a
value for each device they log in from.

l User-specific device: An individual pool for each user. Each user takes
a value (from their own pool) for each device they log in from.
The pool is created in the group, using the attribute name. At this point, the pool has no
entries. You need to populate the pool with values.
Step 2: Populating an attribute pool with values
You can populate an attribute pool with values either by entering the values in the
Attribute Pool page or by uploading a text file.
To enter pool values
1. In the Attribute Pool page, click New.

2. Enter the value or values and click Save.
The values are populated for the attribute pool.

To upload attribute pool values using a text file
1. Prepare a text file.

For group-wide user type and group-wide per-device type, the file should contain
one value per line.
Example:
Group-wide user type or group-wide per-device type
DK3759D73940
DJDYUEIRE830
T835648450507
For user-specific device type, enter multiple values for the same user by entering
multiple lines with the repeated username, a comma, and a unique value.
Example:
User-specific device type
[email protected],1000-1
2. In the Attribute Pool page, click Upload.
3. Browse for the file containing the data and click Submit.

The values are added to the pool.

Step 3: Enabling the attribute pool for each user
You created an attribute pool for an attribute, and added entries to the pool. Now enable
the pool for each user. This is needed especially if users already exist before the attribute
pool is created.
To enable the attribute pool for a user
2. Select a user.
3. On the right pane, scroll down to locate the attribute with the pool.
4. Click Edit, and select the check box for Take from pool?.
5. Click Save.
An attribute pool has been enabled for the user. A value from the pool is assigned to the
user the first time they log in.
Deleting an attribute pool

When you delete a pool that is associated with an attribute, the attribute itself is not
deleted. The attribute is converted to a regular string attribute.
To delete an attribute pool
1. In the group list, right-click the pool and choose Delete.

2. Click Delete on Confirm Delete.
The attribute pool and all of its entries are deleted.
Viewing the assigned pool entries

A pool entry is assigned to a user the first time they successfully log into Stretto. Stretto
marks the entry as assigned by populating the Assigned to, Assigned at, and if

applicable, the Device UUID information on the Attribute Pool screen.
To see which values have been assigned
1. In the Group tree, select the group which includes an attribute pool.
2. Select the attribute pool in the tree. The Attribute Pool screen shows pool entries
along with Assigned to, Assigned at, and, if applicable, Device UUID.
3. You can use the Show filter to narrow down the list of entries. You can filter the list
by:
l assigned or unassigned, or
l provisioning username, or
l Value of a pool entry, or
l Device ID if applicable
Unassigning an attribute pool value

A value gets unassigned from the user in one of these ways:
l You manually unassign the value from the user.
l If Recycle pool entries is enabled in the attribute pool, and either the user or the
device to which the entry is assigned is deleted.
When a value gets unassigned, the value is returned to the pool and could get re-
assigned to any other user, when needed.
Manual unassigning
The assigned entry could become unused if you delete a user who uses the entry or edit
the user so that it no longer uses the entry. If Recycle entries is disabled for the pool and
an entry becomes unused, the assigned status does not get changed automatically.

Remember to manually change the assignment on the Attribute Pool screen. Once the
assignment has been cleared, the entry becomes available for Stretto to automatically
assign to a different user.
To manually unassign an entry
1. Under the group, select the attribute pool.

2. Select the pool entry or entries that you want to unassign. You can use the Show:
filters to view fewer entries.
3. Click Clear Assignment.
The entries are unassigned and can be assigned to new users.
Setting up attribute pools for multiple SIP registrations

Your SIP provider might have a limitation where only one device is allowed per SIP
username. In this case, you can set up attribute pools in Stretto so that your end users
can use Bria on multiple devices.
You will need to decide how many devices to allow per user, then make sure you have
enough pairs of SIP username-password for all users. Stretto will take care of
provisioning both values of a pair to the same user at the same time.
The following step-by-step instruction assumes that you have decided to allow three
devices per user, and you have two users in Stretto. You have a list of SIP username /
password, at least six entries.
1. Use a text editor to create two lists; one for SIP username pool, the other for
password. Populate three values in each pool for each user; add more values if you
support more than three devices per user.
Entries for SIP username:
[email protected],AAA
[email protected],BBB
[email protected],CCC
[email protected],DDD
[email protected],EEE
[email protected],FFF
Entries for SIP password:

[email protected],passwordForAAA
[email protected],passwordForBBB
[email protected],passwordForCCC
[email protected],passwordForDDD
[email protected],passwordForEEE
[email protected],passwordForFFF
Tip: Pay attention to the order you list a value. Stretto Platform provisions a value in the
order a value was added. In the above example, when the user ewilding logs in for the
first time, SIP username AAA and SIP password passwordForAAA will be provisioned
because they are the first one listed for the user.
2. In Stretto Admin, go to your group, and make sure all the users have been created.
3. Create two attribute pools – one for SIP username and one for SIP password.
Choose user-specific per device type for both pools.
Step-by-step: creating an attribute pool

A. In the left pane tree, right-click the group and choose New attribute pool.
B. In a dialog, set as follows:
l Add pool for attribute: choose accountN.credentials.username.

N refers to a number from 1 to 5. If this is your first time configuring an

account, look for account1. Stretto supports multiple accounts to
configure in Bria.
l Pool Type: Choose user-specific per device.
C. Repeat the same steps to create another pool for
accountN.credentials.password. When it's done, you see two pools created.
4. Now the pools are created, add entries to each pool by uploading a text file you
created at Step 1.
Step-by-step: adding entries to an attribute pool

A. In the tree, select an attribute pool for username.
B. Click Upload and choose the file you created at Step 1.
C. Click Submit. Values are added to the attribute pool.

D. Repeat the same steps for SIP password. Make sure to upload the password
file.
5. For each user, enable the Take from pool? checkbox for both attributes.

Step-by-step: enabling attribute pools for each user

A. In the tree, click the Users screen, and select a user.
B. In the right pane, scroll down and look for the username attribute by typing
username.
C. Click Edit. The Take from pool? checkbox becomes editable.
D. Click Save.
E. Repeat the same steps for SIP password. Enter password and check Take
from pool? The first user has been configured to use attribute pools.
F. Repeat the same steps for the second user.
The first time the user logs into the Bria softphone, Stretto assigns the first entry from the
pools to the user; AAA and passwordForAAA in this example.
Working with provisioning templates

A Stretto provisioning template is a file that defines the format and content of the
provisioning response body — that is, the settings that will be provisioned to client

applications. In the template, the values for settings may be represented by Stretto
attributes. There are currently two provisioning file formats used by CounterPath clients:
l Bria desktop uses a format that is similar to a Microsoft Windows .ini file
l Bria mobile uses XML format
Each group contains one or more templates. Typically, you need at least one template for
Bria desktop and at least one template for Bria mobile. If a group has inherited templates,
the group may not have any local template, and it just refers to the inherited templates.
Stretto also uses templates for purposes other than provisioning, such as notification
emails, vCards, and User Portal pages. See Stretto template formats.
Mobile template auto-format

If your template is for provisioning mobile clients, the template format is XML. You can opt
to auto-format mobile XML templates each time you save to ensure correct XML.
Choose Preferences > Auto-format mobile XML templates when saving.
Creating a provisioning template

You can add a blank template to the group list.
To create a blank provisioning template
1. Right-click the group in which you want to create a templates and choose New
Template. Choose the template type: desktop, mobile, or blank.
2. Enter a name for the template.
The template is added to the list under the group.

The new template appears in the group.
You can copy an existing template to the group list.
To copy a template
1. Right-click the source template and choose Copy.

2. Select the group where you want the new template, right-click, and choose Paste
template.
3. Modify the name and press Enter.
The copied template appears in the group.
You can save an existing template under a new name.
To copy a template using Save As
1. Click a template and click Save As.

2. Enter a new name.
The copied template appears in the group.
Editing a provisioning template

You can make changes to an existing template.

To edit an existing provisioning template
1. Select a template to display it in the Template page.

2. Click Design to show lists of template content rather than a text view. The Design
view shows the different sections that are standard for the template type.
3. Click Edit. The Template page can now be edited.
4. For each setting, enter the setting name, data type, and value.
l Name - must be a valid setting name for the section
l Data type - To map to a Stretto attribute, select Attribute; otherwise, choose
boolean or string.
l Value - For attribute data, select the specific attribute name; otherwise, enter
the value.
5. Save your work often.
The edited template is in the group..
Editing a mobile provisioning template as XML

Click Source while editing a template to see the template as XML. You can edit the XML
directly in this screen.
If you choose the option to auto-format the XML, each time you save Stretto edits the
template to ensure it's formatted correctly, and may even add necessary lines.
If you edit the XML source, be sure to click Validate to ensure that:
l your XML has valid syntax and formatting
l the attributes exist
Example:
Valid XML
(dots indicate where data has been omitted for brevity):



<login_response>
<data name="refreshURL" value="https://imap.mobilevoiplive.com/login"/>
<data name="licenseKey" value="180YMYRX31R8ADNG9MP3N0210"/>
</login_response>

<branding>
<settings_data>
<core_data_list>
<data name="useCellularData" value="true"/>
<data name="allowCellVoip" value="true"/>
<data name="enablePRACK" value="true"/>
.
.
.
<codec_list>
<codec_list_audio_wifi>
<codec enabled="true" name="OPUS/48000"/>
<codec enabled="true" name="SILK/16000"/>
.
.
.
</codec_list_audio_wifi>
.
.
.
</codec_list>
<account_list>
<account>
<data name="accountName" value="{{account1Sip.accountName}}"/>
<data name="authName" value="{{account1Sip.credentials.authorizationName}}"/>
<data name="display" value="{{account1Sip.credentials.displayName}}"/>
<data name="domain" value="{{account1Sip.domain}}"/>

<data name="password" value="{{account1Sip.credentials.password}}"/>

<data name="incomingCalls" value="true"/>
<data name="outboundProxy" value="{{account1Sip.proxy}}"/>
<data name="vmNumber" value="{{account1Sip.voicemailNumber}}"/>
<data name="username" value="{{account1Sip.credentials.username}}"/>
.
.
.
<rule_list/>
</account>
<account protocol="xmpp">
<data name="accountName" value="{{account2Xmpp.accountName}}"/>
<data name="display" value="{{account2Xmpp.credentials.displayName}}"/>
<data name="domain" value="{{account2Xmpp.domain}}:{{account2Xmpp.port}}"/>
<data name="password" value="{{account2Xmpp.credentials.password}}"/>
<data name="username" value="{{xmpp:username}}"/>
.
.
.
<rule_list/>
</account>
</account_list>
</core_data_list>
<app_data_list>
<data name="enableLogging" value="1"/>
</app_data_list>
</settings_data>

</branding>
</cpc_mobile>

Uploading a template from a file

If you have a template file on your local or network drive, you can upload it to Stretto as a
template.
Warning: An upload completely replaces all content in the template that you are editing.
There is no undo.
To upload a template
1. Create a new, blank template and click Edit.

2. Click Upload, browse for the template file, and click Submit.
The uploaded content is immediately updated.
3. Edit, validate, and save as described under Editing a mobile provisioning template
as XML.
The uploaded template appears in the group.
Reverting a template to a previous version

Stretto keeps a history of template revisions that are date/time stamped. You can replace
the current version with an older version by restoring it from template history.
To revert a template to a previous version
1. Expand the template's history by clicking the plus sign (+) next to the template
name. If the template has no historical versions, there is no plus sign.
2. Click the date/time that corresponds to the version you want to restore. The
template appears in the Template History page.
3. Click Restore to replace the current version of the template with the version shown
or click Download to save the template to a file that can be uploaded to another
template.

This example shows a desktop template.
The reverted template displays in the group.
Sharing a group's template with subgroups via inheritance

If a group has subgroups, you can let the subgroups use the template by setting it to be
inherited. Profiles in the subgroups can map to the inherited template.
Rules for template inheritance:

l An inherited template must have a name that's unique in the group and its parent
and subgroups.
l The attributes referenced in the template must appear in the subgroups.
l Admins of a subgroup can't view the inherited template's content if they don't have
permission to view the parent group.
l Admins of a subgroup can assign values to a template's attributes if you import the
attributes of the parent group to the subgroup.
To set a template to be inherited by subgroups:
1. Select a template and click Edit.

2. Select the Usable in subgroups setting.
3. If one or more subgroups has a template with the same name, Stretto asks you to
confirm the deletion of those templates. Delete the templates if you want all profiles
that were previously mapped to the subgroup template to refer to the inherited

template.
Note: If you are not sure if the subgroup's template should be deleted, click Cancel and
correct any template name conflicts before trying again.
The template is available to subgroups.
Removing template inheritance

Stretto does not allow you to stop template inheritance if a subgroup uses the template.
Before you turn off template inheritance, make sure that no subgroups use the template —
assign different templates to the subgroups and try removing inheritance again.
Working with profiles

Each profile in a group contains a different set of possible attribute values. Each user is
assigned to a profile — an association that determines which set of attribute values are
provisioned to the user.
For example, in Profile_A, the attribute g711_enabled has a value of true. In Profile_B,
g711_enabled has a value of false. Assigning a user to Profile_A or Profile_B then controls
whether g711_enabled is true or false.
A profile can contain an attribute without a value if that value is to be set at the user level.
Each profile must be associated with at least one provisioning template.
Even if you do not need to separate your users into different profiles, you must create at
least one Stretto profile. Each profile needs to identify the platforms with which the profile
can be used. Typically, profiles apply to both desktop and mobile platforms, but it is
possible to allow only one platform.
Creating a profile from scratch

When creating a profile from scratch, complete the Template Mappings section as well;
otherwise users with this profile cannot log in from any device.

To create a profile from scratch
1. Right-click the group where you want to create the profile and choose New Profile.
2. Enter a name for the profile and press Enter. The new profile is added to the list and
is populated with attributes that exist in the group.
3. Select the new profile you just created and click Edit.
4. Complete the Template Mappings section. See the next section.
5. Assign a value at the profile level as necessary.
6. Click Save.
Mapping device templates to the profile (Template mappings)

Template mappings allows Stretto to find the right device template for the user's device
when they log in. For example, adding a mapping of Desktop platform and Template A
instructs Stretto to use Template A for users using Desktop devices.
Make sure that the profile has Template Mappings for all device types being used in the
group. Otherwise, users who use this profile will not be able to log in with unmapped
device types. Typically, profiles have mappings for Desktop, Android, and iOS devices.
XMPP-enabled groups may also have a vCard mapping.
Tip:
Stretto looks for a device template in the order the mappings are listed in the profile.
The order of mappings does not matter unless you use the All discriminator or the
Custom discriminator.
When to use All or Custom discriminator

l All indicates "everything not yet matched by preceding rules". One use case of
the All discriminator is when you support desktop and mobile devices and you
want to use a single template mapping for both iOS and Android. In this case,
instead of adding two mappings (one for iOS, the other for Android), you can
add one mapping using All. Make sure you place the Desktop mapping before
All; otherwise Stretto ends up using the mobile template for desktop devices.

l If you need to map different templates within a platform, such as Template A for
older clients and Template B for newer clients, you can specify the client
version by using the Custom discriminator.
To map a device template to the profile
1. Select a profile and click Edit.

2. Under Template Mappings, click Add and choose the platform you want to support
such as Desktop or vCard.
3. Select a template to use for the platform.
4. Repeat the mapping until you have mapped all devices to the correct templates.
5. Adjust the order of mappings by clicking the up or down arrow. If All is used, it
should be listed at the bottom to cover "everything not yet matched by preceding
rules".
6. Click Save.
Assigning attribute values at the profile level

The value of the attributes is either inherited from the group, or entered at the profile level,
or at the user level for specific users. The attribute value that is defined closest to the user
level takes precedence over those attributes defined higher up.
Generally, values are assigned at the profile level only when the value is different in one
profile compared to another. If the value is the same in all profiles, you would typically
assign the value at the group level.
If you decide you do want to assign a value in the profile, keep in mind the following: Do
not assign a value in the profile if the attribute does not apply to a given profile. For
example, attributeA is for Bria mobile and for users of “gold service”. ProfileX is for users
of your “silver service”. AttributeA will appear in the profile (because the attribute is part of

the group) but so long as you do not use the attribute in the template that applies to Bria
mobile, you do not have to assign a value to attributeA in profileX.
The ability to set or change a value at the profile level depends on the attribute lock (if
any) and inheritance from a parent group (if any). There are visual cues on the screen
that indicate whether a value can be set or changed.
Icons on Profile screen
Text
Field Style Icon Meaning Value Can Be Changed in Profile?
Color
Outlined field Black Open and local Yes, just type in the field.
Attribute is open and the displayed
value was set (at some point) in this
profile.
Outlined field Empty (none) Open and empty Yes, just type in the field.
No value was set in the group. You
should enter a value here or in each
individual user.
Outlined field Gray (none) Open and local Yes, just type in the field.
The displayed value was obtained
from the group level (group-attribute)
of the current group.
No outline Black Open and inherited Yes, but first set a value for the attribute in the
Attribute is open and the displayed Inherited Attributes section of the current group,
value was inherited from the parent rather than having the value inherited from the
group (it was not obtained from the parent group.
current group)
No outline Black Locked and inherited No, because the attribute is locked.
Attribute is locked and the displayed
value was inherited from the group
level (group-attribute) in the parent
group.
No outline Black Locked and local No, because the attribute is locked.
Attribute is locked and the displayed
value was obtained from the group
level (group-attribute) of the current
group.
No outline Empty (none) Locked and empty No, because the attribute is locked.
Attribute is locked but you forgot to
enter a value at the group level.
An attribute that you The attribute is open but it was No. If you want to set a value at the profile level,
know exists does not created in the parent group and no the attribute must first have a value set in the
appear in the Profile value was set. parent group.
screen

Copying profiles and profile attributes

You can create a profile by copying a profile and its attributes and the values of those
attributes from an existing profile. You can copy the profile to the same or a different
group.
Note: To set your preferences for how Stretto Admin handles profiles, see Setting
preferences.
Results of copying a profile:

l Attributes, profile-attributes, and templates are copied according to the preference
you set.
l If an attribute is both inherited (from the group-attribute of the target group) and
copied (from the profile-attribute of the source profile), then the inherited group-
attribute takes precedence: the profile-attribute is not copied. For example, if
sipDomain is set in the group as acphone.com and sipDomain is set in the profile of the
source as mydomain.com, then the attribute will be set to acphone.com in the new
profile.
To copy a profile
1. Right-click the source profile and choose Copy.

2. Select the group where you want the new profile, right-click, and choose Paste
profile.
3. Modify the name and press Enter. The source profile and all its existing content is
copied to the new location.
Deleting a profile
To delete a profile, right-click it and choose Delete.
Assigning templates to specific clients (custom discriminator)

Usually you only need to pick a platform when mapping a template to a profile.
Occasionally you might need to send different templates to a certain version of the
clients. An example is when upgrading Bria clients to a newer version: you need
Template A for the older clients and Template B for the newer clients.
You can configure Stretto to provision different templates within a given platform by using
a Custom Discriminator.
A Custom Discriminator can include a specific build number, or a range of build numbers
of the clients. Stretto goes through the profile-template mappings in top-down order.
When Stretto finds a match, it sends a provisioning response based on the associated
template. This means that any custom discriminator must appear before the generic ones
in the Template Mappings list.

To set up in Stretto Admin
1. Select a profile and click Edit.

2. Click Add and set the new template mapping to Custom.
3. Enter a discriminator to identify a client version. You can use regular expressions to
specify a range.
4. Select a template to use for the version.
5. Move the custom discriminator to the top by clicking an up arrow.
6. Click Save.
Format of the discriminator

Enter your discriminator in the following format:
[mob.*Android.*|mob.*iphone.*|desk.*]<build_number_expression.*>
Where
l mob|desk must be either mob (mobile) or desk (desktop)
l Android|iP must be either Android or iP (iPhone) if you specify "mob" or nothing if you
specify "desk"
l build_number_expression is an optional regular expression to filter by build number

The discriminator must start with one of these:

l mob.*Android.*
l mob.*iPhone.*
l desk.*
You can optionally add a regular expression to specify a build number terminated with
".*".
Examples:
l mob.*iP.*69231.* - Matches the client with the build number 69231.
l mob.*Android.*7778[0-9].* - Matches the build numbers from 77780 to 77789.
l desk.*77[3-9][0-9][0-9].* - Matches anything that starts with 773xx through 779xx.
Working with users

Each Bria user who logs in to the Bria client must be set up as a Stretto user. The user
automatically contains the attributes of the group. The user must be associated with one
profile.
Creating a user
There are several ways that you can create users:
l Individually using Stretto Admin
l Uploading a .csv file to Stretto Admin
l Auto-creating users with LDAP, see Auto-creation of users in Stretto
To create a user in Stretto Admin
2. Complete the Settings fields. Provisioning Username is required. All other values
are optional.

Fields
l Provisioning Username: this is the username that end user will use to login to
the Bria clients. If the group is auto-managed, enter the name portion only. If
the group is not auto-managed, enter both the name and domain.
l Provisioning Password: Enter the user's password for logging into the Bria
clients. Leave this field blank only if you are using a third-party to authenticate
users (LDAP, ECS).
l Profile: The user must belong to a profile. Select a profile.
l State: Select an active or suspended state.
l Report Tag: Enter a keyword tag that is unique or the same as multiple users,
so you can view reports on particular users rather than everyone in the group.
l Set up XMPP options.
3. Enter values for user-attributes. If an attribute has an attribute pool associated with
it, you can let Stretto automatically assign an entry or you can deselect Take from
pool and enter a value that applies to this user only.
4. Click Save.
The new user is added to Stretto.
To create users by uploading a .csv file:
1. Prepare a .csv file that contains user records in the correct format.
You can download users from Stretto Admin, and edit the downloaded .csv file. Or
create a csv file from scratch.
Tip: A text editor is recommended for opening and editing a .csv file. If you use
Microsoft® Excel®, use the Text Import Wizard instead of double-clicking to
open the .csv file. If you double-click to open the file, Excel removes leading
zeros from numbers, e.g., the VoIP number 003 appears as 3.
To open the downloaded csv file using Text Import

1. Open Excel.
2. Go to Data > From Text, then select the downloaded csv file.

3. Choose Delimited, and click Next.

4. Unselect Tab and select Comma, and click Next.
5. Find a column that contains numbers. Select the column in the data
preview, and choose Text. Repeat this step for all the columns that
contain numbers.
6. Click Finish.
7. When you are done editing, save the file as CSV, not xlsx.
Formatting your .csv file

The file must be a comma-separated values (.csv) text file that contains a heading
row with the field names and one user record per row. All field values must be
separated by commas.
Heading row:
l The first three fields must be username, password, and profile, in any order.
l Username, password, and profile field names are not case-sensitive.
l Other field names are case-sensitive: for example, sipusername is not the
same as sipUsername.
l Omit attributes that have values assigned at the profile level and attributes to
which you will assign values to later.
l Omit the LicenseKey if Stretto automatically assigns this data from a pool.
l Field names can be in quotes or not.
User record:
l Comma-separated values corresponding to the fields defined in the heading
row.
l One complete user record per row.
l Values that contain a comma must be enclosed in double quotes. For good
measure, enclose all values in double quotes.
l Attribute values are case-sensitive. For example, the profile name abcProfile
is not the same as AbcProfile.

l Username must have a value. All other values can be empty but the fields
must still be present in the file.
l Leave password blank if you are using a third-party to authenticate users
(LDAP, ECS).
l Email addresses must be unique — no two users can have the same email
address. As well, a user's email address cannot be the same as any other
user's full provisioning username (username@domain).
Example:
"username","password","profile","email","sipPassword","sipUserName"
"cgale","123$123","P_NA","[email protected]","134ud98e!","6045558900"
"tkay","abc123","P_NA","[email protected]","abcabcabc!1","2045551234"
Note: If you uploaded a .csv file that includes fields that do not match an attribute that
already exists, Stretto creates a new attribute to match.
3. Click Upload. The Upload Users dialog opens and prompts you to select a file.
4. Choose the .csv file that contains user records in the correct format.
5. Choose the upload options:

l Error Handling: Choose what happens when Stretto encounters an error
while processing your file.
l Auto-manage Usernames
Checked: If the domain portion is missing from the username in the file,
Stretto automatically adds it. If the domain is incorrect for the group, Stretto
corrects it.
Unchecked: The users are loaded into the group as-is. If the domain portion is
missing, the username may be invalid. See Enabling username auto-
management.
l Update Existing User Records

Checked: If a username in your file matches an existing user, attribute values

are replaced with the values in your file.
Unchecked: If a username in your file matches an exiting user, attribute
values are not replaced with values from your file. If an attribute does not have
a value, it is updated with the value from your file.
l Attribute Handling: These options describe what Bria does if an attribute is
defined in the file but does not yet exist in the group:
l Fail if attribute not found in group: An error message appears when
you click Submit.
l Create missing attributes in group: The attribute is automatically be
created in the group during the upload. It is created as not pooled, not
masked, and with a “string” format. You can change the attribute (for
example, set it up as masked) by changing the attributes in the group.
l Ignore attributes not found in group: The attribute is skipped; it is not
be created in the group.
l Use attribute pools - Controls the use of attribute pools for the user. If a
record in your CSV file contains a value for the pooled attributes, the
value in your file is used instead of attribute pools whether or not this
option is selected.
Checked: Sets the uploaded user to use the attribute pools. Make sure
that your CSV file contains no value (blank) for the pooled attributes.
The uploaded user is created with (Unassigned), then will be assigned a
value from the pool the first time they log in.
Unchecked: Attribute pools are not used for the uploaded user. Your
CSV file must contain a value for pooled attributes; otherwise the
uploaded user might experience a login error due to lack of provisioned
value.
l Synchronize XMPP accounts - Appears when XMPP is enabled in the group.
Enabling this updates the XMPP accounts with the values in your CSV file.

6. Click Submit.
The users are uploaded to Stretto.
Assigning attribute values at the user level

The value of the attributes is either inherited from the group or profile, or entered at the
user level for specific users. The attribute value that is defined closest to the user level
takes precedence over those attributes defined higher up.
Generally, values are assigned at the user level only when:

l The value is always different for each user (for example, the SIP user name).
l Or when a specific user must have a different value (from the profile or group) for a
special reason.
The ability to set or change a value at the user level depends on the attribute lock (if any)
and inheritance from a parent group (if any). There are visual cues on the screen that
indicate whether a value can be set or changed.

Visual cues for attributes
Text
Style Icon Meaning Value Can Be Changed in User screen?
Color
Outlined Black Open and local - Attribute is open and the Yes, just type in the field.
field displayed value was set (at some point) in this
user.
Outlined Black Open and local - Attribute is open and the Yes, just type in the field.
field displayed value was set (at some point) in the
profile that applies to this user.
Outlined Empty (none) Open and empty - No value was inherited from Yes, just type in the field.
field the group. You should enter a value here or at the
profile level.
Outlined Gray (none) Open and local - The displayed value was Yes, just type in the field.
field obtained from the group level (group-attribute) of
the current group.
No outline Black Open and inherited - Attribute is open and the Yes, but first set a value for the attribute in the
value was inherited from the parent group (it was Inherited Attributes section of the current group,
not obtained from the current group) rather than having the value inherited from the
parent group.
Locked and inherited - Attribute is locked and the No, because the attribute is locked.
displayed value was inherited from the group
level (group-attribute) in the parent group.
No outline Black Locked and local - Attribute is locked and the No, because the attribute is locked.
displayed value was obtained from the group
level (group-attribute) of the current group.
No outline Empty (none) Locked and empty - Attribute is locked but you No, because the attribute is locked.
forgot to enter a value at the group level.
An attribute that you know exists The attribute is open but a value has not been No. If you want to set a value at the user level,
does not appear in the User defined in the group level where the attribute was the attribute must first have a value set in this
screen created (which could be the current group or the group or the parent.
parent group).
Managing user information

User data is accessed in the Users page.
From this page, you can view the user list, retrieve user details, and edit attributes.

l Click Edit to unlock, suspend, or change the attribute values for the selected user
(s).
l Click Delete to delete the selected user or users.
l Click Download to save users as a .csv file.
l Click Notify to either send email to end users, or send the most resent
configurations to the end users.
l Click Search in Users for group: to filter the user list.
l View or edit user data in the Details for user list.
Searching for an attribute

Select Starts with or Contains and type an attribute in Attribute name contains to search
for a specific attribute.
Editing users
In Stretto Admin, you can edit users one at a time or you can edit multiple users with
Attribute Paint. Attribute Paint lets you select multiple users and update one or more
attributes for them at the same time.
If you clear any attribute value defined at the user level, then either the user obtains the
value assigned to the attribute in the profile (if any) or the group (if any). If the attribute is
not assigned in the user, profile, or group, the user does not have a value for this
attribute.

To edit a single user
2. Select a user.
4. On the Settings tab, change the value for any Settings or Attributes that you want
to update.
5. Click Save.
The attributes are updated for the user.
To edit multiple users with Attribute Paint
2. Select the users.
3. Click Edit on Users for group:. The Attribute Paint dialog appears.

4. Select an attribute in the Paint column and update Value.

5. Click Save.
The changes are applied to all selected users.
Saving users to a .csv file.

You may want to save your list of users to a .csv file. You can download users that you
select or you can download the entire list of users for the group.
To download all users
2. Click Download on Users for group:.
3. Click Download all users.
Stretto Admin downloads all the users in the group to a .csv file according to your
browser's settings.

To download selected users
2. Select the users.
3. Click Download on Users for group:.
4. Click Download selected users.
Stretto Admin downloads the selected users to a .csv file according to your browser's
settings.
Tip: A text editor is recommended for opening and editing a .csv file. If you use
Microsoft® Excel®, use the Text Import Wizard instead of double-clicking to open
the .csv file. If you double-click to open the file, Excel removes leading zeros from
numbers, e.g., the VoIP number 003 appears as 3.
To open the downloaded csv file using Text Import
1. Open Excel.
2. Go to Data > From Text, then select the downloaded csv file.
3. Choose Delimited, and click Next.
4. Unselect Tab and select Comma, and click Next.
5. Find a column that contains numbers. Select the column in the data preview,
and choose Text. Repeat this step for all the columns that contain numbers.
6. Click Finish.
7. When you are done editing, save the file as CSV, not xlsx.

Format of the .csv file

The .csv file contains a heading row with field names and one user record per row. Fields
are separated by commas.
Heading row:
l The first three fields must be username, password, and profile, in any order.
l Username, password, and profile field names are not case-sensitive.
l Other field names are case-sensitive: for example, sipusername is not the same as
sipUsername.
l Omit attributes that have values assigned at the profile level and attributes to which
you will assign values to later.
l Omit the LicenseKey if Stretto automatically assigns this data from a pool.
l Field names can be in quotes or not.
User record:
l Comma-separated values corresponding to the fields defined in the heading row.
l One complete user record per row.
l Values that contain a comma must be enclosed in double quotes. For good
measure, enclose all values in double quotes.
l Attribute values are case-sensitive. For example, the profile name abcProfile is not
the same as AbcProfile.
l Username must have a value. All other values can be empty but the fields must still
be present in the file.
l Leave password blank if you are using a third-party to authenticate users (LDAP,
ECS).
l Email addresses must be unique — no two users can have the same email address.
As well, a user's email address cannot be the same as any other user's full
provisioning username (username@domain).

Example:
"username","password","profile","email","sipPassword","sipUserName"
"cgale","123$123","P_NA","[email protected]","134ud98e!","6045558900"
"tkay","abc123","P_NA","[email protected]","abcabcabc!1","2045551234"
Handling end user lockout

If an end user enters a wrong password more than five times, the user gets locked out
from the softphone client. The user may ask you to unlock and reset their password.
Tip: If Allow end users to change their password is selected in the End User Portal
Settings, a user can change their password in the End User Portal. If they cannot remember
their password, they can use the I forgot my password link on the End User Portal login
screen. Users must have an email address in the user property E-mail address set up for
users in the Settings section of Users to use the I forgot my password link.
A red icon in the Susp. column for the user indicates the user is either locked out or
suspended.
To unlock a user
2. Select a user.
4. On the Settings tab, clear Locked (End User).

5. Click Save.
The user is unlocked.
Suspending users
You can suspend a group of users or suspend an individual user using Stretto Admin.
When you suspend a user, Stretto Platform notifies the user to log out if you have set up
the Stretto Notification Service (SNS) feature.
To suspend or activate a user
2. Select a user.
4. On the Settings tab, select Active or Suspended from State.
The users status changes between active and suspended.

Sending the most recent configurations to end users' devices (Refresh

Devices)
There are times when the end users do not immediately receive the changes made by the
administrator in Stretto Admin. This feature allows the administrator to trigger the refresh
so that the users have the up-to-date configurations set by the administrators. Use this
when you are troubleshooting an issue for them for example. This eliminates the need for
end users to log out and log in manually.
This functionality uses the Stretto Notification Service (SNS) which requires a setup in
your Stretto.
To refresh devices of end users:
1. Under the group, select User. The group's user list opens.
2. Select one or more users. Skip if you are notifying all users in the group.
3. Click Notify then Refresh Devices.
The Refresh Devices dialog appears.

4. Choose who should receive the refresh notification:
l Send to all n users in group

l Send to selected users.

5. Click Send. Stretto shows how many devices are notified.

6. Click Close.
Deleting users
You can delete a single user, or select multiple users and delete them at once. When you
delete a user, Stretto Platform notifies the user to log out if you have set up the Stretto
Notification Service (SNS) feature.
To delete users
2. Select a user or multiple users.
3. Click Delete on Users for group:.
4. Click Delete on Confirm Delete.
The selected user or users are deleted.

Removing an unused device
When a user reached their device limit, the Stretto administrator can delete the unused
device for the user. This frees up space.
Tip: If Allow end users to view and delete their devices is selected in the End User Portal
Settings, a user can delete their own devices.
To remove an unused device
2. Select a user.
4. Select the Devices tab.

5. Locate the any devices and click Delete. The device entry turns gray.
6. Click Save.
The device is removed. Stretto Platform also attempts to log the user out of the deleted
device if the SNS feature is configured for the group.
Sending email notifications to users

Administrators can email end users when onboarding new users, resetting their
password, notifying users after unlocking and so on. With this feature, Stretto admin
allows you to:
l create an email template instead of typing an email body each time,
l embed variables such as Stretto username and password to be replaced with real
values for each user, and
l use a temporary password reset code for improved security, which avoids a Stretto
login password to be exposed as plain text in the email. Note that the access codes
have extra requirements.

Warning: Do not use temporary password access codes if you are using a third-party to
authenticate users (LDAP, ECS).
Requirements for email notifications

l Make sure the email notification feature has been set up on the system. See Setting
up email notifications for more information.
l Your end users' email addresses have been entered in Stretto. (It does not matter
which field - in the Email address field or any attribute unless you want to use the
temporary access code feature - see below)
Temporary access codes / Temporary passwords

When using the Notify feature on Stretto Admin, the Stretto login password is emailed to
users in plain text and most users do not change their passwords when they receive
them. To improve security, you can embed a temporary access code in the email instead
of the Stretto login password. A temporary access code will allow end users to only reset
their password in the End User Portal.
Note: End users cannot log into the softphone client with the temporary code!
Requirements for temporary access codes

In addition to the above requirements, the temporary access code feature requires the
following:
l End User Portal has been configured.
l Allow end users to change their password is enabled in their group's Portal
Settings.
l End users' email addresses have been entered in the user property E-mail address
on the Users page.

To use the temporary access code feature and allow them to reset their password,
end user's email address must be entered in E-mail address, not in another
attribute.
l When sending notifications, it requires the following:
l the Use the temporary access code(s) option is enabled
l {{ccs:password}} is embedded in the email which will be replaced with the real
temporary code for each user
How temporary access code works
When an email notification is sent out with Use temporary access code(s) enabled,
Stretto generates an access code for each user and embeds the code in the email as
plain text in place of the {{ccs:password}} attribute. The temporary access code allows
end users to reset their password using End User Portal; they cannot log into softphone
with it!
l The temporary access code is valid for one hour.
l The user's Provisioning Password is not modified by this notification or access
code. The existing login password continues to work until the user resets their
password using End User Portal.
l Your email can include a link to End User Portal to reset the password. Optionally
add parameters after ? to auto-fill the form.
For example:
https://stretto.cloudprovisioning.com:18082/userportal/reset.html
https://stretto.cloudprovisioning.com:18082/userportal/reset.html?username=
{{ccs:userName}}&password={{ccs:password}}&groupname=
{{ccs:groupName}}

l Once users reset their password, they need to log out and log back into the
softphone client.
Create a notification template

You can optionally create one or more reusable email notification templates. See the
email notification template for the format and an example.
To create an email template
1. Right-click the group where you want to create the template and choose New
Template > New notification template.
2. Type a name for your new template and press Enter. The new template appears
with some basic content.
3. Click Edit and format as needed.

4. Click Save.
Your email template is created in the selected group.
Send a notification email

You can send a notification email to users. You can select which users to notify and which
template to use.
To send an email notification
1. Under the group, select User. The group's user list opens.
2. Select one or more users. Skip if you are notifying all users in the group.
3. Click Notify then Notify.

The Notify Users dialog appears.

4. Choose who should receive the email notification:
l Send only to users whose Notify column is empty (they haven't yet been
notified).
l Send to all n users in group
l Send to selected users.
5. Click Next.
6. To use an email template, click Template; otherwise, type the content.
Otherwise, enter content in Email body text....

7. In To, leave set as user's email address to use the email address property in the
Settings section for the user or select an attribute that stores the end users' email
address.
8. To send a temporary access code, select Use temporary access code(s).

9. Click Send.
Notification emails are sent to the selected users. Stretto indicates that the user or users
were notified in the Notified column of each user.
In the full text of the notification email, text in curly brackets {{ }} are placeholders for any
Stretto attribute that you already set in the group, profile, or user. When the emails are
sent, the attributes will be replaced with real values. The following sample could be used
without temporary access codes.
Sample
Welcome aboard AC Phone. Please keep this email for future reference.
To log in to Bria, enter your username and password.

Your username is {{ccs:username}}.
Your password is {{ccs:password}}.
To download a Bria client, visit acphone.com and log in for details.
Thanks,
{{account.notification.administratorName}}

Setting preferences
In Stretto Admin toolbar, click the wrench icon to open a list of Stretto options.
Preferences are saved for each administrator, so if you log onto Stretto at a different
computer or browser, your saved preferences are loaded.
Some preferences may not be available depending on your Stretto installation.
Preference Description
Include all attributes when copying a profile When copying a profile from one group to another, all attributes — including those that are
blank — are copied. When this option is not enabled, attributes with no value are omitted.
Copy missing templates when copying a When a profile is pasted into a different group, any templates to which the profile refers will
profile be duplicated in the new group unless a template of the same name already exists.
Auto-format mobile XML templates when When saving a template for a mobile device, the XML source is tidied up and indented
saving correctly for readability. This is not the same as XML validation.
Trim value input strings When strings values are saved, inappropriate spaces are removed. See Trimming input
string values.
Warn when renaming groups Show a confirmation message when you rename a group.
The warning reminds you that renaming a group may result in users in that group not being
able to log in. In general, it is not a good idea to rename groups that are “in production”.
Warn when encrypting new attributes Show a confirmation message when setting an attribute to "encrypted".
Trimming input string values

Stretto Admin is capable of trimming — or cleaning up — extra spaces from values entered
into attributes. For example, when you type or paste a value, it may not be obvious if
there is a leading or trailing space character in the string. Using value trimming can
prevent accidental input errors.
Some values are always trimmed. You can set an option in Stretto Admin to trim other
values as well. See Setting preferences.

Values that are always trimmed
Entity When trimming is performed
Admin username Creating or editing an administrator.
Admin email address Creating or editing an administrator.
Attribute names Creating an attribute in the Groups screen.
Values that are optionally trimmed
Entity When trimming is performed
Attribute pool values Select an attribute pool in the navigation tree, then click New
Attribute default values Group screen > Group attributes > Default value column
User Editor input values Users screen > New or Edit
Multi-user Editor input values Users screen > New or Edit
Profile Details input values Profile screen > Profile Attributes > Value
Profile discriminator names Profile screen > Template Mappings > Custom > discriminator name
Mobile template input values Template screen when in Designer Mode

If the data type is “String”, then the value you enter in Value is trimmed as necessary.
Mobile template dialplan editor Template screen > Dialplan Rules, when in Designer Mode
The values you enter in Name, Match, Remove, and Add are trimmed as necessary.
Desktop template input values Template screen when in Designer Mode

If the data type is “String”, then the value you enter in Value is trimmed as necessary.
Template values Template screen when in Source Mode

Values are not trimmed.
If you work in Source mode, we recommend this procedure: after making your changes in
Source mode, switch to Designer mode. Make a change (to enable the Save button) then
reverse the change. Click Save: all trimming will be performed on all String values.

Stretto Platform Administration Guide Using Stretto Platform optional features
Using Stretto Platform optional

features
Some of the features available with Stretto Platform are optional either as features that
you can enable or disable or as features that you can add on. This section describes how
to set up Stretto Platform to use these features.
Bria Push for client notifications

Bria Push is an optional module for Stretto Platform that provides an efficient push
notification service for Bria clients. Bria Push works with any Bria mobile client — iOS or
Android — in conjunction with any publicly-accessible SIP service provider or server.
Note: In order to use the Bria Push service, the Bria client app must be version 5.0.3 or newer.
What is Bria Push?

Why you need Bria Push
Mobile applications that provide communications services, especially using SIP over
UDP, are power-hungry. As apps attempt to keep a connection alive, the continuous
communications can deplete the battery and even cause the device to become warm. As
iOS and Android add more limitations on apps that run in the background or conduct
background communications, inbound calls can be missed.
Recent versions of Android and iOS can aggressively stop applications that are running
in the background. In this situation, push notifications help by starting an application that
has been stopped by the operating system when the user receives a call.
Bria Push offers a solution to battery life, reliability, and operating system limitations to
ensure that the end user can stay on top of their calls. By enabling Bria Push in Stretto

and in Bria clients, you provide end users with a reliable service while improving battery
life.
Customers control Bria Push configuration through Stretto Admin, and give their end-
users the option to enable push notifications in each SIP account.
How Bria Push works

l When Bria is in the foreground on the device, it communicates as always directly
with the SIP server.
l When Bria goes into the background, Bria Push registers on behalf of Bria and acts
on its behalf. This relieves the client of the need to maintain its own connection to
the SIP server.
l Bria Push wakes the Bria app when the SIP server sends an inbound call.
l Communications between the client and Bria Push can be encrypted and secure.
The following diagram shows what happens when Bria goes into the background on a
mobile device.
To read more about how Bria Push works, see Push for the People on the CounterPath
blog.
Connecting to the CounterPath-hosted Bria Push service

Follow these steps to connect to the hosted Bria Push service.

1. Contact CounterPath to enable access to Bria Push.

2. Register with Firebase and/or PushKit. See Registering your app with iOS PushKit
or Google Firebase.
3. Go to the CounterPath Branding Portal, and request an updated branded client. For
your branded client to receive notifications, CounterPath needs to build a new
version that includes the correct Firebase or PushKit information. Log into the
Branding Portal to provide this information to CounterPath.
4. Set up Bria Push attributes and templates in your Stretto group. See Setting up Bria
Push attributes and provisioning templates.
5. Test hosted Bria Push on a mobile client. See Testing Bria Push notifications on a
Bria client. For troubleshooting tips, see Troubleshooting the Bria Push Service.
6. Deploy the updated mobile client to your user base.
7. The end user upgrades the client, and turns on Use Push Notifications in the
account settings.
Registering your app with iOS PushKit or Google Firebase

Before you use Bria Push hosted by CounterPath, you need to register your custom app
with iOS PushKit or Google Firebase.
Registering your iOS app with iOS PushKit

Follow the steps described in Branding Portal Guide.
https://docs.counterpath.com/guides/portals/brandingPortal/clients/BrandingPortal/iosP
ushKit.htm
Registering your Android app for Firebase service

Follow the steps described in Branding Portal Guide.
https://docs.counterpath.com/guides/portals/brandingPortal/clients/BrandingPortal/andr
oidFCM.htm
Providing your Firebase and PushKit information to CounterPath

For Bria Push and a client app to communicate, both need to have the correct security
information. Provide your push information to CounterPath and acquire a new build of the

app.
To upload your push information to the Branding Portal
1. Log into CounterPath Branding Portal and click the name of the brand for which you
are uploading push information.
2. Submit your Firebase information for your Android app. Skip this step if you do not
have an Android app.
a. Select Android > Push Notification. The Push Notification page opens.
b. Click Upload and browse your local file system for the google-services.json
file that you obtained from the Firebase website.
c. Click Save.
d. Select the Android hosted push tab, then click FCM server key. Enter the
Server Key that you obtained from the Firebase website in FCM Server Key.
e. Click Save.
3. Submit your PushKit information for your iOS app. Skip this step if you do not have
an iOS app.
a. Select iOS > App Store.
b. Click Upload and browse your local file system for the App Store Distribution
Provisioning Profile that you updated. For details on the Distribution Profile,
see the Branding Portal User Guide.
c. Click Save.
d. Select iOS hosted push > Apple Push Services.
e. Provide the information associated with your .p8 key file.
f. Click Upload and browse your local file system for the .p8 file that you created
earlier.
4. In the list of pages, click Build Requests & Notes and request a new build of your
apps.
Setting up Bria Push attributes and provisioning templates

The mobile client needs to be provisioned with certain Bria Push settings. This topic
explains what to configure Bria Push in your Stretto group.
This instruction assumes you already have users and profiles setup in your group.

Tip: The Stretto attribute names referenced here are recommended by CounterPath. If you
choose to use different attribute names, you must ensure that the provisioning template
correctly maps the Bria setting to your attribute names.
Create Bria Push attributes

Create the following attributes and assign a value at the group, profile, or user level.
Stretto attribute name Type Default value Description Bria setting
pushServerURL string https://push. This attribute pushServerUrl

softphone.com/pus specifies the
under core_data_list
h URL of the
push server
cluster. The
default is to
use the
CounterPath
push server
accountN.briaPush.enabled boolean false Set true to enablePublicPush

enable Bria under account
(where N is a number from 1 to 5)
Push on the
account on the
Bria client.
accountN.briaPush.RegistrationM integer 0 (Standard) Specify a pushRegistrationMo

number from 0
ode de
to 3.
(where N is a number from 1 to 5) Continuous (2) under account
and Standard
(0) are used if
your VoIP
service
provider
supports
multiple
registrations.
Single Device
Takeover (3)
and Single
Device
Emulation (1)
are used if
your VoIP
service
provider does
not support
multiple
registrations.

Most VoIP
service
providers do
support
multiple
registrations.
See below this
table for more
information on
this option.
accountN.briaPush.NATEmulation boolean true This option pushNATEmulation

instructs the under account
(where N is a number from 1 to 5)
Bria Push
server to
simulate that
the Bria Push
server is
registering
from behind a
Network
Address
Translation
(NAT) router
or another
network
element.
Enable NAT
Emulation if
your VoIP
service
provider uses
a session
border
controller. If
enabling NAT
Emulation
results in no
push
notifications or
no audio,
disable NAT
Emulation.
More
details
The Bria Push
server
simulates this

NAT situation
by inserting a
SIP VIA
header into the
SIP
REGISTER
method that
the Bria Push
server sends
to the SIP
server. This
VIA header
often assists
with ensuring
that various
NAT traversal
techniques are
enabled on a
customer’s
Session
Border
Controller
and/or SIP
server.
Enabling the
various
techniques
supported by
these
platforms may
assist with
ensuring that
registrations
are maintained
or may help
with issues
related to call
delivery or
RTP stream
establishment.
Registration Mode
This option controls how the combination of the Bria client and the Bria Push server
interact with the SIP server. For some customer’s SIP servers, the registration mode may
not matter or make a substantive difference to the behavior of the SIP Server or the
reliability of the reachability of the Bria client. For another customer’s, the registration
mode will matter quite a bit because one of the registration modes works best to address
the particular limitations of the customer’s SIP Server. Customer administrators and IT

staff should carefully understand these registration mode options and their potential
impacts.
l Standard (0)
The Standard registration mode allows both the Bria Push servers and the Bria
clients to register to a customer’s SIP account in an alternating manner. In this
mode, there may be short overlaps of registration where both the Bria Push server
and the Bria client are registered to the SIP server. Some PBXs, SIP servers or SIP
services may have issues with this registration overlap. If you encounter an issue
with registering to the SIP server or receiving push notifications, select a different
registration mode.
l Single Device Emulation (1)

The Single Device Emulation registration mode ensures that both the Bria client
and the Bria Push server unregister before the other one registers. In other words,
the Bria client and the Bria Push server never register to a PBX, SIP server, or SIP
service at the same time. The Bria client controls the registrations by requesting the
Bria Push server to register only after the Bria client has de-registered and
alternately, by receiving confirmation that the Bria Push server has de-registered
before the Bria client registers directly to the SIP server. The Bria clients will also
not register while they are in a call delivered through the Bria Push server so that
they do not cause potential issues with the call in progress being terminated by the
SIP Server.
Note that when in the Single Device Emulation registration mode, there are periods
of time (typically fractions of a second) when neither the Bria client or the Bria Push
server will be registered to the PBX, SIP server or SIP service. This gap could lead
to a missed call if the call is presented to the SIP server at the same time that
neither element is actively registered. This is a downside of the requirement of the
SIP server that only one element be registered at any one time.
l Continuous (2)
The Continuous registration mode ensures that the Bria Push server is always
registered on behalf of the Bria client. The Bria client still registers directly to the SIP
server when in the foreground, but the Bria Push server does not de-register from
the SIP server. In this mode, all inbound calls and all outbound calls from the Bria
client are handled by the Bria Push server.

The Continuous mode, in particular, is used when a SIP server supports multiple
registrations at the same time. This mode avoids any gap in SIP registration
because the Bria Push server is always registered on behalf of the Bria client.
In the event of a call to the SIP account while the Bria client is in the foreground, the
Bria client will receive an INVITE directly from the SIP server and via the Bria Push
server. The Bria client will filter out these duplicate events and only allow one of the
call attempts to progress.
l Single Device Takeover (3)

The Single Device Takeover mode is an enhanced option of the Single Device
Emulation mode. The Bria client and the Bria Push server take over registrations
from each other without unregistering first. Neither the Push server or the Bria
client sends SIP de-registration messages when transitioning from one element to
the other. It aims to eliminate gaps that are present in the other registration mode.
This mode is in some cases beneficial for SIP servers that only support single
registration.
Modify the mobile provisioning template

Edit the mobile provisioning template to include required settings.
1. Use the Source view to copy and paste the following data lines under <core_data_
list>.
<core_data_list>
(omitted)
<data name="pushServerUrl" value="{{pushServerURL}}"/>

<data name="supportsLegacyPush" value="false"/>
<data name="supportsPublicPush" value="true"/>
2. In the Source view, locate your SIP account that uses Bria Push and copy and
paste the following data lines under <account>. This example assumes you use push
notifications in Account 1.
<account_list>
<account>
(omitted)
<data name="enablePublicPush" value="{{account1.briaPush.enabled}}"/>

<data name="pushRegistrationMode" value="{{account1.briaPush.RegistrationMode}}"/>

<data name="pushNATEmulation" value="{{account1.briaPush.NATEmulation}}"/>
3. Look for the setting name useAPN under <account_list>. If there is, delete the setting
(the entire setting and not just the value). This setting was used in a previous
version, but is now deprecated.
Add attributes for Bria Push advanced settings

Do this only when your test concluded that you need extra settings to make Bria Push
work with your SIP server. The advanced settings aim to help solve a particular problem
with SIP servers. In most cases, you do not need to change the advanced settings.
Refer to the Mobile Settings list for the advanced settings of Bria Push.
Testing Bria Push notifications on a Bria client

In this section, you test your Bria Push setup with a test user account.
At this stage, you need to confirm that Bria Push works correctly on a Bria client. By
following the testing steps in this section, answer these questions:
A. Does the client connect to the SIP server successfully?

If Bria fails to connect to the SIP server, this indicates a provisioning issue. Go back
and review the provisioning settings for the test user and the test user's profile and
template.
Test SIP connectivity

1. Using the test account, log into Bria on a mobile device.
2. Select Settings > Accounts. The Accounts page opens.
3. Look at the icon next to the name of your SIP server:
l A green icon indicates that Bria is connected to the SIP server.
l A green icon with green bars indicates that Bria is connected to the SIP
server and push notifications are enabled.
l A green icon with gray bars or no bars indicates that Bria is connected
to the SIP server, but push notifications are not enabled.

This client is connected to the SIP server without push This client is connected to the SIP server with push
notifications. Follow the steps to enable push notifications in notifications. Your client is ready to test incoming
the client. calls.
B. Can you enable the option for push notifications?

If the option isn't available, try to enable it in the account settings. Some client apps
can be pre-configured to suppress the option to turn Bria Push on/off, so be aware
of how your client apps are configured and adapt your testing accordingly.
Enable push notifications if push is not enabled

The ability to turn push notifications on and off is not always present in the client
app. Its presence is controlled by options chosen in the CounterPath Branding
Portal. If this option is present in the client app, follow these steps to ensure that
push is enabled.
In iOS
1. In Bria, select Settings > Accounts. The Accounts page opens.
2. Select the information icon . Bria displays the account information for your
SIP account.
3. If Bria indicates that your account status is "Registered", turn off Enabled.
This allows you to change the push settings.
4. Scroll down and select Account Specific Features. The Account Features
page opens.
5. Enable the option Use Push Notifications and return to the previous page.

6. Turn on Enabled and return to the Accounts page. Bria should now indicate
that it is connected to the SIP server (green icon) and that push notifications
are enabled (bars above the icon).
Your client is ready to test incoming calls.
In Android
1. In Bria, select Settings > Accounts. The Accounts page opens.
2. Tap the green slider next to the SIP account name to unregister.
3. Tap the SIP account name. Bria displays the account information for your SIP
account.
4. Scroll down and select Account Specific Features. The Account Features
page opens.
5. Enable the option Use Push Notifications and return to the Accounts page.
6. Tap the slider next to the SIP account name to register.
Your client is ready to test incoming calls.
C. Does the Test Push Service pass?
Try the Test Push Service button in Settings > Accounts - Bria Push Service with
the SIP account enabled and registered. If the test is successful, your device is able
to communicate with the Bria Push server and your device is able to receive push
notifications from the Apple and/or Google FCM push notification systems.
D. Can the client receive a call when the app is in the foreground?
Verify that Bria can receive calls when the client is in the foreground. This
establishes the minimum functionality.

Test an incoming call when Bria is in the foreground

1. Log into Bria and leave the app open on the screen.
2. While the app is still open and visible, use another device to call your test
user.
l If Bria indicates an incoming call, then you can proceed to test with Bria
in the background.
l If Bria does not indicate an incoming call, then look for errors in
provisioning and make sure that the client is logged into the correct SIP
server and user account.
E. Can the client receive a call when the app is in the background?
If Bria notifies you of incoming calls even when the client is in the background or
terminated, then you have confirmed that Bria Push is working as intended.
Test an incoming call when Bria is in the background

1. Log into Bria then press the Home button to return to the home screen. Bria is
now in the background.
2. Use another device to call your test user.
l If Bria notifies you of an incoming call, then this indicates that the Bria
Push server has successfully registered with the SIP server and relayed
the notification to your device's notification service.
l If Bria does not notify you of an incoming call, then perform a check to
see if Bria Push is registering when the device is in the background.
F. Is the client registered with Bria Push?
The final step is to verify in Android and iOS that Bria remains registered with Bria
Push when the client is in the background.
Perform a check to see if Bria Push is registered (Android devices)

1. Log into Bria then press the Home button on your device to return to the home
screen.

2. On the home screen, drag down from the top to open the Android Status Bar.
3. Look under the name of your Bria client (the name may vary depending on the
version).
If you see the words "Push Registered", it means that Bria Push is registered
with your SIP server when Bria is in the background.
Perform a check to see if Bria Push is registered (iOS devices)

1. Log into Bria and select Settings > Accounts. The Accounts page opens.
2. Verify that your SIP server shows a green icon with green bars over it, which
indicates that push is enabled.
3. Press the Home button on your device to return to the home screen. Bria is
now in the background.
4. After about 10 seconds, open Bria again. In the Accounts page, you should
see the client registering with the SIP server, then showing the green icon
again.
These tests should be performed using a Bria client app that has been updated to the
latest version that includes Bria Push support (5.0.3 or newer). The client app used to
illustrate these tests is Bria; however, the procedure is the same for all Bria client apps
and branded client apps.

Note: To stop receiving push notifications, set your device to "Do Not Disturb" mode or log out
of Bria (Settings > Logout).
Troubleshooting the Bria Push Service

This section contains troubleshooting tips when testing the Bria Push Service.
Troubleshooting tips
l Is it Push-related?
Determine whether or not the issue is related to push notifications. To verify this,
test the same scenarios while the Bria client is in the foreground. If you encounter
the same issue while in the foreground as well as in the background, your issue is
likely unrelated to the Bria Push Service.
l SIP server reachability from CounterPath Push servers
The SIP server (a PBX or a SIP service) must be reachable from the Internet. This
is required in order to allow the Bria Push servers to register to your SIP server and
receive calls from your SIP server.
If your SIP server is running inside a restricted network of an organization

You must do both:
a. set the SIP Proxy setting which is a separate item from the one configured as
part of regular SIP settings.
b. provide access to the Bria Push servers CounterPath has deployed. See the
Bria Push Checklist for a list of IP address and DNS names used by the Bria
Push Service. Note that this information may change over time; customers
should monitor the content.
If you are not sure about the network you are using
Verify the SIP server reachability by testing if the Bria client can register to the
SIP server, with the Bria Push Service disabled, in the following networks:
l from a Wi-Fi network that is not associated with your own corporate/home
network, such as a coffee shop or public library, and

l from an LTE / 4G mobile network. Make sure to disable the Wi-Fi network on
the mobile device.
This test is effective when verifying the SIP server reachability because the Bria
client registering from an unknown IP address simulates the interaction of
CounterPath Push servers with the customer's SIP server.
l CounterPath Push server reachability from the Bria clients
Ensure that their mobile devices are on a network that allows them to communicate
with the Bria Push Service. Try the Test Push Service button in Settings >
Accounts - Bria Push Service with the SIP account enabled and registered. If the
test is successful, your device is able to communicate with the Bria Push server and
your device is able to receive push notifications
l Apple APNs / Google FCM reachability from the Bria clients
Apple / Google requires a set of ports to be open in your firewall. If you have a
restricted network, see Apple APNs / Google FCM to make sure the traffic is
allowed. The Test Push Service button can verify this.
l SIP server capabilities: single registration vs multiple registrations
One critical item to understand about a SIP server is if it supports a single
registered client per configured SIP account or line. Different manufacturers,
software providers, and Unified Communications Services use different terminology
for this capability.
a. If you can only use one SIP device at a time, then CounterPath classifies this
as supporting a single registration. In Bria Push configuration, the registration
mode should be either Single Device Emulation or Single Device Takeover.
Try Single Device Takeover unless Single Device Emulation is already
working for you. It might require some testing to figure out which is better for
your deployment.
b. If you can use multiple SIP devices at the same time and specifically receive
calls on all devices for a single inbound call (meaning that all devices are able
to maintain a registration and the SIP server supports call forking), then
CounterPath classifies this as supporting multiple registrations. The
registration mode should be either Standard or Continuous. Try Continuous
unless Standard is already working for you. It might require some testing to
figure out which is better for your deployment.

l SIP server capabilities: setting Contact URI

The SIP server should map the SIP Address-of-Record (AOR) to the Contact URI
when sending the INVITE. The Bria Push server generates a unique Contact URI
for each SIP account on each device the account is registered on. The Bria Push
server uses this unique Contact URI to determine where to send the push
notification for the incoming call. If the SIP server does not pass the unique Contact
URI to the Bria Push server in the INVITE, it is likely that the device will not get a
push notification for the incoming call because the Bria Push server cannot identify
a unique SIP account to route the incoming call.
More details
The Bria Push server sets this unique Contact URI in the REGISTER message
when registering with the SIP server. For the best interoperability, when the SIP
server notifies the Bria Push server of an incoming call, the SIP server should set
the Request-URI of the INVITE message to be the same value as the Contact
header as specified by the Bria Push server in the REGISTER message. If you think
this might be the cause of your issue, try changing the settings for Disable Hash
Token and Insert RInstance.
l Permissions for push notifications on user's device
Make sure the user has given a permission to receive push notifications on their
device. This can be controlled in the same way as you give a permission for the
mobile device to access the microphone, camera, contacts etc.
Common issues
Missed Incoming calls
This is one of the most common issues when testing the Bria client on mobile devices
with or without using push notifications. Make sure:
l Push notifications are enabled in the SIP account on the Bria client.
l The user has given a permission to receive push notifications on the device.
l Your SIP servers can be reached from the Internet, such as a coffee shop or public
library. Try registering to the SIP server with push notifications disabled in such a
location using Wi-Fi and/or a mobile data network.

l The Bria client can reach the CounterPath push servers from behind any firewalls.
Try the Test Push Service button on the Bria client.
l Check if your SIP server cancels the incoming call because it does not receive a
180 RINGING message back from the Push server within an expected period of
time. If this is the case, turn on the Auto Send 180 Ringing setting (one of the Bria
Push advanced settings), or review configurations on your SIP server to increase
the interval in which a 180 RINGING is expected.
l Review the Bria Push Checklist.
No audio or one-way audio

In the CounterPath's experience, no audio or one-way audio has not been related to the
Bria Push Service.
Try calling to and from the Bria client while it is in the foreground, which does not leverage
the Bria Push Service. If you still experience no audio or one-way audio while the client is
in the foreground, it means that the issue is outside the scope of the Bria Push Service
and that it is likely related to a configuration in the SIP network or interaction between Bria
and the SIP server. Try solving the issue with push notifications disabled. After
addressing the issue, try testing push notifications again.
Logs and traces
Consider using the following when troubleshooting push-related issues.
l SIP trace from the SIP server

Not required, but having a SIP trace from your SIP server is beneficial. A SIP trace
provides information needed to understand the interaction between the Bria client,
the push servers, and the SIP server.
Some SIP platforms and providers provide a view of the SIP registration status.
This capability can be helpful to determine if the Bria Push Service is able to
register on behalf of the Bria client.
l Client trace from the Bria client

CounterPath provides the capability for the user to send the device log from the Bria
client to Stretto Platform where their administrator can view the log and
troubleshoot.

More resources
Visit the Bria Push Checklist.
Collaboration (Virtual Meeting Rooms)

Collaboration, also known as Virtual Meeting Rooms, is a cloud-based service hosted by
CounterPath that combines audio, HD video, screen sharing, messaging, and presence
in one virtual meeting.
Contact CounterPath representative about how to obtain the Collaboration feature.
See Configuring Collaboration for how to set up the Collaboration feature in your Stretto
group.
Meeting rooms
Using Stretto Admin, the administrator sets up meeting rooms for each user in a group,
which allows for multi-party audio and video calls. Users can then host meetings that are
reachable by any device with Bria installed, or any device with a web browser.
Each meeting is defined by a unique group bridge prefix plus bridge number and a unique
meeting code. These three identifiers direct callers to a shared multi-party call.
In Stretto Admin, administrators can:

l Set up meetings in which an end user can be called — add, modify, and delete
meetings per user.
l View and download all meeting setup information to a CSV file.
l View and download meeting usage records to a CSV file — all records or records for
a user or selected users.
l Upload meeting configuration for end users in a CSV file.
Meeting recording
Each meeting can be recorded either with only the audio portion, or both the audio and
video portion. In order to record both the audio and video portion, the Host must provide a
Dropbox account to store the recorded files.

l Users can generate an access token for their own Dropbox account and enter it into
Bria through the Collaboration Management User Portal.
l An administrator can acquire an access token from each user and add it to the
meeting settings in Stretto Admin.
Note: An account with Dropbox is required to use this feature. You can read more about
acquiring Dropbox access tokens at dropbox.com.
Viewing usage data

See Accessing meeting usage data
Configuring Collaboration
Setting up a Stretto group for Collaboration
Enable Collaboration by creating and setting attributes and modifying the provisioning
templates.
To set up for Collaboration
1. In Stretto Admin, create the following attributes and set their values at the group
level:
Attribute Value Comment
collabServerUrl wss://collab.cloudprovisioning.com:443/join
vccs:xmpp.chatroom conf-{{ccs:userName.User}}@conference. Do not change the value.

{{ccs:xmppdomain}}
vccs:xmpp.domain {{ccs:xmppdomain}}
vccs:xmpp.proxy imp.softphone.com
vccs:xmpp.guest.username [email protected]
vccs:xmpp.guest.password ThisIs4Collab
vccs:xmpp.websocket-url wss://imp.softphone.com:5291/
Up to you. For example: true Optional attribute if you do not want to set a

feature.stretto_vccs_ value in the templates (i.e., if you want to

available.enabled give this ability to only some of your users,
not all users).
This controls whether to enable the
Collaboration feature in the client.
Up to you. For example: true Optional attribute if you do not want to set a
feature.allow_vccs_call_ value in the templates (i.e., if you want to
recording.enabled give this ability to only some of your users,
not all users).
This controls whether to allow recording of
themeeting call by participants.
2. Modify the provisioning templates to map the attributes to settings, as follows:

Desktop template:
feature:vccs:group="{{ccs:groupName}}"
feature:vccs:url="{{collabServerUrl}}"
feature_options:stretto_vccs_available:enabled="{{feature.stretto_vccs_available.enabled}}"
feature_options:allow_vccs_call_recording:enabled="{{feature.allow_vccs_call_
recording.enabled}}"
Mobile template: Find <core_data_list> in the template.
<core_data_list>
<data name="useStrettoVccs" value="{{feature.stretto_vccs_available.enabled}}"/>
<data name="enableStrettoVccsRecording" value="{{feature.allow_vccs_call_
recording.enabled}}"/>
<data name="vccsGroup" value="{{ccs:groupName}}"/>
<data name="vccsUrl" value="{{collabServerUrl}}"/>
Collaboration is enabled for the group.
Setting up Collaboration Management User Portal

This is optional; do this only if you want to allow end users to change their configurations
using the End User Portal.
Set up End User Portal and make sure to check Allow end users to change meeting
settings. Your end users can set their preferences using the Meetings section on their
End User Portal page in the clients.

Customizing Collaboration templates

Various templates are in place for Collaboration. These templates can be customized,
and inherited by the subgroups.
To customize the templates, copy the content from the following page, create a blank
template in your Stretto group, and save it as the same filename indicated on the said
page.
l Collaboration email invite templates are used when Bria invites people to a
meeting, or schedules a meeting.
l Collaboration email summary template defines the email formatting when Bria
emails the Host with the summary such as participants and chat history after a
meeting ends.
Editing the vCard template

If you support vCard for XMPP, add the <X-CPCOLLAB> line at the bottom of the vCard
template. This adds the Collaboration meeting link to each person's contact information.
<vCard xmlns="vcard-temp">
(( omitted ))
<X-CPCOLLAB>vccs://collab.cloudprovisioning.com:443/join/{{ccs:user.conference.code}}/
{{ccs:groupName}}</X-CPCOLLAB>
</vCard>
Setting admin privileges for accessing meeting settings

Change admin privileges so that the admins for this group can access the Meetings page
in Stretto Admin. Go to the Admins tab in Stretto Admin to change the admin option.
l Normal admin needs no change; they already have access to the Meetings page.
l Some admin types such as Users&Profiles admin need to have the Meetings
admin option enabled.
l ReadOnly admin needs to have the Meetings admin option enabled, and they can
only view the Meetings page.

Creating meetings for end users

Create a bridge for end users. The users with a bridge become the Host of a meeting.
This step can be done by another admin; see the section above for setting the privileges.
See Setting up a Collaboration meeting for an end user.
Setting up a Collaboration meeting for an end user

Each end user that will be the Host of a Collaboration meeting needs to have a bridge set
up.
Although Stretto Admin lets you set up meetings one-by-one, you may find it easier to
add meetings to Stretto Admin in bulk by using a CSV upload.
After meetings are set up, users can see the meeting title, access numbers, and URL
when they start a meeting or schedule a meeting in their client app.
Setting up a single meeting in the Meetings page

To set a meeting:
1. Under the group in which the particular user belongs, select Meetings. The
Meetings page opens and shows a list of any existing meetings.
2. Check to see if the user already has a meeting by searching for their provisioning
username in the search bar.
3. Click Add. A blank Meeting Editor dialog appears.

4. Enter the settings for the new meeting and click Save.
Meeting
Required Description
Setting
Provisioning ✓ Enter the Stretto username exactly as it appears in the group user list. You can select a user
Username from a list by typing a partial username.
Group Bridge ✓ This number is set up by the Stretto system administrator and should be unique to the group.
Prefix
Bridge ✓ Enter a number that callers dial. The number can be up to 12 digits and must be unique per
Number group bridge prefix.

Meeting
Setting
Title Type a short title for the meeting. Descriptive titles with a consistent naming scheme can be
helpful when reading meeting reports. The Title appears in the calendar invitations and in
History.
Participant Participants are prompted to enter this PIN to join the meeting. The Host must give this PIN to
PIN participants prior to the meeting.
Moderator PIN If the meeting is moderated (a meeting will not start until a moderator joins) and the Host dials in
directly to the bridge, the Host must enter the moderator PIN to start the meeting. You must set
the Participant PIN as well as the moderator PIN so that dialing into your bridge will provide
options to enter the PINs.
Meeting Code This is a unique and randomly-generated ID code to identify the meeting for participants. The
Host can provide the calling URL, which includes this code, to participants before they call in.
Meeting Code If you want the meeting code to expire after a set time period, select this check box and set a
Expires? duration. After that duration, even if a participant has a URL with the meeting code, they cannot
call in again until they acquire the new, randomly-generated code from the Host.
Moderated Select Meeting starts only when moderator joins if participants should wait in a virtual lobby
until the Host joins the meeting. When this is enabled, the Host must do one of the following to
start the meeting:
l Join the meeting by using Bria. You need to log into Bria so that the
system knows it is the Host.
l Join the meeting by dialing in. You need to set the Participant PIN and the Moderator
PIN prior to the meeting, and make sure participants know the Participant PIN to enter
upon joining your meeting.
Grace period This setting specifies how long participants can remain in a meeting after the Host has
after host disconnected. After the time has elapsed, participants are notified that the session is closing
leaves before they are disconnected.
Email Select this option if you want the Host to receive an email summarizing the call: user info, SIP
Summary address, display name, XMPP name (if applicable), time stamps, and link to a recording (if
enabled). The user's email address field must be configured for this feature to work correctly.
Email Select a timezone to be used for email summary. Type a name of country or city, and pick the
Summary suitable one from the suggested list.
Timezone
Recording Choose whether the Host can record the audio or the audio and video portions of a meeting. To
format record the video portion, enter the Host's Dropbox token.
Recording Select this option to automatically record meetings with no user intervention. Meeting recordings
auto-start begin when two or more members join.
Initial Video Select the default resolution for your meetings. 848x480, 1280x720, or 1920x1080. All video
Resolution streams at this resolution if available. If a participant is sending video at a lower resolution, their
video appears in the lower resolution in the video stream. 1080p video provides a crisper image
but uses more data than 720p.
Entry/Exit If Play tones when participants join or leave the meeting is selected, members hear a tone

Meeting
Setting
tones every time a participant joins or leaves the meeting.
Lone Choose the sound to play when a meeting has only one participant. Uploading your own sound
Participant file is not supported.
Sound
Join muted Select this option if you want to mute new participants when they join the meeting.
Initial Video Choose the layout to use for video metings:

Layout Focus - a grid layout where the active speaker takes a larger box than other participants.
Grid - a simple grid of all video streams.
Ribbon - the active speaker appear in a large box with other streams arranged in a ribbon along
the bottom.
Townhall - a single video stream is displayed.
Show Video Select this option to display the participant's display name on their video stream.
Name Tags
Dropbox If you want the Host to record both the audio and video portion of a meeting, enter the Host's
Token Dropbox token. Alternatively, users can provide their own Dropbox token in the End User Portal,
so that each meeting owner can upload recordings to their own Dropbox.
Description Enter a description of the meeting. This is a free-form text box for any notes you might have.
Setting up many meetings by uploading from CSV

To save time and effort, you can create meetings for many users at once by uploading a
comma-separated values (CSV) file that contains the settings for each meeting.
The format of the CSV should be as follows:

l First line is a header line that contains the field names.
l Each subsequent line is a record in which each value is separated by commas.
l Use double quotation marks around values.
l If a field has no value, use empty quotation marks.
Tip: To get the format of the CSV file, click Download in the Meetings screen, save the file,
then replace the content (except the heading line).
Fields:

meeting_title, user_name, meeting_key, meeting_key_expiry, participant_pin, bridge_number, moderator_

pin, nomoderator_overrun, is_moderated, summary_email, video_layout, video_frame_rate, dropbox_token,
auto_record, auto_record_audio_only, description
Example:
"meeting_title","username","meeting_key","meeting_key_expiry","participant_pin","bridge_
number","moderator_pin","nomoderator_overrun","is_moderated","summary_email","video_layout","video_
frame_rate","dropbox_token","auto_record","auto_record_audio_only","description"
"Marketing NA Meeting","[email protected]","FASGPXAEIR","6/7/2020
16:20","1234","1006","1000","0","true","true","focus","30","","false","false","North America region
marketing meeting"
"Marketing Asia
Meeting","[email protected]","RQNVSVUNAL","","1234","1007","2000","30","false","true","grid","30","","t
rue","false","Asia region marketing meeting"
"Sales NA
Meeting","[email protected]","NTIAKEZLNM","","1234","1008","3000","0","false","true","ribbon","30","","
false","false","North America region sales meeting"
To upload meeting data in a CSV file:
1. Under the group in which the particular user belongs, select Meetings. The
Meetings page opens and shows a list of any existing meetings.
2. Click Upload then browse for and select a file.
3. In the Meeting Configuration Upload dialog, click Submit.
If a record that you upload matches the owner, lobby, and bridge of an existing meeting,
the existing meeting is updated with the uploaded settings; otherwise, a new meeting is
created.
Accessing meeting usage data

Stretto saves meeting usage metadata that you can view and download in Stretto Admin.
When a meeting is held, Stretto records the following information per session:
Meeting information
l Owner
l Meeting bridge
l Start time

l End time
l Duration (for meeting)
l A number of Participants, with a breakdown of:
l Desktop participants
l Mobile participants
l Tablet participants
l Dial-in participants
l Web participants
l Kicked participants
l Screenshare usage (duration for screenshare)
l Physical Bridge, indicating which call server hosted the meeting.
Each participant information

l Username
l Connection type
l SIP address
l XMPP address
l PSTN Tag
l Joined timestamp
l Call start
l Call end
l Call duration
l Own (meeting owner)
l Mod (meeting moderator)
l Rec (meetingis recorded)
l Prs (meeting had a presenter with screen sharing)
l User Agent

Chat information
l Date
l Sender
l Message
Usage:
l To view meeting usage for a group, select Meetings > Usage Records.
l To filter the list by provisioning username, meeting title, bridge number, meeting
code, or description, click the Search icon in the Usage Records tab and enter a
partial search string.
l To download the list of meeting records currently displayed in the Usage Records
tab, click Download.
l To view detailed metadata for a meeting, click a usage record in the Meetings tab.
Up and down arrows browse through the list of usage records.
Messaging and presence (XMPP)

Stretto offers an XMPP module to act as an XMPP server. The XMPP module allows
enterprises and service providers to provide an XMPP service to their end users.
The XMPP module provides:

l Roster management including vCards and avatar images
l Account management
l One-on-one chat. See Setting up Stretto Sync for syncing the message history
across all devices of an end user.

l Chat room (persistent): public (anyone can join) or private (invite only)
l Delayed Delivery
l Presence subscription
l LDAP/Active Directory integration (for authenticating XMPP users as well as
building shared rosters and vCards)
l Privacy – blocking communications to or from specific users. This can be done at a
domain level by configuring federation, or at user level on the softphone client.
l File Transfer – Peer-to-peer transfer support is subject to the softphone client
capability. No support for server-controlled file transfer.
l Multi-tenanted capability
Deployment
The XMPP module can be deployed in the customer's environment, or hosted by
CounterPath, with or without the Provisioning module.
The XMPP module is deployed behind the firewall in the network. NAT/port forwarding
must be configured to allow connections through the firewall. Also the XMPP domain
must be set up with DNS-SRV on your DNS server so other servers and clients can find
the server.
Security
The connection between Bria clients and the XMPP server can be encrypted using TLS.
Remote monitoring
The XMPP module can be remotely monitored using HTTP and SNMP.
User management
Stretto allows the administrator to manage their users by using the web interface called
Stretto Admin or the Stretto API. Stretto shares the user data for provisioning and for the
XMPP service. This means that the administrator can easily add the XMPP service to the
existing provisioning users, and vice versa.

Stretto also supports LDAP/Active Directory integration for XMPP service as well as
provisioning. If the administrator uses LDAP for authenticating the provisioning users,
they can do the same for the XMPP service.
Roster management
The Stretto Platform offers two ways to configure XMPP rosters. One is to create rosters
locally within Stretto by using Stretto Admin or the Stretto API. The other way is to retrieve
the roster information from LDAP/Active Directory.
The administrator can configure rosters for their users and push them down to the client
when they log into the XMPP service. The Stretto Platform supports shared rosters; the
administrator can configure multiple rosters instead of putting all users into a single
roster.
Create a Supervisor Mode roster which only shows presence for some users or addnon-
Stretto contacts as Common Contacts to an existing roster.
Presence, vCards, and contact photos are also supported.
vCard support
Stretto offers a vCard template that the administrator can customize. User information for
vCards can be populated via LDAP, or via Stretto Admin, or Stretto API which support
bulk users upload using a .csv file. Stretto creates vCards from the template, and pushes
them down to the client. The template is in an XML format and follows the schema
specified in RFC 6351.
Photos
Photos of users can be supplied to Stretto via Stretto Admin or Stretto API, or retrieved
from an LDAP/Active Directory server using the vCard template. The photo requirements
are listed below:
l The size of the photo must not exceed 64KB, which is configurable.
l The image content type must be image/png, image/gif, or image/jpeg.
l When uploaded via the API, the image data must be encoded as a base64 binary.

LDAP/Active Directory integration

The administrator can integrate LDAP/Active Directory for authenticating XMPP users,
building rosters, and generating vCards and photos.
Stretto LDAP integration includes load balancing and failover on multiple LDAP servers,
as well as a feature to bypass login when no LDAP servers are available. If the
administrator has already integrated LDAP with Stretto, using LDAP for XMPP is simple.
The administrator needs to configure a separate LDAP admin DN and password for
retrieving vCards, and map Stretto attributes with LDAP attributes.
Account management: provisioning end users with credentials

Bria clients can handle separate accounts for Voice (SIP), IM and Presence (XMPP), and
SMS (SIP SIMPLE).
The administrator can use the Provisioning Module to send the account configuration
down to their end users. Alternatively, the Stretto Email notification feature can be used to
notify end users of their XMPP credentials so end users can enter their credentials on the
client for login.
Restore and backup

You can create backups of XMPP-related configurations such as rosters, users and
avatar photos by downloading your group to a zip file. The zip file can be imported to a
Stretto group.
XMPP domain and HTTPS certificate

Decide on your XMPP domain name before starting configurations. By default, Stretto
uses the Stretto group name as your XMPP domain. You can assign a different name as
an XMPP domain. Both Stretto group names and XMPP domain names must be unique
in Stretto. Check with CounterPath about the XMPP domain name you want to use before
configuring to ensure that no one else has taken the name.
One example you might want to have a different XMPP domain name rather than your
Stretto group name is an SSL certificate for XMPP connections.
Do I need to create a certificate?

If you want to use a certificate for a secure connection for XMPP, you have two options

l Create your own certificate and upload it to Stretto. Your XMPP domain name can
be any name as long as it is unique in Stretto. Check with CounterPath about the
XMPP domain name before creating a certificate to assure the name is unique.
l Use CounterPath softphone.com certificate. Your XMPP domain name must be in
the format of xxxxx.softphone.com, and must be unique in the Stretto Platform.
Your Stretto group name and XMPP domain name will be different. During
configuration, you must set the XMPP alternate domain name in GUI.
If you do not want to use a certificate for XMPP, turn off the XMPP cert checking setting in
the clients. The clients skip the TLS certificate validation for XMPP connections. No need
to create a HTTPS certificate.
Naming conventions for XMPP

In addition to naming conventions for Stretto, be aware of the following rules for XMPP
domain name and user names.
XMPP domain name
l Must be lower case.

l Must start with a letter (a to z). After that, it may include a-z, 0-9, - (hyphen), and .
(period).
l Must end with a letter or number (a-z or 0-9).
l Do not include: _ (underscore), space, " , & , ' , / , : (colon), < , > , @ , \ . ; (semi-
colon).
XMPP user names (JID)
l Must be lower case. They are not case-sensitive, so kperera and KPerera are
treated as the same username.
l May include a-z, 0-9, - (hyphen), . (period), and _ (underscore).
l Do not include: space, " , & , ' , / , : (colon), < , > , @ , \ , ; (semi-colon)
Creating HTTPS certificates for your XMPP domain

You can place an HTTPS certificate on Stretto to ensure that the XMPP connections for
your XMPP domain is secured.

Each XMPP domain must have a valid certificate configured in Stretto. Even if you
decided to use the existing Stretto provisioning certificate for the XMPP domain, you still
need to create a pem file and upload it to Stretto.
Requirements for the certificate

The certificate must meet the following requirements:
l Named as the XMPP domain name.
l Contain a chain file and a key.
l The chain file must have a complete chain, including the root certificate and all
intermediate certificates.
l Have the .pem format.
l Must be publicly signed.
Preparing a certificate for upload
1. Obtain a certificate with the XMPP domain name.

The XMPP domain name must match the group name on Stretto. If you have
subgroups, you can use a wildcard in the cert (for example, the common name in
the cert can be *.acphone.com if your XMPP domains are asia.acphone.com and
euro.acphone.com).
2. Make sure that you have a chain file for your XMPP domain certificate.
3. Create a .pem file that contains your server certificate, your private key, and the
chain file. The .pem file must be named your-xmpp-domain.pem. For example, if your
XMPP domain is example.com and you created/obtained a chain file called
ca.bundle.crt, the following command will create a .pem file.
cat example.com.crt example.com.key ca.bundle.crt > example.com.pem
4. Upload the pem file to Stretto by following the next section.
Uploading XMPP certificates to Stretto

You can upload the certificate, if you choose to provide one for your XMPP domain, to
Stretto via Stretto Admin. It also allows you to view the information about the current
certificate: such as associated domains and an expiry date.

To upload an HTTPS certificate to Stretto
1. In Stretto Admin, select your group and click the Messaging options tab.
2. Under the XMPP certificate management section, click Add Certificate.
3. Select a .pem file to upload, and click Submit. Stretto checks the certificate and
shows a message.
4. To view the certificate information you just uploaded, click Certificate Info.
Setting up SRV records for XMPP on DNS

Set up a server/client SRV record on your DNS server so that other systems can locate
your Stretto XMPP server via DNS. The following shows an example of the SRV records

on a DNS server, set up for the XMPP domain “softphone.com”.
Contact CounterPath for details on the SRV configuration.
Use the dig command on Linux to query the SRV record. The ANSWER SECTION should show
the configured information.
Below is an example of the SRV record for im.softphone.com.
45269 is the external server-to-server port which maps to 5269 internally. im-
b1.softphone.com is the A record for the host IP (or VIP) of the server.
[root@stretto-site1-b1 ~]# dig SRV _xmpp-server._tcp.im.softphone.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 <<>> SRV _xmpp-server._tcp.im.softphone.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32100
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;_xmpp-server._tcp.im.softphone.com. IN SRV
;; ANSWER SECTION:
_xmpp-server._tcp.im.softphone.com. 299 IN SRV 0 50 45269 im-b1.softphone.com.
;; Query time: 69 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Oct 20 10:36:23 2014
;; MSG SIZE rcvd: 91
Setting up for XMPP federation

This section describes how to configure the Stretto XMPP server to federate with other
XMPP servers.
To federate with other XMPP servers:

l Set up a server SRV record in your DNS server so that other systems can locate
your Stretto XMPP server via DNS.
l Set up the other XMPP server to federate with your Stretto XMPP server. Some
XMPP servers might require explicitly configuring the domain of your Stretto XMPP
server.

l Make sure that the remote certificate is publicly signed and can be validated.
l Configure a permission of the XMPP domain in Stretto for accessing external
servers. This is done by setting a group attribute xmpp:domain:filter on Stretto. See
below.
An XMPP domain is represented by a group in Stretto. Stretto groups by default have a

permission of ALL, which means users can contact external domains and other internal
domains.
This can be changed by defining a group attribute within Stretto, xmpp:domain:filter, with
one of the following values:
l ALL (default) - allows users to communicate with anybody on any other domain,
including external servers.
l LOCAL - allows users to communicate with all users on the same installation on any
domain. It only blocks communication with external servers.
l OWN - allows users to communicate with all other users on the same domain. Plus it
allows users to communicate with sub domains such as muc.domain,
pubsub.domain, etc.
l BLOCK - completely blocks communication for the domain or for the user with
anybody else. This could be used as a means to temporarily disable accounts or
domains.
l List of domains - if it is not one of the above, it is assumed to be a comma-separated
list of allowed domains with which users on the domain can communicate.
To configure xmpp:domain:filter:
1. In Stretto Admin, create an attribute xmpp:domain:filter and set its value at the
group level.
2. Click Save.

Configuring XMPP attributes

This topic provides an overview of XMPP attributes that help you determine what values
to configure for each attribute. After deciding on values to set to each attribute, follow the
step-by-step instruction to create XMPP users.
Decide whether to use LDAP
You can store data locally in Stretto, or configure Stretto to use your LDAP server for
authenticating XMPP users, building rosters, and supplying vCards and photos. Stretto
supports load balancing and failover on multiple LDAP servers as well as a feature to
bypass login when no LDAP servers are available.
If you already have users in Stretto and use LDAP to authenticate users for provisioning,
you must use LDAP to authenticate users for the XMPP service.
XMPP Username and Password
During a setup of an XMPP server on Stretto, you instruct Stretto to create XMPP users
(jids) and rosters. You can configure Stretto what data to use as jid or display name by
assigning a value to an attribute using Stretto Admin or Stretto API. Stretto creates XMPP
users based on the values you assign to the attributes.
There are several approaches to setting a value to the XMPP attributes.
Most of the XMPP data you need to provide Stretto with is user-specific; therefore the
simplest way is to assign a value (real data) at the user level when creating a user on
Stretto. This can be done either by manually entering information for each user, or by
uploading a .csv file that includes information on all users. The other way is to assign an
existing attribute at the group level. It is possible to assign an attribute to an attribute - this
is called a nested attribute. This way makes sense when Stretto already has information
that the administrator wants to use as, for example, XMPP username or password.
Two examples at the bottom can help you decide values for the XMPP attributes and
values. If you are provisioning an XMPP account to end users using the Provisioning
Module, it is a good idea to plan ahead what attributes you will be provisioning.
Where to
Set Value
Creating an XMPP account for Stretto users

Where to
Set Value
xmpp:username A user name portion of the XMPP jid. At the group

Mandatory because Stretto has no default value. The administrator must or user level
create the attribute {{xmpp:username}} and assign a real value at
the user level (such as kperera) or assign a nested attribute at group
level. Stretto creates XMPP jids using the assigned username and the
XMPP domain name.
You can instruct Stretto to use the provisioning username for XMPP
usernames by assigning {{ccs:userName.User}}. Stretto creates
XMPP users by using the username portion of the provisioning username.
If using LDAP, make sure whatever you are going to set to
{{xmpp:username}} matches the LDAP username. For example, in
order to enter {{xmpp:username}}=
{{ccs:userName.User}}, Stretto provisioning username must
match the LDAP username.
Important: Make sure that the nested attribute can be resolved to a real
value such as kperera. XMPP users are not created if Stretto fails to
determine a real value of {{xmpp:username}}.
xmpp:password A password used for the XMPP service. The administrator must create the Empty or at
attribute {{xmpp:password}}. As for what value to assign, there are the group
three options: level
l Option 1: Let Stretto create a random password for each user, or
l Option 2: Assign a value to be used as a password (for example,

use the same value as the SIP password), or
l Option 3: Use LDAP to authenticate XMPP users.
For Option 1, leave it empty, in other words, assign no value to the attribute.
You see the field populated with a random password after Stretto creates
an XMPP user.
For Option 2, assign a nested attribute at the group level such as
xmpp:password ={{sipPassword}}. Make sure
{{sipPassword}} can be resolved to a real value in Stretto.
For Option 3, make sure:
You already configured an LDAP server, particularly
{{std:ldap:bindDN}}, in your group, and
{{xmpp:password}} is empty.
Stretto hands over user authentication to the LDAP server instead of
generating a Stretto password.
xmpp:displayname A display name of the XMPP user. Optional. At the group,

Create one of these attributes if you want to change the default display profile or
or
name used by Stretto, or if you want to provision a display name to the user level
xmpp:ldap:displayname XMPP users. By default, Stretto uses the value for
{{xmpp:username}} as a display name of the XMPP user.

Where to
Set Value
You can assign a real value at user level (such as Kokila Perera) or
map a nested attribute at the group level, e.g., xmpp:displayname
={{sipDisplayName}}. Make sure {{sipDisplayName}}
can be resolved to a real value in Stretto.
Setting an admin account to access LDAP entries
std:ldap:adminDN The admin account on the LDAP server that has a permission to access all At the group
the entries you want to pull into Stretto for a roster and/or vCards. or profile
level.
std:ldap:adminPW The password for the admin account above. At the group
or profile
level.
Creating a roster using LDAP

Make sure that std:ldap:server has been configured for the group.
xmpp:roster:ldap:baseDN The DN of an entry in the LDAP directory tree to start the search for users A value must
to be included in a roster. Must be a full DN. The entire subtree under the exist at the
base DN is used for searching. group level,
For example, dc=acphone, dc=local. then can be
overwritten
at the profile
level.
xmpp:roster:ldap:groupDN The DN of a Group entry in the LDAP directory tree (objectClass=group). A value must
This group should list all users you want to be included in a roster. If your exist at the
users are organized under multiple nodes and there is no group in your group level,
LDAP server that holds all users in one place, you need to create a group then can be
with users linked as members. By default, Stretto fetches users from this overwritten
LDAP group, and filters to only show softphone users with XMPP enabled. at the profile
To change which users to include in a roster, see level.
xmpp:ldap:dbcheck and xmpp:ldap:roster:check1.
xmpp:roster:ldap:jid Specify an LDAP field to be used as a username portion of an XMPP jid in A value must
Stretto. For example, uid. exist at the
Stretto uses this value stored in this LDAP field when filtering users for a group level,
roster as well as creating a new Stretto user (based on the then can be
overwritten
xmpp:create:stretto:user attribute).
at the profile
level.
xmpp:ldap:department Specify an LDAP field that stores the department information of the users. At the group
Stretto uses this LDAP field to group users into multiple rosters. If this or profile
attribute is empty, the users are displayed under one roster. level.
xmpp:ldap:rostergroupname Create this attribute only when you want to change the default roster name At the group
displayed on the softphone. Valid when all users are displayed under one or profile
roster (in other words, when xmpp:ldap:department is empty). level.

Where to
Set Value
xmpp:ldap:dbcheck This setting controls what users to include in the roster. At the group
When true (default), the roster is filtered to only include Stretto users who level.
have XMPP account enabled. The value of
{{xmpp:roster:ldap:jid}} is used for the check against Stretto
database. This is suitable for an organization where all users use the
softphone client for XMPP. The roster does not show a user who is on the
LDAP server but has no access to softphone, for example, a contractor.
When false, Stretto includes all users returned from the LDAP server
regardless of whether or not the user has XMPP enabled. Setting it to false
may be beneficial to an organization where only a small portion of users
have access to a softphone client. It allows the admin to provide a contact
list of all people in the LDAP, which increases productivity of the select
softphone users. You might also want to set xmpp.audit.timer to
keep the roster synched with the LDAP server.
xmpp:ldap:roster:check1 Create this attribute when you want to apply a condition/rule for retrieving At the group
users from LDAP depending on whether a certain LDAP field is populated. or profile
For example, you can set to retrieve users who have a telephone number level.
stored in LDAP, instead of importing all users with or without phone
number. In this case, enter telephoneNumber if that is the LDAP field where
a phone number is stored.
Valid only when xmpp:ldap:dbcheck is set to false.
xmpp:ldap:roster:check2 This attribute works with the xmpp:ldap:roster:check1 attribute At the group
above, to add an OR condition to the first LDAP field. or profile
level.
For example, you can set a rule to retrieve users who have a value in either
the telephoneNumber field or the mobile field. To do this, you set
check1=telephoneNumber, and check2=mobile.
xmpp.audit.timer Create this attribute if you set xmpp:ldap:dbcheck to false and want At the group
to keep the roster synched with the LDAP server. level
This attribute allows you to set the interval to check the LDAP server for
auto-imported users. Value in seconds, Stretto deletes the auto-imported
users when they are removed from the LDAP server by checking the roster
in this interval. The default value is 0 (does not check the LDAP server to
sync the roster).
xmpp:create:stretto:user Create this attribute and set to true when you want to use LDAP to supply At the group
vCard information of non-Stretto users. When set to true, this attribute or profile
instructs Stretto to automate the required processing of auto-importing level.
Stretto users.
Supplying vCard using LDAP

Make sure that std:ldap:server has been configured for the group.
xmpp:vcard:ldap:baseDN The distinguished name (DN) of an entry in the LDAP directory tree to start At the group

Where to
Set Value
the search for users to supply vCard with. Must be a full DN. The entire or profile
subtree under the base DN is used for searching. level.
For example, dc=acphone, dc=local
xmpp:vcard:ldap:filter This is the LDAP filter for retrieving the vCard. At the group
Create a filter that restricts the retrieval from the LDAP to the one user. To or profile
do so, create a filter that maps the user ID as known on the LDAP server level.
(for example, "uid") to the username portion of the Stretto XMPP jid.
uid={{xmpp:jidUser}}
(Note that xmpp:jidUser is an internal data element; you do not have
to define it.)
xmpp:vcard:useLdap Controls whether LDAP is used to retrieve the vCard. Set to true to At the group
enable. Also make sure that a vCard template has been set up with the or profile
following attributes embedded. level.
Nested attributes: Assigning an attribute to an attribute

Typically, the administrator assigns a value to an attribute. They can also assign an
attribute to another attribute. This is called a nested attribute. It is useful when Stretto
already has information that the administrator wants to use as XMPP username or
password.
One of the examples is when the administrator already has a list of XMPP usernames
that are configured as {{account2.username}} in Stretto. Configure at the group level as
xmpp:username = {{account2.username}}. Stretto creates XMPP jids using the values
assigned to {{account2.username}}.
Another example is that the administrator wants to use the same display name for the SIP
and XMPP accounts, and they already have populated values to
{{account1.credentials.displayName}}. In this case, the administrator configures as
xmpp:displayname = {{account1.credentials.displayName}}. Stretto creates XMPP display
names using the values assigned to {{account1.credentials.displayName}}.
Make sure that the nested attributes — {{account2.username}} and

{{account1.credentials.displayName}} in the above examples — can be resolved to a real
value such as kperera. XMPP users are not be created if Stretto fails to determine a real
value of {{xmpp:username}}.

Example 1: Creating users from scratch without provisioning

This example assumes that the administrator is starting a new group only for the XMPP
service. No provisioning involved; end users create an XMPP account manually on the
softphone client.
XMPP User Data:
l XMPP domain - the Stretto group name is acphone.com that becomes their XMPP
domain.
l xmpp:username - The administrator has a list of XMPP usernames.
l xmpp:password - The administrator wants Stretto to create a random password for
each XMPP user.
l xmpp:displayname - The administrator wants to use the default, which is the same
value as xmpp:username.
Configuring Attributes:
l xmpp:username = import the XMPP usernames to Stretto and assign at user level
l xmpp:password = leave it empty to instruct Stretto to create random password.
l xmpp:displayname = leave it empty to instruct Stretto to use the default.
Creating Users
Synchronize Stretto users with XMPP. Stretto creates XMPP users. The resulting values
for kperera:
Item Value Description
Provisioning username [email protected] This is the value the administrator assigned to the provisioning
username, which is a separate field from xmpp:username.
xmpp:username kperera This is the value the administrator assigned to the

xmpp:username attribute.
xmpp:password 7X39PSG7S88F Created by Stretto.
XMPP jid (in database) [email protected] The Stretto group name has been appended to
xmpp:username.
XMPP display name kperera Copied by Stretto from xmpp:username.

Providing End Users with XMPP Credentials:
Set up as follows using Email notification feature:
Hello {{ccs:userName}},
Your XMPP account has been created. Please create an XMPP account on Bria
with the following information:
XMPP username: {{xmpp:username}}
XMPP domain: {{ccs:xmppdomain}}
XMPP password: {{xmpp:password}}
Kokila receives an email as shown below:
Hello [email protected],
Your XMPP account has been created. Please create an XMPP account on Bria
with the following information:
XMPP username: kperera
XMPP domain: acphone.com
XMPP password: 7X39PSG7S88F
Example 2: Adding XMPP to existing users with provisioning

This example assumes the administrator already has users in Stretto with a SIP account
configured. The administrator wants to add the XMPP service to those users and
provision an XMPP account along with the existing SIP account.
XMPP User Data:
l XMPP domain - The Stretto group name is, in this example, acphone.com becomes
the XMPP domain name.
l xmpp:username - use the same value as Stretto login user name, which can be
configured using {{ccs:userName.User}}.
l xmpp:password - use the same value as Stretto login password: {{ccs:password}}.
l xmpp:displayname - use the same value as the display name of the SIP account,
which is {{account1.credentials.displayName}} in Stretto.

Configuring Attributes
l xmpp:username = {{ccs:userName.User}} at group level

l xmpp:password = {{ccs:password}} at group level
l xmpp:displayname = {{account1.credentials.displayName}} at group level
Provisioning Clients
Use {{ccs:userName.User}} instead of {{ccs:userName}} to provision an XMPP username

to the softphone clients. The softphone clients do not accept an XMPP username with a
domain included. {{ccs:userName}} contains both username and domain portion of the
provisioning username while {{ccs:userName.User}} extracts only the username portion.
The following example is a mobile client template.
<account protocol="xmpp">
<data name="accountName" value="Stretto XMPP"/>
<data name="display" value="{{account1.credentials.displayName}}"/>
<data name="domain" value="{{ccs:xmppdomain}}"/>
<data name="password" value="{{ccs:password}}"/>
<data name="username" value="{{ccs:userName.User}}"/>
</account>
Creating XMPP users

XMPP use depends on access to the Stretto XMPP module. If you do not already have
XMPP functionality, please contact CounterPath an Alianza Company to find out how to
add it.
XMPP user configuration steps

Add your users to the Stretto Platform if you have not already done so. Stretto then
creates XMPP users based on the information provided in the XMPP attributes, as
described in Configuring XMPP attributes. After XMPP users are created, test the
provisioning and provide your end users with the generated XMPP credentials either by
provisioning or using the Stretto Email notification feature.

To create XMPP users in Stretto
1. Log into Stretto Admin.

2. If you do not already have users in Stretto, create a group that you want to enable
XMPP for.
l Create one group per XMPP domain. By default, Stretto uses the group name
as an XMPP domain. You can assign a different name as an XMPP domain
(as explained below). Both Stretto group names and XMPP domain names
must be unique in Stretto.
l If you determine that you need more than one group, creating a top-level
group is recommended so you can implement inheritance of attributes.
3. Contact CounterPath and request that your group be set up with the feature.
4. By default, your Stretto group name becomes your XMPP domain. To change the
XMPP domain name, go to the Group screen and click the Messaging options tab,
and assign a value under XMPP Domain.
5. On the Group screen, create the attributes: xmpp:usernameand xmpp:password are
mandatory.
6. Assign a value to attributes that you have identified as group-attributes at

Configuring XMPP attributes. You will add a value to user-attributes later when
creating a user.
7. Create a profile if you do not have one yet. The profile can be empty; a profile is
required to create users in Stretto.
8. Create users if you do not have them yet and assign a value to the attributes that
you have identified as user-attributes. The following fields are mandatory in order
for Stretto to create XMPP users:
l Provisioning Username
l Profile
l xmpp:username (assign a value either at group level or user level)

If you have many users to add/change, you can upload a .csv file with all users
information; it allows you to create multiple users and assign a value to user-
attributes at the same time in one batch.
9. Make sure that the xmpp:username attribute can be resolved to a real value within
Stretto. XMPP users are not be created if Stretto fails to determine the value.
You map xmpp:username = {{account2.xmpp.username}}, but

{{account2.xmpp.username}} has no value or the attribute itself does not
exist in Stretto. Stretto does not create XMPP users.
10. On the Group screen, click the Messaging Options tab and click Synchronize
Users.
Skip this step if you are manually creating a user one by one; Stretto syncs
automatically when you save each user's information.
Stretto creates XMPP users based on your configuration. Check the message area at the
bottom; Stretto Admin shows how many users have been added. The Total members
section shows the list of XMPP users created by Stretto.

Optional XMPP features

Optional features for XMPP include:
l XMPP rosters - see This section describes how to configure rosters manually. If you
are using LDAP to build rosters, see Configuring XMPP rosters using LDAP. or
Configuring XMPP rosters using LDAP.
l vCards - see Configuring vCards for XMPP buddies
l Avatar photos - see Uploading an avatar photo for XMPP users
Test the XMPP setup

Stretto has a tool to test the provisioning response. If you use a nested attribute, we
recommend that you use this testing feature to make sure that the provisioning response
contains the correct data. For details on the testing feature, see Testing your provisioning
setup.
Testing on the softphone client.
Log in from the softphone client using the generated credentials.
To test XMPP setup
1. Go to a softphone client, create an XMPP account, and connect to the XMPP

service.
2. Check the rosters and vCards (if you set it up).
3. Try sending messages.
If you can see rosters, vCards, and send messages, XMPP is set up properly.
Provide users with XMPP login credentials

You can provision the XMPP configurations to the softphone clients or you can use the
Stretto Email notification feature so end users can manually enter the credentials. The
XMPP-related attributes such as {{xmpp:username}}, {{xmpp:password}}, and
{{xmpp:displayname}} can be used for both provisioning and the email notification feature.
Registering from multiple XMPP clients

When an end user has multiple XMPP clients to register to the Stretto XMPP service, the
XMPP resource ID field must be empty so that Stretto can generate and assign a unique

resource ID.
If you are provisioning XMPP accounts to end users, make sure the resource ID is empty
in the provisioning setup. If you allow end users to create an XMPP account, instruct
them to leave the Resource ID field empty.
Client configuration - XMPP proxy

Make sure to provision an XMPP proxy to the softphone clients. The value should be
imp.softphone.com, regardless of your XMPP domain name.
Synchronizing XMPP users
The Synchronize Users button on the Messaging options screen allows you to manually
sync Stretto users with the XMPP service. You do not need to sync manually when you
update user's information one-by-one manually (Stretto syncs in the background when
you save a user's information) or after changing XMPP roster information or avatar
photos. However, for other occasions, you can manually sync Stretto users with the
XMPP service. This includes changes to group configuration and attributes.
What is it for?
Stretto generates internal XMPP user entries and rosters based on the values configured
by the administrator. Updating a value in Stretto Admin results in regenerating XMPP
elements in Stretto, which could have an impact on the network when performed
repeatedly or if a group has many users.
The Synchronize Users button allows the administrator to instruct Stretto to regenerate
XMPP elements when the administrator finishes all the updates to Stretto Admin. This
minimizes impacts on network.
When to perform sync

Sync must be performed manually when one of the fields is changed by one of the
following methods.
Fields
l Stretto group name, or XMPP domain

l xmpp:username

l xmpp:password
l Nested attributes, which are assigned to the above attributes. For example, if you
set up as xmpp:username = {{account2xmpp.username}} and change value A to B for
{{account2xmpp.username}}, you must sync manually.
Methods
l By changing a value at the group or profile level

l By uploading a file (both group and user level)
l Paint feature which allows the administrator to make change to select users. This
applies to only nested attributes; if you change a value for xmpp:username using the
Paint feature, Stretto will sync automatically.
Configuring XMPP rosters

This section describes how to configure rosters manually. If you are using LDAP to build
rosters, see Configuring XMPP rosters using LDAP.
A roster is an XMPP contact list stored on the server. In Stretto, a roster is a list of users
with which members of a group can communicate with each other via 1:1 messages, chat
rooms, presence, and using vCard information (if vCard is configured). Rosters are
created and maintained in Stretto and provisioned to the Bria client.
Note: The recommended roster size for each user is 500 users. The roster size has impacts
on the presence traffic on the network. Contact CounterPath if you want to exceed this
capacity.
The simplest approach for a roster is to put all users in one roster. This approach works
when you have 500 users or fewer. If you have a larger user base, consider dividing
users into multiple rosters. You can also:
l group users under departments within the roster. For example, the image on the left
below shows a flat list of users while the image in the middle shows Chad under a
separate group called AC Phone HR. More details can be found under Grouping.
l add non-Stretto users to the roster either at group level (called Common Contacts)
or at user level. A common contact appears in the roster without presence
information. See the image on the right below for an example.

Creating a roster and assign all users

If your group has 500 users or fewer, create one roster in your group, then assign all
users to the roster.
To create an XMPP roster
1. Click the Messaging options tab on the Group screen.

3. Under Group Rosters in the XMPP Options section, enter a Roster Name and a
Roster Display Name.
The Roster Name appears in Stretto Admin and is only seen by the administrators.
The Roster Display Name is seen by end users on the softphone clients.
4. Click Save under Group:.
The XMPP roster is created.
Once the roster is created in the group, you need to assign users to it. A roster can be
assigned to a user at profile level or user level.
Note: We recommend avoiding complex configurations such as setting rosters in both profile
and user level.
To assign a roster at the profile level
1. On the Profile screen, click Edit.

2. Select a roster in XMPP Roster.

3. Click Save.
The users with the profile have been assigned to this roster. Repeat the steps for all
profiles being used by your users.
To assign a roster at the user level using Stretto Admin
1. On the User screen, select a user, click Edit under Details for user:. Optionally,
use Attribute Paint to assign multiple users to the same roster.
2. Select a roster in XMPP Roster.
Leave the Additional Rosters field empty; this is usually used only for Supervisor
Mode.
3. Click Save in Details for user:.
The users are assigned to the roster.
To assign a roster at the user level by uploading a .csv file

Users can be added to Stretto by uploading a .csv file. To add a roster when you are
creating the users, use the ccs:roster column to specify the Roster Name for each user.

To see if a roster has been configured with the users, go to the Messaging options tab >
Group Rosters, and click Members for the roster you want to check. The pop-up appears
listing all members assigned with the roster. If not updated correctly, click Rebuild
roster beside the roster, and click Members again.
Grouping
On the softphone clients, you might want to organize users under groups, such as Sales
and HR, instead of displaying a single flat list of users. You can do this within a roster by
using the xmpp:department grouping feature.
Tip: Remember that end users can choose to show or hide groups in the client. If displaying
groups on the Roster tab is important for your organization, make sure to let your end users
know to show groups for their Roster tab. (Desktop: Contacts > Show Groups, iOS:
Preferences > Show Groups, Android: an icon on the Roster tab)
To display users under departments within a roster
1. On the Group screen, create an attribute xmpp:department if it does not exist yet.
2. Create an attribute for each group; for example, department:group1,
department:group2, department:group3. In the Value field, enter the group name of
your choice. Create as many attributes as you want for a roster.
3. On the Users screen, locate the xmpp:department attribute, and assign the group to
which the user should belong, for example department:group2 for a HR team
member.

Tip: Using a nested attribute makes it easy to change the group name in the future (for
example from HR to Talent Management); you change the value of department:group2
once at group level, as opposed to going through all users.
To test grouping, log out a softphone client and log back in. Or use the Stretto Admin web
interface and click the Members icon under Group Rosters section of the Messaging
options tab.
The same look and feel can be achieved by creating multiple rosters and assigning a user
to multiple rosters; however assigning a user to multiple rosters is more complex, and it
creates duplicate entries among rosters. This method is usually only used for Supervisor
Mode where not all users exchange presence with each other.
Example - how to calculate a roster size for a user who is assigned with multiple
rosters
Let's say you created 3 rosters: A with 400 users, B with 100, and C with 100.
l User X belongs to only Roster A. The roster size for User X is 400.
l User Y belongs to Roster A and B. The roster size for User Y is 500 (400+100=500),
which is a recommended maximum size.

l User Z belongs to all three, and their roster size exceeds the limit of 500
(400+100+100=600).
Supervisor Mode
Supervisor Mode is useful in a call center situation where supervisors need to know that
presence status of all the agents and supervisors but agents only need to know the
presence status of supervisors.
Create a separate roster that is only used in Supervisor Mode. One roster is used for both
supervisors and agents. Then assign the Supervisor Mode roster to users at the user
level in Additional Rosters. This roster should not be assigned as the main XMPP
Roster for any users.
Use the presence states Show Presence and Disable Presence when setting up the
additional roster.
To create an XMPP roster

3. Under Group Rosters in the XMPP Options section, enter a Roster Name and a
Roster Display Name.
The Roster Name appears in Stretto Admin and is only seen by the administrators.
The Roster Display Name is seen by end users on the softphone clients.
The XMPP roster is created.
To assign a Supervisor Mode roster to users
1. On the User screen, select a user, click Edit under Details for user:. Optionally,
use Attribute Paint to assign multiple users to the same additional roster and the
same presence state.

2. Select the roster being used for Supervisor Mode in Additional Rosters.
3. Select a presence state.
Presence states
Regardless of this setting, users can message each other and see the vCard of a
member as long as vCard is configured. This option controls with whom the
member shares their presence information.
l None: this user's presence is shared with everyone in the roster. Do not select
this state for Supervisor Mode. Very few occasions use this state because it
creates duplicate entries among rosters, which could negatively affect system
performance.
l Show Presence: this user's presence is shared with everyone in the roster. In
a call center, you could use this for supervisors.
l Disable Presence: this user's presence is shared only with the users with
"Show Presence". In a call center, you could use this for agents where agents
see the presence of Supervisors, but not the presence of other agents.
4. Click Save in Details for user:.
Supervisors and agents are added to the additional roster. Supervisors see the presence
state of all members of the additional roster. Agents see all members of the additional
roster but only see the presence of supervisors.
To assign a Supervisor Mode roster by uploading a .csv file

Users can be added to Stretto by uploading a .csv file. If you want to add rosters and
additional rosters, including a roster for Supervisor Mode, when you are creating the

users, use the following internal data elements.
Internal Data Elements
Name Description
ccs:roster Use this element for assigning the main roster to a user. Enter the Roster Name.
ccs:rosterextra Use this element for assigning additional rosters to a user. You can add multiple additional rosters by separating
rosters with | (pipe). The Presence state is represented by the following:
l #0 or blank: None
l #1: Show Presence (supervisor)
l #2: Disable Presence (agent)
Use the following format:

Roster NamePresence state |Roster NamePresence state |
Example:
To assign the sales and callCenter rosters, sales with a Presence state of None and callCenter with a
Presence state of Disable Presence:
sales#0 |callCenter#2 |
Common Contacts
You can add non-Stretto users to a roster. For example, you could add external
contractors, business partners your team calls often, or the group's favorite takeout
places for easy access. Roster members can make a phone call to Common Contacts,
but cannot exchange 1:1 or chat room messages, or share presence information.
Common Contacts appear in the roster on Bria softphone clients with vCard information
as long as vCard is configured.
A JID is required for each Common Contact in order for it to display in Bria.
Requirements for a JID used for Common Contacts

As the Common Contacts do not display presence, you do not need to enter a real JID.
However, the username portion of the JID must be unique in the Stretto group, and the
JID domain name must match the XMPP domain name.

l If you try to create a Common Contact but the username is already taken by an
XMPP user, Stretto displays a warning that the user already exists as an
XMPP user. You must enter a different username.
Note: For the other way around, which means if you try to create an XMPP user but the
username is already taken by a Common Contact, Stretto converts the existing
Common Contact to the new XMPP user. In other words, the existing Common Contact
will be deleted rather than appearing twice.
l If you enter a JID with an external domain when creating a Common Contact,
Stretto removes the external domain and replaces it with the group XMPP domain
name.
Common Contacts can be added individually or by uploading a .csv file. Stretto supports
up to 500 common contacts per group.
To add Common Contacts individually

3. Under Group Rosters, locate the roster to add the Common Contacts to and click
Common Contacts.
4. Type in the contact information for each Common Contact. The information entered
in these fields populates the vCard. XMPP JID is required and each Common
Contact should have at least one phone number.
Common Contacts fields

l XMPP JID
l Name
l E-mail
l Extension
l Work
l Mobile
l Website
l Department

5. Optionally, click Upload XMPP Avatar Image.

6. Click Close on the Common Contacts dialog.
The Common Contacts are added to the roster. The Common Contacts appear under the
group you entered in the Department field. If you left Department blank for a Common
Contact, they appear under the roster to which they were added.
To upload Common Contacts by .csv

2. Under Group Rosters, locate the roster to add the Common Contacts to and click
Upload Common Contacts csv. The Upload dialog open.
3. Choose the .csv file that contains the Common Contacts in the correct format.
Formatting your .csv file

l One complete user record per row
l Values that contain a comma must be enclosed
l XMPP JID is a required field for each user record
l Each user record should contain at least one phone number
l Follow the structure: XMPP JID, Name, E-mail, Extension, Work, Mobile,
Website, Department
The Common Contacts appear under the group you enter in the Department
field. If you leave Department blank, they appear under the roster to which
they were added.
Example:
[email protected],Kokila
Perera,[email protected],12,6045555555,6045551234,myurl.com,Contractor
4. Select or clear Override, if it exists.

Selected: If a Common Contact with a matching External JID is found in the file,
contact details are replaced with the values in your file.

Cleared: If a Common Contact with a matching External JID is found in the file,
contact details are not replaced with the values in your file. If a field does not have a
value, it is updated with the value from your file.
5. Click Submit.
6. Click Close.
The Common Contacts are added to the roster.
Adding external JIDs to users

You can add the JIDs of non-Stretto users to specific Stretto users as buddies. The buddy
can be on different XMPP domains as long as federation has been configured for the
Stretto group. For example, you could add external contractors to the corporate roster or
add an IT/support account to offer chat service to the employees.
When you add a buddy to a specific user, the buddy is not persistent. If an end users
deletes the buddy in Bria, the buddy is removed from Stretto Admin and from Bria.
To add a buddy to a specific user

3. Under XMPP Users, select a user to add a buddy and click Manage user's
additional non-roster buddies..
4. Type the XMPP JID, XMPP Display Name, and the XMPP Group Name.
The XMPP Display Name is seen by the end user in Bria.
For XMPP Group Name, specify a roster name or names to add to the JID to.
Separate multiple names with a comma.
5. Click Close on Additional Buddies.


The buddy is added for the specific user. Select a user and click Manage user's
additional non-roster buddies. to open Additional Buddies and view buddies added for
the user.
To delete a buddy from a specific user

3. Under XMPP Users, select a user to add a buddy and click Manage user's
additional non-roster buddies.
4. Click Delete beside the buddy you want to delete.
5. Click Close on Additional Buddies.
The buddy is deleted from the specific user.
Note: The Additional Buddies table may list buddies added by the end user via Bria. Be
careful when deleting a buddy – an unfamiliar JID may be the end user's personal contact.
View a roster configured for a specific user
When you have multiple rosters, Common Contacts, Supervisor Mode as well as external
JIDs added to some rosters or users, you might want to view a list of rosters that are
configured for each user.
To view rosters configure for a specific user

2. Click on the user in the Total members section at the bottom of the page.
3. Click View the cached contents of the selected user's roster..

Stretto Admin displays a dialog with the list of buddies configured for the user. The dialog
includes members from the main and additional rosters, common contacts, as well as
external JIDs configured for this user.
How rosters are updated and sent to end users

When an end user logs into Bria, rosters are displayed to the end user. After that, there
are some occasions that Stretto updates the roster and sends it down to end users who
are currently registered with the XMPP service.
Stretto sends the updated roster to users when:

l a new user is added to the roster.
l a user is deleted from the roster.
l a user is moved from the roster to another. This particular user needs to log out and
log back in to see the updates in their client.
l a value is changed for the xmpp:username and xmpp:displayname attributes.
l Additional buddies are added to the roster.
Note: Stretto does not propagate the update to all the clients if vCard information is changed
such as phone number. Stretto sends down the vCard change to the clients later when other
changes happen as described above.
To test rosters, try the following:

l Click Members under Group Rosters to see if they are grouped as intended. Click
Rebuild roster beside the roster if necessary.
l Log out the softphone clients and log back in. Or use Force XMPP Logout under
Total members on the Messaging options tab.
l Click View the cached contents of the selected user's roster. under Total
members.
l If none of the above works, try the following steps.

Note that this operation requires more system resources; use with caution.
1. In the Total members section, select the user to test, and click Rebuild
roster.
2. Click Reset XMPP group cache in the Total members section. This
functionality is group-wide; it deletes cache for all users in this group.
3. Log out the softphone clients and log back in. Or use Force XMPP Logout
under Total members on the Messaging options tab.
Uploading an avatar photo for XMPP users

You can upload an avatar photo of each end user so it appears on the roster on softphone
clients. Supported file types are: jpg, jpeg, and png.
To upload a photo
1. Go to the Users page, and select a user you want to upload a photo for.
2. Click the Upload button in the XMPP Avatar Image field.
Do not click Edit before uploading. The photo upload works only in non-edit
mode.
3. Choose a photo to upload, then click Submit.
4. Click the icon to verify the photo is saved.
A photo is added to the user on the roster. Note that it might take some time until all the
users on the roster see the new avatar photo on their softphone clients.

Configuring XMPP rosters using LDAP

If you deploy the XMPP module with Stretto, an LDAP server can be used to supply a
roster and vCards.
Stretto creates a roster from an LDAP server, and populates users' vCards using the
information stored in the LDAP server. By default:
l a roster only includes Stretto users who have XMPP enabled. You can change this
to import non-Stretto users into a roster from LDAP, or manually add external JIDs
to the LDAP roster. See below for details.
l all users are shown in a single roster. You can change this to split into multiple
groups using the xmpp:ldap:department attribute. Or you keep a single roster, and
change the default roster name using the xmpp:ldap:rostergroupname attribute. See
Configuring XMPP attributes.
Adding external JIDs to an LDAP roster

You can add the JIDs of non-Stretto users to an LDAP roster. The buddy can be on
different XMPP domains as long as federation has been configured for the Stretto group.
Examples would include adding external contractors to the corporate roster or adding an
IT/support account to offer chat service to the employees.
Method 1: Import non-Stretto users from the LDAP server
One way to achieve this is to configure the xmpp:ldap:dbcheck attribute. It allows you to
add non-Stretto users to the LDAP roster. When using this option, you can also supply
vCard information of non-Stretto users using LDAP. Supplying vCards of non-Stretto
users results in automatically creating Stretto users in your group because that is one of
the requirements in order to retrieve information for vCards from LDAP. Stretto deletes
those auto-created users when they are removed from the LDAP server by checking the
roster in an interval set in xmpp.audit.timer.
A variation: You can apply rules/conditions on which LDAP users to fetch depending on
whether certain LDAP fields are populated; for example, you can set a condition to auto
import users who have their phone number in the LDAP's telephoneNumber field, instead
of importing all users with or without phone number.
See Configuring XMPP attributes for more details.

Method 2: Manually add non-Stretto users to the LDAP roster
Another way to add non-Stretto users is to manually add JIDs that are not in your LDAP to
the Stretto rosters. Use the LDAP Buddy button under the Group Rosters section for this
purpose. This button appears only when LDAP is configured to build a roster.
To manually add an external JID in an LDAP-supplied roster
1. In the Group page, choose the Messaging Options tab.

2. Under Group Rosters, locate the roster to add and click LDAP Buddy.
3. Enter a JID and display name and click Save.
The non-Stretto users are added to the roster as LDAP Buddies.
How LDAP rosters are updated

When an end user logs into Bria, rosters are displayed to the end user. After that, Stretto
refreshes the roster in a set interval. End users might experience some delay on the
softphone to see the latest change made in the LDAP server. If that’s the case, it is
recommended that the user logs out of the softphone and logs in again.
Configuring vCards for XMPP buddies

You can configure vCards to use for XMPP buddies. You can configure vCards on Stretto
by adding a vCard template to your group. Typically you add attributes in the vCard
template that are replaced by a real user-specific value when a vCard is loaded to each
user.
To create a vCard using a template
1. Right-click on the group in which you want to create a template, click New
Template and choose New vcard template.
2. Enter a name for the vCard template. The default vCard template is created with
pre-defined attributes.
3. Add or change any of the attributes in the template. Stretto vCard templates follow
the schema specified in RFC 6351. The administrator can use any name for the
attributes in the vCard template if no LDAP is used.
4. Select the profile in which you want to assign the template and click Edit.

5. Click Add.
6. Select vCard as the Discriminator and select the new vCard template as the
Template.
7. Click Save.
8. If LDAP is not being used, go to the Group screen, and create the attributes you
used in the vCard template.
9. Assign values to the attributes. Typically these are user-attributes. If you are using
LDAP, read the section below.
The vCard is configured.
Viewing a vCard loaded for a specific user

Stretto Admin displays the vCard information for a selected user.
To view a vCard for a specific user
2. Select a user.
3. Click XMPP on Details for user:.
The vCard information cached on the Stretto Platform for this user is displayed in the
Client vCard section.

Click Edit, then Delete to delete the cache; a vCard is created next time the Bria client
requests for it.
Using LDAP to supply vCard information

In the vCard template, use these special attributes to extract data from LDAP. Replace
"attribute" with the name of an LDAP field to extract data from.
l xmpp:ldap:att:attribute - for extracting string data. For example, use
xmpp:ldap:att:sn to pull a value in the LDAP sn field.
l xmpp:ldap:batt:attribute - for extracting binary data. For example, use
xmpp:ldap:batt:thumbnailPhoto to pull an avatar photo in the LDAP thumbnailPhoto
field.
You do not need to create these attributes in your Stretto group, or assign values to these
attributes because the values come from the LDAP server.
Tip: You can use the LDAP test tool to verify that your LDAP configuration is correct.
See Test your LDAP configuration.
Example:
vCard template
<N>
<GIVEN>{{xmpp:ldap:att:givenName}}</GIVEN>
<FAMILY>{{xmpp:ldap:att:sn}}</FAMILY>
</N>
<EMAIL>
<INTERNET/>
<USERID>{{xmpp:ldap:att:mail}}</USERID>
</EMAIL>
<FN>{{xmpp:ldap:att:displayName}}</FN>
<ADR>
<HOME/>
</ADR>
<ADR>

<WORK/>
<STREET>{{xmpp:ldap:att:streetAddress}}</STREET>
<LOCALITY>{{xmpp:ldap:att:l}}</LOCALITY>
<REGION>{{xmpp:ldap:att:st}}</REGION>
<PCODE>{{xmpp:ldap:att:postalCode}}</PCODE>
<CTRY>{{xmpp:ldap:att:co}}</CTRY>
</ADR>
<TEL>
<WORK/>
<VOICE/>
<PREF/>
<NUMBER>{{xmpp:ldap:att:ipPhone}}</NUMBER>
</TEL>
<TEL>
<WORK/>
<VOICE/>
<NUMBER>{{xmpp:ldap:att:telephoneNumber}}</NUMBER>
</TEL>
<TEL>
<CELL/>
<NUMBER>{{xmpp:ldap:att:mobile}}</NUMBER>
</TEL>
<TEL>
<WORK/>
<PAGER/>
<NUMBER>{{xmpp:ldap:att:pager}}</NUMBER>
</TEL>
<TEL>
<HOME/>
<VOICE/>
<NUMBER>{{xmpp:ldap:att:homePhone}}</NUMBER>
</TEL>
<TEL>
<WORK/>
<FAX/>
<NUMBER>{{xmpp:ldap:att:facsimileTelephoneNumber}}</NUMBER>
</TEL>

<TITLE>{{xmpp:ldap:att:title}}</TITLE>
<ORG>
<ORGUNIT>{{xmpp:ldap:att:department}}</ORGUNIT>
</ORG>
<URL>{{xmpp:ldap:att:url}}</URL>
<PHOTO>
<TYPE>image/jpeg</TYPE>
<BINVAL>{{xmpp:ldap:batt:thumbnailPhoto}}</BINVAL>
</PHOTO>
</vCard>
Managing XMPP chat rooms

Chat rooms are where multiple users exchange messages. Any participant in a chat room
can see all messages posted by other participants. A chat room can have up to 512
participants.
No configuration is needed by the administrators to start using chat rooms. End users
with the Bria clients can create and join a chat room as long as the following requirements
are met:
l You have configured the XMPP feature in your Stretto group and your end users
have an XMPP account enabled.
l The version of the Bria desktop clients must be 5.5.0 or higher.
l The version of the Bria mobile clients must be 5.5.3 or higher.
l Chat rooms belong to a Stretto group; end users need to be in the same Stretto
group to use the XMPP chat rooms.
Using Stretto Admin, the administrators can:

l View statistics on all or each chat room such as a number of messages and
participants.
l Delete a chat room.
l Save chat room information for backup - Archive a chat room.
l Restore the archived chat room - Reload chat rooms.

Do not modify chat room configurations using Stretto Admin. All changes should be done
by end users using the Bria clients.
Viewing statistics on chat rooms

To view statistics on all chat rooms
1. Go to the Group page, and select the Messaging Options tab.

2. Under the XMPP Chat rooms section, click Chat room statistics.
To view statistics on a specific chat room

2. Under the XMPP Chat rooms section, locate a chat room in the list. You can use
the filter to narrow down the rooms in the list.
3. Click Chat room statistics.
Details on statistics
l Chat rooms count indicates a total number of all chat rooms created in this group.
l Chat room messages count indicates a total number of messages posted in the
chat room(s).
l Total chat room message body size indicates the size of all messages entered by
the participants. Value in bytes.
l Total chat room message size indicates the size of all messages with related meta
data. Value in bytes. It usually shows a bigger number than the body size; the body
size captures just plain messages such as Sure.
l Participants who have posted indicates a total number of participants who have
commented in the chat room(s).
l Room invited participants indicates a number of users who are invited to the chat
room but have not accepted the invitation. To see a list of such participants, click
View room invited participants.
l Room last update time indicates the time stamp of the most recent message
posted in the chat room(s).
l Chat Room participant count (available only for each chat room) indicates a
number of participants who are currently in the chat room.

Deleting a chat room

A chat room is created by an end user using the Bria client. The owner (the user who
created a chat room) can delete a chat room using the Bria client. Follow this instruction if
you, as the administrator, need to delete a chat room on behalf of the owner. You might
want to archive the chat room before deleting in case you need to restore the information
later.
To delete a chat room using Stretto Admin

4. Click Remove chat room.
5. Click Save at the top of the page.
Archiving a chat room (creating a backup)

Chat room information can be downloaded on a computer in the XML format. The
archived XML file includes the message history. This file can also be used to restore the
deleted chat room.
To save chat room information on a computer

3. Click Archive chat room.
The browser downloads the XML file.
4. Delete the chat room if desired.
Restoring an archived chat room

If you have saved a backup for a chat room using the Archive chat room button, you can
restore the chat room by uploading the file.

To restore an archived chat room

2. Under the XMPP Chat rooms section, click Reload chat rooms.
3. Upload the XML file that you saved onto your computer using the Archive chat
room button.
The chat room shows up under the XMPP Chat rooms section.
Broadcasting messages to XMPP users

An administrator can send messages to XMPP users in their Stretto group – this could be
useful for notifying users of service interruptions. A message can be broadcast to all
XMPP users or to XMPP users in a specific group roster.
Sending a message to all users in a group

Messages are sent to all XMPP users who are currently logged in — offline users or users
who are not registered to the XMPP account don’t receive the broadcast message.
To send a message to all users

2. In Total members, click IM Broadcast.
3. Compose your message and click Send.
Stretto sends the message to all XMPP users in the group that are logged in.
Sending messages to a group roster

A group roster is a subset of XMPP users in your group. By sending a message to a group
roster, you can target a message to specific types of users rather than the entire user list.

A broadcast to a group roster is sent to all XMPP users who are currently logged in —
offline users or users who are not registered to the XMPP account don’t receive the
broadcast message.
To learn how to set up rosters, see This section describes how to configure rosters
manually. If you are using LDAP to build rosters, see Configuring XMPP rosters using
LDAP..
To send a message to a group roster

2. In Group Rosters click IM Broadcast beside the roster you want to send a
message to.
3. Compose your message and click Send.
Stretto sends the message to all XMPP users in the group roster that are logged in.
Viewing XMPP information on users

This topic covers various items the administrators can view about users on Stretto Admin.
Viewing online status of XMPP users

You can see a list of XMPP users who are active. Or you can use Stretto Admin to display
the Online Status of all XMPP users in the group.
To view which users are active

2. Scroll down to the Total members section.
3. Click the Get Active XMPP Users button.
The pop-up opens listing all the active users in the group.

To view online status for all XMPP users

3. Click the View Presence button.
The Online Status column gets updated with the current presence of the users. When
users are displayed in multiple pages in the table, this button updates the current page
only.
Viewing connection information

Stretto Admin displays the connection information for a specific user. The connection
information includes: IP address and port used by a specific user, a number of packets,
Resource ID, priority, authorization status, Presence, and Last accessed time and more.
You can only get the information on a user who is online. When a user is online on
multiple devices, this functionality shows connection information on all the devices of the
user.
To view connection information for a specific user

3. Select a user who is online, and click the View Connection Information button.
The State: pop-up appears.
Viewing rosters configured

When you have many rosters, common contacts, and external JIDs, you might want to
make sure each user gets everything as intended. You may also want to view rosters
configured when you need to troubleshoot for a user on their roster. Stretto Admin
displays the roster information for a specific user.

To view a list of rosters and additional JIDs for a specific user

3. Select a user, and click View the cached roster .
A XMPP Roster test result pop-up appears with the roster information for this user.
Viewing vCard information

Stretto Admin displays the vCard information for a specific user.
To view a vCard for a specific user
2. Select a user.
3. Click XMPP on Details for user:.
The vCard information cached on the Stretto Platform for this user is displayed in the
Client vCard section.
Click Edit, then Delete to delete the cache; a vCard is created next time the Bria client
requests for it.
Viewing chat room information

Stretto Admin displays the following information on a specific user:
l Chat rooms created by the user
l Chat rooms the user was invited to
l Chat rooms the user has posted to

To view the Chat room information for each user, either go to Users > XMPP, or go to
Group > Messaging Options and scroll down to the Total members section.
To view chat room information for a specific user

XMPP Chat rooms displays a list of chat rooms configured in Stretto.
2. Click the user you want to view chat room information for in Total members.
3. Click one of the following options:
l View rooms created by the user.
l View rooms the user has been invited to.
l View rooms the user has posted to.
l View the bookmarks of user - It displays data sent by the Bria clients to the
XMPP server for syncing devices. The data might help troubleshooting sync
issues.
Stretto displays the information for the user.
Setting up Stretto Sync

The Stretto Sync feature allows end users to synchronize message history of their XMPP
accounts across all devices using the same Stretto account. With Stretto Sync, when a
user enables their XMPP account on multiple devices, the user sees consistent history of
both sent and received messages on all the devices. For example, a user can start a chat
on a Windows computer, and continue the chat on an iPhone without losing previous
messages.
Note: The Stretto Sync feature synchronizes a message history of one-to-one chats. It does
not support synchronization of SIP SIMPLE/SMS messages, or XMPP chat rooms. It does not
synchronize the files exchanged via File Transfer either.
How it works
When the Stretto Sync feature is enabled, Stretto has the ability to store message history
per Stretto user.

l The user logs into Stretto as usual.

l When Stretto Sync is enabled for the user's XMPP account, Bria performs the
following:
l Deletes previous messages saved locally on the user's device and replaces
with the synchronized message history.
l Posts messages to Stretto when it sends and receives a message on the
XMPP account.
l Stretto creates a sync account for the user's XMPP account and stores the
messages uploaded by Bria.
l When the user logs into Stretto from a second device, the messages stored on
Stretto are downloaded/synchronized to Bria on the second device. Bria does not
download all messages at once but in small increments as the user scrolls down the
list or tries to show older messages.
l When an incoming message arrives while the user is on multiple devices, all the
enabled devices receive the incoming message.
l When the user deletes a message from the history on one device, it deletes from
Stretto as well as all the other devices.
l If Stretto is not available for sync, Bria retries after a certain interval.
Supported clients
You need to include the Stretto Sync feature in your branded Bria clients.
The supported versions are:

l Bria desktop 4.2.0 or newer
l Bria mobile 3.4.1 or newer
Setting up for Stretto Sync

Enable Stretto Sync by creating and setting attributes and modifying the provisioning
templates.

To set up for Stretto Sync
level:
account2Xmpp.strettoSyncEnable true or false Enables the feature on a

specific account -
account2 in this example.
When true, the client
checks the end user
preference to determine
whether or not to enable
the feature.
std:sync:url wss://stretto.cloudprovisioning.com:18889 This is the location on

/sync/sock/{{ccs:groupName}} Stretto where the client
/{{ccs:userName}}?uuid={{ccs:req:uuid}} attempts to post message
history.
Up to you. true or false Optional. The end user

For example, preference for enabling
the feature per account.
account2Xmpp.showSyncUserPref
The client has two
separate settings to
enable sync; one is the
admin/provisioning
control, and the other is
the end user control. The
admin control is a higher-
level setting. When the
admin control disables
the feature, the end user
control is completely
ignored.
If you decide to hide the
client GUI from end
users, you might need to
enable the end user
preference via
provisioning.

Desktop template: Make sure you change N to a number to refer to the XMPP
account you want to use message sync with.
feature_options:stretto_sync_available="true"
proxies:proxyN:supports_stretto_sync="{{account2Xmpp.strettoSyncEnable}}"

proxies:proxyN:stretto_sync_url="{{std:sync:url}}"
proxies:proxyN:stretto_sync_password="{{ccs:password}}"
proxies:proxyN:use_stretto_sync="{{account2Xmpp.showSyncUserPref}}"
Mobile template: Find <account> in the template. The template contains multiple
<account> sections if you support multiple SIP/XMPP accounts. Make sure to add
this feature to the XMPP account you want to use message sync with.
<account_list>
<account>
<data name="supportsStrettoSync" value="{{account2Xmpp.strettoSyncEnable}}"/>
<data name="strettoSyncUrl" value="{{std:sync:url}}"/>
<data name="strettoSyncPassword" value="{{ccs:password}}"/>
<data name="useStrettoSync" value="{{account2Xmpp.showSyncUserPref}}"/>
Stretto Sync is enabled for the group.
Deleting a sync account

See Managing synced messages - deleting a sync account on Stretto for more
information.
Viewing Stretto Sync reports

To view Stretto Sync reports and for detailed information on the reports, see Reporting
Stretto Sync activity.
Setting up Call History Sync

The Call History Sync feature allows end users to synchronize call log history of their SIP
accounts across all devices using the same Stretto account. Deleting an entry from Bria's
call log history results in deleting the entry from all the devices.The information on
whether a call was recorded, as well as the audio files of the call recording will not be
synced; the red icon indicating that the call was recorded appears only on the device
used for recording. Other devices still show the call log entry without the red icon or
access to the audio file. Call History Sync can be configured for your Stretto group by
your administrator.

How it works
When the Call History Sync feature is enabled, Stretto has the ability to store call log
history per Stretto user.
l The user logs in as usual.
l When Call History Sync is enabled for the user's SIP accounts, Bria performs the
following:
l Deletes the previous call history saved locally on the user's device and
replaces with the synchronized call log history.
l Posts call logs to Stretto when new call logs are created.
l Stretto creates a sync account for the user's SIP account and stores the call logs
uploaded by Bria.
l When the user logs into Stretto from a second device, the call logs stored on Stretto
are downloaded and synchronized to Bria on the second device. Bria does not
download all call logs at once but in small increments as the user scrolls down the
list or tries to view older call logs.
l When the user receives an incoming call with more than one device running Bria,
Stretto matches the call logs coming from both devices into one record and stores
the record on Stretto.
l When the user deletes call logs from the call history on one device, the call logs are
deleted from Stretto as well as all the other devices.
l If Stretto is not available for sync, Bria retries after a certain interval.
If the Call History Sync feature is disabled after previously being enabled, the history is
removed from Bria but remains on Stretto.
Supported clients
You need to include the Call History Sync in your branded clients. The supported
versions are:
l Bria desktop 6.0 or newer
l Bria mobile 6.0 or newer
Call types that are not synced

The following calls are not synced using Call History Sync:

l Calls that occur on an account that is monitored using BLF or SCA

l Accounts that are synced using BroadWorks XSI
l Accounts that are synced using Ribbon
Setting up for Call History Sync

To set up for Call History Sync
1. Call History Sync uses the Stretto Sync feature. See the section on setting up the
Stretto Sync feature in the Stretto Platform Installation Guide.
2. In Stretto Admin, create the following attributes and set their values:
feature.sync.callhistory.enabled true or false Enables the Call History Sync feature for the
profile or the user.
std:sync:callhistory:url wss://sync1.cloudprovisioning.com This is the location on Stretto where the

/sync/sock/{{ccs:groupName}} client attempts to post call history.
/{{ccs:userName}}?uuid=
{{ccs:req:uuid}}

Desktop template
Add these settings under the [SETTINGS] section in the template.
feature_options:call_history_sync_available:enabled="{{feature.sync.callhistory.enabled}}"
feature:call_history_stretto_sync:enabled="{{feature.sync.callhistory.enabled}}"
feature:call_history_stretto_sync:url="{{std:sync:callhistory:url}}"
feature:call_history_stretto_sync:password="{{ccs:req:password}}"
Mobile template
Add these settings under <core_data_list> in the template.
<core_data_list>
<data name="useCallHistoryStrettoSync" value="{{feature.sync.callhistory.enabled}}"/>
<data name="callHistoryStrettoSyncUrl" value="{{std:sync:callhistory:url}}"/>
<data name="callHistoryStrettoSyncPassword" value="{{ccs:req:password}}"/>
Call History Sync is enabled for the group.

Deleting a sync account

See Managing synced messages - deleting a sync account on Stretto for more
information.
Configuring SMS API integration

Stretto Platform supports integration with SMS API providers such as Twilio and
Bandwidth so that Stretto end users can send and receive SMS messages using a third
party SMS provider.
Requirements for clients

Make sure your branded clients have the following features enabled. If not, order a new
build using CounterPath Branding Portal.
l SMS (Text Messaging)
l Stretto Sync
Authentication
By default, Stretto verifies that the SMS messages came from the matching configured
account of the SMS provider.
For Twilio, this is done by checking the X-Twilio-Signature HTTP header. If your SMS
server does not support the X-Twilio-Signature HTTP header, you need to disable the
authentication by adding ;noauth=true to the SMS connection URL in the attribute
std:strettosync:smsprovider. The X-Twilio-Signature HTTP header is used to verify that
inbound messages are coming from their SMS provider. See
https://www.twilio.com/docs/usage/security#validating-requests for details on this
header.
For Bandwidth, basic authorization is performed over HTTPS.
Setting up for SMS API integration

To set up for SMS message integration:

1. In Stretto Admin, create the following attributes and set a value to the attributes at
the group level.
Attribute Value
account.sms.username This is the username or phone number provided by your SMS API provider. If

the user has logged into Bria from multiple devices using the same SMS
username/phone number, the messages will be synched across the devices.
std:strettosync:smsprovider The value should consist of the SMS provider name and key-value pairs.
For Twilio;
twilio:username=Twilio_account_sid;password=Twilio_token;URL=Twilio_
URL
where:
Twilio_account_sid is the Twilio account SID used to authenticate.
Twilio_token is the password token used to authenticate.
Twilio_URL is the API URL to connect to. For example,
https://api.twilio.com/2010-04-01/Accounts/
[username]/Messages.json. Note that [username] in the
URL will be replaced by the value of Twilio_account_sid.
To disable the authentication of the SMS messages, add ;noauth=true
to the end of the URL, such as https://api.twilio.com/2010-
04-01/Accounts/
[username]/Messages.json;noauth=true
These items can be obtained from your Twilio API/account portal.
For Bandwidth:
bandwidth:accountId=Bandwidth_account_id;applicationId=Bandwidth_
application_id;apiToken=Bandwidth_api_token
;apiSecret=Bandwidth_api_secret;URL=Bandwidth_URL
These items can be obtained from your Bandwidth Portal.
Bandwidth_URL is by default,
https://messaging.bandwidth.com/api/v2/users/
[accountId]/messages. Note that [accountId] in the URL will
be replaced by the value of Bandwidth_account_id.

Desktop template: Make sure you change N to a number to refer to the SMSAPI
account you provision.
feature_options:stretto_sync_available="true"
feature_options:sms_over_sync_protocol_available:enabled="1"
proxies:proxyN:account_name="SMS"
proxies:proxyN:protocol="smsapi"
proxies:proxyN:username="{{account.sms.username}}"

proxies:proxyN:enabled="true"
proxies:proxyN:digit_
map="+xxxxxxxxxxT|xxxxxxxxxxT|1xxxxxxxxxxT;match=1;pre=+1;prestrip=1;match=2;pre=+1;match=3;pr
e=+"
proxies:proxyN:supports_stretto_sync="true"
proxies:proxyN:stretto_sync_options_available="true"
proxies:proxyN:stretto_sync_url="{{std:sync:url}}"
proxies:proxyN:stretto_sync_password="{{ccs:password}}"
proxies:proxyN:use_stretto_sync="true"
Mobile template: Find <account_list> in the template. The template contains

multiple <account> sections if you support multiple SIP/XMPP accounts. Make sure
to add this feature to an SMSAPI account which is a different type than SIP or
XMPP.
Also make sure to enable the SMS feature under <core_data_list>.
<core_data_list>
<data name="messagesSMS" value="true"/>
</core_data_list>
<account_list>
<account protocol="smsapi">
<data name="accountName" value="SMS"/>
<data name="username" value="{{account.sms.username}}"/>
<rule_list>
<rule add="+1" match="xxxxxxxxxx" name="North America" remove=""/>
<rule add="+" match="1xxxxxxxxxx" name="North America2" remove=""/>
<rule add="+1" match="+xxxxxxxxxx" name="North America3" remove="+"/>
</rule_list>
<data name="supportsStrettoSync" value="true"/>
<data name="strettoSyncUrl" value="{{std:sync:url}}"/>
<data name="strettoSyncPassword" value="{{ccs:password}}"/>
<data name="useStrettoSync" value="true"/>
</account>
3. For Twilio, configure the Twilio phone numbers to call into Stretto for incoming SMS
messages. This is done through the Twilio API/account portal, and this URL is
called a webhook URL in the Twilio API/account portal.
The Twilio webhook URL is:
https://stretto.cloudprovisioning.com:18889/sync/sms/twilio/{{ccs:groupName}}
Replace {{ccs:groupName}} with your Stretto group name such as acphone.com

when entering the URL in the Twilio API/account portal.
4. For Bandwidth, configure a callback URL (or webhook) in your Bandwidth Portal.

The Bandwidth webhook URL is:
https://stretto.cloudprovisioning.com:18889/sync/sms/bandwidth/{{ccs:groupName}}
Replace {{ccs:groupName}} with your Stretto group name such as acphone.com

when entering the URL in your Bandwidth Portal.
How Stretto SMS API integration works

Outbound Messaging
When a Bria user sends a message to an SMS chat account, the Stretto Sync server will
issue a POST message to the configured SMS provider.
The message is formatted to match the requirements of the corresponding API.
The message is also stored and forwarded as usual for the Stretto Sync functionality.
Twilio/Bandwidth will call back with changes to message status (accepted, delivered,
error, etc).
Inbound Messaging
When a Twilio or Bandwidth number receives an SMS message, it will invoke the
webhook URL and post a message to Stretto Sync.
Stretto Sync will determine the recipient of the message, add the message to their sync
database, and forward the message to any connected devices.
Managing synced messages - deleting a sync account on

Stretto
The sync account holds the content which are synchronized across all the end user's
devices. Currently Stretto Sync is used for three types: Message sync, Call History Sync,
and SMS API. If all three are configured for a Stretto user, they typically have multiple
Sync accounts. The Stretto admin can differentiate the sync accounts by a prefix of the
sync account name.
l sip: refers to call history on a SIP domain. If the user has multiple SIP domains
configured, they likely have a sync account per SIP domain.

l sip:conference@vccs refers to call history of Collaboration meetings.

l xmpp: refers to Message sync.
l tel: refers to SMS API.
You might want to delete a sync account if you recycle a DID from one Stretto user to
another. When a sync account is deleted, the associated content will be removed from
Stretto Platform. The original end user will see their synced content deleted from their
client next time they log into Stretto, and get a new sync account created as long as the
Stretto Sync feature is enabled for the user.
Tip: All the sync accounts will be deleted from the user and Stretto Platform when a Stretto
user is deleted entirely. This Delete a sync account option is available for customers who want
to keep the Stretto users but do not want the sync content associated to the user.
To delete a sync account
1. Go to the Users tab.

2. Select a user and click the Sync Accounts tab.
3. Click Edit.
4. Delete a specific sync account by clicking Delete beside the sync account.
5. Click Save.
The select sync account is deleted from Stretto Platform. The user will see the content
removed from their devices next time they log back into the clients.

Setting up email notifications

Stretto includes the following email features:
l administrators can send email notifications to users using Stretto Admin
l administrators can receive notifications for Enhanced Client Traces via email
l administrators can receive Stretto reports via email
l administrators can reset their own password via the Stretto Admin login screen.
In order to set up email notifications, you must have access to an SMTP server. If you
decide not to set up Stretto for email notifications, advise your administrators that the
email notification features cannot be used.
During the set up, you configure:

l The SMTP server to accept traffic from Stretto ,and
l Stretto to connect to the SMTP server. This can be done by using Stretto Admin to
set it up per group.
Gather information
Obtain information from your email administrator about the SMTP properties that must be
set up on your SMTP server. A full list of SMTP properties can be found at
https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html.
SMTP properties required by Stretto Platform

l mail.smtp.host: The SMTP server host name. For example, smtp.acphone.com.
l mail.smtp.port: The SMTP server port. For example, 587.
l mail.smtp.auth: Whether or not your SMTP server requires that the connection for
the authorization username (below) be validated using SMTP authentication.
l authorization username and authorization password: These are custom properties
used for SMTP authentication.
Do not confuse these custom properties with the standard mail.smtp.user property,
which shouldn’t be set — Stretto sets them internally.

The auth username might be an email address or may be a regular username,

depending on the requirements of your SMTP server.
l from username: A custom property. Emails are sent showing this address as the
sender, who is typically the group administrator or a “no reply” address. For
example, [email protected]. If mail.smtp.from is not specified, Stretto uses
authorization username.
Your SMTP server might require additional information, so it is up to you to identify and
set those properties as well.
Configure Stretto
Configure Stretto to connect to the SMTP server.
To configure outgoing mail for each group using Stretto Admin

In your top-level group, create the following attributes. Assign values to the attributes at
the group level. As with all other group defaults, the values are inherited by any
subgroups in the group.
Corresponding SMTP
Stretto Attribute Type Description
Property
smtp:mail.auth.password String Authorization password These username and password are custom properties
(custom property) used for authentication. For example,
strettoadmin and secret.
smtp:mail.auth.username String Authorization username The authorization username may be an email address
(custom property) or may be a regular username, depending on the
requirements of your SMTP server.
smtp:mail.auth.from String From username (custom Emails are sent as if coming from this email address.
property) Typically, it is the email address of the group
administrator. For example,
[email protected]. If this property is not
specified, Stretto uses [email protected].
smtp:mail.smtp.auth String mail.smtp.auth Set to true to require that the connection for the
Authorization username (e.g., strettoadmin) be
validated using SMTP authentication.
smtp:mail.smtp.host String mail.smtp.host The SMTP server host name. For example,
smtp.acphone.com.
smtp:mail.smtp.port String or mail.smtp.port The SMTP server port. For example, 587.
Integer

Corresponding SMTP
Stretto Attribute Type Description
Property
smtp:mail.<name> String Any other properties you Name the Stretto attribute by prepending the standard
identified. property name with “smtp” For example, the property
“mail.smtp.ssl.enable” becomes
“smtp:mail.smtp.ssl.enable”. As noted
above, be careful with the colons and dots.
Configure your SMTP server

Configure your SMTP server to accept traffic from Stretto Platform.
l Set up to expect authentication from the user identified by the authorization
username custom property (e.g., strettoadmin).
l Set up to accept email using the email address identified by the From username
custom property.
Verify that outgoing emails are sent

Using Stretto Admin, test the setup.
To send a test email
1. Log into Stretto Admin and go to a group.

2. On the Users screen, create a test user with an email address.
Note email addresses must be unique in Stretto; if you have added an email
address in other groups, the same email address cannot be used in a different
group on the same Stretto.
If you want to use the existing email address, create an attribute (such as
account.notification._userEmailAddress) and populate it instead of the Email
address field.
3. Select the test user you just created, and click Notify.
4. Select Send to selected users. The Notify Users dialog opens.

5. Select either user's email address or the attribute you created for email address for
notifications.
6. Enter test in Subject and Body. For the purposes of this test, no template is
needed.
7. Click Send.
Once you have sent the email, you should see the test email in your inbox.
How it works
When you send an email from Stretto, Stretto constructs an email using the “from”
attribute as the source email address. It then connects to the SMTP server specified in
the host and port attributes and gets authenticated with that server using the data in the
username and password attributes. Stretto then sends the email to the SMTP server. The
SMTP server already knows about this email address, so it accepts the email and
delivers it to the recipient or recipients.
Resolving email issues

If you have more than one top-level group and you do not set them all up for email, then
you may have a problem where some administrators do not get emails of reports, even
though they have set up for this feature.

When Stretto sends reports to an administrator, it looks in the administrator's default

group. If that group is not set up for email, the attempt to email reports to that
administrator fails.
Therefore, make sure that email is set up in the default group of each administrator.
Stretto notification service (SNS)

The Stretto Notification Service (SNS) allows Bria clients to receive notification events
from Stretto Platform. Customers can use the Stretto API to trigger the notification events,
and/or integrate the SNS with Stretto Admin web interface so that events are sent to the
Bria clients when the administrator performs a certain task on Stretto Admin.
When configured, notifications can be sent to Bria clients as follows:

l When the administrator suspends or deletes a user using Stretto Admin, Stretto
also attempts to log the user out from all of their devices.
l When a device of end users is deleted from Stretto Platform; for example, the
administrator deletes it from the Users page, or end users delete it using End User
Portal, or a device is deleted via Stretto Platform API , or a device is aged out per
std:deviceAgeDays, then Stretto attempts to log the user out from the deleted device.
l The administrator can refresh the end users' devices any time with up-to-date
configurations using the Notify > Refresh Devices feature.
Before you start

Make sure to include the SNS feature in your custom brand. Also include and configure
Bria Push in mobile clients.
Setting up for the SNS feature

Enable SNS by modifying the provisioning templates.
Using Stretto Admin, modify the provisioning template to include the following settings.
For Desktop clients:
feature_options:show_stretto_notifications:enabled="true"
feature:stretto_notifications:sns_group="{{ccs:groupName}}"

feature:stretto_notifications:sns_websocket_
url="wss://stretto.cloudprovisioning.com:18082/notification/subscription"
For Mobile clients: insert the following settings under <core_data_list>
<core_data_list>
<data name="strettoNotificationServiceEnabled" value="true"/>
<data name="snsGroup" value="{{ccs:groupName}}"/>
<data name="snsUrl"
value="https://stretto.cloudprovisioning.com:18082/notification/subscription"/>
Setting up user traces

User Traces provide detailed information about a user’s login attempt.
Enabling user traces

Enable user traces by creating a Stretto attribute. This attribute must be set at the group
level, not at the profile or user level.
To enable user traces on Stretto:
1. In Stretto Admin, create the following attribute and set their values at the group
level:
std:usertrace:enable True Enables user traces for this group
User traces are enabled for this group.
Viewing user traces

See Viewing User Traces.
Setting up enhanced Client Traces

This feature allows Stretto administrators to view client traces, which are device logs
created by the softphone clients. When this feature is enabled on both Stretto and Bria,

log files are sent to Stretto where Stretto administrators can view them in order to
troubleshoot problems.
When the user clicks the Send Log button on Bria, the softphone client contacts Stretto at
the specified URL, logs in using the username and password, and sends the log files.
Stretto stores the files for the specified group in that group’s folder.
Enabling enhanced client traces

Follow these steps to prepare Stretto Platform to use Enhanced Client Traces:
To enable enhanced client traces
level:
Commen
Attribute Value
t
std:logserver:enab true Enables

device
le You must set the attribute value at the group level, not at the profile or user level.
log
handling
for this
group.
std:logserver:url https://stretto.cloudprovisioning.com:18082/client This is

the
trace/submit/{{ccs:groupName}}
location
on
Stretto
where
the client
attempts
to post
log files.
std:logserver:user Any value. The user

All users must use the same value, so you must set the attribute value at the group ID that
level, not in a profile or user. will be
used to
validate
the client
when

Commen
Attribute Value
t
that client
attempts
to post
client log
files to
Stretto.
Creating
this
attribute
actually
creates
this user
ID on
Stretto.
The next
time the
user logs
in, this
value is
sent
down to
the
softphon
e client.
In this
way, both
the client
and
Stretto
have the
ID.
std:logserver:pass Any value. The

All users must use the same value, so you must set the attribute value at the group passwor
word
level, not in a profile or user. d that will
be used
to
validate
the client
when
that client
attempts
to post
client log
files to
Stretto.
Creating
this

Commen
Attribute Value
t
attribute
actually
creates
this
passwor
d on
Stretto.
Then,
when the
user logs
in the
next
time, this
value will
sent
down to
the
softphon
e client.
In this
way, both
the client
and
Stretto
have the
passwor
d.
2. Modify the provisioning templates to map the attributes to settings. Click the
template in the tree, choose the Source view, and copy and paste the following
lines into each template, as follows:
Desktop template
feature:standard_log:post_server_url="{{std:logserver:url}}"
feature:standard_log:post_username="{{std:logserver:user}}"
feature:standard_log:post_password="{{std:logserver:password}}"
Mobile template: Find <app_data_list> in the template and add the data lines under
<app_data_list>.
<app_data_list>
<data name="logCustomerPostUrl" value="{{std:logserver:url}}"/>
<data name="logCustomerPostUsername" value="{{std:logserver:user}}"/>
<data name="logCustomerPostPassword" value="{{std:logserver:password}}"/>

Viewing Enhanced Client Traces

Stretto administrators can view enhanced client traces from the Client Traces tab on
Stretto Admin. The administrators must have the View client traces option enabled under
their Admin Options.
See Viewing Enhanced Client Traces (device logs) for how to view client traces as well as
sample logs.
Notifying administrators of enhanced client traces

Set up notifications for administrators so that they receive emails periodically and/or
when a new client trace has been uploaded from Bria to Stretto Platform.
Receive notification each time a new log is uploaded

This might be suitable for Support representatives who help troubleshoot issues with end
users.
Stretto emails the client log files to any administrator who has the Client Traces
Notification option enabled, provided that the log is from a user in an administrator’s
default group, extra groups, or inherited subgroups. If a log file is very large, Stretto
emails only the log’s location rather than attaching the log file itself. The administrators
then can view the log file using Stretto Admin.
To set up notifications for new enhanced client traces
1. In the Admins page, select an administrator to modify and click Edit. The Edit
Admin dialog opens.
2. In Admin Options, select Client Traces Notification.
3. Click Save.
The administrator is set up to receive an email every time a user in the administrator's
groups sends a client trace to Stretto.
Receive email reports periodically

Administrators can receive Stretto reports via email periodically. When Enhanced Client
Traces is included in this report, the report sends the file names of the client traces
received from the Bria clients along with the time stamp.

To set up periodic email notifications for enhanced client traces
1. In the Admins page, select an administrator to modify and click Edit. The Edit
Admin dialog opens.
2. Under E-Mail Reports, select the Enhanced Client Traces checkbox.
3. If Report Frequency has not been set, choose how often the administrator receives
the reports: daily, weekly, monthly, or quarterly.
4. Click Save.
The administrator is set up to receive email reports including Enhanced Client Traces.
Royalty-bearing codecs tracking

You can handle tracking (and payment) of royalty-bearing codecs in one of two ways:
l Pay as you go (PAYG): You are charged for royalty-bearing codecs only if the
codec is enabled for that user and only when that user logs on for the first time.
In this case, the Group Information section of the Group screen includes the RBC
PAYG mode indicator, with the value set to “true”.
l Pay in advance (PIA): You want to be charged for royalty-bearing codec usage
based on the number of softphone clients you pay for. In this case, your softphone
client brands must include all the royalty-bearing codecs you want to use, and these
codecs are already enabled in your brands.
In this case, the RBC PAYG mode indicator does not show.

Contact CounterPath and request that your groups be set up with the desired tracking
method.
Setting up for PAYG

To set up for "pay as you go" (PAYG), keep in mind that
l When a user logs in for the first time from a different device and the provisioning
response for that login includes a royalty-bearing codec (in other words, that codec
is enabled), you incur a royalty payment. The number of payments is limited by the
maximum devices for the user.
l Deleting a device (to free up the user’s max device count) does not result in an
increase in the codec usage count. Once the user has reached their max devices
count, no more royalty payments are due if the user simply gets rid of an old device
and starts using a new one. But if you increase the user’s max device count and the
user logs on from yet another device, then a payment is incurred.
To set up for PAYG:
1. Create an attribute for each “enable codec” setting for each desired codec. For
example, create an attribute for the setting that enables the G.729 codec.
2. Set these attributes to true at the group, profile, or user level, according to your
policy or service levels. For example, always enable these codecs only for your
“gold service” users.
Setting up for PIA

No setup is required on your part and device tracking does not have to be supported.
Setting up User Experience Metrics

Note: User Experience Metrics (UEM) is an optional component of Stretto Platform. To enable
this feature, contact CounterPath and request that your groups be set up with the feature.
In your Stretto group, there are two areas in which you configure UEM:

l Adding and defining attributes for UEM at the group level. The values you enter
here are for every Bria client in the group.
l Adding settings to the desktop and mobile provisioning templates. These settings
take the values from the group attributes so that those values are provisioned to all
Bria clients in the group.
Follow these steps to configure group attributes and provisioning settings for UEM.
1. In Stretto Admin, add the UEM attributes at the group level. These attributes all
begin with std:vqmserver for easy identification.
List of UEM attributes and their values
Attribute Type Value
std:vqmserver:url String https://stretto.cloudprovisioning.com:18082

/uxmetrics/submit/{{ccs:groupName}}
This is the URL to which Bria posts analytics data. When this URL is
provisioned to Bria clients, {{ccs:groupName}} is replaced with the
group name.
std:vqmserver:user String Enter the name of a user that Bria uses when posting analytics data to
Stretto. All Bria clients in the group use the same account for posting
analytics data, so this attribute should be set at the group level and not in a
profile or user.
std:vqmserver:password String Enter the password for the user ID in std:vqmserver:user. This
password is sent along with the user name each time Bria posts analytics
data to Stretto.
std:vqmserver:timer Integer This is the frequency (in seconds) at which Bria posts analytics data to
Stretto. The minimum value is 21600 seconds (6 hours). If you enter a
smaller number, the value will be ignored, and data will be sent every 6
hours.
2. Modify each provisioning template — mobile and desktop — to add each UEM setting
and their corresponding value. This step connects each UEM setting in Bria to the
UEM attributes that you defined in your group.
Settings to add in provisioning templates

Desktop template
feature:uem:enable_analytics="true"
feature:uem:analytics_reporting_frequency="{{std:vqmserver:timer}}"

feature:uem:feedback_url="{{std:vqmserver:url}}"
feature:uem:feedback_user="{{std:vqmserver:user}}"
feature:uem:feedback_password="{{std:vqmserver:password}}"
Mobile template
<core_data_list>
<data name="enableAnalytics" value="true"/>
<data name="analyticsReportingFrequency" value="{{std:vqmserver:timer}}"/>
((omitted))
<app_data_list>
<data name="feedbackPostUrl" value="{{std:vqmserver:url}}"/>
<data name="feedbackPostUsername" value="{{std:vqmserver:user}}"/>
<data name="feedbackPostPassword" value="{{std:vqmserver:password}}"/>
Note: Tip: You may want to create “Support” administrators to allow people in your
organization who are not involved in provisioning to access the Reports button on the main
toolbar in order to view and print reports. This type of administrator will not be able to access
other Stretto functions.
Setting up The End User Portal

This feature allows end users to interact with Stretto in a variety of ways to assist in
managing their own services. The End User Portal helps reduce strain on administrators
by allowing end users to self-manage their softphone client.
There are two sides to the End User Portal. On Stretto, you, the administrator, must
select which of the possible functions you want your users to access. Then on a web
browser on end user's device or computer, the user displays the End User Portal web
interface that shows them these functions.
Choosing which features to expose

Using Stretto Admin, specify which End User Portal features you want to make available
to your users. All of the attributes that you expose are be changeable by the end user. If
the end user makes a change, the value they entered appears at the user level on the
Users screen.

To expose End User Portal features
1. Click the Portal Settings tab in the Groups screen. The Portal Settings section
appears.
2. Click Edit and select what appears in the End User Portal.
Functions available
l Allow end users to view and delete their devices: Allows users to manage
their own devices. Typically, when you set up Stretto, you limit the number of
devices users can deploy Bria on. If the limit has been reached and a user
wants to deploy on a new device, an existing device must be deleted from the
user's device list on Stretto.
l Allow end users to view their enhanced client traces: Allows end users to
troubleshoot issues by viewing the client traces. Usually, when the user
generates a client trace from Bria, they send it to the support team in your
organization. Typically, you would only enable this function if your end users
are technically savvy.
l Allow end users to change their password: Allows end users to change or
reset their Stretto password. To change their password directly in the End
User Portal, users must remember their current password. To reset their
password using I forgot my password in the End User Portal, users must also
have the user property E-mail address set up in the Settings section of
Users.

Warning: Do not select this option if you are using a third-party to authenticate
users (LDAP, ECS).
l Allow end users to change meeting settings: Allows end user to edit their
Collaboration options including basic information, video quality and layout,
moderation options, and recording.
l Allow end users to upload their XMPP Photo: Allows users to upload an
avatar photo for XMPP chat.
l Allow end users to edit attribute values: Allows users to set the value for
certain attributes on Stretto. For example, you might choose to allow each
user to change their own Display Name (which is an attribute on Stretto).
l End User Portal Administrator messages: Display messages set up by the
administrator to users in the End User Portal, allowing the administrator to
communicate whatever they want to their end users.
3. If you clicked Allow end users to edit attribute values, the dialog expands to show
all the applicable attributes that exist in the group. The applicable attributes are
those that:
l Were created directly in the group (so inherited attributes are not shown).
l Have an Open or Empty Rootlock (so Locked, Final, and SuperFinal attributes are
not shown).
Attributes that are masked or encrypted are shown if they are open and local.
4. Find the attribute that you want the end user to be able to configure. In the In-portal
name column, enter a user-friendly name. In the In-portal description column,
enter a short description or useful tip.

5. If you enable the Administrator Messages function, the dialog expands to show the
message field. Click New, give the message a Title and write the message body.
The End User Portal features are set up to be exposed to the end user.
Setting the URL for the End User Portal

Your users access the End User Portal screen in a web browser. There are two options:
l Internal browser: Users access the End User Portal screen in a web browser tab
within Bria.
l External browser: Users access the End User Portal screen in a browser outside of
Bria.
Internal browser
You can add up to three web links in Bria clients. One link can be to the End User Portal.
You can also enter links to other useful and informative sites in your organization.
To set up access to the End User Portal within Bria
1. In the Group page, click Attributes and click Edit.

2. Under Group Attributes, create these attributes and assign the values at the group
level.
Attribute name Description
desk.feature.webBrowser.enabled True to make the web panel visible in the Bria clients.
and
mob.feature.webBrowser.enabled
desk.feature.webBrowser.name Enter the name (label) of the link as it should appear in the softphone
client, such as End User Portal.
and
mob.feature.webBrowser.name
desk.feature.webBrowser.url You should see an URL already populated for your group. If not, enter
the URL of the web page to open in Bria clients.
and
You can configure Bria clients to use either a HTTPS GET or HTTPS
mob.feature.webBrowser.url POST request when accessing the web page.

Attribute name Description
To use a HTTPS GET, enter the URL and the parameters (if applicable)
in this url attribute. Note that parameters such as username and
password will be sent to the server as plain text, and recorded in the log.
For example:
https://stretto.cloudprovisioning.com:18082
/userportal/login?username=$loginusername$&password=$loginpassw
ord$
To use a HTTPS POST, enter only the URL in this url attribute, and enter
the parameters in another attribute as described in the next row. For
example:
https://stretto.cloudprovisioning.com:18082/userportal/login
desk.feature.webBrowser.postPara If you choose to use a HTTPS POST request, enter the parameters you
ms want to use for the POST request, followed by &redirect=true.

For example:
and
username=$loginusername$&password=$loginpassword$&redirect=tru
mob.feature.webBrowser.postParam e
s For HTTPS GET, leave it empty.
3. Click Save.
4. Modify the provisioning templates to map the attributes to settings. Click the
template in the tree, choose the Source view, and copy and paste the following
lines into each template, as follows:
Desktop template
feature:browsertab:enable1="{{desk.feature.webBrowser.enabled}}"
feature:browsertab:title1="{{desk.feature.webBrowser.name}}"
feature:browsertab:url1="{{desk.feature.webBrowser.url}}"
feature:browsertab:post_params1="{{desk.feature.webBrowser.postParams}}"
Mobile template: Find <app_data_list> in the template and add the following section
under <app_data_list>.
<app_data_list>
(omitted)
<gui_custom_view_list>
<gui_custom_view>
<data name="enabled" value="{{mob.feature.webBrowser.enabled}}"/>
<data name="title" value="{{mob.feature.webBrowser.name}}"/>
<data name="url" value="{{mob.feature.webBrowser.url}}"/>
<data name="postParams" value="{{mob.feature.webBrowser.postParams}}"/>
</gui_custom_view>
</gui_custom_view_list>
(omitted)
</app_data_list>

The End User Portal is set up as an internal web browser within Bria.
External browser
With this option, there is no extra setup in Stretto. Give the URL for the End User Portal to
your end users, for example in an email. The URL must be in this format:
https://stretto.cloudprovisioning.com:18082/userportal/
When the user enters this URL in a web browser, the End User Portal login page
appears. The user logs in with their regular Stretto username and password. With this
option enabled, be prepared to handle user lockouts. If the user logs in incorrectly five
times, they are locked out and see Locked_Out on the End User Portal log in screen.
LOCKED_OUT
To unlock a user
2. Select a user.
4. On the Settings tab, clear Locked (End User).

5. Click Save.
The user is unlocked.
Tip: If Allow end users to change their password is selected in the End User Portal
Settings, a user can change their password in the End User Portal. If they cannot remember
their password, they can use the I forgot my password link on the End User Portal login
screen. Users must have an email address in the user property E-mail address set up for
users in the Settings section of Users to use the I forgot my password link.
Testing the setup

Typically, when you deploy the End User Portal feature, your organization obtains brands
of with the User Portal set up as an internal browser. In this way, the end can access the
End User Portal directly from the Bria client. However, for testing, you can use a web
browser on your computer.
To test the setup of the End User Portal
1. Go to a web browser and enter the End User Portal URL:

https://stretto.cloudprovisioning.com:18082/userportal/
The End User Portal login page appears.
2. Log in using the regular Stretto credentials of a user on Stretto. Typically, you can
leave the Group name field empty.
Warning: Do not log in using your Stretto administrator credentials.

The End User Portal window appears. It shows a tab for each function you enabled
in set up.
3. Make sure each function you enabled has a tab. If not, go back and verify your
setup.
The End User Portal set up is complete.
Previewing the End User Portal functions

While you are still logged in to the End User Portal, you can try using the functions so that
you understand the user experience. Only the options you enabled in Portal Settings
appear.
To try the End User Portal functions
1. In Messages, you see a preview of any messages your created in End User Portal
Administrator messages.
2. In Settings, you see a tab for the string value in In-portal name. Click on the tab
and you see the string value in In-portal description and the current attribute value
set in Stretto at the group, profile, or user level.
Change the value for one of the Settings and click Save. Log in to Stretto Admin
and view this attribute for the user. The attribute shows the changed value.
3. Before you can preview Device Logs, you need to send a log from Bria.

l On Bria mobile, go to the Advanced Settings screen and send a log.

l On Bria desktop, go to Help > Troubleshooting > Support, and click Send
Log.
In Device Logs, click on the log. This log is identical to the log that you view on the
Client Traces screen.
4. To preview Device Management you must log in to a Bria client first. In Device
Management, click Delete for one of the devices and click Delete in Delete
Device. Log in to Stretto Admin and view devices for this users. The device is no
longer listed.
5. In XMPP photo, you see the current image being used for the avatar, if an image
has been set. Click Choose File and select the image file you want to use.
Optionally, select a new size from Resize image width:. Click Upload JPEG or
PNG Image. Log in to Stretto Admin and click View beside XMPP Avatar Image
in user Settings. The image you uploaded appears.
6. In Meetings, you see the settings and the meeting link. To preview the meeting
records, you must host a meeting first.
7. Click Change Password. Enter Old password, your New password and Confirm
password. Click Change Password. Type ESC to cancel. You are logged out of the
End User Portal and must use your new password to log in.
Passwords requirements:
l Must be at least 8 characters
l Must contain
l 1 uppercase character
l 1 lowercase character
l 1 number
l 1 punctuation character
The End User Portal functions are tested.
Customizing appearance of End User Portal

You can customize the appearance of the End User Portal for a group or for specific
users by creating a User Portal Template. This template is an HTML file with

placeholders for Stretto attribute values. When a user opens the End User Portal link in
their client, they see a page that displays information specific to their account.
A User Portal Template lets you:

l create a unique landing page
l apply branding to the End User Portal
l add personalized links and information
l insert blocks of HTML
User Portal Templates are specified by the group attribute std:userportal:template.

When this attribute contains the name of a template that exists under the group, this
template is used in place of the default End User Portal landing page.
Creating a User Portal template

Templates appears under a group folder in the group list.
To create a user portal template
1. Right-click the group to which you are adding the template and choose New
template > New blank template.

2. Give the template a name, press ENTER, and select the new template. The blank
template appears on the right.
3. Click Edit and write an HTML template using the format described under User
Portal template. As usual for templates, you can insert a Stretto attribute by
enclosing it in double brackets (such as {{account1.credentials.displayName}} to
insert the users's SIP account display name).

Your User Portal Template can include a link to the main End User Portal page at
https://Stretto_URL/userportal/home.html where the end user can access their
account settings.
4. Click Save.
Your template is ready to be associated with a profile, group, or user.
Uploading a User Portal template

If you prefer to create your User Portal Template using another application, you can save
it as HTML and upload it to Stretto Admin.
Note: Your uploaded file replaces the contents of the template that is currently selected.
To upload a User Portal template
1. After you create a template, make sure your blank template is selected and click
Upload.
2. Browse for the HTML file you want to use as the template and click Open. The
Upload template dialog shows the name of the file you're uploading.

3. Click Submit. Stretto uploads the file and displays it in the Template screen.
Your template is ready to be associated with a profile, group, or user.
Associating a template with users

A User Portal Template is associated with users by specifying a template name in the
attribute std:userportal:template.
You can set this attribute in these ways:

l In profiles. If you specify a template name in profiles, new users are provisioned
with the template attribute along with all other attributes in the profile.
l In the group attributes. If you specify a template at the group level, all users get the
same User Portal Template. As well, child groups inherit the same template for their
users.
l In the user attributes. You can set the template at the user level only if
std:userportal:template hasn't been set at the group level.

To find out more about creating attributes, see Working with attributes.
Using attributes to store HTML blocks

A User Portal Template can reference Stretto attributes so that attribute values are
substituted when a user views the User Portal. If you create an attribute and enter HTML
markup as its value, the markup is used as-is in the User Portal page.
Your template can be built from many such HTML-containing attributes to ensure that the
End User Portal has the correct look and feel. For specifics on the formatting of a User
Portal Template, see User Portal template.
Note: A string attribute is limited to 256 characters for a profile attribute and 300 characters for
group or user attributes.
Example:
Link to website
If you want to include a link to a website, you could create a group attribute named
html:siteLink (or any name) and define it as the following HTML markup:
<a href="https://www.acphone.com/" target="_blank">Visit us on the web!</a>
When you insert the attribute placeholder {{html:siteLink}} into a User Portal
Template, the output is a hyperlink, like this:
Visit us on the web!
Help Desk Assistant (HDA)

Help Desk Assistant is an optional feature for Stretto Platform.
What is Help Desk Assistant?

Help Desk Assistant allows a support representative to remotely troubleshoot issues that
end users may be experiencing with Bria clients. An end user can contact support

representative (by phone or email, for example) and share control of Bria with that
representative. Through Help Desk Assistant, your support representative can review
diagnostics from both the Bria client and the underlying OS and send diagnostic
commands to Bria to reproduce the issue.
For example, they can:

l Review a list of previous calls or call attempts, review device configuration, review
client traces, and make Bria to send logs to Stretto.
l View system-level information on the user’s device, such as a list of running
processes, memory usage, network connection information, and processor type.
l Remotely control the client: place an audio or video call from Bria to a specified
number.
Gathering information through Help Desk Assistant

This feature allows your support representative to retrieve information about a user's
device and the network to which the device is connected. Ideally, the end user should be
advised to be connected to the same network on which they experienced the problem.
For example, if the end user has an audio issue over a certain Wi-Fi network, they should
start a Help Desk Assistant session while connected to that particular network. This
allows your support representative to get diagnostic information about the network that
may help in identifying an issue or issues.
Getting ready to use Help Desk Assistant

To use Help Desk Assistant, the following configuration is required for Bria and Stretto
Platform.
On the device
Bria must be configured to include a link to Help Desk Assistant in the app settings. For a
branded client, this option should be enabled when the application is built. When Help
Desk Assistant is enabled, Help Desk Assistant appears in the app's Settings page.

On the Stretto Platform server

l Help Desk Assistant must be enabled for the group to which the user belongs. See
Setting up Help Desk Assistant.
l Support representatives in your organization need a Stretto Admin administrator
account that permits access to Help Desk Assistant.
When Stretto is correctly set up for Help Desk Assistant, upon logging in as an
administrator in Stretto Admin, your support representative sees a Help Desk
Assistant tab.
Setting up Help Desk Assistant

To use Help Desk Assistant to help end user troubleshoot an issue with the softphone
client, enable the feature in your group as follows. You also need to give the support
representative an access to Stretto.
Enabling the Help Desk Assistant in your group

Enable Help Desk Assistant for your group by creating and assigning values to attributes
and modifying templates.

To enable Help Desk Assistant
1. In the Group page, create each attribute in the following table. Assign a value to the
attribute at the group level.
Attributes for Help Desk Assistant
Attribute Value
remoteDebugUrl wss://stretto.cloudprovisioning.com:18082/hda/socket
Help Desk Assistant uses this information to take control of Bria, during a Help Desk
Assistant session.
std:remotedebug:authurl https://stretto.cloudprovisioning.com:18082/hda/aut
h/{{ccs:groupName}}
Bria accesses this location to request a Help Desk Assistant session.
std:remotedebug:user Enter the name of a user account to for Help Desk Assistant sessions. This user
name is used group-wide by Bria to log into a Help Desk Assistant session — set the
attribute value at the group level and not at the profile or user level. When an end user
requests a Help Desk Assistant session in Bria, this user name is used to validate the
client.
Entering a value for this attribute creates the user account. The name must not
already exist in any group.
std:remotedebug:password Enter a password to go with user account that you specified in

std:remotedebug:user. All Bria clients in the group use the same user
name and password — set the attribute value at the group level and not in a profile or
user.
2. Modify each mobile template to map the attributes to settings, as follows.
<core_data_list>
<data name="remoteDebugPostServiceUrl" value="{{remoteDebugUrl}}"/>
<data name="remoteDebugPostAuthUrl" value="{{std:remotedebug:authurl}}"/>
<data name="remoteDebugPostUsername" value="{{std:remotedebug:user}}"/>
<data name="remoteDebugPostPassword" value="{{std:remotedebug:password}}"/>
Help Desk Assistant is enabled for your group.

Giving your support representatives access to Stretto Admin

Create one or more administrator account for your support representatives so that they
can log into Stretto Admin. There are different types of administrator accounts with
varying abilities. Choose the administrator type that is most appropriate for your support
representative:
l Support administrators, to give them access only to the Help Desk Assistant
screens (accessed via the Help Desk tab on the main toolbar) and to the Enhanced
Client Traces screens (Client Traces on the main toolbar).
l Users&Profiles administrators, to give them access to the Help Desk Assistant
screen and the Enhanced Client Traces screens, and to give them the ability to
change the end user's configuration (by changing the values of attributes at the
profile or user level).
To learn how to create administrators, see Creating an administrator.
Handling Help Desk Assistant sessions

For information on using the Help Desk Assistant screens to establish a session with a
user and then troubleshoot their issue, see the following topics:
l Starting a Help Desk Assistant session with an end user
l Performing remote diagnostics in Help Desk Assistant
l Help Desk Assistant console commands
Starting a Help Desk Assistant session with an end user

This section is intended for representatives at enterprises and VoIP service providers
who intend to provide end-user support using Help Desk Assistant.
During a conversation between you (a support representative) and a Bria end user,
arrange for the user to initiate a Help Desk Assistant session for remote diagnostics.
About a Help Desk Assistant session:

l End users initiate sessions; sessions cannot be initiated from Stretto Admin.
l Sessions remain active for up to 20 minutes. A timer is visible to you in the Help
Desk Assistant tab.

l If a session closes, the end user must initiate a new session, which generates a
new reference number. A reference number is valid for one session only and cannot
be reused.
l Sessions connect through the end user's mobile data plan. Be conscious of data
usage.
l If you want to remotely make calls from the end user's device, the end user must go
to Preferences in Bria and enable Use When Available and Allow VoIP Calls.
To initiate a Help Desk Assistant session
1. In conversation with the end user, help them to start a session using the following
steps.
The end user should:
a. In Bria, select Settings then Help Desk Assistant. The Help Desk Assistant
page opens.
b. Tap Connect. Bria shows a reference number.
c. Give the reference number to the support representative by whatever means
available (for example, phone, email, IM, etc.).
d. Wait for the support representative to start the session.
2. Log into Stretto Admin and click Help Desk Assistant.
3. Click Connect to Client. Stretto Admin prompts you for the session reference
number.
4. Enter the session reference number that was provided to you by the end user and
click Connect. Stretto Admin establishes the connection and displays a
"connected" message in the console.
Bria shows a message to the end user indicating that Help Desk Assistant is now
connected.
To end a Help Desk Assistant session

Either party can end a session.

l The end user can end a session by:

l Tapping Disconnect in the Help Desk Assistant screen in Bria.
l Logging out or closing Bria.
l You can end a session by:
l Clicking Disconnect in the Help Desk Assistant page in Stretto Admin.
l Entering the app exit command in the Help Desk Assistant console.
Note: If a session disconnects for any reason (for example, a network connectivity issue), ask
the end user to initiate a new session and give you the new reference number.
Performing remote diagnostics in Help Desk Assistant

This section is for a support representative using Help Desk Assistant in Stretto Admin.
Once a Help Desk Assistant session is established between Stretto Admin and the Bria
client, you can:
l View the end user's Bria-related information as well as system-level information
such as memory usage and network connection.
l Remotely control the client to make a calls.
l View the device log in the console and send the device log to Stretto Admin.
Using the remote console

The Help Desk Assistant console provides links to diagnostic information and lets you
enter console commands at the command line. The following image describes the
console during an active session.

Diagnosing issues in Help Desk Assistant

A typical troubleshooting procedure is as follows:
1. Start a Help Desk Assistant session with the end user. See Starting a Help Desk
Assistant session with an end user.
2. Enable logging on Bria.
3. Reproduce an issue that the end user is experiencing.
4. View the network information as well as the device log in Help Desk Assistant.
5. Instruct Bria to send the device log to the Stretto Platform.
6. If appropriate, push the latest configuration from Stretto Platform to Bria.
7. End a session.
Example:
Reproducing an audio issue
In this example, you attempt to reproduce an audio issue on a Wi-Fi network. This
example includes how to use Help Desk Assistant to get Bria to start recording
diagnostic data in a log and to send the log to Stretto.
1. Start a Help Desk Assistant session with the end user.

2. On theHelp Desk Assistant Command line, enter the following command to
enable diagnostic logging:
log advanced enable
If the command is successful, Bria responds with this message:
advanced log enabled
3. Using a test account and a Bria client, make a call to the end user's account.
The device receives the incoming call.
4. On the Help Desk Assistant Command line, enter the following command to
make the end user's device answer your call:

call answer
If the command is successful, Bria responds with these messages:
Call Status Answering

Answered
Call Status Connected
5. If you have purchased the optional User Experience Metrics module for Stretto
Platform, use the following command to retrieve call statistics from Bria:
call stats
If the command is successful, Bria responds with several lines of information.

Dots indicate lines that have been omitted for brevity.
Remote Peer sip:[email protected]

Call Time 00h:00m:55s
AUDIO
Codec G722 @16kHz
.
.
.
Use the following command to retrieve voice quality metrics:
call vqmon
If the command is successful, and if you have purchased User Experience

Metrics, Bria responds with several lines of information. Dots indicate lines that
have been omitted for brevity.
VQSessionReport
CallID: -AUXQsQnY5TP0Mj.1USBQBZP7Al8CTfS
.
.
.
6. End the call by entering the following command:

call terminate
If the command is successful, Bria responds with these lines:
Call Finished
Call terminated
7. Retrieve the device log from Bria by entering the following command:
log simplified
If the command is successful, Bria responds with log data. Dots indicate lines
that have been omitted for brevity.
.
.
.
12:46:39.548 [1][I] [Calls] New call conv: 1, join: 0, replace: 0, type: 1200, addr:
sip:[email protected], display: Joseph Santos
.
.
.
8. Instruct Bria to upload the device log to Stretto.
log advanced send
If the command is successful, Bria confirms the log is sent and provides a
reference ID.
Logs have been sent

Log received with refId:3B7A2C6A
The content of the log is similar to the log you retrieved with the log simplified
command. If you have the Enhanced Client Traces feature installed, the log is
in the Client Traces page in Stretto Admin and listed by its reference ID.
9. You can view device and network information by using the snapshot
commands:

snapshot basic
.
.
.
Accounts info:
Number of SIP accounts: 1
---------------------------------------
name:CounterPath PBX type:Sip status:200 Dtmf:RFC
name:CounterPath Stretto IM type:Xmpp status:200 Dtmf:
.
.
.
snapshot advanced
.
.
.
CPU info:
cpu usage:0.000000, number of threads:20
.
.
.
Example:
Applying the latest configuration update to Bria
You can find out if Bria has received the latest provisioning update from Stretto. If
there are changes (deltas) to the configuration, you can apply those changes to Bria
by updating Bria.
1. Compare the configuration of Bria to the current configuration in Stretto by

using the following command:
config delta
Bria responds with a list of the differences between the two configurations.
Client value -----------Name----------Stretto value

YES enableVPN NO

In this example, the end user has changed enableVPN to YES since Bria last
received a provisioning update.
2. Start an update by using the following command:
config reload
Bria responds with status messages:
Start provisioning refreshing.

Configuration has been reloaded
3. Confirm that the update has been applied by re-checking the delta:
config delta
If the update has been applied successfully, Bria responds with this message:
There is no delta found
Example:
Prompting the end user to upgrade Bria to the latest version (Android only)
If an end user has an older version of Bria on an Android device, you can prompt the
end user to upgrade to the latest version.
1. Check the Bria version on the user's Android device using the following
command:
app update check
Bria responds with the app ID and version number. The app ID and version
here are examples only — the actual ID and version will be different.
You have com.briaccs.voip with 5.1.5 version.

2. Instruct Bria to prompt the end user to get the latest version from Play Store by
using the following command:
app update execute
The user's device opens the app page on Play Store. The app cannot be
upgraded automatically — it is up to the end user to perform the upgrade
manually.
3. If the end user is on a mobile network, advise them that the client can be
downloaded later using Wi-Fi.
Help Desk Assistant console commands

During a Help Desk Assistant session with a device, you can remotely control Bria by
entering commands at the Command line. Some commands only work if the connected
device runs Android and not iOS.
Before you can execute any commands, you need to establish a Help Desk Assistant
session with the end user's Bria. See Starting a Help Desk Assistant session with an end
user.
Command Platform Description
app exit Android Close the Bria app and end the Help Desk Assistant session. The client cannot accept any more
only commands until the user opens Bria and initiates a new session.
app update Android Check if there is a newer version of the client available on Play Store.
only
check
app update Android Open the Play Store page where the user can upgrade the client to a newer version. This command
only does not automatically download the client; it is up to the user when to download it. Note that
execute
downloading over a mobile network uses end user's data plan if they have no Wi-Fi access.
call answer Answer an incoming call.
call audio Start an audio call to the specified number.
number
call record Initiate call recording during a call. The recording ends when the call ends. Help Desk Assistant does
access to the recording — the user needs to send you the file via by other means, such as email.
call stats View call statistics of the current call. Use this command while Bria is in a call. This command returns
the same content as Call Statistics under Advanced Settings on the Bria client.

call End the call.
terminate
call video Start a video call to the specified number.
number
call vqmon View voice quality data of the current call. Execute this command while there is an ongoing call on the
device. This command requires the optional User Experience Metrics feature in Stretto.
config View current configuration of the client. Use this command to see how Bria settings are configured in
the client .
current
config View the differences (the "delta") between the Bria settings and the latest settings as provisioned by
Stretto. Bria periodically contacts Stretto to retrieve the latest configuration. If the configuration does
delta
not match, it can mean that the user changed a setting in Bria or the device has not contacted Stretto
recently. If this command reveals configuration differences, use the config reload command to
force a provisioning update.
config dtmf View DTMF settings. The same information is also available in snapshot basic.
config Update Bria with the latest configuration from Stretto. Use this command if the configuration settings
have changed since Bria last retrieved an update.
reload
log Disable advanced/verbose logging on Bria.
advanced
disable
log Enable advanced/verbose logging on Bria.
advanced
enable
log Send the Bria device log to Stretto. The content of the log is the same as the response to the log
advanced simplified command. You can view the logs from the Client Traces tab in Stretto Admin. This
send command requires the optional User Experience Metrics feature in Stretto.
log calllog View the call history stored in Bria. The history contains a list of all the incoming, outgoing, missed,
and recorded calls.
log View the device log. This device log contains detailed information on what the client is doing.
simplified
snapshot View detailed information about the device, including:
advanced l CPU Load information
l Memory information
l Location information (Android only)
l Wi-Fi information (IP address, link speed)

l Mobile Network information (IP address, link speed)
l List of running processes (Android only)
l List of recorded calls
l Call history
l Hardware Information (device model etc)
l NAT Traversal Method
l Failed Registrations
snapshot View the basic set of information about the user's device, including:
basic l Client name, version, built date
l Enabled add-ons and app purchases
l Number of accounts (SIP/XMPP), registration statuses, DTMF type
l Provisioning user name (Stretto username)
l License information
l OS version and device model of the device
l Data connection (Wi-Fi or mobile)
l Audio Setup on the device
l Network Interfaces
l Last successful provisioning update
l Call audio properties
l Last call made on the client
system cpu View CPU load.
system View memory usage.
memory
system View active network interfaces.
network
active
system View network usage per interface.
network
usage
system ps Android View a list of running tasks.

only

Setting up remote upgrade of Bria desktop

Note: Remote “update” refers to updating the configuration. Remote “upgrade” refers to
upgrading the software version of the softphone.
Bria desktop supports the remote upgrade feature where it checks if a newer version of
the Bria desktop client is available for upgrade. If an upgrade is available, then Bria
desktop connects to a remote upgrade server where the upgrade is stored, and
downloads the installer file.
On Stretto, Windows and Mac upgrades can be managed separately. Stretto handles the
“is an upgrade available” logic, but it does not actually host the upgrade file. You must
host that yourself on a separate server.
Add settings to the Desktop template
Desktop setting Description
feature:auto_ Set to true to enable the remote upgrade feature so that the Bria desktop client checks if a new version of
the software is available for upgrade. Set to false to disable it.
update:enable_
code_check
feature:auto_ Set to the URL of your upgrade server which handles requests from Bria desktop to determine a given
deployment needs an upgrade. See examples of the upgrade URL.
update:code_
Set to the following URL. Stretto uses a script to determine a given deployment needs an upgrade. Make
server_url sure to include all the parameters as listed below.
feature:auto_update:code_server_
url="https://stretto.cloudprovisioning.com/upgrade?Username=$loginname$
&Password=$loginpassword$&build=$build$&platform=$platform$&uuid=$computerid$&spid=
{{ccs:groupName}} &type=$type$"
feature:auto_ The initial value for the upgrade timer. Default is 60 seconds. Used for timing the first time the Bria
desktop client hits the remote upgrade server. After the initial hit, the client hits the upgrade server every
update:code_
24 hours.
check_initial_t_s A value of 0 means never, which means remote upgrade checks will not be performed. However, note
that end users are able to manually check for upgrade if your custom brand has the "Check for updates"
capability.
feature:auto_ Set to true to instruct the Bria desktop client to verify the authenticity of the downloaded installer using the
MD5 checksum. If the hash does not match, remote upgrade will fail.
update:strict_
When set to false, the Bria desktop client proceeds to install the downloaded file without verifying the
hash_check authenticity.
Example

[DATA]
Success=1
.
.
[SETTINGS]
feature:auto_update:enable_code_check="true"
feature:auto_update:code_server_url="https://MyUpgradeServer.com/upgrade?Username=$loginname$
&Password=$loginpassword$&build=$build$&platform=$platform$&uuid=$computerid$"feature:auto_
update:code_server_url="https://stretto.cloudprovisioning.com/upgrade?Username=$loginname$
&Password=$loginpassword$&build=$build$&platform=$platform$&uuid=$computerid$&spid={{ccs:groupName}}
&type=$type$"
feature:auto_update:code_check_initial_t_s="3600"
feature:auto_update:strict_hash_check="true"
Create attributes
Create the following attributes and set the values in Stretto at the group or profile level.
These attributes are not mapped to any settings in the template. Instead, they are read by
Stretto during the upgrade process, as described in How remote upgrade works.
Remember that attribute names are case sensitive.
System Attribute Type Description
std:upgrade.< Integer Where <platform> is "windows" or"mac". Create one or more

platform>.version attributes, depending on which platforms you support. Specify the build
number of the most up-to-date version of your softphone. In other words, the
build number of the executable that will be on your upgrade server. For
example, 32000.
std:upgrade.<platform>.url String Where <platform> is "windows" or "mac". Create one or more

attributes, depending on which platforms you support. Specify the URL of the
executable for the specified platform. For example:
https://MyUpgradeServer.com/mac/ACphone.2/ACph
one_120_32000.dmg
std:upgrade.< String Optional. Specify a MD5 hash of the installer file that will be on your upgrade
platform>.md5hash server. Where <platform> is "windows" or "mac". Create one or

more attributes, depending on which platforms you support.
To generate a MD5 hash, use the UNIX/Linux’s md5sum command, the
Mac’s md5 command, or any third party’s tool of your choice.
std:upgrade.windows.msiUrl String Use this attribute instead of url attribute above for Bria desktop 6.2.0 clients
or newer, which handle MSI installer.
Specify the URL of the MSI installer for the specified platform. For example:
https://MyUpgradeServer.com/win/ACphone.2/ACph
one_120_32000.msi

System Attribute Type Description
std:upgrade.windows.msimd5ha String Optional. Specify a MD5 hash of the MSI installer that will be on your
upgrade server.
sh
To generate a MD5 hash, use the UNIX/Linux’s md5sum command, the
Mac’s md5 command, or any third party’s tool of your choice.
std:upgrade.< String Optional. This attribute allows the administrator to show a hyperlink in an
upgrade pop-up on Bria desktop. End users can click the link and view your
platform>.releasenotesurl
release notes. The release notes can be in any file format, and be hosted on
any server. Where <platform> is "windows" or "mac". Create one or
more attributes, depending on which platforms you support.
std:upgrade.< Integer Optional. Create this attribute to show release highlights in the upgrade
prompt. This attribute indicates how many bullet points to show. It ranges
platform
from 0 to 3 depending on how many highlights you want to display to end
>.releaseFeatureCount users.
Where <platform> is "windows"or "mac". Create one or more
attributes, depending on which platforms you support.
std:upgrade.< String Optional. Create this attribute and enter a brief description of the new feature
you want to display to end users about this new version. This value comes up
platform>.releaseFeatureOne
as the first bullet point.
Where <platform> is "windows" or "mac". Create one or more
attributes, depending on which platforms you support.
std:upgrade.< String Same as above, except this is for the second bullet point.
platform>.releaseFeatureTwo
std:upgrade.< String Same as above, except this is for the third bullet point.
platform
>.releaseFeatureThree
Make a software upgrade available to end users

Once you have set up for remote upgrade, you need to do the following maintenance
when a new version of your software becomes available:
1. Put the upgrade on your upgrade server.

2. Change the std:upgrade.<platform>.version attribute (or attributes) to specify the
build number of the new version.
3. Change the std:upgrade.<platform>.url, if necessary.
For example, if the filename portion of the original URL includes the build number,
change the URL. For example, change

https://MyUpgradeServer.com/mac/ACphone1.2/ACphone_120_32000 to
https://MyUpgradeServer.com/mac/ACphone1.2/ACphone_120_39010.
If the filename portion of the original URL does not include the build number, you
may not need to change anything.
4. Change the std:upgrade.<platform>.md5hash,
std:upgrade.<platform>.releasenotesurl, and
std:upgrade.<platform>.releaseFeatureXXXX, if necessary.
Set up your upgrade server

Customers must set up a remote upgrade server to host installer files to be delivered to
their end users. The path and file name must match the value you entered in the
std:upgrade.<platform>.url attribute.
How remote upgrade works

1. The first time Bria desktop starts on the end user's computer, it contacts Stretto for
login and gets provisioned with the settings for the remote upgrade feature.
If your custom brand does not have login, the remote upgrade settings will be set in
your brand.
2. As soon as login is complete and Bria desktop has appeared on the user's
computer, the initial upgrade timer starts using the value in code_check_initial_t_s.
3. When the initial upgrade timer expires, Bria desktop contacts code_server_url by
sending a GET in order to do an upgrade check.
Details on code_server_url
The value of code_server_url can include includes Stretto data elements (such as
{{ccs:groupName}}) and Bria desktop macros (such as $build$) which are replaced
by real values before Bria desktop sends the GET request to the URL.
For example, the following URL
https://MyUpgradeServer.com/upgrade?Username=$loginname$
&Password=$loginpassword$
&build=$build$
&platform=$platform$
&uuid=$computerid$

&spid={{ccs:groupName}}
&type=$type$
becomes:
https://MyUpgradeServer.com/[email protected]
&Password=1234
&build=31002
&platform=windows
&uuid=3478REUEIRU784WURUEIYRFUEIW
&spid=acphone.com
&type=windows.desktop
4. Stretto makes decisions whether an upgrade is available to the user.
Details
Stretto authenticates the username, password and SPID in the GET request to the
user in Stretto.
If the authentication fails, a failure response is sent down.
Stretto determines (from the GET header) the platform the user is using: Windows
or Mac.
Stretto compares the build number sent by Bria desktop against the “new version
value” set on Stretto, and determines whether or not Bria desktop needs upgrade.
Stretto sends down a success response to the user’s Bria desktop, including the
following information:
l The URL from the std:upgrade.<platform>.url attribute.
l The URL from the std:upgrade.windows.msiUrl attribute.
l The value from the std:upgrade.<platform>.version attribute.
l If configured, the values from the MD5 hash attributes, the release notes URL
attribute, and release highlight attributes.
If Stretto determines that Bria desktop does not need upgrade, it notifies Bria
desktop that no upgrade is required.
Note: You do not have to create a template for this response; Stretto creates the entire
response on its own.

5. The upgrade server makes decisions whether an upgrade is available to the user,
and sends a response to Bria desktop.
The format of server response

The upgrade server must respond with one of the following:
[DATA]
Success=0
or
[DATA]
Success=1
version=60000
url=https://MyUpgradeServer.com/newversion.exe
hash=595f44fec1e92a71d3e9e77456ba80d1
msiUrl=https://MyUpgradeServer.com/newversion.msi
msihash=5944fec192a71d3e9e7e745f56ba80d1
response_version=1
release_notes_url="http://your_release_notes_locations.com"
release_version=4.8.1
release_feature_count=3
release_feature_1="a description of New Feature 1"
installer_extension=.exe
where:
l Success=1: True (there is an upgrade) or 0=false (there is no upgrade).
l version: Identifies a build stamp of the upgrade. Bria desktop uses this version
to determine whether to prompt the user to install the upgrade.
l url: The absolute path to the installer software for the new version.
l hash: The MD5 checksum used to verify the authenticity of the downloaded
installer.
l msiUrl: The absolute path to the MSI installer for the new version.
l msihash: The MD5 checksum used to verify the authenticity of the
downloaded MSI installer.
l response_version=1: The version of the response the server returns to Bria
desktop. Included if release_notes_url is configured.

l release_notes_url: Identifies the location of your release notes for the new
version of Bria desktop.
l release_version: The new version number of Bria desktop. This number
appears on the upgrade dialog when notifying end users of an upgrade.
l release_feature_count: The number of new features in the upgrade. Ranges
from 0 to 3.
l release_feature_n: A brief description of the new feature. N indicates a
number from 1 to 3.
l installer_extension: The type of installer file for the url parameter: .exe for
Windows and .dmg for Mac.
The response must end with a CRLF (Carriage Return / Line Feed).
The response cannot include a [SETTINGS] section. In other words, none of the
user’s current settings can be changed via this response.
6. Bria desktop compares the build number of the application on the user's computer
to the build number specified in the server response.
l If the response has the same number, Bria desktop does not prompt the user
to download. Skip to Step 8 below.
l If the response has the lower number, Bria desktop does not prompt the user
to download: downgrades are not supported. Skip to Step 8 below.
l If the response has a higher number, Bria prompts the user to download the
upgrade. Go to Step 6.
7. Bria desktop presents upgrade to end users, along with release highlight points and
a link to the release notes if provided.
The user takes one of these actions:
l If the user initiates the download, Bria desktop will download the installer and
save it to the local Bria desktop program folder. Go to Step 7.
l If the user chooses to install later, Bria desktop will enter its timing cycle and
display the upgrade prompt again in 24 hours.
8. Bria desktop checks the MD5 hash of the downloaded installer against the one
provided by Strettoyour upgrade server (if configured).

l Bria desktop proceeds with upgrade only if both values match. Bria desktop
prompts the user to exit in order to install the new version. The user can install
immediately or postpone installation.
l If the values do not match, Bria desktop shows an error to the end user,
indicating that download failed.
9. Bria desktop checks for the upgrade every 24 hours by contacting code_server_url.
SIP server failover using DNS or NAPTR

Bria supports SIP server failover. This functionality allows the client to search for and
connect to another SIP server if the primary SIP server is not available. There are various
ways to achieve it; one using a DNS server, the other using NAPTR lookup. This topic
describes how the client handles the SIP failover and its related settings to fine tune the
behavior.
DNS-based SIP failover
Upon SIP account enablement, Bria clients will attempt DNS SRV lookup of the domain
account setting (or outbound proxy account setting if also specified), if no port is
specified. If a port is specified, the client will skip immediately to A record lookup. If the
domain or outbound proxy is an IP address, DNS lookup is skipped altogether.
If multiple SRV records are returned, the client attempts to connect to the target with
highest precedence per SRV record priority and weight.
If a successful SIP registration is made, this target becomes whitelisted. The client will
continue to re-REGISTER to this whitelisted target for future registration refreshes,
unless:
l Future re-registration attempts fail due to an unreachable target or 4xx/5xx server
responses. In this case, the client would attempt to SIP register against the next
highest precedence record from DNS SRV results, unless that record had been
recently attempted unsuccessfully
l A network change occurs; e.g. on mobile if the device switches from Wi-Fi to
Cellular, or vice versa. In this case, the client behaves as if it was an initial SIP
account enablement, as above.

l The client is restarted, or the client’s SIP account is disabled then re-enabled (e.g.
via user interface, or if SIP push is enabled and the client moves from the
background to foreground). Again, in this case the client behaves as if it was an
initial SIP account enablement, as above.
Note this implies that even if the TTL (time to live) expires for DNS SRV record queried
previously, and subsequent DNS SRV queries result in a list of records with different
priority, the client will continue to prefer the whitelisted target.
Using NAPTR
NAPTR lookup is performed prior to SRV lookup (described above), on SIP account
enablement, if the SIP transport type is set to Auto, the domain or outbound proxy has no
port, and is not an IP address. If NAPTR results are returned, they are used to initiate
SRV queries per above, except using address from NAPTR record result instead of
domain or outbound proxy. If NAPTR results are not returned, the client initiates DNS
SRV queries for UDP, TCP, TLS. If the SIP transport type is set to something other than
Auto (e.g. UDP), the client skips to SRV lookup per above.
Customizing and translating login error

messages
You can translate Stretto login error messages into a language or languages of your
choice. These “login error messages” are messages that Stretto sends down to the user
and that are displayed on the user’s device when the login fails. For example “Incorrect
user name or password”.
When the user logs into Stretto, the language being used on the device (the locale) is
included in the HTTP request. Stretto reads this information in each request. If an error
occurs, and if the specific error has been translated on your Stretto, then the error is sent
down to the softphone client in that language.
Setup
Note: You must set the values for these attributes at the group level. Do not set override
values at the profile or user level because in most cases these values never get used.

Language is indicated using a two- or four-character ISO language code. For example,
“en” or “en-us”. Make sure to enter the language code all in lower case and to enter a
dash between the two parts (not an underscore).
1. Create an attribute for each error/language you want to support. For example:
l msg:auth:susp:en
l msg:auth:susp:en-us
l msg:auth:susp:fr
2. Enter the translated error message as the attribute value. Typically, enter this value
at the group level.
3. In addition, identify one of your language sets as the default that is used for
languages you do not support. For example, identify French as your default. Create
the attribute std:locale.default and set its value to that fallback language.
How error messages are shown to users

When the user logs into Bria, their current language is included in the login request.
If a login error occurs, Stretto determines which error to send down.

l It then looks for an attribute that matches that error and the user’s language, takes
the value of that attribute, and sends down that value as the error.
l If there is no attribute that exactly matches the user’s language, Stretto looks for an
attribute with a two-digit code. For example, if the user’s language is “en-us” and
there is no corresponding attribute, Stretto looks for “en” alone.
l If there is still no attribute, Stretto falls back to the default language, as specified in
the std:locale:default attribute. If that attribute does not exist, Stretto falls back to
the built-in error, which is US English.
Note that this feature also allows you to customize the English wording (independently of
translation). For example, if the built-in error is Device Activation Limit Reached, you
could customize it to:
l “Device Activation Limit Reached. Contact [email protected]” for en-us.
l “Device Activation Limit Reached. Contact [email protected]” for en-uk.

Mapping to one language

If you want to provide error messages in only one language, then create the attribute
std:locale:override and set it to a language. For example, if you want all error messages
in German, regardless of the language in the request, then set this attribute to “de”.
You must create attributes for all the errors and set values that show the German text. For
example, create msg:auth:susp:de, msg:auth:badpw:de, and so on.
With this setup, you only need one set of attributes because all users are mapped to use
German. Of course, if you want to provide error messages only in US English, there is no
work to do at all; US English is the default language.
Table of customizable error messages

Use this table to identify error messages that you can customize for region or
language
Attribute Purpose English Wording
msg:auth:badpw:<locale> Invalid password Incorrect user name

or password
msg:auth:lockedout:<locale> The user has made failed login attempts in a row for a Account is locked
specified number of times, and the user is locked out out.
from logging in.
msg:auth:noaccess:<locale> User is valid, but no template is defined for the user: the Access not allowed
profile that this user belongs to does not include a for this softphone
template mapping for this platform. platform
msg:auth:notfound:<locale> User was not found User not Found
msg:auth:susp:<locale> User is suspended Suspended
msg:device:limit:<locale> The user is trying to log on from a new device but the Device Activation
maximum device allocation has been reached. Limit Reached
msg:device:nouuid:<locale> No device ID was found in the incoming user request; Device ID is

there is an error on the softphone client that means the missing
request is missing this important information.
msg:ldap:badpw:<locale> LDAP authentication is being used and the user's Invalid credentials
LDAP password was invalid
msg:ldap:notfound:<locale> LDAP authentication is being used and the user was User not found
not found on an LDAP server
msg:groupdesktopdevice:limit:< You have set up for group device limits on a per- Desktop Device
platform basis and the desktop limit has been reached Limit reached.
locale>
for this group. Contact us for

Attribute Purpose English Wording
assistance.
msg:groupdevice:limit:<locale> You have set up for group device limits on a per-group Per-group Device
basis and the limit has been reached for this group. Limit reached.
New users or old users logging in from a new device Contact us for
cannot log on. assistance.
msg:groupsmartphonedevice:limit:< You have set up for group device limits on a per- Smartphone Device
platform basis and the smartphone limit has been Limit reached.
locale>
reached for this group. Contact us for
assistance.
msg:grouptabletdevice:limit:< You have set up for group device limits on a per- Tablet Device Limit
platform basis and the tablet limit has been reached for reached. Contact
locale>
this group. us for assistance.

Stretto Platform Administration Guide Viewing logs and reports
Viewing logs and reports
The administrator can view various logs and reports using Stretto Admin. A report may be
blank (showing no data) if a particular feature is not enabled.
Where to
Log Content
Download
Event Logs Contains user activities of all users captured by Stretto such as login attempts. Group >
Logs or
Users >
Logs
User Traces Provides information about login attempts by a specific user. It provides more detailed information than Users >
the corresponding Event Log. Logs
Enhanced You can view device logs that your users send to you. The device log contains Bria’s activity on a specific The Client
Client Traces device of a specific user. This is also known as the Enhanced Client Traces feature. Traces tab
(Device or
Logs) Group >
Logs or
Users >
Logs
Device Lists Lists all devices for a selected group, along with a username. Group >
Devices
Stretto Provides statistics about login, device counts, and user activity. The Reports
reports tab
User Provides analytical reports and logs for diagnosing technical issues with audio and video calls. The Reports
Experience tab
Metrics
Viewing Event Logs

The Event Logs show attempts by all users to log into Stretto. A new file is created every
15 minutes (although no file is created if there is no activity during a given 15-minute
period).

Viewing and downloading Event Logs

The Event logs can be downloaded from the Group screen or the Users screen. Both
screens provide the same list of event logs.
1. In the Group page, click Logs > Event Logs.

2. Specify the number of records to show on each page and filter the records by date
or text string.
3. To save the records to a file, click Download All or select some records and click
Download Selected.
Downloaded records are saved in a ZIP file that contains the individual records as text
files.
Event Log contents

Each text file contains one or more records. Each record contains the following data
Item Example Description
timestamp 110928173138-0400 Date and time of the HTTP response.

Format is YYMMDDHHMMSS[+-]HHMM,
the +HHMM or -HHMM is the time to
add/subtract to get to GMT/UTC
userName [email protected] Username of the user sending the request
url /login Path portion of the URL sent by the client. If

you use different URLs for login and
upgrade, this information helps identify the
type of request.
clientType mob Type of softphone client: mob for Mobile or

desk for Desktop
device iPhone3%2C1 For Mobile, identifies the device model

(iPhone or Android)
For Desktop, identifies the platform (win or

mac).
userAgent Bria iPhone 1.4.0 User agent information built into the
softphone client.
address 10.10.10.10 IP address of the user connecting to Stretto
uuid 54ada729dbe9c6d60c40770571e5cd5ede108df5 The UUID of the requestor’s softphone.

Item Example Description
method POST HTTP method of the request: POST or

GET.
httpCode 200 Response code for the HTTP request itself

(not for the implied provisioning request).
For example, 200
httpStatus OK Response status for the HTTP request itself

(not for the implied provisioning request).
For example, OK.
clientError Identifies the code for a Stretto internal

error.
tag Not currently used.
template T_mobile The template that was selected by Stretto

for this provisioning request
traceEvents Skipping password check for test access See below for a complete list of event
messages.
by [email protected]
groupName acphone.com The group to which the user belongs.
For example
110928173138-0400,[email protected],/login,mob,iPhone2%2C1,iPhone Services iPhone

0.1,97.65.224.2,54ada729dbe9c6d60c40770571e5cd5ede108df5,POST,200,OK,,,T_mobile,Skipping password
check for test access by [email protected], acphone.com
Trace Events List
Event Message Type Comment
Assigned value <value> from attribute pool Info

<attribute pool name> for user <username>
Attempting LDAP validation to <LDAP URL> Info
Checking upgrade for user <username>, current Info

version=<version>, desired version=<version>
Could not add device <device> for user Warning Login does not fail.
<username>
Could not bind LDAP session handler URI <LDAP Error You are set up for LDAP authentication. Login fails because the LDAP
URI> and bindDn=<Bind DN>: <LDAP return server refused the request.
code> - <LDAP error message>
Could not create LDAP session handler for Error You are set up for LDAP authentication. Login fails because the LDAP
userName=<username> with URI=<LDAP URI>: server refused the request.

<LDAP return code> - <LDAP error message>
Could not parse Mobile Login request: <Login Info A random request (not from a Bria softphone client) has been received
Document> at Stretto.
Could not replace device for user <username>, Warning Login does not fail.
device <device>
Could not search LDAP for baseDn <base DN Error You are set up for LDAP authentication. Login fails because the LDAP
value>, filter <LDAP Filter>: <LDAP return code> server refused the request.
- <LDAP error message>
Could not update device last access for user Warning Login does not fail.
<username>, device ID <ID>
Device limit (<number>) exceeded for user Error Login fails

<username>
Device not added for test access Info You are using the Test Provisioning feature, so the device is not added
to the user's device list.
Device not updated for test access Info You are using the Test Provisioning feature, so the device is not
modified on the user's device list.
Exception while matching <Discriminator> with Error Login fails. You may have specified a discriminator with bad formatting.
<Discriminator pattern>
Expired device not replaced for test access Info You are using the Test Provisioning feature, so the expired device
(std:deviceAgeDays attribute) is not removed from the user's
device list.
Group <group name> is suspended Error Login fails
Group <group name> was not found Error Login fails
Group not specified in request from <username> Error Login fails
IP Screening is on: User <username> not allowed Error Login fails or a remote update (refresh) causes the user to be logged
from IP <IP address> off.
LDAP authentication is on. Skipping Info You are set up for LDAP authentication. Login does not fail. You have
authentication for <username> because LDAP set the std:ldap:ignoreError attribute to true and all the
servers are unreachable. servers are unreachable.
LDAP data retrieval: Error processing user Error Login does not fail. You are set up for LDAP authentication. LDAP
<username>: <HTTP Error Code> - <Error authentication includes data retrieval but the data could not be
Message> retrieved.
LDAP data retrieval: Setting attribute '<attribute Info You are set up for LDAP authentication.
name>' from LDAP attribute '<attribute name>',
value=<value>
LDAP data retrieval: Skipping LDAP attribute Error Login does not fail. You are set up for LDAP authentication. LDAP
<attribute name> for user <username> (too long - authentication includes data retrieval but the data could not be
not a string?) retrieved.
Maximum devices (<number>) is not valid Error Login fails. The max devices was probably set using the API and a
letter instead of a number was specified.

No attribute pool entries for assigning value to Error Login fails

user <username> for attribute <name>
No attribute pool for assigning value to user Error Login fails

<username> for attribute <name>
No LDAP response for baseDn <base DN>, filter Error You are set up for LDAP authentication. Login fails because the LDAP
<LDAP Filter>: <LDAP return code> - <LDAP server refused the request.
error message>
No unique ID for this device, rejecting Error Login fails; the login request did not include a device ID
No unique ID pattern, skipping because tracking Info If a desktop brand does not have tracking then the device ID is not
is not enabled for this device. included in the URL. Stretto detects this and assumes "tracking is off".
Parent Group <parent group name> of <group Error Login fails

name> is suspended
Passwords don't match for user <username> Error Login fails
Profile is not defined for user <username> Error Login fails
Profile templates not found for profile <profile Error Login fails
name>
Redirected to <URL> Info User login request has been redirected to another Stretto.
Replacing expired device <device> for user Info The Device Age feature is being used (std:deviceAgeDays). A
<username> with <device> device has expired since the last login and now the user is logging in
from a new device that will replace the expired device in the Stretto list.
Skipping LDAP service for test access by Info You are set up for LDAP authentication. You are using the Test
<username> Provisioning feature, so LDAP is being skipped.
Skipping password check for test access by Info You are using the Test Provisioning feature, so the password is not
<username> being verified.
Template <template name> not found Error Login fails
Template does not exist Error Login fails
Template not found for <Profile> Error Login fails
Template provisioning response could not be Error Login fails

generated for <username>
Upgrade required for <username>, version Info

<version>
User %s password could not be decrypted. Check Error There is a problem with the encryption keys on your Stretto. Contact
encryption settings or contact support. CounterPath.
User <username> is suspended Error Login fails
User <username> not found Error Login fails

Viewing User Traces

The User Traces provide detailed information about a user’s login attempt. The User
Traces provides more detailed information than the Event Log. The User Traces are
available from the Users screen.
To view User Traces
1. In the Group page, click Logs > Event Logs.

2. Specify the number of records to show on each page and filter the records by date
or text string.
3. To save the records to a file, click Download All or select some records and click
Download Selected.
A log file is downloaded.
Each file contains information on one login or login attempt by one user. Trace files are
created only for valid users, not for users in unknown groups or unknown users in known
groups. For any valid user, the login attempt may be successful or it may be unsuccessful
(for example, user is suspended, user enters incorrect password).
The User Trace files contain more detailed information than the Event logs.
Files are accumulated for 7 days.
Each file consists of these five sections

l User trace header. Shows the login ID of the user, and the date and time the user
logged in or attempted to log in.
l Request. Shows the contents of the HTTP POST that was sent from the user's
device to Stretto. This is the user's login request.
l Details. Shows:
l l The user record in the Stretto database.
l The attribute name/values for this user. The values could come from the
group, the template for this user, or the user. The attributes shown include
some internal data elements (ccs:xxx) that are not visible in Stretto Admin.
These internal data elements may be:

l Set internally by Stretto. For example, ccs:userName is the attribute that

holds the Provisioning Username you created for the user the Edit User
dialog.
Or captured from the login request. For example, in the following
l
example, ccs:clientType shows the current login request is from Bria

desktop.
Response. Shows the provisioning response sent down to this user.
l If the login attempt succeeded, the response is similar to the one below (which
shows data for Bria desktop).
l If the login attempt failed, the response is a few lines describing the reason for
the failure. For a list of reasons, see Login error messages.
l Event log. The User Event Log that corresponds to this User Trace Log. See User
> Logs > Event Log for this user. See Viewing and downloading Event Logs.
Sample
-- User trace header --

Date created: 2013-05-21 18:12:14 -- Tue May 21 18:12:14 EDT 2013
---- Request ----
&Username=kperera%40acphone.com&Password=********
&spid=acphone.com
&uuid=1a9de6e89534a3b5ff6d5eaeb8235fcd831845e9&build=70220
&platform=windows
&&Username=kperera%40acphone.com
&Password=123456
---- Details ----
CcsSsd {
Method: POST
Address: 66.38.133.13
URL: /login
Query:
UserGroup: acphone.com
UserName: [email protected]
Device: windows
NextService :
Template: P_Asia
CcsUserRecord: CcsUserRecord {
userId: 18445
userName: [email protected]
password: ********
suspended: false
templateId: 802
metaData:
}

Attributes {
ccs:address 66.38.133.13
ccs:clientError
ccs:clientType desk
ccs:device windows
ccs:groupName acphone.com
ccs:httpCode 200
ccs:httpStatus OK
ccs:lastProvision 1369174334
ccs:method POST
ccs:password ********
ccs:remoteIp 66.38.133.13
ccs:req:
ccs:req:build 70220ccs:req:Password ********
ccs:req:platform windows
ccs:req:spid acphone.com
ccs:req:Username [email protected]
ccs:req:uuid 1a9de6e89534a3b5ff6d5eaeb8235fcd831845e9
ccs:template T_desktop
ccs:timestamp 130521181214+0400
ccs:url /login
ccs:userAgent Bria 3 release 3.5.2 RC12 stamp 70220
ccs:userName [email protected]
LicenseKey 1800W13DD3PD8Y8X9MP3N0226
logServerName https://myprovisioningserver.com:18082/CCSLogServer/submit
sipDomain acphone.com
sipPassword ********
sipUserName 1331
std:logserver:enable true
std:logserver:password ********
std:logserver:user emilywilding
std:usertrace:enable true
stunServer acphone.stun.com
}
}
---- Response ----
[DATA]
LicenseKey=1800W13DD3PD8Y8X9MP3N0226
Success=1
[SETTINGS]
proxies:proxy0:domain=acphone.com
proxies:proxy0:password=********
proxies:proxy0:transport=udp
proxies:proxy0:username=1331
[##MEMORY##]
proxies:proxy0:enabled=
---- Event Log ----
130521181214+0400,[email protected],/login,desk,windows,
Bria 3 release 3.5.2 RC12 stamp 70220,66.38.133.13,POST,200,OK,,,T_desktop,acphone.com

Viewing Enhanced Client Traces (device logs)

You can use Stretto to view Enhanced Client Traces, which are device logs created by
the softphone clients. The user can send device logs, which record information about
activity on Bria, from their softphone client. The logs are sent to Stretto, where you can
view them.
The Stretto administrators must have the View client traces option enabled under their
Admin Options in order to view Enhanced Client Traces.
Accessing Enhanced Client Traces

There are three ways to access the Enhanced Client Traces logs:
l After logging into the Stretto Admin web interface, click Client Traces. In the
Enhanced Client Traces screen, you can search all groups you have access to, or
filter it by a group, user, or log reference number.
l To view the logs for all users in a specific group, use the Group screen. In the
toolbar, click Logs > Enhanced Client Traces; the Enhanced Client Traces screen
opens with the logs sent by all users in the group.
l To view the logs for a select user, use the Users screen. Select a user, then in the
toolbar, click Logs > Enhanced Client Traces; the Enhanced Client Traces screen
opens with the logs sent by the user.
Working in the Enhanced Client Traces screen

You can filter the list of files using any combination of several filters:
l Group: Select a specific group. Subgroups are included in the search.

l Username: Enter a username to list only logs that contain this name in the file
name.
l File name contains: Enter characters to list only logs that contain these characters
in the file name. Keep in mind that the log reference (which your end user may
provide to you) is part of the file name, so this is a way to find a specific log.
l Full text search: Enter characters to list only logs that contain these characters in
the file contents.
Download a log by clicking a log file name.

Enhanced Client Traces Log contents

For information on the Enhanced Client Traces logs, see:
l Desktop sample log for Enhanced Client Traces
l Mobile sample log for Enhanced Client Traces
Desktop sample log for Enhanced Client Traces

Read this topic if you are using the Stretto Platform to provision softphone clients and
your Stretto deployment includes the Enhanced Client Traces feature.
When users send logs from their devices, the logs are sent to Stretto where you can view
them from the Client Traces tab or the Users screen. See Viewing Enhanced Client
Traces (device logs) for information on how to view the log.
General structure of the Desktop log

Each time Bria desktop logs in, a new data collection starts. Generating a file captures all
the data from login until that point. Information collection then continues to accumulate,
so that if a second file were generated, it would contain all the information since startup
(not all the information since the last generation).
The log is structured as follows:

l Log file header. System Information, Account Settings, Codecs. This information is
generated once.
l Activity Stream. Activity on the softphone. Information collection is started as soon
as the softphone is started or logs in and continues until shutdown or logoff.

Sample - Desktop log when a call fails for "No common codecs"
Startup
1-9: Information about the user and Desktop softphone.
12-21: Information about the computer.
22-31: Key information about the configuration of each account. In this case, only one
account is set up.
32-36: A list of enabled codecs. Note that in this example, the only audio codec is OPUS.
User places phone call

39-41: Low level message; you can ignore these messages.
42: Identifies a SIP transaction outgoing from the softphone.
43-51: Details of the SIP transaction: INVITE to [email protected] from

[email protected].
52-68: Contents of the SIP header and body. Line 63 specifies the codecs being offered
in the INVITE.
69: Identifies a SIP transaction coming into the softphone.
70-79: Details of the SIP transaction: The response to the request is 100 “Giving a try”,
indicating that the INVITE is in progress.
81-94: Details of the SIP transaction: Another response, 180 “Ringing”, indicating that the
call is ringing at the other party ([email protected]).
More responses and acknowledgment

96-106: Details of the SIP transaction: The final response is 488 “Not acceptable here”.
Line 103 shows the reason: There are no common codecs between the two endpoints.
This means that the other party ([email protected]) does not have the OPUS codec
enabled.
107-114: Low level message; you can ignore these messages.
115: Identifies a SIP transaction outgoing from the softphone.
116-128: Details of the SIP transaction: The softphone is acknowledging the 488
response from the other party.
Mobile sample log for Enhanced Client Traces

Read this topic if you are using the Stretto Platform to provision softphone clients and
your Stretto deployment includes the Enhanced Client Traces feature.
When users send logs from their devices, the logs are sent to Stretto where you can view
them from the Client Traces tab or the Users screen. See Viewing Enhanced Client
Traces (device logs) for information on how to view the log.
General structure of the Mobile log

The log is structured as follows:
l Identifying information.
l A line that references “sip_log.c” identifies the beginning of a “log message”. This
line includes a summary of lines that follow.
l Each log message provides details about the SIP message that has occurred.
l Each log message terminates with an --end msg-- line.

l The end of the log displays summary information about the device and softphone
configuration.
Sample - Mobile log when a call fails for "No common codecs"
Startup
1-7: Identifying information.
8-25: Application diagnostics: Information on what the application is doing. In this case,
the app is performing low-level initialization.

Registration request
26: Summary of the next few lines indicating they represent a REGISTER request.
Whenever logging is turned and the user clicks the Apply button, Bria performs a fresh
SIP registration. Note that there is no Apply button on Bria Android editions, so these
lines are omitted.
26-42: Details of the registration.
43-45: Application diagnostics. In this case, handling.
46: Another registration request.
47-60: Details of the request.

63: Summary of the next few lines indicating they represent a response to the
registration.
64-76: Details of the response.
77-78: Application diagnostics. In this case, Bria is contacting the license server. Bria
always contacts the license server after an initial registration (but not after a registration
refresh) in order to check the authenticity of the client.
79-85: Application diagnostics. In this case, the application is performing actions at the
request of the user: it is placing an outgoing phone call.

User places phone call
86: Summary of the next few lines indicating they represent an INVITE request.
87-112: INVITE from [email protected] to [email protected]. Lines 101-110 show

the contents of the SIP header and body. Note the codecs being offered in the INVITE.

113: Summary of the next few lines indicating they represent a response to the INVITE.
114-125: The response is a 100 “Trying”, indicating that the INVITE is in progress.
126-130: Application diagnostics. In this case, the application is performing actions

relating to the call.
130: Summary of the next few lines indicating they represent another response to the
INVITE.
131-144: The response is a 180 “Ringing”, indicating that the call is ringing at the remote
end ([email protected]).

146-151: Application diagnostics. In this case, the application is performing actions

relating to the call. It is handling the response to the INVITE.
152: Summary of the next few lines, indicating that they represent a response to the
INVITE.
153-164. The response is 488 “Not acceptable here”. Line 160 shows the reason: There
are no common codecs between the two endpoints.
165: Summary of the next few lines, indicating that they represent an ACK from the other
party.
166-176: Details on the ACK.

User sends the log
177-184: Application diagnostics. In this case, the application is handling the 488
response and displaying information to the user (line 183).
185-186: Application diagnostics. In this case, the application is setting up audio ready for
the next call.
187-189. Application diagnostics. In this case, the user has just press Send Log and Bria
is prompting the user to confirm.

Current configuration as per provisioning response
189-232: The content of the most recent provisioning response received from Stretto.

Current configuration applied by Bria Mobile
242-297: The current configuration of Bria. Some of this information comes from the
provisioning response from Stretto, some from exposed Settings screens, some from
internal data, and some is auto-detected by Bria (for example, whether the transport is
currently Wi-Fi).
243-250: Global preferences.
252-270: Global service configuration.

271-295: Account-specific configuration. There are two accounts – 0 (SIP) and 1 (XMPP).
296: The response from the log server, indicating that the device log was successfully
received by the Stretto log server.
Viewing a list of all devices in a group

The Group page includes a Devices tab that lists all user devices, along with UUID, for
the selected group. Only active devices are included in the list; if a user or administrator
deletes a device, it does not appear in the list.
To view a list of all devices in a group
1. Click on the group you want to view the list of devices for.
2. Click the Devices tab on the Group screen.
3. Change how the list is sorted by clicking a table heading.

4. Optionally, click Download to export the list to a .csv file.
Viewing Stretto reports

Stretto provides various reports that show statistics about login, device counts, and user
activity.
Administrators can view Stretto reports in several ways:

l Viewing using Stretto Admin: Use the following steps to view reports. Your parent
administrator might need to enable the admin option "View reports" in order to view
reports.
l Downloading Reports: Using Stretto Admin, you can download any report to a .csv
file.
l Emailing Reports: You can be set up to receive any report by email. Your parent
administrator needs to set up email reports for you.
This section describes how to use Stretto Admin to view a report, and download it.
Select a report
To view a report
1. From the toolbar, click Reports. The Reports Dashboard opens.

2. Click Report and choose a report type from the list.

Filter data
Configure filters in order to retrieve data you are looking for.
Available filters are
Filter To Filter Reports to Include
Groups Only data for the specified group or groups.
Dates Only data for the specified time period.
Users Only data for the specified user or users.
Profiles Only data for users associated with the specified profiles.
Tags Only data for users associated with the specified tag. See below.
Admin Only data for groups who are controlled by the specified administrator.
Blades Only data for the specified blade.
MOS limit Only data in the range of the specified MOS scores. Requires the UEM Module.
If Stretto displays No results found, try selecting a group in the filter.

Set the breakdown of statistics

For some reports, you can display a breakdown of statistics by device
l Device Type: The type of Bria. Phone, tablet, desktop. (Bria mobile running on an
Android tablet would be a “phone”)
l Device Model: Mobile only. For example, iPhone3, Galaxy Nexus, ADR6400L
l OS: ios/android/windows/mac/linux
l OS Version: The OS version running on the device. For example, WIN7, WIN8,
OSX10.8.2.
l Load version: The Bria release number.
You can change the order of the breakdown columns (and thereby the Count) by clicking
Breakdown order:

Example:
This example shows one breakdown for the acphone.com group:
Download the report

If you want to save the report, click the Download button on the top right corner and
follow the prompts. The report is saved into a csv file.
Reporting API activity
Stretto offers reports access via the Stretto Platform API.
API Activity – Attempts

Shows a count of HTTP/HTTPS API requests by the specified administrator. This count
includes both successful and failed authentications.

API Activity – Authentication Challenge

Shows HTTP/HTTPS API requests by the specified administrator and that were sent an
authentication challenge response (401 or 407).
API Activity – Authentication Failures

Shows HTTP/HTTPS API requests by the specified administrator, where an incorrect
password was provided.

API Activity – Error Response

Shows HTTP/HTTPS API requests by the specified administrator and where the
authentication succeeded but the request resulted in an error code rather than the
expected response. For example, the API request attempted to modify a user, but the
user does not exist, which resulted in error code 800. Possible errors are listed in the
“Result Codes” section of Stretto Platform API Developer's Guide.
Reporting codec usage

This set of reports appears only if you set up Stretto to track royalty-bearing codecs.
There are three codec usage reports available, one for each royalty-bearing codec:
l AMR-WB
l G.729
l H.264.
These reports are useful only if you are set up to pay for royalty-bearing codecs on a “per
activation” (Pay-as-you-go) basis, rather than having paid for them in advance. You will
have discussed your method for paying for these codecs when you signed up for Stretto.

Each report shows information about initial activations of the codec in the specified time
period.
An activation is considered “initial” when it is the first activation for a given

user/device/codec combination (in this way, repeat logins do not increase the codec
count).
If the Known Devices report shows data (indicating that you have at least set up correctly
for device usage tracking) but this Codec Usage report does not show data in the left-
hand section for a specific group, verify that:
l You actually have royalty-bearing codecs in Bria and that you have enabled the
specified codec in this group.
l You have set the std:maxDevices attribute for this group.
l You have set the std:rbc:enable attribute for this group.
Reporting meeting activity

Use the Meeting Activity reports to analyze how client applications are interacting with the
Stretto Collaboration module.
Meeting Activity - Connections
The Client Connections report shows the number of client connections to the group's
meetings within the specified period. This data is viewable in these formats:
l Line chart
l Table
The chart shows client connections and disconnections, allowing you to see not only the
volume of meeting activity but also where there is a discrepancy between the
connections and disconnections and if there are spikes or dips in usage during certain
periods.

Data points include:

l Connects - The number of clients that connected to a meeting during the interval.
l Disconnects - The number of clients that disconnected from a meeting during the
interval.
Meeting Activity - Logins

The Meeting Login Activity report shows data for client logins and subscriptions to the
group's meetings during the specified period. This data is viewable in these formats:
l Line chart
l Table

l Logins - login requests made by clients
l Failed logins
l Subscribes - the number of times participants have subscribed to a bridge.
l Unsubscribes - the number of times participants have unsubscribed from a bridge.

Meeting Activity - Message I/O
The Meeting Message I/O report shows data for client-server interactions for the group's
meetings during the specified period. The data is viewable in these formats:
l Line chart
l Table

l Requests - A request message from a client.
l Responses - A response message from a client.
l Screenshare Updates - Screen data from a client.
l Pings - A ping request received from a client.

Meeting Activity - Meeting Activity

The Meeting Activity report shows basic meeting events for the group's meetings during
the specified period. The data is viewable in these formats:
l Line chart
l Table

l Meeting started - The number of times meetings started during the interval.
l Meeting ended - The number of times meetings ended during the interval.
l Mute changed - The number of times a client muted or un-muted their client during
a meeting during the interval.
l Participant kicked - The number of times a meeting moderator ejected a participant
from a meeting during the interval.
Meeting Activity - Call Activity

The Meeting Call Activity report shows how many of the group's meeting calls were
started, ended, and joined during the specified period. The data is viewable in these
formats:
l Line chart
l Table

l Call started - The number of meeting calls started during the interval.
l Call ended - The number of meeting calls ended during the interval.
l Joined Meeting - The number of clients that joined a meeting during the interval.
Reporting device counts

Stretto offers several reports on device counts.
Device Counts – Provisioned Device Counts
This report provides the following information about devices currently known to Stretto.
l Provisioned Group Devices: The maximum possible number of devices for the
group.
For example, if max devices is set to 2 at the group level and there are 10 users set
up on Stretto:
2 x 10 = 20

If max devices is set as above, but with user A set with an override of 3 and user B
set with an override of 4:
(2 x 8) + (3 x 1) + (4 x 1) = 23
A group shows zeros (0) if you have set up to track device usage but no users in the
group have a number in their std:maxDevices attribute or no users exist in the group
l Actual Group Devices: The number of devices that have actually logged on.
For example, if user A has logged on via 2 devices, B via 3 devices and C, D and E
via 1 device each:
2+3+1+1+1=8
A group shows zeros (0) if you have set up to track device usage but no users have
logged on during the specified time period or no users exist in that group.
Device Counts – New Activations
This report shows the number of users who have done a first-time login during the
specified time period.
A group show zeros (0) if you have set up to track device usage but no users have logged
on during the specified time period or no users exist in that group.

Device Counts – Recent Logins
This report shows the number of devices (new and existing) that have logged on during
the specified time period. You can show a breakdown of information by selecting one
group.
Device Counts – Active Devices

This report shows information about the devices that have logged in during the specified
time period. The difference between Active Devices and Known Devices is that the
Active Devices report excludes deleted devices.
Device Counts – Active Devices by Type

This report shows the count by the device type, such as desktop, mobile phones and
tablets as well as 'unknown' devices that logged in during the specified time period. The
difference between Active Devices and Known Devices (in the next section) is that the
Active Devices report excludes deleted devices.

This report only shows a summary. If the administrator wants to know detailed
information, such as how many iPhone 5 versus iPhone 7, use the other report “Active
Devices” which shows the breakdown information of each device type.
Device Counts – Known Devices

This report shows information about the devices that have logged in during the specified
time period. The report includes deleted devices.
Device Counts – Known Devices by Type
This report shows the count by the device type, such as desktop, mobile phones and
tablets as well as unknown devices that logged in during the specified time period. The
report includes deleted devices.
This report only shows a summary. If the administrator wants to know detailed
information, such as how many iPhone 6 versus iPhone 8, use the other report Known
Devices which shows the breakdown information of each device type.

Reporting Stretto Sync activity

Stretto offers several reports on Stretto Sync activity. This section appears when the
Stretto Sync feature is enabled
Sync Activity - Connections

This report indicates how many devices are connected to and disconnected from their
sync account on Stretto during the period.
Sync Activity - Sync Accounts

This report indicates the number of sync accounts per group, as well as the number of
sync users with one or more sync accounts.
Sync Activity - Logins
l Logins: the number of login attempts for the Sync feature.

l Failed Logins: the number of attempts that failed to log into the sync account.

l Set Account: the number of requests from the client to update the sync account list;
for example, when sync gets turned off for a particular account.
l Account Created: the number of the first sync account created for a user.
Sync Activity - Message I/O

Message I/O indicates traffic volume for the sync feature, such as the number of requests
from the client as well as the number of responses from Stretto.
Forwarded messages indicate how many messages Stretto sends in order to

synchronize other enabled devices with the user’s activities on the first/primary device.
For example, when a user reads a new message on the primary device, Stretto
communicates that information to other enabled devices in order to sync the message
history. This is a forwarded message, which is different from a fetch.
Sync Activity - Item Activity
A conversation refers to a history of a chat with a specific person while an item refers to a
message in a conversation. A user typically has multiple conversations in their Messages
window, and one conversation could have hundreds or thousands of items.

Sync Activity - Fetch Activity

A fetch is an activity when a user downloads previous messages and/or conversations to
a device. A conversation refers to a history of a chat with a specific person while an item
refers to a message in a conversation. Get Message Count indicates how many unread
messages are available in the account.
Reporting user activity

Stretto offers several reports on user activity.
User Activity – User Counts

This report shows a number of groups and users currently set up in each group and
subgroup.

Column Description
Number of Direct A number of the subgroups created right under the selected group. Excludes grand children (a
Subgroups subgroup of a subgroup) and below.
Number of All A number of all subgroups under the selected group, including children and below.
Subgroups For example, if the first column shows 3 and the second column shows 15, this group has 3
children and 12 groups underneath the children groups.
Allocated Children A number of maximum users that have been allocated to its subgroups. This number
represents a limit of users as opposed to the actual count. Limiting the number of users per
group (Maximum users) describes how to allocate a number to subgroups.
Actual Group User A number of users that have been created in the selected group. Excludes users in children and
Count below.
Actual Subgroup A number of users that have been created in all the subgroups, including children and below.
User Count
Actual User Total A sum of Actual Group User Count and Actual Subgroup User Count.
Max User Limit A number of maximum users limit configured in the selected group, as described in Limiting the
number of users per group (Maximum users).
User Activity – Logins

This report shows login information from softphone clients. The first two columns show
login attempts, separated into HTTP and HTTPS. The attempts are a combination of local
authentications (those that do not involve an external server such as LDAP) and external
authentications.
The last column shows successful logins.

User Activity – Authentication

This report shows the results for local login attempts (those that do not involve LDAP or
SOPI).
Local login attempts are processed in three steps:

l Find the group
l Find the user
l Validate the password
Column Description
Local Both successful and unsuccessful local logins.

authentication
Local auth failures Local logins that failed because the password was incorrect. For some other reasons for
failure, see the User Activity - Screened report.
User not found The user portion in the username entered by the user is wrong. For example,
[email protected] does not exist in the group acphone.com.
These attempts did not get to the “authentication step” so they are not part of the Local
authentication column.
User Activity – LDAP
This report shows data only if you have integrated Stretto with an LDAP server in order to
have user logins authenticated by that server.

Column
Column Description
Number
1 requests - The number of HTTP requests from the client to the LDAP server.
HTTP
2 requests - The number of HTTPS requests from the client to the LDAP server.
HTTPS
3 Logins The number of requests that the user is successfully authenticated by an LDAP server.
Successful
4 Alternate The number of redirects; if the LDAP server is not available and a failover server is set up, redirect the
request to the alternate server
5 unavailable The number of requests that end up with none of the alternates being available.
6 auth failures The number of auth failures; if an LDAP server is available, the password is validated and either
succeeds or fails.
7 data retrieval The number of requests that include retrieval of data from the LDAP if Stretto has been set up for data
retrieval.
l Each time column 4 increments, column 1 or 2 also increments. So if an HTTP

request comes in and gets redirected to LDAP server B and then to LDAP server C,
then column 1 shows “3” and column 4 shows “2”.
l Column 5 increments only once for each login attempt. So if the request goes from
LDAP server A to alternate B to alternate C and ultimately fails, column 5
increments only 1.
l Columns 5 to 7 combine HTTP and HTTPS requests.
User Activity – ECS

This report shows data only if you have integrated Stretto with an external configuration
server (ECS) in order to have user logins authenticated by that server.

Column
Column Description
Number
1 requests - HTTP The number of HTTP requests from the client to the ECS
2 requests - The number of HTTPS requests from the client to the ECS.
HTTPS
3 Logins The number of requests that the user is successfully authenticated by the ECS.
Successful
4 unavailable The number of requests that end up with no ECS being available.
5 auth failures The number of auth failures; if an ECS is available, the password is validated and either succeeds
or fails.
Columns 3, 4, and 5 combine HTTP and HTTPS requests.
User Activity – Updates

This report shows data only if you have implemented the Remote Upgrade feature (Bria
desktop only) and/or the re-provisioning (refresh) feature (Bria mobile only).
Shows upgrade and update (setting refresh) requests, separated into HTTP and HTTPS.
User Activity – Screened

This report shows login requests from clients that failed because the IP was blocked, the
user was suspended, the group was suspended, or the maximum devices limit was
reached for the user. (Blocking may be performed by Stretto and only if the optional “IP
Screening” feature is implemented; for information on this feature, contact CounterPath.)

User Activity – Usage Summary

This report shows a summary of activities for each user. It includes a number of devices
the user has logged on as well as a number of calls and IMs the user has made and
received.
Column Description
User The user's Stretto provisioning username.
Number of Devices A number of the devices the user has logged on during the specified
time period. This number excludes deleted devices.
Number of Calls A number of calls the user has made and received during the
specified time period. It includes both successful and failed calls.
Failed Calls A number of calls that failed.
Audio Calls A number of successful audio calls the user has made and received
during the specified time period. It excludes failed calls.
Video Calls A number of successful video calls the user has made and received
during the specified time period. It excludes failed calls.
Message IN A number of incoming instant messages to the user's account(s).
Message OUT A number of outgoing instant messages from the user's account(s).
Viewing User Experience Metrics (UEM)

The User Experience Metrics module incorporates both analytics and voice quality
monitoring features, which can provide valuable insight into end-user experiences, user
behaviors, quality of service, and usage patterns.
Using data collected from Bria clients, UEM can display it in raw form, export to an
application such as a spreadsheet, or display it as a chart or graph. The dashboard
feature provides operations staff with a reference page with up to four reports, which
makes reviewing analytics data quick and efficient. Support staff can proactively detect
and pinpoint voice quality issues in the network and measure historical voice quality
trends.

Areas of reporting
Data is collected and stored by the Bria client and then sent to Stretto when a timer
expires or after each call. UEM provides information on that data in the following two
areas:
l Voice quality reporting provides information about the voice quality for calls. Data
collected about each user’s phone calls is sent to Stretto at the end of each call.
Stretto accumulates the data for all calls made within a five-minute period, then
performs some calculations on that collection of data — typically the minimum and
maximum data point is captured and the mean or average of all points is calculated.
These three data points can then be viewed graphically in Stretto Admin.
Data collection starts when the call starts and ends when call ends. Each time the
call goes on or off hold, the current segment of data is closed, and a new collection
opens.
l Analytics reporting provides detailed information about the softphone client and
device, about accounts on the client, about, about phone calls and about instant
messages.
Most analytics data is captured when a report is sent to Stretto. An exception is the
call history; it will be collected as follows: The current segment of data is closed and
a new collection opens when std:vqmserver:timer expires.
For example, std:vqmserver:timer is set to 6 hours. When Bria starts, the timer
starts running and collection starts. A new storage segment is created every 6
hours.
Dates and times in User Experience Metrics

This section describes how to handle dates and times in UEM.
Dates and times

l Dates and times in all chart view of reports are shown for the timezone of the
computer where the reports are being viewed.
12 PM is 12:00 noon
12 AM is 12:00 midnight

l Dates and times in the Report Data report are stored in Coordinated Universal Time
(UTC+0), and are translated into your browser’s timezone for display. When times
are shown as text data, the timezone information is typically included (for example,
Start time: 2017-07-26 02:00:33 PM UTC-0400).
Periods
Data in reports is shown in 5 minute "periods". The time of the period is the end time. So a
data point on at 6:15 covers the data from 6:10 to 6:15.
Date and time range

You can select the date and time range. In this example, the 48 hours starting at 12:00
p.m. on March 23.
Now, when you click the blue arrow buttons, you will move to 12:00 p.m. but two days
later or earlier.
To change the start time of the range, click the End Time box, and select a time from the
list or type a time.
How "min, avg, max" data is collected

For the reports that show a minimum, average, and maximum, the data is collected as
follows:
l A "phone call segment" is an uninterrupted phone call, or a segment of a phone call
between the call being taken off hold and put back on hold (or ending). So, for
example, if a phone call is put on hold and taken off hold, it consists of two
segments.
l During the segment, data is collected. Data maybe collected only once or it may be
collected at regular intervals. Different data is collected for different reports.
l When the segment ends, Bria sends one data point to Stretto. This data point may
be an average of all samples, or it may be the one data point collected.
l Stretto collects the data from all segments for a 5 minute "period".
l Stretto then calculates the minimum, maximum, and average for all data points of
all users in the group for that period.
l Each "set" of three points is charted on the report.

Note: When viewing a larger timescale, data points will be merged. For example, when
viewing a one-month timescale, data points are merged into 24-hour bins.
So the raw data consists of:

l A Bria data set for a given segments.
l A Stretto data set for a given period.
Example: Here is a closeup of the data for a MOS CQ Trend report, showing the three
data points being charted every 5 minutes.
Each set may represent one segment or several segments.
l If only one segment is collected during the period, the three dots will overlap.
l If there are no segments collected at all during a given period, no data is charted
(there is no dot).
You can view all the data, or you can filter the data to view only the data for a specific
user. In this case, when Stretto calculates the points for the period, it includes only data
received from that user.

Viewing User Experience Metrics on voice quality

Voice quality in User Experience Metrics (UEM) can be visualized in Stretto Admin by
producing the following graphs:
l Mean Opinion Score (MOS)
l Delay
l Jitter Buffer
l Packet Loss
l Burst/Gap Loss
l Call Volume
l Raw Report Data
To begin viewing voice quality metrics:
1. Select the Reports tab in Stretto Admin.

2. Select a group and time period.
3. Click Report and select a Voice Quality report.
Burst/Gap Loss
Bursts or burst phases are the phases of transmission in which packet loss or discard is
over 5%. Gaps or gap phases are the phases of transmission between the bursts. During
the burst phase, attempts are made to recover the lost packets. The burst phase ends
when the packet loss goes below 5%, which may occur either because the recovery
attempt succeeds or because the cause of the packet loss ceases. Bursts can be seen as
substandard phases, while gaps can be regarded as normal phases.
Burst Density
The Burst Density report shows packets lost during all the bursts that occurred during a
given period, expressed as a percentage of the total packets transmitted during the burst
phases.

Each data set from a Bria client consists of one burst density score that is the mean of all
scores for that user for that segment. There may be more than one burst during the
segment. A density score of 20% means that, on average, 20% of packets for this user
were lost during all bursts for this segment.
Each data set in Stretto consists of:

l Minimum: The minimum density amongst all users in a given period.
l Average: The average of all density amongst all users in the given period.
l Maximum: The maximum density amongst all users in a given period.
Burst Duration
The Burst Duration report shows burst segment lengths, in milliseconds, during the burst
phases. Each data set from Bria clients consists of one burst length that is the mean of all
burst lengths for that segment. There may be more than one burst during the segment.


l Minimum: The minimum duration amongst all users in a given period.
l Average: The average of all duration amongst all users in the given period.
l Maximum: The maximum duration amongst all users in a given period.
Gap Density
This report is identical to the Burst Density report, but for the gap phases rather than the
burst phases. The Gap Density report shows packets lost during all the gaps that
occurred during a given period, expressed as a percentage of the total packets
transmitted during the gap phases.
Each data set from Bria clients consists of one gap density score that is the mean of all
scores for that user for that segment. Keep in mind that there may be more than one gap
during the segment.
l Minimum: The minimum density amongst all users in a given period.

l Average: The average of all density amongst all users in the given period.
l Maximum: The maximum density amongst all users in a given period.
Gap Duration
This report is identical to the Burst Duration report, but for the gap phases rather than the
burst phases. The Gap Duration report shows gap segment lengths, in milliseconds,
during the gap phases. Each data set from Bria clients consists of one gap length score

that is the mean of all scores for that user for that segment. Keep in mind that there may
be more than one gap during the segment.

l Minimum: The minimum duration amongst all users in a given period.
l Average: The average of all duration amongst all users in the given period.
l Maximum: The maximum duration amongst all users in a given period.
Call volume
The Call Volume report shows the number of segments reported during each period.
Delay times
The Delay reports provide information on the amount of time it takes for a data packet to
be transmitted. By comparing the output from different Delay graphs, it's possible to
narrow down where in a packet's route that delays are introduced and by how much.

In the context of this report, a "delay" is the length of time for a signal to travel to the next
point in its route to the destination and then receive an acknowledgment in return. The
transmission of a packet may include multiple points between the sender and the receiver
and each step along the route — each "segment" — introduces a certain amount of delay.
l Segment A: Send packet from the softphone to the first router (for example, the
PBX or SIP proxy) and receive acknowledgment.
l Segment B: Send packet from the first router to the destination (likely multiple
points along the route) and receive acknowledgment.
l Segment C: Send packet from the destination to back to the first router (likely
multiple points again) and receive acknowledgment.
l Segment D: Send packet from the first router to the softphone and receive
acknowledgment.
Because these reports are based on data gathered from a Bria softphone, Stretto has
data on segments A and D only. A softphone itself has no data past the first router.
Round Trip
The Round Trip report shows the intervals between sending a packet and receiving a
response from the destination. In other words, it measures from the start of segment A to
the end of segment D.
Each data set consists of:

l Min: The lowest score amongst all users in the given period.
l Average: The average of all scores in the given period.
l Max: The highest score amongst all users in the given period.

In this example, the average delay was generally under 200 milliseconds, but around
17:00 the maximum delay spiked to more than 2000 milliseconds, which brought up the
average to over 1000 milliseconds.
One Way
The One Way report shows the intervals between sending a packet and receiving an
acknowledgment from the first point in the route (segment A).

This example shows the same time period as in the Round Trip report. The maximum
delay across segment A spiked to 1100 milliseconds compared to 2000 milliseconds
across the entire round trip. From this one can determine that segments B through C
account for 900 milliseconds of the total round-trip delay.
Jitter Buffer
Stretto Admin offers reports to help monitor the Bria jitter buffer during calls, which can
aid in the diagnosis of voice quality issues. The jitter buffer mitigates some voice quality
issues.
In VoIP communication, data packets that comprise the audio stream are sent in a
specific order and at a regular rate. Any delays in the delivery of these packets can lead
to packets being received late, in the wrong order, or not at all, which leads to loss of

voice quality. The variation between the expected packet frequency and the frequency as
received is referred to as "jitter".
To mitigate the effects of jitter, incoming packets are delayed in a temporary buffer — a
"jitter buffer" — from which an audio stream can be played with packets restored to a
regular rate and order. The jitter buffer should be large enough to accommodate the
maximum jitter without introducing a noticeable delay in playback. If the jitter rate
exceeds the frequency of the jitter buffer, then packets may get dropped, which has a
negative effect on voice quality.
Stretto Admin provides reports on the jitter buffer based on data from Bria softphones.
l Jitter buffer - nominal: This graph shows time that packets stay in the jitter buffer.
l Jitter buffer - max: This graphs shows the maximum delay of packets in the jitter
buffer.
Jitter Buffer - Nominal
This report shows the length of time in milliseconds that packets stay in the jitter buffer. A
higher number indicates a higher latency in the segment (the last step between the router
and Bria).

Each data set from a Bria client consists the mean delay in milliseconds for that user for
that segment.

l Minimum: The lowest delay in milliseconds.
l Average: The average delay in milliseconds.
l Maximum: The maximum delay in milliseconds.
Jitter Buffer - Max
This report shows the maximum jitter buffer sizes in this segment. Stretto collects these
maximum values as reported by Bria clients and reports the maximum, minimum, and
average.
Each data set from a Bria client consists of the jitter buffer delay for that user for that
segment.

l Minimum: The lowest delay in milliseconds.
l Average: The average delay in milliseconds.
l Maximum: The maximum delay in milliseconds.
Mean Opinion Score (MOS)

Mean opinion score (MOS) is a measure of the quality of calls in the form of a number
from 1 to 5 ("bad" to "excellent").

Score Description
5 Excellent
4 Good
3 Fair
2 Poor
1 Bad
Although in other contexts MOS might be derived based on gathering subjective user
input, Bria calculates MOS algorithmically based on objective measures of network
statistics like packet loss. Based on these measures, Bria assesses the impact of noise,
distortion, signal volume, echoes, and delays in the MOS calculation.
Call quality is measured in two basic categories:

l Conversational quality (CQ): MOS-CQ measures the call quality in both directions
including factors like echoes and delays.
l Listening quality (LQ): MOS-LQ measures the call quality in one direction only and
omits factors like echoes and delays.
The results of MOS-CQ and MOS-LQ are likely to vary depending on the audio codec
used in the calls — a wideband codec will likely provide a better user experience than a
narrowband codec, in which listeners receive a smaller range of audio frequencies. For
this reason, Stretto Admin produces MOS reports separately for wideband and
narrowband MOS.
Stretto Admin offers a few report types in both MOS categories (CQ and LQ) and for both
narrowband and wideband codecs.
l Call Cloud
l Trend
l Distribution
l Percentile
Call Cloud
The Call Cloud report shows the distribution of call quality over time, where dot size
indicates relative numbers of scores of that value — that is, a large dot at 4.5 and a small
dot at 4.0 means that more users experienced a MOS of 4.5 than 4.0 at that time.

Click a data point to show the total number of calls and the per-user number of calls.
Trend
The Trend report shows the MOS over time so you can determine if call quality is trending
towards the better or worse. Because this report omits the outliers that the Percentile

report shows, it can be regarded as a representation of the trending "average user"

experience.

Distribution
The Distribution report shows the number of calls for each recorded score during the
specified time period.
Each bar on the x-axis represents a different MOS and the height represents the number
of calls. A percentage indicates the percentage of the total number of calls that the bar
represents.
Percentile
The MOS Percentile report breaks down scores into six percentiles graphed over time.

For example, a score of 4.2 for "95th percentile" means that 95% of the calls in the period
had a score of 4.2 or less, while a score of 3.6 for "50th percentile" means that 50% of the
calls had a score of 3.6 or less.
Packet loss
Stretto Admin can report on packet loss over a specified time period.
Packet loss occurs when data transmitted over a network either fails to reach the
destination, and is usually caused by network congestion. A packet is considered lost
when:
l the packet failed to arrive at the endpoint
l the packet was discarded for arriving late
l the acknowledgment (ACK) to a packet was not received (if ACKs apply)
Network Loss Rate
This report shows packet loss across the network. Packet loss is expressed as a
percentage of the total packets transmitted during a specified period.

Each data set from a Bria client consists of one packet loss percentage that is the mean
of all packet loss percentages for that user for that segment.

l Minimum: The lowest percentage amongst all users in the given period.
l Average: The average percentage amongst all users in the given period.
l Maximum: The maximum percentage amongst all users in the given period.
Jitter Buffer Discard
This report shows the packets that were discarded by the jitter buffer at the receiving end.
The packets discarded are expressed as a percentage of the total packets received at the
during the specified period.
A packet will be discarded when:

l the arrives in the jitter buffer out of order and after subsequent packets have left the
buffer
l the jitter buffer is full
Each data set from a Bria client consists of one discard rate that is the mean of all discard
rates for that user for that segment.
Each data in Stretto set consists of:

l Minimum: The lowest percentage amongst all users in the given period.
l Average: The average percentage amongst all users in the given period.
l Maximum: The maximum percentage amongst all users in the given period.

Raw Report Data

Raw Report Data lets you view and download data in table format for several areas:
l The local side (the Bria softphone)
l The remote side (the other party in the call)
Data for both the local and remote sides is provided by the Bria softphone.
To add columns, click Show, choose columns to add, then click Update.

These columns can be added to the report:

l Jitter Buffer
l jitterBufferNominal
l jitterBufferMax
l networkPacketLossRate
l jitterBufferDiscardRate
l Burst Gap Loss
l burstLossDensity
l burstDuration
l gapLossDensity
l gapDuration
l Delay
l roundTripDelay
l oneWayDelay
l Signal
l signalLevel
l noiseLevel
l Quality Esitmates
l conversationalQualityR
l MOSLQ
l MOSCQ
Viewing analytic reports with User Experience Metrics

The Analytics area of User Experience Metrics (UEM) provides information on client
usage in the form of charts, graphs, and tables.
Analytics - Account Data

The Account Data report provides data on how SIP and XMPP accounts operate on the
network. In this report, each user initially has one record. Each time the user's data
changes, a new record is added, until each user has multiple records.

Column Description
Group The name of the Stretto group to which the user belongs.
Device ID The unique identifier of the user's softphone.
Created The date/time on which the record was created.
Account username The user's Stretto provisioning username without the @ domain.
Domain The user's Stretto domain (in other words the @groupname part of the username).
Outbound proxy The address (IP address or DNS hostname) of the outbound proxy configured for the account (if used).
Protocol The protocol used by the account (SIP or XMPP).
Enabled Whether the account is enabled (true/false).
Keepalive cell Whether the account is configured to use keepalive messages over a mobile network (true/false).
Keepalive cell interval The interval in seconds to send a keepalive message over a mobile network if enabled.
Keepalive Wi-Fi Whether the account is configured to use keepalive messages over a Wi-Fi network (true/false).
Keepalive Wi-Fi The interval in seconds to send a keepalive message over a Wi-Fi network if enabled.
interval
SIP cell refresh interval The interval in seconds before refreshing the SIP registration over a mobile network.
SIP Wi-Fi refresh The interval in seconds before refreshing the SIP registration over a Wi-Fi network.
interval
Cell NAT ICE Indicates if the SIP account is configured to use ICE for network firewall traversal over mobile networks
(true/false).
Cell NAT STUN Indicates if the SIP account is configured to use STUN for network firewall traversal over mobile networks
(true/false).
Cell NAT TURN Indicates if the SIP account is configured to use TURN for network firewall traversal over mobile networks
(true/false).
Wi-Fi NAT ICE Indicates if the SIP account is configured to use ICE for network firewall traversal over Wi-Fi networks
(true/false).
Wi-Fi NAT STUN Indicates if the SIP account is configured to use STUN for network firewall traversal over Wi-Fi networks
(true/false).
Wi-Fi NAT TURN Indicates if the SIP account is configured to use TURN for network firewall traversal over Wi-Fi networks
(true/false).
SIP Simple supported Whether SIP simple is supported (true/false).
Signaling transport The transport method used by the account (for example, TCP, UDP, or TLS).
Media encryption Whether encryption is used for audio and video streams (true/false).

Analytics - Audio and Video Codecs

The UEM Analytics reports include several reports that show the breakdown of codecs
used for all phone calls within the selected group and within the selected date range.
There are separate reports for codecs used for audio in, audio out, video in, and video
out.
The report can display the data as:

l pie chart
l line chart
l table
Analytics - Call Explorer

The Call Explorer offers a per-transaction view of calls for the selected group during the
specified period. This view combines data from several other reports so that each column
represents a different report on the individual data point.

VQM Session Data
Name Description
Call ID A unique identifier used during the SIP call.
Local ID The unique SIP identifier used by the local end. Not used.
Remote ID The unique SIP identifier used by the remote end. This ID is typically unknown or unused.
Orig ID Not used.
Local Address The local address includes the data needed to locate a call participant. It includes IP, port, and SSRC.
Remote Address The remote address includes the data needed to locate a call participant. It includes IP, port, and SSRC.
Local MAC A MAC address is a media access control address, which is a unique identifier for a device's network interface.
Remote MAC A MAC address is a media access control address, which is a unique identifier for a device's network interface.
VQM Local/Remote Metrics
Name Description
Start Time The time at which the call was started.
Stop Time The time at which the call was ended.
Payload Type The SIP/RTP payload type used in the call.
Payload A readable codec name for the Payload Type.

Description
Wideband codec A wideband codec encodes with higher quality with the assumption that the network has enough bandwidth.
Sample Rate The frequency in hertz used to record audio.

Name Description
Frame Duration The duration of audio contained within a single RTP frame.
Frame Octets The size of an RTP frame, measured in bytes.
Frames Per The number of frames (units of data within a packet) per each data packet.
Packet
Packets Per The number of packets received per second.

Second
FMTP Options RTP media format options.
Packet Loss The name of the algorithm used to conceal packet loss, if any. Packet loss concealment is used to reduce audio
Concealment artifacts such as pops, clicks, or buzzing when packets are lost.
Silence Whether audio is not transmitted from the client when no sound or voice is detected (true/false).
Suppression
JB Adaptive A numeric indicator of whether the jitter buffer is adaptive, static, or unknown.
l 0 - unknown
l 1 - reserved
l 2 - non-adaptive
l 3 - adaptive
JB Rate The jitter buffer adaptation rate.
JB Nominal The nominal time that packets stay in the jitter buffer.
JB Max The maximum time that packets stay in the jitter buffer.
JB Discard Rate The rate at which packets are being discarded by the jitter buffer.
Network Packet The rate at which packets are being lost over the network.
Loss Rate
Burst Loss The percentage of packets lost during burst phases. See Burst Density.
Density
Burst Duration The burst segment lengths during burst phases. See Burst Duration.
Gap Loss The percentage of packets lost during gap phases. See Gap Density.
Density
Gap Duration The gap segment lengths during gap phases. See Gap Duration.
Min. Gap The minimum threshold to be considered a "gap" in the network packet stream.
Threshold
Round Trip Delay The delay between sending a packet and receiving a response from the destination. See Round Trip
One Way Delay The delay between sending a packet and receiving a response from the first point in the route. See One Way.
Listening Q R The listening quality expressed as an R factor. This does not include the effects of echo or delay. The range of R is 0
to 95 for narrowband calls and 0 to 120 for wideband calls. Refer to RFC 3611.

Name Description
Conv. Q R The cumulative measurement of voice quality from the start of the session to the reporting time (expressed as an R
factor). The range of R is 0 to 95 for narrowband calls and 0 to 120 for wideband calls. Refer to RFC 3611.
External R In The voice quality as measured by the local endpoint for an incoming connection on the other side (expressed as an R
factor). The range of R is 0 to 95 for narrowband calls and 0 to 120 for wideband calls. Refer to RFC 3611.
External R Out This value is copied from the RTCP XR message received from the remote endpoint on the other side of this
endpoint. The range of R is 0 to 95 for narrowband calls and 0 to 120 for wideband calls. Refer to RFC 3611.
MOS Listening Q The Mean Opinion Score for incoming audio. See Mean Opinion Score (MOS).
MOS The Mean Opinion Score for combined incoming and outgoing audio.
Conversational Q
Call Data
Name Description
Start Time The time at which the call started.
Duration The length of the call in seconds.
Incoming Whether the call was incoming (true/false).
Call successful Whether the call was made successfully (true/false).
Failure reason The reason for the call failure, if the call was unsuccessful (for example, "Locally Terminated", "404", and other
server error codes.)
# digits dialed The number of digits dialed if it was an outgoing call.
Transferred Whether the call was transferred to another number (true/false).
Local conference Whether the call was a conference call with only local participants (true/false).
Max conference The maximum number of participants during the call if it was a conference call.
participants
Video call Whether the call was a video call (true/false).
Video conference Whether the call was a video conference call.
Audio in codec The codec used to decode the incoming audio stream.
Audio out codec The codec used to encode the outgoing audio stream.
Recorded Whether the call was recorded by the client (true/false).
USB device The name of any USB device or devices used by the client during the call, separated by commas.
Bluetooth device The name of any Bluetooth device or devices used by the client during the call, separated by commas.

Name Description
Video out device The name of any device or devices used to display the video stream during the call, separated by commas.
Video out codec The codec used to encode the outgoing video stream.
Video out portrait Whether the outgoing video stream was in portrait mode (true/false).
Video out width The width of the outgoing video stream in pixels.
Video out height The height of the outgoing video stream in pixels.
Video in codec The codec used to decode the incoming video stream.
Video in portrait Whether the incoming video stream was in portrait mode (true/false).
Video in width The width of the incoming video stream in pixels.
Video in height The width of the incoming video stream in pixels.
One way audio Whether audio was sent but not received (true/false)
Poor network quality Whether the client determined that the network quality was below a threshold (true/false).
Network type The type of network: Wi-Fi or mobile.
Network IP change Whether the network IP of the client changed during the session (true/false).
SRTP media encryption Whether Secure Real-time Transport protocol was used to encrypt the call (true/false).
Account Data
Name Description
Created The date on which the user account was created.
Account username The user's Stretto provisioning username without the @ domain.
Domain The user's Stretto domain (in other words the @groupname part of the username).
Outbound proxy The address (IP address or DNS hostname) of the outbound proxy configured for the account (if used).
Protocol The protocol used by the account (SIP or XMPP).
Enabled Whether the account is enabled (true/false).
Keepalive Cell Whether the account is configured to use keepalive messages over a mobile network (true/false).
Keepalive Cell interval The interval in seconds to send a keepalive message over a mobile network if enabled.
Keepalive Wi-Fi Whether the account is configured to use keepalive messages over a Wi-Fi network (true/false).
Keepalive Wi-Fi The interval in seconds to send a keepalive message over a Wi-Fi network if enabled.
interval

Name Description
SIP Cell refresh The interval in seconds before refreshing the SIP registration over a mobile network.
interval
SIP WiFi refresh The interval in seconds before refreshing the SIP registration over a Wi-Fi network.
interval
Cell NAT ICE Indicates if the SIP account is configured to use ICE for network firewall traversal over mobile networks
(true/false).
Cell NAT STUN Indicates if the SIP account is configured to use STUN for network firewall traversal over mobile networks
(true/false).
Cell NAT TURN Indicates if the SIP account is configured to use TURN for network firewall traversal over mobile networks
(true/false).
WIFI NAT ICE Indicates if the SIP account is configured to use ICE for network firewall traversal over Wi-Fi networks
(true/false).
WIFI NAT STUN Indicates if the SIP account is configured to use STUN for network firewall traversal over Wi-Fi networks
(true/false).
WIFI NAT TURN Indicates if the SIP account is configured to use TURN for network firewall traversal over Wi-Fi networks
(true/false).
SIP-Simple supported Whether SIP simple is supported (true/false).
Signaling transport The transport method used by the account (for example, TCP, UDP, or TLS).
Media Encryption Whether encryption is used for audio and video streams (true/false).
General Data
Name Description
Created The date on which the user account was created.
Last Updated The date/time on which the user account was most recently updated.
Installation Date The date on which the client app was installed.
OS Type The operating system that's running on the device.
OS Version The software version number of the operating system.
Hardware Model The make/model of the user device.
Client Version The software version number of the Bria client.
Client IP Address The client device's IP address. This can be IPv4, IPv6, or both (separated by a semi-colon).
Client Launch Time The date/time when the client software was started on the user's device.

Name Description
Template Version The Stretto version number to which the user's provisioning template belongs.
Language The ISO-639-1 language code for the client.
# SIP Accounts The number of SIP accounts registered on the client.
# SIP Simple Accounts The number of SIP Simple accounts set up on the client.
# XMPP Accounts The number of XMPP accounts set up on the client.
LDAP Whether an LDAP account is set up on the client (true/false).
Outlook Sync Whether Outlook sync is set up on the client (true/false).
Mac Address Book Whether a Mac Address Book is set up on the client (true/false).
Run in background Whether the client is set to allow "run in background" mode (true/false).
Data over mobile data net Whether the client is set to allow "run in background" mode (true/false).
VoIP over mobile data net Whether the client is set to allow the use of VoIP over a mobile connection (true/false).
Timezone Offset Time difference between the client time zone and UTC time (hh:mm).
Interval Data
Name Description
Interval Start The date/time of the start of the data interval.
Report Start The date/time within the interval when the client starts recording data.
Report End The date/time within the interval when the client stops recording data.
Contacts The number of contacts in the client contact list during the data interval.
Contacts with Presence The number of contacts in the contact list that provide presence information during the data interval.
Successful Provision Attempts The number of successful provisioning attempts made during the data interval.
Failed Provision Attempts The number of unsuccessful provisioning attempts made during the data interval.
Crashes The number of times the client terminated unexpectedly during the data interval.
Analytics - Call Data

The Call Data report contains one record for each phone call made by a user during the
specified date range. The audio and video information lets you assess network quality.

Column Description
Start time The time at which the call started.
Duration The length of the call in seconds.
Incoming Whether the call was incoming (true/false).
Call successful Whether the call was made successfully (true/false).
Failure reason The reason for the call failure, if the call was unsuccessful (for example, "Locally Terminated", "404", and other
server error codes.)
# digits dialed The number of digits dialed if it was an outgoing call.
Transferred Whether the call was transferred to another number (true/false).
Local conference Whether the call was a conference call with only local participants (true/false).
Max conference The maximum number of participants during the call if it was a conference call.
participants
Video call Whether the call was a video call (true/false).
Video conference Whether the call was a video conference call.
Audio in codec The codec used to decode the incoming audio stream.
Audio out codec The codec used to encode the outgoing audio stream.

Column Description
Recorded Whether the call was recorded by the client (true/false).
USB device The name of any USB device or devices used by the client during the call, separated by commas.
Bluetooth device The name of any Bluetooth device or devices used by the client during the call, separated by commas.
Video out device The name of any device or devices used to display the video stream during the call, separated by commas.
Video out codec The codec used to encode the outgoing video stream.
Video out portrait Whether the outgoing video stream was in portrait mode (true/false).
Video out width The width of the outgoing video stream in pixels.
Video out height The height of the outgoing video stream in pixels.
Video in codec The codec used to decode the incoming video stream.
Video in portrait Whether the incoming video stream was in portrait mode (true/false).
Video in width The width of the incoming video stream in pixels.
Video in height The width of the incoming video stream in pixels.
One way audio Whether audio was sent but not received (true/false)
Poor network quality Whether the client determined that the network quality was below a threshold (true/false).
Network type The type of network: Wi-Fi or mobile.
Network IP change Whether the network IP of the client changed during the session (true/false).
SRTP media encryption Whether Secure Real-time Transport protocol was used to encrypt the call (true/false).
Analytics - Call Issues

The Call Issues report helps to identify dates and times during which problems with call
quality may have existed. The report shows the total calls in the specified group within the
specified date range. "Issues" include a change in the client's network IP address, one-
way audio, and poor network quality.

l line chart
l table

Columns Description
Total The total number of calls either sent or received by the client.
Network IP Change The number of calls in which the client's IP address changed.
One Way Audio The number of calls in which audio was not received by both participants.
Poor Network Quality The number of calls in which the client determines that the network quality fell below a certain threshold.
Analytics - Call Network Type

The Network Type report shows the type of network used by clients in the selected group
for the specified date range. Network types can include NW_LTE, NW_3G, NW_4G,
NW_WIFI.

l pie chart
l line chart
l table

Analytics - Conference Participants

The Conference Participants report shows, for all conference calls, the number of
participants in the call.

l line chart
l table

Analytics - Encrypted Calls

The Encrypted Calls report shows total calls in the selected group within the selected
date range with a breakdown of whether the calls were encrypted.

l pie chart
l line chart
l table
Analytics - Call Termination Reasons

The Call Termination Reasons report shows the breakdown of reasons for unsuccessful
calls. Typical reasons will be either server error codes — such as "400 - Bad Request",
"401 - Unauthorized", "404 - Not Found", and similar — or whether the call was terminated
locally or remotely.

l pie chart
l line chart
l table

Analytics - General Data
Note: This section pertains to reports that are available as part of User Experience Metrics.
This report provides information about the device on which Bria is operating, including
operating system, device type, installation date, client version, numbers of each account
type, and more.
In this report, each user initially has one record. Each time the user's data changes, a
new record is added, until each user has multiple records.
Column Description
User The user's Stretto provisioning username..
Created The date/time on which the record was created.
Last updated The date/time on which the record was last updated. This is normally the same as Created.
Installation date The date on which the client app was installed.

Column Description
OS type The date on which the client app was installed.
OS version The software version number of the operating system.
Hardware model The make/model of the user device.
Client version The software version number of the Bria client.
Client IP address The client device's IP address. This can be IPv4, IPv6, or both (separated by a semi-colon).
Client launch time The date/time when the client software was started on the user's device.
Template version The Stretto version number to which the user's provisioning template belongs.
Language The ISO-639-1 language code for the client.
# SIP accounts The number of SIP accounts registered on the client.
# SIP Simple accounts The number of SIP Simple accounts set up on the client.
# XMPP accounts The number of XMPP accounts set up on the client.
LDAP Whether an LDAP account is set up on the client (true/false).
Outlook sync Whether Outlook sync is set up on the client (true/false).
Mac Address Book Whether a Mac Address Book is set up on the client (true/false).
Run in background Whether the client is set to allow "run in background" mode (true/false).
Data over mobile data net Whether the client is set to allow "run in background" mode (true/false).
VoIP over mobile data net Whether the client is set to allow the use of VoIP over a mobile connection (true/false).
Timezone offset Time difference between the client time zone and UTC time (hh:mm).
Analytics - Incoming/Outgoing
The Incoming/Outgoing report shows the total calls, incoming calls, and outgoing calls for
the selected group during the selected time period.

l line chart
l table

Analytics - Instant Messages

The Instant Messages report shows messages that were sent or received by the users in
the specified group or groups during the specified date range.

l line chart
l table
Each IM snippet is counted as a separate instant message. For example:
Kokila: Hi
Joseph: Hey
Kokila: Just a sec

Kokila: hi, I’m back. do you know if

Kokila: Rita is coming in today?
This example shows five instant messages.
If both people are in the specified group or groups, each snippet counts once as incoming
and once as outgoing, for a total of 10 instant messages.
A snippet in a group chat or chat room that is going to three people counts as one
outgoing message. If all the recipients are in the specified group or groups, the snippet
counts as five incoming messages.
Analytics - Interval Details

This report displays basic client information at a specific sampling rate (the data interval).
It can be used to track provisioning activity, contacts and presence, and crashes. This
information can be useful in correlating provisioning events, contact additions, and more
with client crashes (terminates unexpectedly), among other things.
Column Description
Interval start The date/time of the start of the data interval.

Column Description
Report start The date/time within the interval when the client starts recording data.
Report end The date/time within the interval when the client stops recording data.
Contacts The number of contacts in the client contact list during the data interval.
Contacts with presence The number of contacts in the contact list that provide presence information during the data interval.
Successful provision attempts The number of successful provisioning attempts made during the data interval.
Failed provision attempts The number of unsuccessful provisioning attempts made during the data interval.
Crashes The number of times the client terminated unexpectedly during the data interval.
Analytics - Local Conferences

The Local Conferences report shows the total calls and the calls that included a local
conference. A call is considered a "local conference" if the conference was created using
the Bria conference features — merging calls or creating a conference — rather than the
conference taking place on a conference bridge.

l line chart
l table

Analytics - Provisioning Attempts

The Provisioning Attempts report summarizes the number of successful and
unsuccessful provisioning attempts made by all users during the specified time range.

l pie chart
l line chart
l table
Slice Description
Successful Shows the number and percentage of all successful provisioning attempts during the reporting period. A
Provisioning provisioning attempt is considered "successful" if the client response contains no error message.
Attempts
Failed Shows the number and percentage of all failed provisioning attempts during the reporting period. A provisioning
Provisioning attempt is considered "failed" if the client response is an error message.
Attempts
Analytics - Recorded Calls

The Recorded Calls report shows the total number of calls and the number of calls that
were recorded in whole or in part by the client.

l line chart
l table

Analytics - Registrations
The Registrations report shows failed attempts to register an account with the SIP proxy.

l line chart
l table
Analytics - Stability
The Stability report provides data on the stability of the client software by showing the
number of times that the Bria client has crashed (terminated unexpectedly) during the
specified time range.

l line chart
l table
Analytics - Total calls

The Total Calls report shows the total number of calls, the number of failed calls, and the
number of successful calls. This can be a useful diagnostic to identify when issues
occurred on the network.

l line chart
l table

Analytics - Transferred Calls

The Transferred Calls report shows the total number of calls and the number of calls that
were transferred. A call is considered "transferred" if it is an outgoing call that is
transferred by the client.

l line chart
l table
Analytics - Video Calls

The Video Calls report shows all calls in which video was either sent or received by the
clients as well as some details of the nature of the video calls.
l line chart
l table

Columns Description
Total The total number of calls either sent or received by the client.
Video The total number of calls in which video was either sent or received by the client.
Conference The total number of video calls in which there were more than two participants.
Landscape The total number of video calls in which the client either sent or received video in landscape orientation.
Portrait The total number of video calls in which the client either sent or received video in portrait orientation.

Stretto Platform Administration Guide Reference
Reference
This section provides reference material to support the management of Stretto Platform.
Administrator privileges
This section identifies the privileges of Stretto admins.
Access to groups
Read-
Admin Admin Admin
Admin
View all groups
View assigned groups

and subgroups no
subgroups
Create a group
only within the Only within the assigned
assigned groups.
groups The new group is a copy of a
source group; not a blank
group.
View group information
Modify group information

Only the subgroups.
View Max users and

Group Limits for a group
Modify the Max users or

Group Limits for a only within the only the subgroups.
subgroup assigned
groups
Suspend a group

Read-
Admin Admin Admin
Admin

assigned
groups
Move a group
only within the assigned
groups
Move a group to the root
Delete a group
assigned
groups
Upload and download

groups
Access to attributes and attribute pools

View attributes
Add, modify, delete attributes
Modify encryption property of an

attribute
Lock an attribute
Lock an attribute with a Super

Final lock
Set attribute values at the group

level
Set attribute value at the profile

level
Set attribute value at the user level
View attribute pools
Create and delete attribute pools

only the
subgroups.
View pool entries
Add pool entries to attribute pools


Enable an attribute pool for user
Unassign pool entries
Access to Stretto templates, profiles, users

Feature
View templates
Add, modify, delete, upload, download

templates
View profiles
Add, modify, delete profiles Optional Optional

(admin option = Add/delete profiles)
View users
Add users Optional Optional Optional

(admin option = Add users)
Upload users and Download users Optional Optional Optional

(admin option = Upload/download users)
Modify user’s provisioning username and

password
Send email notifications to end users
Suspend and unlock users
Delete user's device Optional Optional Optional

(admin option = Delete user devices)
Delete users Optional Optional Optional

(admin option = Delete users)
Access to Stretto features

Feature
Test setup (Group Validation)

only the
subgroups.


Feature
Test provisioning response (in Users section)
Test LDAP server connection
View event logs
View user traces
View and download a list of devices
View Stretto reports (in Reports tab) (admin Optional Optional Optional Optional Optional
option = View reports)
Receive email reports Optional Optional Optional Optional Optional Optional
View enhanced client traces (device logs) (in Optional Optional Optional Optional Optional
Client Traces tab) (admin option = View
client traces)
Receive notification every time new device Optional Optional Optional Optional
log is uploaded (admin option = Client
Traces notification)
Help Desk Assistant (admin option = Help Optional Optional Optional Optional Optional
Desk Assistant)
Messaging and presence (XMPP) Optional Optional Optional Optional

(admin option = Messages option) The
XMPP tab
appears
for each
user.
End User Portal (admin option = Portal Optional Optional Optional

Settings)
Virtual Meeting Rooms (Collaboration Optional Optional Optional

meeting) (admin option = Meetings)
Privileges over admins

Feature
Privileges over Group Associations
Automatically associated with all groups
Can be associated with any number of Optional Optional

groups (and their subgroups) Only one
(admin option = Multi-group admin) group
Privileges over Administrators


Feature
View their own administrator privileges
View child administrators
Create an administrator
as a as a
descendant descendant
of itself of itself. Can
create only
certain admin
types 1
Associate a group with an administrator

only the only the
groups they groups they
are are
associated associated
with, with,
and only their and only their
child admins. child admins
of certain
types2
Move an administrator
Unlock an administrator
of certain
types3
Suspend an administrator
of certain
types4
Modify setup to receive email reports

admins of certain
types5
Modify admin options

admins of certain
types6


Feature
Modify groups itself is associated with
Reset the password of another

administrator only their only their
Reset its own password (admin option = Optional Optional Optional Optional Optional
Change own password)
Delete an administrator
and Support.
and Support.
and Support.
and Support.
and Support.
and Support.
Login error messages

The table lists possible errors that may be displayed Bria when it is trying to communicate
with Stretto.
Errors with an asterisk * can be translated. Errors without an asterisk * are generated by
the softphone client (they are not sent down by Stretto) and they may already be
translated, depending on your brand.

Platform Message Reason
Bria A system error occurred during An unknown error occurred. This error should not occur.
desktop the login process. Contact Ask the user to try again.
technical support to correct.
* Both Access not allowed for this User is valid, but no template is defined for the user: the profile that this user
softphone platform belongs to does not include a template mapping for this platform. For example, the
profile does not have a mapping for Bria desktop. This mapping may be missing
on purpose; for example, users in this profile may not actually be permitted to use
Bria desktop.
Fix the Stretto setup, if appropriate.
Both Codec Not Allowed You have set up for royalty-bearing codec tracking as PAYG but you have not set
up for device tracking (a necessary pre-requisite).
* Both Desktop Device Limit reached. You have set up for group device limits on a per-platform basis and the desktop
Contact us for assistance. limit has been reached for this group. New users or old users logging in from a new
device cannot log on.
Either remove unused devices or increase the device limits.
* Both Device Activation Limit Reached The user is trying to log on from a new device but the maximum device allocation
has been reached.
If desired, you can remove a device from the device list for this user; this decision
depends on your internal policies.
* Both Device ID is missing No device ID was found in the incoming user request; there is an error on the
softphone client that means the request is missing this important information.
Ask the user to try again. If the problem recurs, contact CounterPath; you may
need new builds of some softphone clients.
Bria Error in response from server, The provisioning response from Stretto was invalid.
desktop please try again. If this situation Check your templates and validate them.
persists, contact technical
support to correct.
Both Group not found The domain portion of the user's login is incorrect. The user probably entered it
incorrectly, for example “[email protected]” instead of
“[email protected]”.
Note that this message cannot be translated, even though it comes from Stretto.
* Both Incorrect user name or The login credentials are invalid. The user should re-enter the credentials and try
password again. If you changed their credentials, you may have forgotten to send an email
notification; do so now.
The user has not been set up as a user in Stretto.
* Both Invalid credentials LDAP authentication is being used and the user’s LDAP password was invalid.
Ask the user to enter the password again.
Bria No Internet connection found. The Bria mobile user has no internet connection.
mobile Please check your Internet
connection.
Both No pool entries for assigning You set up the specified attribute to use an attribute pool and either the pool has
<name of attribute> no entries or the pool has no more unused entries.

Platform Message Reason
* Both Per-group Device Limit reached. You have set up for group device limits on a per-group basis and the limit has been
Contact us for assistance. reached for this group. New users or old users logging in from a new device
cannot log on.
Bria Provisioning server did not The provisioning server has sent down a badly formatted response.
mobile respond with required field. If the This error should not occur.
problem persists, please contact
us for assistance.
Bria Provisioning server did not The provisioning server has not responded quickly enough.
mobile respond. If the problem persists, This error should not occur.
please contact us for assistance.
* Both Smartphone Device Limit You have set up for group device limits on a per-platform basis and the
reached. Contact us for smartphone limit has been reached for this group. New users or old users logging
assistance. in from a new device cannot log on.
* Both Suspended Group or user is suspended.
* Both Tablet Device Limit reached. You have set up for group device limits on a per-platform basis and the tablet limit
Contact us for assistance. has been reached for this group. New users or old users logging in from a new
device cannot log on.
Either remove unused devices or increase the device limits
Bria The login operation has failed. If Stretto is not available.

mobile the problem persists, please
contact us for assistance.
Bria Unable to connect to the server. The Bria desktop user has no internet connection.
desktop Check your network connection
and try again. If the problem
persists, contact technical
support to correct.
Bria Unable to establish a secure There is a problem with the security certificate on the computer that is running Bria
desktop connection with the server. If the desktop.
situation persists, please contact
customer support
* Both User not found User was not found.

Check if the user has been created on Stretto; check that they are logging in using
the username user@group, for example, [email protected].
Make sure that the user is in the correct group.
Or
LDAP authentication is being used and the user was not found on an LDAP server.
Ask the user to enter their login credentials again.
Bria Your login details do not match An unknown error occurred. This error should not occur.
desktop our records. If you are a new
user you will need to create an
account first.

Building a search query to fetch LDAP entries

This topic discusses general tips on how to navigate an LDAP directory tree. This topic
assumes the purpose for the search is to retrieve a list of people to be displayed on the
softphone client.
LDAP Terminology
LDAP entries, such as a person or a computer, are organized in a tree structure. When
referring to an entry in LDAP, you start from the bottom of the tree; e.g.,
CN=admin,OU=IT,DC=example,DC=com. This is called a distinguished name (DN). A DN
uniquely identifies an LDAP entry. To organize a large number of entries, a container is
used to group entries together; this container is called an organizational unit (ou).
Examples of directory tree

l In Example A, all users exist under one organizational unit (ou).
l In Example B, users are organized across multiple organizational units. Example B
uses groups to combine users.
Every organization has a different directory structure, but typically, the following
components are required to retrieve entries from an LDAP server:
l An LDAP account to access the tree. Often called a bind DN. Some LDAP servers
do not allow anonymous binds. This LDAP account should have a permission to
perform the operation.
l Base DN: this is a starting point of the search. Also known as root DN. Typically, a
base DN is the root node at the top of the tree. The search is performed underneath

the node. It's DC=example,DC=com in Example A; ou=acphone,DC=ac,DC=local in

Example B.
l A filter/query: this is a way to restrict retrieval from LDAP to whatever you are trying
to achieve with the operation. For example, when retrieving a list of people from
LDAP to use as a contact list, you only want real people to be returned, not
computers. Or you might want to exclude people who do not have any phone
number.
One of the popular tasks is to show a list of users on the softphone. There are two ways to
achieve this: using the Directory tab, or a roster (Stretto XMPP module is required).
Following discusses how to configure a filter/query for setting it up.
Directory tab on the softphone client

This section explains settings related to finding LDAP entries. See the Settings document
for a complete list of the settings required for enabling the Directory tab.
To retrieve a list of people from an LDAP server to Bria, you need to configure a base DN,
a search expression, and attribute mapping. Bria constructs a search query by combining
a search expression and attribute mapping, and sends the resulting query to the LDAP
server.
Note: This section explains the configuration using the examples above. The actual
configuration for your LDAP server differs depending on how users are created ( e.g., what
object class is used), and what LDAP fields are populated (e.g., whether phone numbers are
stored in the telephoneNumber field or the mobile field). Modify the configuration accordingly.
Base DN and search expression

First, you need to know where users are located in the directory tree. Using an LDAP
client allows you to view your LDAP directory in a tree structure.
l If users are organized under one organizational unit (ou) as shown in Example A,
set the DN of the ou as a base DN, and set a search expression to filter to only show
person (not computers). For example:

feature.ldap.server.root=OU=People,DC=example,DC=com
feature.ldap.searchExpression=(objectClass=user)
This example assumes that users are created with a user object class
(objectClass=user). To check what object class the users have in your organization,
use an LDAP client and view details of the users.
l If users are grouped as shown in Example B, set a search expression to pull all the
members of the group (Acphone_Users in this case).
feature.ldap.server.root=OU=acphone,DC=ac,DC=local
feature.ldap.searchExpression=(memberOf=CN=Acphone_
Users,OU=Groups,OU=acphone,DC=ac,DC=local)
Tip: Start with a simple search expression (e.g., what type of objects you want to
retrieve). You can further filter it through the attribute mapping.
Attribute mapping
Next, choose what LDAP fields to search and filter by configuring attribute mapping.
Attribute mapping has two purposes:
l to populate contact information shown on Bria, and
l to be used as a filter for the search of a person in the LDAP server.
Attribute mapping creates a set of a Stretto attribute and an LDAP field. This is a way to
tell Bria which information in the LDAP server to use. Let us assume you mapped Bria's
email address to the LDAP field email, first name to the LDAP field givenName, and work
phone number to the LDAP field telephoneNumber.
The Directory tab is empty until the end user types something in the Search field and
clicks Search. When the end user types Mi and performs a search, Bria checks the
values of the email, givenName, and telephoneNumber fields in the LDAP server, and
returns entries that have Mi in one of the three fields. Bria also displays the email
address, first name, and work phone number for the person that was a match.
The configuration for the above example is as follows:

feature.ldap.searchExpression=(objectClass=user)
feature.ldap.attributeMappingForEmailKey=mail
feature.ldap.attributeMappingForFirstNameKey=givenName
feature.ldap.attributeMappingForPhoneKey=telephoneNumber
The end user enters Mi in the search field and clicks Search. Bria builds a search query
by combining the parts. The mapped LDAP fields are appended to the LDAP query you
specified in feature.ldap.searchExpression. The final query is sent to the LDAP server as
follows:
(&(objectClass=user)(|(mail=Mi*)(givenName=Mi*)(telephoneNumber=Mi*)))
Supplying an XMPP roster using LDAP

When a Stretto XMPP module is deployed, you can use LDAP to supply an XMPP roster
which shows a list of people on the softphone client.
Group DN
The concept is the same as when using the Directory tab; however, instead of setting a
query/filter, Stretto LDAP roster uses a different method to refine the returned results.
The main things to note:
l The Stretto attribute xmpp:roster:ldap:groupDN assumes you have a group
configured as shown in Example B.
l Optionally you can apply conditions on which users to fetch depending on whether
certain LDAP fields are populated: for example, you can set a condition to fetch
users who have their phone number in the LDAP's telephoneNumber field, instead
of fetching all users with or without phone number. For details, see Configuring
XMPP attributes.
l Contact CounterPath if your deployment requires a different configuration.

Admin DN and Admin Password

For supplying a roster and vCard information, Stretto needs an LDAP account that has a
permission to view information of all users. Your organization might have a service
account for this purpose.
Admin DN and admin password are configured in the std:ldap:adminDN and

std:ldap:adminPW attributes, .
Ports, IP addresses, firewall rules to allow on

your network
We recommend that your DNS environment is set up to answer SRV queries.
Provisioning / Stretto core services

IP addresses and domain names
IP addresses
l 216.93.246.0/24 is our own Class C network / IP range for our primary location. We
suggest customers open up outbound access to this range.
l 69.90.51.0/24 is our own Class C network / IP range for our secondary location.
l 52.183.45.217 (for licensing)
l 40.78.10.175 (for licensing)
DNS Names
The DNS names associated with the services are:

l stretto.cloudprovisioning.com (for most services). This replaces
ccs3.cloudprovisioning.com.
l strettoadmin.cloudprovisioning.com (for the Stretto Admin web interface).
l im.softphone.com, imp.softphone.com, imp2.softphone.com, imp3.softphone.com,
imp4.softphone.com. (specific to XMPP)
l sync1.cloudprovisioning.com (for Stretto sync - IM sync and call history sync)
l secure.counterpath.com (for licensing)

l secure-east.counterpath.com (for licensing)

l secure-west.counterpath.com (for licensing)
l docs.counterpath.com (for documentation)
All interactions with all services other than XMPP are HTTPS over TLS.
XMPP does also have clients accessing the XMPP server by using DNS SRV if a proxy is
not specified, so clients could reach out to customer's XMPP domains on ports specified.
Ports
Ports for core services
All traffic for these ports is HTTPS.
Port Description Access
443 Client provisioning and licensing All clients need to be able to reach this port.
SIP This is as specified by your SIP All clients need to be able to reach this port range. Bria uses 5060 or
network. the port number specified in the SIP domain field such as
aaaprovider.com:5061.
RTP This is as specified by your SIP All clients need to be able to reach this port range.
network.
Push This is as specified by Apple APNs / All push-enabled clients need to be able to reach these ports.
Google FCM.
18082 User Services that includes: All clients need to be able to reach this port.
(WSS and Enhanced Client Traces
HTTPS) User Experience Metrics
End User Portal
Help Desk Assistant (Remote access
to mobile app running on user
device)
18083 Web administration (using the Stretto No client traffic here.

Admin web interface)
18889 Stretto Sync (Syncs instant All clients need to be able to reach this port.
messages and call history
sent/received between all clients)
50443 Stretto API access No client traffic here.
Ports for XMPP

Port Description Access
1080 The standard port for SOCK5 proxy which enables XMPP file transfer. All clients need to be able to reach this port.
5222 The standard port for XMPP - Client to Server connections All clients need to be able to reach this port.
5269 The standard port for XMPP - Federation and Server to Server connections Not a concern for client access.
Push servers hosted by CounterPath

Clients should automatically route to the correct nearest regional server, but we
recommend ensuring that ALL addresses are accessible in case of traveling users, etc.
Please also note that IP addresses may change in the future; if you manually configure
your firewall/etc. for these addresses and experience issues in the future, please revisit
this page to find the latest information.
Current limitations:
Only IPv4 SIP servers are currently supported for calls involving the push server. The
Bria mobile client will support IPv6-only networks utilizing DNS64/NAT64 when
communicating with IPv4 SIP servers.
HTTPS
Domain Names IP Address
https://push.softphone.com 216.93.246.120
https://push-as.softphone.com 35.185.177.49
https://push-as3.softphone.com 35.240.151.194
https://push-au.softphone.com 35.189.7.217
https://push-au2.softphone.com 35.244.85.149
https://push-eu.softphone.com 35.195.163.239
https://push-eu2.softphone.com 34.89.45.1
https://push-jp.softphone.com 104.198.91.17
https://push-uc.softphone.com 35.239.221.102
https://push-ue.softphone.com 216.93.246.120
https://push-ue3.softphone.com 35.230.185.25
https://push-uw.softphone.com 35.197.16.246

https://push-uw3.softphone.com 35.247.85.64
https://push-za.softphone.com 102.133.161.81
WSS
wss://push1.softphone.com 216.93.246.121
wss://push2.softphone.com 216.93.246.122
wss://push-as1.softphone.com 35.187.236.29
wss://push-as3ws.softphone.com 35.247.187.184
wss://push-au1.softphone.com 35.189.10.177
wss://push-au2ws.softphone.com 35.244.75.9
wss://push-eu1.softphone.com 35.195.65.27
wss://push-eu2ws.softphone.com 34.89.19.0
wss://push-jpws.softphone.com 34.84.10.191
wss://push-uc1.softphone.com 35.193.78.38
wss://push-ue2ws.softphone.com 3.18.216.43
wss://push-ue3ws.softphone.com 35.199.2.199
wss://push-uw1.softphone.com 35.197.115.127
wss://push-uw3ws.softphone.com 35.227.171.146
wss://push-za1.softphone.com 102.133.163.77
Ports for the push service

l 443 for HTTPS and WSS. This is for connections between the Bria client and the
Bria Push server.
l The ports as specified by Apple APNs / Google FCM. This is for connections
between the Bria client and Apple APNs / Google FCM.
Screenshare servers hosted by CounterPath

DNS name IP address
screensharing.softphone.com 34.98.109.124

Additional IP addresses:
l 35.203.69.154
l 35.232.101.44
l 35.246.61.224
l 35.246.101.218
Ports for the screenshare service

l 443 for desktop
l 9005 for mobile apps / web browser access
l 49152:65535 (UDP)
Collaboration servers hosted by CounterPath

Controllers and Related Servers
DNS name IP address
stretto.cloudprovisioning.com 216.93.246.36
collab.cloudprovisioning.com 216.93.246.134
imp.softphone.com 216.93.246.136
screensharing.softphone.com 34.98.109.124
35.203.69.154
35.232.101.44
35.246.61.224
35.246.101.218
Call Servers
DNS name IP address
as-cs1.softphone.com 34.87.78.58

DNS name IP address
au-cs1.softphone.com 35.189.11.31
euwest1-cs1.softphone.com 35.187.58.3
cs18.softphone.com 35.189.95.113
asiasouth-cs1.softphone.com 35.200.232.44
mex-cs1.softphone.com 169.57.16.58
sa-cs1.softphone.com 35.247.196.243
useast4-cs1.softphone.com 35.245.66.188
useast-cs1.softphone.com 3.232.187.240

DNS name IP address
usw1-cs1.softphone.com 34.82.183.225
za-cs1.softphone.com 102.133.231.159
Ports for the Collaboration service

All ports are TCP unless otherwise mentioned.
l 443
l 5060
l 5061
l 5291 (WSS for guest collab chat access)
l 7443
l 8082
l 9005 for screenshare with mobile apps and web browser access
l 16384:32770 (TCP and UDP for RTP)
l 49152:65535 (UDP)
Stretto attributes and data elements

The following table lists the special attributes (those that are used by Stretto to make
decisions) and internal data elements that are referenced in this manual.

Name Type Description Cross Reference
ccs:groupName internal data The Stretto group the user Setting up remote
element belongs to. upgrade of Bria
desktop
ccs:password internal data The user’s password for logging Configuring XMPP
element into Stretto. attributes and
Sending email
notifications to
users
ccs:roster attribute You create this attribute if you This section

want to assign a main roster to describes how to
XMPP users via .csv files. Use configure rosters
the attribute as a header in a .csv manually. If you
file. are using LDAP to
build rosters, see
Configuring XMPP
rosters using
LDAP.
ccs:rosterextra attribute You create this attribute if you This section

want to assign extra rosters to describes how to
XMPP users via .csv files. Use configure rosters
the attribute as a header in a .csv manually. If you
file. You can add multiple are using LDAP to
additional rosters by separating build rosters, see
rosters with | (pipe). The Configuring XMPP
presence state is represented by rosters using
the following LDAP.
l #0 or blank: None
l #1: Show Presence

(supervisor)
l #2: Disable Presence
(agent)
Use the following format:

Roster Namepresence state
|Roster Namepresence state |
ccs:userName internal data The user’s name for logging into Sending email
element Stretto. For example, notifications to
[email protected] users
ccs:userName.User internal data The username portion of the Configuring XMPP

element ccs:userName. For attributes
example, kperera.
ccs:xmppdomain internal data The XMPP domain name. By Configuring XMPP

element default (if not overridden by the attributes
administrator), it holds the same
value as ccs:groupName.

msg:<wording> attribute Holds the wording for one of the Customizing and
customizable login error translating login
messages. error messages
std:default:profile attribute You create this attribute if you Configure LDAP

want to support auto creation of properties and
Stretto users for LDAP or ECS Configure external
authentication. configuration
server properties
std:deviceAgeDays attribute You create this attribute, but only Limiting the
if you want to support tracking of number of devices
devices by each user. per user
(maxDevices and
deviceAgeDays)
std:ldap:adminDN attributes You create this attribute if you Configuring XMPP

want to provide rosters or vCard attributes
std:ldap:adminPW information using your LDAP
server.
std:ldap:baseDN attribute You create this attribute, but only Configure LDAP
if you want to support LDAP properties, and
std:ldap:bindDN authentication. Configuring XMPP
std:ldap:domain attributes
std:ldap:ignoreError
std:ldap:server
std:ldap:user
std:ldap:fetchMode attribute You create this attribute if you Configure LDAP

want to support auto creation of properties
Stretto users for LDAP
authentication.
std:locale:default attribute You create this attribute if you Customizing and

support customizable login error translating login
messages, and want to set the error messages
default language to a language
other than the built-in US
English.
std:locale:override attribute You create this attribute if you Customizing and

support customizable login error translating login
messages, and want to show all error messages
login error messages in one
specific language regardless of
the language used in the client.
std:logserver:enable attribute You create these attributes if you Setting up

want to support Enhanced Client enhanced Client
std:logserver:url Traces. Traces
std:logserver:user

std:logserver:password
std:maxDevices attribute You create this attribute, but only Limiting the
if you want to support tracking of number of devices
devices by each user. per user
(maxDevices and
deviceAgeDays)
remoteDebugUrl attribute You create these attributes, but Setting up Help

only if you want to support Help Desk Assistant
std:remotedebug:authurl Desk Assistant.
std:remotedebug:password
std:remotedebug:user
std:strettosync:smsprovider attribute You create the attribute, but only Configuring

if you want to support the SMS API
account.sms.username SMS API integration feature. integration
std:sync:url attribute You create the attribute, but only Setting up Stretto
if you want to support the Stretto Sync
Sync or SMS API integration Configuring
feature. SMS API
integration
std:sync:callhistory:url attribute You create this attribute if you Setting up Call

want to support call history sync. History Sync
std:upgrade.<platform>.url attribute You create these attributes, but Setting up remote

only if you want to support upgrade of Bria
std:upgrade.<platform>.version remote upgrades of Bria desktop. desktop
std:upgrade.<platform>.md5hash
std:upgrade.<platform>.releasenotesurl
std:userportal:softphone.brand attribute You create this attribute to Setting up The

change the softphone name that End User Portal
appears in End User Portal or
email templates.
std:usertrace:enable attribute You create this attribute to Setting up user

enable User Traces. traces
std:vqmserver:url attributes You create these attributes, but Setting up User

only if you want to support User Experience
std:vqmserver:user Experience Metrics. Metrics
std:vqmserver:password
std:vqmserver:timer
xmpp:domain:filter attribute You create this attribute if you Setting up for

deploy the XMPP module. It XMPP federation
controls federation/access to
your XMPP domain from other
domains.

xmpp:username attribute You create these attributes if you Configuring XMPP

deploy the XMPP module. Stretto attributes
xmpp:password creates XMPP users based on
xmpp:displayname the value assigned to these
attributes.
xmpp:ldap:displayname
xmpp:jidUser internal data The username portion of jid. Configuring XMPP

element Once the Stretto database is attributes
synced with the XMPP database,
it should match the value of
{{xmpp:username}}.
xmpp:ldap:att:attribute attribute Use these attributes in the vCard Configuring

in a template when using LDAP to vCards for XMPP
xmpp:ldap:batt:attribute populate vCards. The attribute buddies
template
will be replaced by a real user-
specific value when a vCard is
loaded to each user. Where
"attribute" is the name of an
LDAP field to extract data from.
xmpp:ldap:department attribute Used if you deploy an XMPP Configuring XMPP

module and supply rosters using attributesand
xmpp:ldap:rostergroupname LDAP. Configuring XMPP
xmpp:ldap:dbcheck rosters using
LDAP
xmpp:ldap:roster:check1
xmpp:ldap::roster:check2
xmpp:audit:timer
xmpp:create:stretto:user
xmpp:roster:ldap:baseDN attribute Used if you deploy an XMPP Configuring XMPP

module and supply rosters using attributes
xmpp:roster:ldap:groupDN LDAP.
xmpp:roster:ldap:jid
xmpp:vcard:ldap:baseDN attribute Used if you deploy the XMPP Configuring XMPP

module and supply vCards using attributes
xmpp:vcard:ldap:filter LDAP.
xmpp:vcard:useLdap
Stretto template formats

The body of a template defines the format and content to be used in these ways:
l If you create templates for use with the Stretto API, the template defines the
information that goes in the HTTP POST.

l If you create templates by using Stretto Admin, the template is associated with
profiles.
Template format differs depending on the use.

l A Bria desktop template the provisioning response data sent to desktop clients.
l A Bria mobile template defines the provisioning response data sent to mobile
clients.
l An Email notification template defines the format of emails that are sent to new
users.
l A vCard template defines the content of associated vCard contact information.
l Collaboration email invite templates define the content of email invitations.
l A Collaboration email summary template defines the content of the summary sent
to the Host by email.
l A Collaboration guest access template defines the format required for
authenticating guest users to a meeting.
l Collaboration dial-in numbers template defines the dial-in numbers for guest
access.
l A User Portal Template defines the appearance of the End User Portal.
Bria desktop template

The format of the body of the template for Bria desktop is similar to that of a
Microsoft® Windows® .ini file.
Client configuration templates handle successful logins (hence the “success” keyword at
the top of the templates). For failures, Stretto automatically creates the response without
using a template.
[DATA]
Success=1
LicenseKey="{{license_key_attribute}}"
[SETTINGS]
bria_desktop_setting="{{value}}"
[##MEMORY##]

Section names
Sections of the template are defined in square brackets to indicate the kind of data that
follow it:
l [DATA] - Required. This section contains only one line: Success=1.
l [SETTINGS] - Indicates that the settings that follow it should be written to persistent
memory. Bria uses the values immediately and, at shutdown of Bria, saves them to
a file on the user's computer.
l [##MEMORY##] - Indicates that the settings that follow it should be written to non-
persistent memory. Bria uses the values immediately, but only for the current
session.
Settings and values

Success=1
This line is required and is always 1 or true. This template is for a successful provisioning
request. If the provisioning request is refused, Stretto responds with Success=0 without
referring to a template.
LicenseKey="{{license_key_attribute}}"
Include this line if you provision the license key. Specify the name of the attribute that
contains the license key, and enclose it in double braces and quotes. For example:
Each setting line maps the name of a Bria desktop setting to the name of a Stretto
attribute that contains the value. You can obtain the names of settings from the document
Settings for Bria Desktop. Enclose value in double braces and quotes.
Example of value as the name of a Stretto attribute:
proxies:proxy1:username="{{SipUserName}}"
Example of a a hard-coded value. For example:

proxies:proxy1:transport="udp"
Example of a Bria desktop template
[DATA]
Success=1
[SETTINGS]
proxies:proxy1:username="{{sipUserName}}"
proxies:proxy1:domain="{{sipDomain}}"
proxies:proxy1:password="{{SipPassword}}"
proxies:proxy1:transport="udp"
[##MEMORY##]
proxies:proxy1:enabled="{{sipAccountEnabled}}"
Bria mobile template

The format of the body of the template for Bria mobile is XML.
Client configuration templates handle successful logins (hence the “success” keyword at
the top of the templates). For failures, Stretto automatically creates the response without
using a template.
To populate the template with the settings you want to provision, consult Settings for Bria
Mobile. In this list (an Excel file), the location of each setting (the first column) is color-
coded to make it easier to determine which section a setting belongs in. For example, the
accountName setting is tagged in pale pink to indicate it belongs in the account data
section.

Here is the meaning and location of each color:
Three dots indicate a continued list of entries. For example account_list can contain
many account sections — one per account.
l mobile_setting_name refers to the Bria mobile setting name as it appears in Settings
for Bria Mobile.
l attribute_name is the Stretto attribute from which the value comes. You can replace
attribute_name with hard-coded data.
Example of a template:

<login_response>
</login_response>


<branding>
<settings_data>
<core_data_list>

<codec_list>



</codec_list>
<account_list>
<account>
<data name="accountName" value="{{sipAccountName}}"/>
<data name="username" value="{{sipUserName}}"/>
<data name="password" value="{{sipPassword}}"/>
<data name="domain" value="{{sipDomain}}"/>
<data name="enabled" value="true"/>
<rule_list>

</rule_list>
</account>
</account_list>
</core_data_list>
<app_data_list>

<app_data_list>
</settings_data>
</branding>
</cpc_mobile>
Email notification template

The format of the body of an email notification template \
--EMAIL TEMPLATE--
html:false
temppass:false
Subject: Welcome to AC Phone!
Body:
Welcome aboard AC Phone. Please keep this email for future reference.
To log into {{std:userportal:softphone.brand}}, enter your username and password.

Your username is {{ccs:userName}}
Your password is {{ccs:password}}
To download {{std:userportal:softphone.brand}}, visit acphone.com and log in for details.
The first line must be --EMAIL TEMPLATE--, and it must be in capital letters. This line
ensures that Stretto recognizes this template as an email notification template.
Other keywords that Stretto recognizes and handles appropriately are:

l html: Set to true if you want the email to be formatted as HTML.
l temppass: Set to true to enable the Use temporary access code(s) option in the
Notify Users dialog.

l Subject: The rest of the text on this line goes into the subject line of the email.
l Body: The rest of the text to the end of the file goes into the body of the email.
Do not add “from” as a keyword. Stretto obtains the sending email address from the initial
setup information.
Rules for keywords:

l All keywords must include a colon.
l One keyword per line.
l The “Body:” keyword must be last.
You can include any attribute by entering the name in double curly braces, for example,
{{account.notification.administratorName}}. Attribute names are case sensitive. You can
also include any internal data element, such as:
l {{ccs:userName}} - the user’s login name
l {{ccs:password}} - the user’s login password or a temporary access code (if
enabled)
vCard template
Default vCard template
The format of the body of the vCard template is as follows.
The template follows the schema specified in RFC 6351. Like the other types of
templates, Stretto attributes are enclosed in double curly braces.
<N>
<GIVEN>{{xmpp:givenName}}</GIVEN>
</N>
<EMAIL>
<INTERNET/>
<USERID>{{xmpp:email}}</USERID>
</EMAIL>
<FN>{{xmpp:displayName}}</FN>
<TEL>
<WORK/> 
<VOICE/> 
<PREF/>
<NUMBER>{{xmpp:extension}}</NUMBER>
</TEL>

<TEL>
<WORK/>
<VOICE/>
<NUMBER>{{xmpp:officeNumber}}</NUMBER>
</TEL>
<TEL>
<CELL/>
<NUMBER>{{xmpp:mobile}}</NUMBER>
</TEL>
<TEL>
<WORK/>
<FAX/>
<NUMBER>{{xmpp:facsimile}}</NUMBER>
</TEL>
<TITLE>{{xmpp:title}}</TITLE>
<ORG>
<ORGUNIT>{{xmpp:department}}</ORGUNIT>
</ORG>
</vCard>
vCard template when using LDAP

When using LDAP, use the Stretto special attributes in the vCard template. They are
replaced by a real user-specific value extracted from the LDAP server when a vCard is
loaded to each user.
<N>
<GIVEN>{{xmpp:ldap:att:givenName}}</GIVEN>
<FAMILY>{{xmpp:ldap:att:sn}}</FAMILY>
</N>
<EMAIL>
<INTERNET/>
<USERID>{{xmpp:ldap:att:mail}}</USERID>
</EMAIL>
<FN>{{xmpp:ldap:att:displayName}}</FN>
<ADR>
<HOME/>
</ADR>
<ADR>
<WORK/>
<STREET>{{xmpp:ldap:att:streetAddress}}</STREET>
<LOCALITY>{{xmpp:ldap:att:l}}</LOCALITY>
<REGION>{{xmpp:ldap:att:st}}</REGION>
<PCODE>{{xmpp:ldap:att:postalCode}}</PCODE>
<CTRY>{{xmpp:ldap:att:co}}</CTRY>
</ADR>
<TEL>
<WORK/>
<VOICE/>
<PREF/>

<NUMBER>{{xmpp:ldap:att:ipPhone}}</NUMBER>
</TEL>
<TEL>
<WORK/>
<VOICE/>
<NUMBER>{{xmpp:ldap:att:telephoneNumber}}</NUMBER>
</TEL>
<TEL>
<CELL/>
<NUMBER>{{xmpp:ldap:att:mobile}}</NUMBER>
</TEL>
<TEL>
<WORK/>
<PAGER/>
<NUMBER>{{xmpp:ldap:att:pager}}</NUMBER>
</TEL>
<TEL>
<HOME/>
<VOICE/>
<NUMBER>{{xmpp:ldap:att:homePhone}}</NUMBER>
</TEL>
<TEL>
<WORK/>
<FAX/>
<NUMBER>{{xmpp:ldap:att:facsimileTelephoneNumber}}</NUMBER>
</TEL>
<TITLE>{{xmpp:ldap:att:title}}</TITLE>
<ORG>
<ORGUNIT>{{xmpp:ldap:att:department}}</ORGUNIT>
</ORG>
<URL>{{xmpp:ldap:att:url}}</URL>
<PHOTO>
<TYPE>image/jpeg</TYPE>
<BINVAL>{{xmpp:ldap:batt:thumbnailPhoto}}</BINVAL>
</PHOTO>
</vCard>
Collaboration email invite templates

vccsInviteEmailHtml
<h1>You've been invited to the meeting with {{xmpp:displayname}}!</h1>

<p>To join using Bria or a web browser: <a href="{{vccs:conference:briaUrl}}">Click Here</a>.
</p>
<p>To join using a phone: Please select a local dial-in phone number from this site <a
href="https://go.counterpath.com/virtual-meeting-rooms-dial-in-
numbers">https://go.counterpath.com/virtual-meeting-rooms-dial-in-numbers</a>; and enter Bridge #
{{vccs:conference:sipAddress}}
#</p>
<ul>
<li>Meeting title: {{vccs:conference:title}}</li>
<li>Participant PIN: {{vccs:conference:participantPin}}</li>

<li>Bridge #: {{vccs:conference:sipAddress}}#</li>
</ul>
vccsInviteEmailText
You've been invited to the meeting with {{xmpp:displayname}}!
To join using Bria or a web browser click: {{vccs:conference:briaUrl}}
To join using a phone: Please select a local dial-in number from this site
https://go.counterpath.com/virtual-meeting-rooms-dial-in-numbers and enter Bridge #
{{vccs:conference:sipAddress}}#
Meeting title: {{vccs:conference:title}}

---------
* Participant PIN: {{vccs:conference:participantPin}}
* Bridge #: {{vccs:conference:sipAddress}}
Collaboration email summary template

conferenceSummaryHtml
<html>
<head>
<style>
#header {
background-color:#fc6831;
color:white;
text-align:center;
padding:5px;
}
#footer {
background-color:#fc6831;
color:white;
clear:both;
text-align:center;
padding:5px;
}
</style>
</head>
<body>
<div id="header">
<h1>Meeting Summary Report</h1>
</div>
<h3>Bridge Information</h3>
<ul>
<li>Title: {{title}}
<li>Bridge #: {{prefix}}{{bridge}}
<li>Owner: {{owner}}
<li>Description: {{desc}}

</ul>
<br>
<h3>Meeting Information</h3>
Start Time: {{startTime}}<br>
End Time : {{endTime}}<br>
<br>
{{screenShareUsage}}<br>
Number of Participants removed: {{numKicked}}<br>
<br>
Total Number of Participants: {{numParticipants}}
<ul>
<li>Desktop: {{numDesktop}}
<li>Mobile: {{numMobile}}
<li>Tablet: {{numTablet}}
<li>Dial In: {{numDial}}
<li>Web: {{numWeb}}
</ul>
{{recordingData}}
{{participantInfo:num;info;sip;name;xmpp;joined;start;duration;recorded}}
{{chatData:time;from;message}}
<div id="footer">
<h3>Powered by CounterPath</h3>
</div>
</body>
</html>
Keywords supported in this template

These keywords are variables; they will be converted to a real value when Stretto creates
an email for the host.
l {{title}} = Meeting title
l {{prefix}} = Meeting group bridge prefix
l {{bridge}} = Meeting bridge
l {{owner}} = Meeting owner
l {{desc}} = Meeting description
l {{startTime}} = Meeting start time
l {{endTime}} = Meeting end time
l {{screenShareUsage}} = screen share label and duration

l {{numKicked}} = number of participants kicked out of the meeting

l {{numParticipants}} = number of participants
l {{numDesktop}} = number of desktop participants
l {{numMobile}} = number of mobile participants
l {{numTablet}} = number of tablet participants
l {{numDial}} = number of dialed in participants
l {{numWeb}} = number of web participants
l {{recordingData}} = recording label and link
l {{participantInfo:num;info;sip;name;xmpp;username;joined;start;duration;recorde
d}} = table of participant information. The participantInfo is shown in a table format
and the fields following the : represent the columns of the table.
l {{chatData:time;from;message}} = table of meeting chat messages. The chatData is
shown in a table format, and the fields following the : represent the columns of the
table.
Collaboration guest access template

This template is used to authenticate guest users to a meeting. The template might
require slight adjustments depending on your firewall settings or network.
vccsDirectSipTemplate
{
"sipAccount": [
{
"sipAccountSettings":
{
"username": "{{vccs:guest:username}}",
"domain": "{{vccs:guest:domain}}",
"outboundProxy" : "{{vccs:guest:domain}}:5061",
"alwaysRouteViaOutboundProxy" : true,
"password": "{{vccs:guest:password}}",
"displayName" : "{{vccs:guest:displayname}}";
"useRegistrar": true,
"ipVersion": 2,
"enableNat64Support": true,
"sipTransportType": 4,
"acceptedCertPublicKeys" : ["{{tls:public_key}}"],
}
}
],

"conversation": [
{
"conversationSettings" :
{
"natTraversalMode" : 2,
"natTraversalServerSource" : 2,
"natTraversalServer" : "stun.counterpath.com"
}
}
]
}
Collaboration dial-in numbers template

There are two styles supported: show numbers inline (on the left), or linked to an external
page (on the right).
or
vccsAccessTemplate - Inline
The country_list section is optional; when used, the page shows a subheading under the
region. In the above image, notice the Canada subheading under the North America
region, as opposed to the EMEA region.
{
access:{
"numbers": [
[{
region: 'NORTH AMERICA',
country_list: [
{
name: 'CANADA',
number_list: [
'Alberta - Edmonton: +1-587-414-1311',

'Alberta - Calgary: +1-587-333-7730 ',

'British Columbia - Vancouver: +1-778-656-0781'
]
},
{
name: 'MEXICO',
number_list: [
'México - México City: +52 555 350 3588 (english)'
]
},
{
name: 'USA',
number_list: [
'California - Los Angeles: +1-213-460-4891'
]
}
]
}],
[{
region: ' EMEA',
number_list: [
'Austria - Nationwide: New +43 7208 82757 (deutsche)',
'Belgium - Brussels: New +32 2588 8809 (français)',
'Belgium - Brussels: New +32 2588 8810 (deutsche)'
]
}],
[{
region: 'ASIA PACIFIC',
number_list: [
'Australia - Sydney: +61 2 8607 8079'
]
}, {
region: 'SOUTH AMERICA',
number_list: [
'Argentina - Buenos Aires: +54 115 168 5873 (english)'
]
}]
]
}
}
vccsAccessTemplate - external link
{
access:{
"URL": "https://.....";
}
}

User Portal template

A User Portal template is formatted as shown below
A User Portal template is an HTML document. Like the other templates, the values of
Stretto attributes can be included by inserting the attribute name in double curly braces:
{{attribute_name}}. As well, you can create attributes that contain blocks of
HTML markup, which is inserted as-is into the User Portal page.
In the following example, the User Portal page includes the user's personal information,
markup to insert HTML head markup, a company logo, and links to the company website.
<!DOCTYPE html>
<html>
<head>
{{htmlPortalHeadContent}}
</head>
<body>
<p>{{htmlAcphoneLogo}}</p>
<h1>User Portal</h1>
<p>Customer name: {{diplayName}}<br/>
Account: {{accountNum}}<br/>
Email: {{emailAddress}}</p>
<p>To manage your account settings, please visit the settings page:<br/>
<a href="../home.html">SETTINGS</a></p>
<p>ACPhone.com links:<br/>
{{htmlAcphoneSiteLink}}<br/>
{{htmlSupportLink}}</p>
</body>
</html>
Stretto URLs
This section lists the URLs used in the various Stretto features. It is intended to serve as a
convenient summary. If you are not familiar with how these URLs are used, read the
relevant section of this guide.
Bria Push Service

l URL: https://push.softphone.com/push
l Related attribute: None
l Related Bria mobile setting: pushServerUrl in "Core Settings"

Call History Sync

l URL:
wss://sync1.cloudprovisioning.com
/sync/sock/{{ccs:groupName}}
/{{ccs:userName}}?uuid={{ccs:req:uuid}}
l Related attribute: std:sync:callhistory:url
l Related Bria desktop setting: feature:call_history_stretto_sync:url
l Related Bria mobile setting: callHistoryStrettoSyncUrl in "Core Settings"
Collaboration
l URL:
wss://collab.cloudprovisioning.com:443
/join
l Related attribute: collabServerUrl
l Related Bria desktop setting: feature:vccs:url
l Related Bria mobile setting: vccsUrl in "Core Settings"
l URL:
wss://imp.softphone.com:5291/
l Related attribute: vccs:xmpp.websocket-url
Desktop remote upgrade

l URL:
https://stretto.cloudprovisioning.com/upgrade?Username=$loginname$&Passwor
d=$loginpassword$&build=$build$
&platform=$platform$&uuid=$computerid$&spid={{ccs:groupName}}&type=$type$
l Related attribute: None
l Related Bria desktop setting: feature:auto_update:code_server_url
End User Portal

l URL: https://stretto.cloudprovisioning.com:18082
/userportal/login?
username=$loginusername$&password=$loginpassword$

l Related attribute: desk.feature.webBrowser.url and mob.feature.webBrowser.url

l Related Bria desktop setting: feature:browsertab:url<number>
l Related Bria mobile setting: url in "Application Settings"
Enhanced Client Traces

l URL:https://stretto.cloudprovisioning.com:18082/clienttrace/submit/
{{ccs:groupName}}
l Related attribute: std:logserver:url
l Related Bria desktop setting: standard_log:post_server_url
l Related Bria mobile: logCustomerPostUrl in “Application Settings”
Help Desk Assistant

l URL: wss://stretto.cloudprovisioning.com:18082/hda/socket
l Related attribute: remoteDebugUrl
l Related Bria desktop setting: Not supported
l Related Bria mobile setting: remoteDebugPostServiceUrl in "Core Settings"
l URL: https://stretto.cloudprovisioning.com:18082/hda/auth/{{ccs:groupName}}
l Related attribute: std:remotedebug:authurl
l Related Bria mobile settings: remoteDebugPostAuthUrl in "Core Settings"
Stretto Admin
l URL: https://strettoadmin.cloudprovisioning.com/stretto/
Stretto Notification Service

l URL:
wss://stretto.cloudprovisioning.com:18082/notification/subscription
l Related attribute: no attribute unless you create your own
l Related Bria desktop setting: proxies:feature:stretto_notifications:sns_
websocket_url

Stretto Sync
l URL:
wss://stretto.cloudprovisioning.com:18889/sync/sock/{{ccs:groupName}}/
{{ccs:userName}}?uuid={{ccs:req:uuid}}
l Related attribute: std:sync:url
l Related Bria desktop setting: proxies:proxyN:stretto_sync_url
l Related Bria mobile setting: strettoSyncUrl in the Account Data Settings section
User Experience Metrics

l URL:https://stretto.cloudprovisioning.com:18082/uxmetrics/submit/
{{ccs:groupName}}
l Related attribute: std:vqmserver:url
l Related Bria mobile setting: feedbackPostUrl in “Application Settings”

Stretto Platform Administration Guide What's new in Stretto 3.4.0 - November 2022
What's new in Stretto 3.4.0 -

November 2022
Here is a list of new features and changes made to the Stretto Admin web interface and
Stretto Platform API.
Stretto Sync improvements

Previously the only way to delete the synced content was to delete the Stretto user
entirely. For example, if you need to recycle a DID (move a DID from one Stretto user to
another Stretto user), in previous Stretto, deleting the Stretto user was required.
With Stretto 3.4.0, the new Users > Synced Accounts tab allows the admin to delete a
sync account and its content from a user, which means the admin can assign the DID to a
different Stretto user without deleting the original Stretto user who was associated with
the DID. See Managing synced messages - deleting a sync account on Stretto for more
information.
There are also new Stretto APIs available for managing sync accounts. See this page.
Changes - Service level limits to be copied

over for Domain admins
Note: Service levels and Domain admins apply to select customers; skip this section if your
organization do not use them.
If you have Domain admins in your Stretto, you, as a Normal admin, can set a service
level limit in the "-template" group, so that all the groups created by Domain admins has
a service level limit in place. Previously by default all service levels had a limit of 0 which
means no users were allowed to access until a Domain admin sets a limit in every new

Stretto Platform Administration Guide What's new in Stretto 3.4.0 - November 2022
group created by the Domain admin. Starting Stretto 3.4.0, service level limits will be
copied over from the -template group to new groups created by Domain admins.
Previous releases
l Stretto 3.3.0 New features - May 2022
l Stretto 3.2.0 New features - September 2021
l Stretto 3.1.0 New features - June 2021
l Stretto 3.0.0 New features - December 2020
l Stretto 2.3.0 New features - March 2020
l Stretto 2.2.0 New features - August 2019
l Stretto 2.1.1 New features - March 2019
l Stretto 2.1.0 New features - October 2018
l Stretto 2.0.0 New features - April 2018
l Stretto 1.9.1 New features - October 2017

Stretto Platform 340 Admin Guide CP-Hosted

Uploaded by

Copyright:

Available Formats

Stretto Platform 340 Admin Guide CP-Hosted

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Stretto Platform 340 Admin Guide CP-Hosted

Uploaded by

Copyright:

Available Formats

Stretto Platform Administration

Copyright ©2022 CounterPath an Alianza Company. All rights reserved.

Stretto™ and the Stretto Platform™ are trademarks of CounterPath Corporation.

CentOS is a trademark of Red Hat, Inc.

CounterPath an Alianza Company

Overview of Stretto administration 1

Viewing logs and reports 312

Overview of Stretto administration

This document describes the provisioning of CounterPath® softphones using Stretto

This manual is intended for:

CounterPath an Alianza Company 1

l Internet Explorer® 11 or newer is supported. The older versions of Internet Explorer

CounterPath an Alianza Company 2

CounterPath an Alianza Company 3

Each profile must be associated with at least one provisioning template.

CounterPath an Alianza Company 4

CounterPath an Alianza Company 5

Synchronizing your systems

How data becomes unsynchronized

If an administrator makes a change on Stretto, a data discrepancy obviously occurs.

CounterPath an Alianza Company 6

Which system is the "master"?

CounterPath an Alianza Company 7

Designing your Stretto framework

Rules for the order in which you create entities

l Create the group first.

Case sensitivity for Stretto entities

CounterPath an Alianza Company 8

Case sensitivity for provisioned data

Known Stretto attributes

CounterPath an Alianza Company 9

Setting up Stretto entities

Identify settings and their combinations

To identify settings and their combinations

CounterPath an Alianza Company 10

Instead, create one called “codec_g722_enabled” and another called “codec_

Configuration A 0 stunserverA.com false false

Configuration B 0 stunserverB.com false true

Configuration C 0 stunserverA.com true false

Configuration D 0 stunserverB.com true true

CounterPath an Alianza Company 11

Determine the number of groups

More than one real group?

CounterPath an Alianza Company 12

different deployments is instead handled by profiles within the group, not by

Determine the number of templates and profiles

CounterPath an Alianza Company 13

used to differentiate between deployments: this is the purpose of profiles.

CounterPath an Alianza Company 14

Create the entities in Stretto

To create Stretto entities

1. Log into Stretto.

CounterPath an Alianza Company 15

Modify the templates

In a Bria mobile template:

CounterPath an Alianza Company 16

For template formats, see Stretto template formats.

Modify the profiles

Assign values to group-attributes

CounterPath an Alianza Company 17