6 Session Border Controller Configuration

6.1 Introduction

This chapter describes all the necessary information about the settings that should be made on the customer’s SBC in order to integrate with the AnywhereNow Dialogue Cloud Session Border Controllers.

6.2 Enabling SIP over TLS

6.2.1 Introduction

Since the AnywhereNow Dialogue Cloud SBC is running in the Azure Cloud and the Customer’s SBC will interconnect with this cloud using the public internet, it is advised to encrypt both signaling (TLS) and media (SRTP) interfaces.

6.2.2 Supported TLS versions

For setting up a secure signaling connection the SIP over TLS encryption is supported. Where the Anywhere 365 will only support the TLS versions 1.2 + 1.3.

6.2.3 TLS profile Ciphers

For Cipher server and client, AnywhereNow has 2 profiles available: Default and Strong-TLS. If the customer wants a Strong-TLS profile, this must be communicated before setting up the TLS interface to the delivery manager or project lead.

Profiles are in OpenSSL Cipher list format. For possible values and additional details, visit the OpenSSL website at https://www.openssl.org/docs/man1.1.1/man1/ciphers.html

Default:

• The default cipher list for TLS 1.2 + 1.3.

Strong-TLS:

• HIGH:!SHA:!AES128:!ECDHE-RSA-AES256-SHA384:!DHE-RSA-AES256-SHA256:!AES256-SHA256:!aNULL

Both profiles use DH Key size of 2048.

6.2.4 TLS Certificate Root Chain

The AnywhereNow SBC uses Sectigo as the public certificate provider for all regions.

The root chain for the certificates contains the following:

• Intermediate certificate 1:

  • CN = Sectigo RSA Domain Validation Secure Server CA

  • Serial number: 7d5b5126b476ba11db74160bbc530da7

• RootCa:

  • CN = USERTrust RSA Certification Authority

  • Serial number: 01fd6d30fca3ca51a81bbc640e35032d

If the certificates are needed to trust our TLS connection, please download them at https://sectigo.com/resource-library/sectigo-root-intermediate-certificate-files using the above-mentioned information.

6.3 Enabling SRTP/SRTCP

6.3.1 Introduction

Since the AnywhereNow Dialogue Cloud SBC is running in the Azure Cloud and the Customer’s SBC will interconnect with this cloud using the public internet, it is advised to encrypt both signaling (TLS) and media (SRTP) interfaces.

Since the same encryption key (master key) is used for SRTP as well as for SRTCP, for simplicity the topic below will referrer to SRTP only instead of naming them both throughout the text.

6.3.2 Exchange of SRTP encryption keys

When SRTP is enabled the encryption keys used will be transferred in the SDP part of the SIP messages used for setting up the voice session (referred to as SDES). To assure that the SRTP encryption keys cannot be compromised it is required to only active SRTP if SIP over TLS has also been activated.

6.3.3 Preferred SRTP Encryption Settings

Note that the list below contains many SRTP-specific settings. The list has been created based on resolving different customer integration issues and complaints. Following the guidelines below may not be possible for all settings because the available SRTP parameters may differ per SBC vendor and even per SBC software version. It is however strongly recommended to follow these settings as closely as possible ensuring a smooth customer integration.

The table lists several possible, required and optional settings (Note: below the table each setting is explained in more detail):

Table 8 – Preferred SRTP/SRTCP settings

6.3.3.1 Offered Cipher suite

The logic for the Dialogue Cloud has been built on top of a generic VoIP Microsoft service. For this Microsoft service it has been specified that the cipher AES-CM-128-HMAC-SHA1-80 should be used.

This requirement is mandated to the customer’s SBC, avoiding re-ciphering between different ciphers for each RTP packet on any intermediate SBCs.

6.3.3.2 SRTP Encryption

It should be noted that it is possible to activate SRTP and on this SRTP connection to disable encryption of the SRTP packages (this can be a local requirement). In this case SRTP will only be using the authentication module of the SRTP stack.

If encryption is not locally prohibited, it is advised to enable SRTP encryption, blocking the possibility for unwanted eavesdropping.

6.3.3.3 SRTP Authentication

It is advised to enable SRTP Authentication, assuring that:

• No man-in-the-middle attacks can be performed on the exchanged RTP packages

• Reducing the impact of a DOS attack because all packages that do fulfill the Authentication check or Authentication window can be dropped by the SBC without further processing.

6.3.3.4 SRTCP Encryption

Since an SRTCP package only contains information about the quality of a media connection, the RTCP packet's contents are not considered a major sensitivity to eavesdropping. For this reason, SRTCP encryption is set to preferred. It should be noted that SRTCP Authentication cannot be disabled, since its risk for fraudulent attack risks for altering the voice quality parameters, causing media renegotiations.

6.3.3.5 MKI size “1”

The logic for the Dialogue Cloud has been built on top of a generic VoIP Microsoft services. For these Microsoft services it has been specified by Microsoft that an MKI value of 1 is preferred, but a value of 0 is supported. It should also be noted that by default Microsoft used MKI value 1 for all originating sessions.

To follow this recommendation and to avoid rekeying needs to be performed in the Dialogue Cloud SBC for each handled RTP packet, this requirement to also use the MKI value of 1 is also mandated to the customer’s SBC.

6.3.3.6 Symmetrical MKI

When terminating of tunneling an SRTP session, the SDP offer returned to the VoIP User Agent Client (UAC) should preferrable match the MKI size offered by the UAC. This will ensure that the SRTP MKI size always matches the MKI size supported by the UAC.

6.3.3.7 Rekey on REINVITE

In theory it is possible to create a new SRTP master key per SDP renegotiation (i.e. REINVITE request) but is reality this is not really required this since the lifetime of a masterkey greatly outlives the lifetime of a phone call. Furthermore, in certain deployments the activation of SRTP re-keying triggered one-way audio issues after the rekey event. For the reasons above it is preferred to disable this functionality.

6.3.3.8 Rekey on Session Expire

In theory it is possible to create a new SRTP master key when a REINVITE is sent due to a Session Expire i.e. triggering a REINVITE request containing new session Expiry Timer values. However, in providing a new master key as part of a session expiry is in reality not really required this since the lifetime of a masterkey greatly outlives the lifetime of a phone call. Furthermore, in certain deployments the activation of SRTP re-keying triggered one-way audio issues after the rekey event. For the reasons above it is preferred to disable this functionality.

6.3.3.9 SRTP Tunneling Authentication for RTP

Some SBC’s provide the option to enable an SRTP authentication check for each SRTP packet that is tunneled through the SBC.

By enabling SRTP authentication for a tunneled session the tunneling SBC can already recognize and drop faulty/invalid SRTP packages before forwarding them on the tunnel. Enabling this setting will slightly enlarge the system load on the tunneling SBC, but it will assure that the AnywhereNow SBC (handling a lot higher number of connections), does not spend unnecessary time on processing the packages for which it is already known that they are invalid. Example: If the customer’s SBC receives a targeted SRTP DOS attack and drops all invalid packages, this will not harm the AnywhereNow SBC.

6.3.3.10 SRTP Tunneling Authentication for RTCP

Some SBC’s provide the option to enable an SRTCP authentication check for each SRTCP packet that is tunneled through the SBC.

By enabling SRTCP authentication for a tunneled session the tunneling SBC can already recognize and drop faulty/invalid SRTCP packages before forwarding them on the tunnel. Enabling this setting will slightly enlarge the system load on the tunneling SBC, but it will assure that the AnywhereNow SBC (handling a lot higher number of connections), does not spend unnecessary time on processing the packages for which it is already known that they are invalid. Example: If the customer’s SBC receives a targeted SRTCP DOS attack and drops all invalid packages, this will not harm the AnywhereNow SBC.

6.4 Supported Media Codecs

AnywhereNow Dialogue Cloud supports 2 media codecs:

• G711U (Preferred codec in region: NORA)

• G711A (Preferred codec in all other regions)

6.5 Number Format specifications

6.5.1 E-164 Only

AnywhereNow Dialogue Cloud only uses and routes all voice sessions to and from the customer’s SBC using the +E.164 The E.164 phone number format is an international (ITU) standard for dialing telephone numbers on the Public Switched Telephony Network (PSTN). Loosely formulated, only "+" and upto 15 digits (0-9) are allowed For example: +4433221100 (For number notation/display and storage see the E.123 standard) number format. If no +E.164 format number is present in the TO and FROM header, the AnywhereNow Dialogue Cloud will not handle the call and will reply with an unwanted SIP 408 message.

E.164 is the international telephone numbering plan that ensures each device on the PSTN has a globally unique number.

This number allows phone calls and text messages to be correctly routed to individual phones in different countries. +E.164 numbers are formatted [+] [country code] [subscriber number including area code] and can have a maximum of fifteen digits.

6.5.2 Unsupported To and From header contents

AnywhereNow Dialogue Cloud does NOT support numbers with extra parameters in the From and To URL. Parameters like:

• Extension. ;ext=xxxxx

• Verstat (USA Stir/Shaken verification)

This will result in an unwanted SIP 408 message. Please only send unique numbers and remove all extra parameters.

AnywhereNow Dialogue Cloud will not look at domain-part of SIP Uri of From and To on incoming calls and follows the user=phone parameter.

6.5.3 Privacy headers and anonymous calling

AnywhereNow Dialogue Cloud considers all our SIP-Trunk’s connections as trusted proxies. If privacy header with value ID is presented to us AnywhereNow Dialogue Cloud will not change the From Uri to anonymous as we expect to honor settings that are been set in SharePoint which CallerID needs to be presented.

When customer or partner SBC sends us an anonymous call it will be respected but under the following conditions:

• RFC3323 privacy header

  • User-Uri / Src.User / Header.from.URL.User needs to be exactly: anonymous

    • No capital letters

  • Examples:

    • From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774

    • From: "Peter" <sip:anonymous@example.com>;tag=1928301774

    • From: "A0017" <sip:anonymous@voorbeeld.nl>;tag=1928301774

    • From:  <sip:anonymous@anonymous.invalid>;tag=1928301774

    • From: "Reception" <sip:anonymous@workstreampeople.com>;tag=1928301774

6.6 AnywhereNow specific routing logic

6.6.1 Routing rules

In the customer’s SBC AnywhereNow specific routing logic should be implemented to assure that all calls destined to the Anywhere Direct Cloud application are routed to the AnywhereNow SBC.

This routing logic should assure that the following calls are forwarded to the AnywhereNow SBC:

• Calls destined to a UCC A Unified Contact Center, or UCC, is a queue of interactions (voice, email, IM, etc.) that are handled by Agents. Each UCC has its own settings, IVR menus and Agents. Agents can belong to one or several UCCs and can have multiple skills (competencies). A UCC can be visualized as a contact center “micro service”. Customers can utilize one UCC (e.g. a global helpdesk), a few UCC’s (e.g. for each department or regional office) or hundreds of UCC’s (e.g. for each bed at a hospital). They are interconnected and can all be managed from one central location. phone number^*

• Calls destined to a phone number assigned to a Teams user that needs to be inbound intercepted^*

• Calls originated from a phone number that is assigned to a Teams user that needs to be outbound intercepted^*

^* These calls should be routed to the AnywhereNow SBC, independent of whether they have been received from the PSTN or from the Teams Calling application server.

It will be up to the customer’s SBC supported configuration settings and the design choices made by the customer’s VoIP engineer how the above routing rules are implemented. Examples of routing solutions that are available:

• Create a set of routing rules in the SBC per phone number
  Pro: Very precise mapping

  • Cons: Labor intensive and error prone

• Query an external database (e.g. using LDAP or ENUM)

  • Pros: In most cases having better configuration interfaces than an SBC

  • Cons: Adding an additional server into the service chain.

• Route all call request first to the AnywhereNow SBC and let this SBC decide if the call should be handled by the Dialogue Cloud platform (for all unknown users a SIP 408 is returned, to allow further call routing)
  Pro: Easy to configure and minimal maintenance

  • Cons: All call setup requests are routed via the AnywhereNow infrastructure.

6.6.2 Dialogue Cloud Interception Service

6.6.2.1 Introduction

Next to the Dialogue Cloud Service Contact Center service, the Dialogue Cloud also offers the service to intercept regular calls made to and from Teams Calling users. Examples of services that can be provided to this intercepted user are:

• Calls made directly to the Teams user’s phone number can be intercepted and directly routed to the UCC of which the user is a contact center agent.

• Call recording for calls made to and from this user

• Outbound calling number manipulation (e.g. replace the outbound Calling Party number of the user with the number of the UCC).

6.6.2.2 Specific Inbound call handling logic on the customer’s SBC

To assure that the Interception service is able to provide the above mentioned services, the customer’s SBC must be configured to differentiate for each incoming call from the ITSP/PBX if:

• The call can be directly routed to Teams (non-intercept-user)

• The call should first be forwarded to the Dialogue Cloud (intercept-user).

Activating inbound interception

Per SBC vendor and customer VoIP support team, different routing solutions can be implemented to assure that calls destined to Teams Calling phone numbers are routed to the AnywhereNow Dialogue Cloud SBC instead of to the Teams application server.

For more information about routing rules that should be implemented on your SBC, refer to section 6.6.1 Routing rules.

Routing after interception

After receiving an incoming intercepted call, the Dialogue Cloud will perform the required services for this call leg. When the logic indicates that the call should be routed to the initially intended Teams Calling user, a new UCC initiated session interconnecting the two call legs will be routed to the customer’s SBC. In this call request the Dialogue Cloud will provide an additional indication in the SIP message (A365-AgentHunt=1) that the call is intended for the Teams Calling user.

6.6.2.3 Specific Outbound call handling logic on the customer’s SBC

To assure that the interception service is active for each outbound call of a user for which the Interception Service should be provided, logic is required on the customer’s SBC to recognize this call request and route the call to the AnywhereNow Dialogue Cloud SBC instead of the ITSP.

Note: On the SBC routing rules can for example be defined on the phone number provided in the SIP FROM header.

Activating outbound interception

Per SBC vendor and customer VoIP support team different routing solutions can be implemented to assure that calls originated by Teams Calling phone numbers, are routed to the AnywhereNow Dialogue Cloud SBC instead of to the ITSP (or other destination).

For more information about routing rules that should be implemented on your SBC, refer to section 6.6.1 Routing rules.

Routing after interception

After receiving an outcoming intercepted call, the Dialogue Cloud will perform the required services for this call leg. When the logic indicates that the call should be routed to the intended destination number, a new UCC initiated session interconnecting the two call legs will be routed to the customer’s SBC. In this call request the Dialogue Cloud will indicate in the SIP request (A365-AgentHunt=0) that the call should be routed to the requested destination.

6.7 Contact Center Agent initiated call transfers

6.7.1 Introduction

When for a UCC call the answering Contact Center agent determines that a call transfer is required, the knowledge about the performed call transfer is essential for the Dialogue Cloud application software. Having knowledge about this change, for example allows the Dialogue Cloud to add this additional “meta data” the UCC call records, making this available for e.g. call center supervisors.

At the moment that the AnywhereNow Dialogue Cloud is integrated into the existing Teams Direct Routing ecosystem, a number of changes are required in the customer’s SBC to assure that when for a Contact Center Calls a call transfer performed, that this transfer is handled by the Dialogue Cloud application and not by Teams or the customer’s SBC itself.

A more detailed explanation of the required changes and call handling are explained in the topics below.

6.7.2 Handling of SIP REFER message (EDR prerequisite description)

Whenever an attended or un-attended call transfer is performed by a Teams user, Teams will translate this request by initiating a SIP REFER message requesting the transfer request to the underlying SIP network elements.

How these transfers are performed and how the SIP REFER messages are handled is  described in the Teams Direct Routing guidelines (reference: Teams Phone System Direct Routing: SIP protocol - Microsoft Teams; Section: “Call Transfer”.

In this guideline two different call transfer implementations are described:

• Option #1: The Teams application server fully handles the call transfer

• Option #2: The Teams application server delegates the call transfer to an underlying SIP Server. <- This is used by AnywhereNow EDR Enhanced Direct Routing (EDR) is a mechanism introduced by AnywhereNow based on Microsoft Direct Routing (Option 2) to allow richer transferheaders in SIP messages, allowing for more information to be passed on in transfer and forward scenarios.

In order to make sure that the AnywhereNow Dialogue Cloud application server will be in involved in the call transfer, the Teams option #2 will be used, in which the Dialogue Cloud Application server will act as the SIP Proxy mentioned in the diagram. (see: Teams Phone System Direct Routing: SIP protocol - Microsoft Teams; Section: "SIP proxy send the Refer to the SBC and acts as a Transferor")

In order to support the option #2, the Dialogue Cloud has to indicate in each outgoing call request that it is capable of handling call transfers. The application indicates this by including in each outgoing call request the REFER text in the SIP allow header.

At the moment that an agent performs a call transfer, the Teams Application server will know from the initial received call request that the Dialogue Cloud supports call transfers, and as a result it will send a SIP REFER message requesting the call transfer over the existing UCC call leg to the customer’s SBC. In its turn the customer’s SBC should forward the SIP REFER message to the Dialogue Cloud, requesting if this application server can perform the call transfer for the intended call leg.

6.7.3 Handling of the new initiated call leg (EDR technical description)

After receiving the request to perform the call transfer on the Dialogue Cloud (i.e. receiving the SIP REFER) the Dialogue Cloud will initiate a new call leg to the intended destination.

Following the Teams Calling specifications for a call transfer, the newly created call leg should always be routed via the Teams application server before it is forwarded towards the intended destination. In order to make sure that this routing logic is followed for a call Transfer, the Dialogue Cloud application server will add a specific parameter (A365-IsRefer) into the outgoing call request, allowing the customer’s SBC to recognize this call request and using specific routing rules to route this call to Teams instead of to the requested destination.

6.7.4 If integration issues occur

If the customer’s SBC or network prohibit the specified implementation as described in the previous topics, a different integration is supported with the AnywhereNow Cloud Application but it will provide a loss of functionality.

If integration issues occur and a different alternative is required, please contact the AnywhereNow Professional Services Team.

6.8 AnywhereNow specific SIP Headers

AnywhereNow Dialogue Cloud will add additional headers in the sip flow towards the customer’s SBC. These headers will give extra functionality for call forwarding settings and routing purposes.

6.8.1 Header X-MS-RoutingPolicies

This header is introduced by Microsoft Teams and is re-used in the Dialogue Cloud solution.

The header is inserted by the AnywhereNow Dialogue Cloud for each outgoing call to a Contact Center agent, indicating to the MS Teams Application server to either follow or ignore the end-user’s call forwarding settings. The header can contain the following values:

• none

• disable_forwarding

6.8.1.1 RoutingPolicy: none

When the RoutingPolicy is set to ‘none’ it will ensure that MS Teams honor and follow the call forwarding settings set by the Teams user or Teams Administrator.

Example: Teams user has configured a call forward to user’s voicemail if the call is unanswered for 10 seconds. The UCC hunt-time-out has been set for 20 seconds in SharePoint. When this Teams user is hunted, and the call is not answered within 10 seconds the call will go to the voicemail of this user. The customer that called the UCC can then leave a message in the agent’s voicemail.

6.8.1.2 RoutingPolicy: disable_forwarding

When the RoutingPolicy is set to ‘disable_forwarding it will make sure that MS Teams will ignore the call forwarding settings either set by the Teams user or Teams Administrator.

Example: Teams user has configured a call forward to user’s voicemail if the call is unanswered for 10 seconds. The UCC hunt-time-out has been set for 20 seconds in SharePoint. When this Teams user is hunted, and the call is not answered within 10 seconds the hunt will go on for 10 seconds before it will timeout. After the timeout, the UCC will hunt for the next available agent.

6.8.1.3 Example

The figure below gives a summarize SIP INVITE message containing the X-MS-RoutingPolicies header:

INVITE sip:+31707777001@region.p-sbc01.region.anywhere365.cloud;user=phone SIP/2.0
From: "UCC Anywhere" <sip:+31881200600@region.p-sbc01.region.anywhere365.cloud;user=phone>
To: <sip:+31707777001@region.p-sbc01.region.anywhere365.cloud;user=phone>
User-Agent: WSP Cloud Controller
A365-AgentHunt: 1
A365-TenantId: A365
X-MS-RoutingPolicies: None

6.8.1.4 SharePoint settings

The value can be changed with the SharePoint setting: DisableCallForwarding. This setting can have multiple values:

Table 9 – DisableCallForwarding settings on SharePoint

6.8.2 Header A365-TenantId

This header is used by the AnywhereNow Dialogue Cloud application to support partner solutions that interconnect with multiple tenants over the same SIP trunk with the AnywhereNow SBC.

For each outgoing call request, the Dialogue Cloud application server includes in indication to which Tenant the call is destined. By default, the value is always set to ‘A365’.

For example, if the customer's name is Contoso; the outgoing SIP traffic from AnywhereNow will have this header. The customer or partner can then route/manipulate/do a set of actions based on that header.

The figure below gives a summarize SIP INVITE message routed from the Dialogue Cloud Application to the customer’s SBC containing the A365-TenantId header:

INVITE sip:+31707777001@region.p-sbc01.region.anywhere365.cloud;user=phone SIP/2.0
From: "UCC Anywhere" <sip:+31881200600@region.p-sbc01.region.anywhere365.cloud;user=phone>
To: <sip:+31707777001@region.p-sbc01.region.anywhere365.cloud;user=phone>
User-Agent: WSP Cloud Controller
A365-AgentHunt: 1
A365-TenantId: A365-Contoso
X-MS-RoutingPolicies: None

6.8.3 Header A365-IsRefer

For each outgoing call leg that is performed by the AnywhereNow Dialogue Cloud application on request of a Teams initiated call transfer, the outgoing call request will contain the A365-IsRefer header.

For more information about this parameter and its usage refer to section 6.7 Contact Center Agent initiated call transfers .

To make sure that the Call Transfer is handled by the AnywhereNow Dialogue Cloud application and not by the customer’s SBC, the customer must:

• Make an adjustment to the existing Direct Routing Setup

• Create a new routing rule for handling the A365-IsRefer header

6.8.3.1 Make an adjustment to the existing Direct Routing Setup

To make sure call transfer request will function a change in customer’s SBC is required. To support transfers, SIP REFER messages need to be sent towards AnywhereNow Dialogue cloud instead and should not be handed locally.

MS Teams does not share information about what kind of transfer has been selected. Therefore, AnywhereNow Dialogue Cloud will use the Teams environment as a regulating hub for all transfers. This results in additional legs, but this will make sure all consultative transfer scenarios work with every provider and SBC brand.

For more information about the routing path for call transfers, refer to chapter 7.5 Transfer Scenarios.

6.8.3.2 Create a new routing rule for the A365-IsRefer header

AnywhereNow Dialogue Cloud will add the following header to the Invite that is the result of a REFER:

• A365-IsRefer with value 1

If this header is present, AnywhereNow Dialogue Cloud advice is to route this call request towards MS-Teams to assure that every transfer scenario functions correctly. As our back end does not know if the REFER is result of a direct or consultative transfer, the header will be added to all transfer calls as result of a SIP REFER.

6.8.4 Header A365-AgentHunt

For each session that is initiated by the AnywhereNow Dialogue Cloud (e.g. hunting for an agent) and that is routed to the customer’s SBC, the SBC needs to determine if the call should be routed to the Teams Application server or e.g. to the ITSP. In order to prevent that the customer’s SBC will require a lot of in-depth routing logic for each destination number, the Dialogue Cloud will indicate using the A365-AgentHunt parameter if the call is intended to be routed to Teams (value=1) or intended to be routed to the ITSP or another non-Teams destination (value=0).

The figure below gives a summarize SIP INVITE message containing the A365-AgentHunt header:

INVITE sip:+31707777001@region.p-sbc01.region.anywhere365.cloud;user=phone SIP/2.0
From: "UCC Anywhere" <sip:+31881200600@region.p-sbc01.region.anywhere365.cloud;user=phone>
To: <sip:+31707777001@region.p-sbc01.region.anywhere365.cloud;user=phone>
User-Agent: WSP Cloud Controller
A365-AgentHunt: 1
A365-TenantId: A365
X-MS-RoutingPolicies: None

In the Dialogue Cloud application, the decision to set the A365-AgentHunt to the value ‘1’ is determined by the following:

1. To use the service in general the SharePoint parameter 'UseTeamsHunter' must be set to ‘true’

2. If the provided destination matches one of the SIP URIs provisioned on the SharePoint in the configured agent’s, trainee’s, supervisor’s or PSTN agent’s TeamsAssignedPhoneUri field.

3. If the call scenario matches one of the below scenarios:

   • An Agent is invited using:

     • This can be a regular Agent with SIP Address and TeamsAssignedPhoneUri
     • This can be a PSTN Agent.

   • A Phone URI is invited that matches the Phone Uri of an Agent.

   • An Agent is invited for a Campaign-Dialer call

   • An Agent is invited for a Direct-Dialer (DCI) call

   • An Agent is invited for a voicemail-Dialer call

   • A "listening" participant (e.g. trainee or supervisor) is added to a dialogue

   • If the Customer is invited for a Campaign-Dialer call, and the Customer URI matches the Phone Uri of an Agent

   • If the Customer is invited for a Direct-Dialer (DCI) call, and the Customer URI matches the Phone Uri of an Agent

   • When the Invitee is invited for an Autonomous-Dialer call; When the Invitee is identified as an Agent based on Phone Uri

   • A Forward Skill forwards a call to a Phone destination that matches the Phone URI of an Agent.

Scenario when Agent-Manipulation is set 0

For any other scenario than the mentioned above, the A365-AgentHunt parameter will be set to ‘0’.

6.9 Miscellaneous VoIP characteristics

6.9.1 Introduction

This section contains a collection of miscellaneous VoIP specific characteristics that can influence the behavior of the AnywhereNow Dialogue Cloud Platform call handling as well as in the session’s speech path.

6.9.2 Call hold

Whenever in the session a call is been placed on hold, the following restrictions apply:

• If a UCC call the call is placed on hold by e.g. the contact center agent and on the Dialogue Cloud Application server an SDP is received with the value A=sendonly, the Dialogue Cloud assumes that Music on Hold is provided by the device on which the call is placed on hold and therefore it will NOT provide a Music on Hold treatment itself (i.e. ignoring Music on Hold settings of the UCC).

• If a UCC call the call is placed on hold by e.g. the contact center agent, and on the Dialogue Cloud Application server an SDP is received with the value A=inactive, the Dialogue Cloud will follow the Music On Hold setting provided for the UCC and therefore (if enabled) provide the Music on Hold treatment.

6.9.3 DTMF

The support of DTMF is according to RFC2833 and RFC4833. Specific remarks are:

• Please declare DTMF in all invite offerings (this also means re-invites), else the call will not establish/break.

• Payload: 101

• Only DTMF Events 0-15/16.

• There is NO support for (please remove from SDP offer accordingly):

  • Data Modem and Fax Events (32-49)
  • Line Events (64-89)
  • Country-specific Line Events (96-112)
  • Trunk Events (128-173).

6.9.4 Early Media

The AnywhereNow Dialogue Cloud supports Early Media offers (i.e. SDP) in the following Provisional Responses:

• The 180 Ringing

• The 183 Session Progress.

6.9.5 Privacy PAI Header

When the Privacy PAI header is available in an incoming call the Anywheres365 Dialogue Cloud SBC will set this as the Source Uri. If this is unwanted, please remove the PAI header.

6.9.6 Silence Suppression / Comfort Noise.

For Silence Suppression / Comfort Noise the following is applicable:

• The AnywhereNow Dialogue Cloud SBC supports comfort noise using the rtpmap:13 CN/8000

• AnywhereNow Dialogue Cloud SBC has RTP broken connection time-out timer of 120 seconds and will break the disconnection if there is no RTP or RTCP packet received for 120 seconds.
  

Note: This is to protect our platform from rogue sessions and prevent overflooding.

6.9.7 SIP Privacy Header

The RFC3323 privacy header is supported under the following conditions:

• User-Uri / Src.User / Header.from.URL.User needs to be exactly: anonymous

  • No capital letters

  • Examples:

    • From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
    • From: "Peter" <sip:anonymous@example.com>;tag=1928301774
    • From: "A0017" <sip:anonymous@voorbeeld.nl>;tag=1928301774
    • From:  <sip:anonymous@anonymous.invalid>;tag=1928301774
    • From: "Reception" <sip:anonymous@workstreampeople.com>;tag=1928301774

• When using anonymous calling please make sure when P-Asserted-Identity is being used that the PAI-Header User value is also in +E.164 Format.

6.9.8 SIP REFER Message

When an Agent (Teams client) transfers a call, the customer SBC needs to send the REFER to AnywhereNow Dialogue Cloud SBC. Please refer to 6.8.3 Header A365-IsRefer.

6.9.9 SIP REINVITES

For SIP REINVITES the following is applicable:

• SIP REINVITES should only be sent when something changes in the SDP, a REINVITE with no change to channel/port/codec can cause call renegotiating failures.

• AnywhereNow does codec restriction (i.e. removes codecs from offer, please take this in account).

6.9.10 SIP REPLACES

For SIP REPLACES header the following applies:

• When sending an REPLACES INVITE with the headers:

  • Require: Replaces
  • Replaces: Call-leg-id@host

• AnywhereNow SBC will reply with a SIP 420 Bad extension because it is not supported.

6.9.11 SDP Bandwidth Modifiers

For the SDP body please remove bandwidth lines. These causes a RTP packet time issue (also see 6.9.14 Bandwidth SDP parameters). Examples are:

B=AS:Value
B=RR:Value
B=RS:Value

6.9.12 RTCP

For RTCP the following is applicable:

• AnywhereNow Dialogue Cloud SBC has been set to always generate this. Even when the call is on hold

• If possible, also set the customer SBC to generate this always, even when the call is on hold, towards AnywhereNow Dialogue Cloud SBC.

6.9.13 User-Agent Header

The User-Agent field is used by several SBC vendors to validate if on the SBC itself certain licenses should be active. On the AnywhereNow Dialogue Cloud SBC, the software automatically checks for each incoming call request if the User-Agent contains “PSTN hub” information (Example: “Microsoft.PSTNHub.SIPProxy v.2021.6.15.17 i.EUWE.1) and if present the SBC software checks if a “Direct Routing” license is active on the SBC.

Since the Direct Route is connected to the customer’s SBC and the AnywhereNow SBC does NOT have a Direct Route with the Microsoft Teams Application server AND therefore no Direct Route license has been activated/purchased by AnywhereNow, this license check will fail resulting that the call request will be rejected with a SIP 500 message. This issue can be resolved by creating an egress manipulation rule on the customer's SBC to alter an outgoing User-Agent header containing “PSTN hub” information to another User-Agent type (e.g. the Customer’s SBC vendor’s name).

6.9.14 Bandwidth SDP parameters

We do not support Bandwidth parameters in the DSP. For example:

b=AS:80
b=RR:800
b=RS:256

Some providers add bandwidth parameters in the SDP body, limiting the bandwidth available. Our backend automatic response is to increase the Ptime of the RTP to 40 or even 60ms, even if 20ms was negotiated. This usually results in one way audio as downstream these larger Ptime packets get dropped. Please remove these parameters from the SDP body

6.10 Multitenancy on one trunk

Multitenancy is mostly seen at partner level where a partner hosts multiple direct routing connections towards MS Teams. In summary the routing will be the same as mentioned in previous chapters. Impersonation, DCI and Interception are available to each customer as explained in this document. The only added difficulty is that multiple customers will use the same trunk towards AnywhereNow Dialogue Cloud SBC. Here are a few examples of how this could look at a high level.

The following figure illustrates the Multitenancy on one trunk option 1:

Figure 5 – Multitenancy on one trunk - option 1

The following figure illustrates the Multitenancy on one trunk option 2:

Figure 6 – Multitenancy on one trunk - option 2

Third option is logically to use (as a partner) one SBC per customer. Since this implementation matches all other pictures and descriptions in this document, this option is not further elaborated. Note: For each customer, a new SBC-SBC trunk will be created towards AnywhereNow Dialogue Cloud SBC. Please note that the SBC per customer will also need a unique IP-address per SBC. If it is not unique, errors can occur because the same IP-address is used for multiple SBC’s.

For partners we have added the header A365-TenantId. The value of this header can be requested by the customer or partner. The default value is ‘A365’.

This header can be used for multitenancy over one trunk connection with AnywhereNow partners to determine for which customer the SIP traffic is meant. For example, if the customer's name is Contoso; the outgoing SIP traffic from AnywhereNow will have this header A365-TenantId with a value of Contoso added in the SIP messages. The customer or partner can then route/manipulate/do a set of actions based on that header.

Example invite from UCC to agent belonging to Contoso:

INVITE sip:+31707777001@customer-sbc;user=phone SIP/2.0
From: "UCC Contoso" <sip:+31881200600@anywhere365-dialoguecloud-sbc;user=phone>
To: <sip:+31707777001@customer-sbc;user=phone>
User-Agent: WSP Cloud Controller
A365-AgentHunt: 1
A365-TenantId: Contoso
X-MS-RoutingPolicies: None

Please note that the A365-AgenHunt has the value 1 and the A365-TenantId has the value Contoso. Meaning this is an agent hunt (please see chapter 6.8.4 Header A365-AgentHunt for explanation) for the customer Contoso.

Example invite from UCC belonging to Fabrikum to customer cell phone:

INVITE sip:+31612345678@customer-sbc;user=phone SIP/2.0
From: "UCC Fabrikum" <sip:+31881200500@anywhere365-dialoguecloud-sbc;user=phone>
To: <sip:+316512345678@customer-sbc;user=phone>
User-Agent: WSP Cloud Controller
A365-AgentHunt: 0
A365-TenantId: Fabrikum
X-MS-RoutingPolicies: None

Please note that the A365-AgenHunt has the value 0 and the A365-TenantId has the value Fabrikum. Meaning this is a call to a normal phone number (please see chapter 6.8.4 Header A365-AgentHunt for explanation) for the customer Fabrikum.