about the project

A large petrochemical company with a large number of offices throughout the country approached us for help. The offices use IP-PBXs of various manufacturers, mainly Cisco and Avaya, while Skype For Business (SFB) helps to solve some of the tasks. We had to integrate the company’s telephony system with Skype For Business so that SfB users could make calls to landlines and vice versa. The customer did not plan to abandon one of the communication channels and completely switch to another. It was required to configure the system in such a way that the user could answer each incoming call as it is more convenient for him – from the phone or from SfB. Of course, the solution must be fault-tolerant.

For those who are not familiar with the work of SIP telephony, I will briefly describe its basic principles. When making a call between clients, two types of network traffic are transmitted: signaling traffic (SIP – Session Initiation Protocol) and media traffic (RTP – Real-time Transport Protocol and SRTP – Secure Real-time Transport Protocol). SIP transmits information necessary to start and end a conversation session. SIP packets contain data, for example, about phone numbers or information about when the subscriber answered the call, when he ended it. Media traffic includes directly sound (voice) compressed with codecs.

When configuring the integration of SfB with an IP-PBX, there are two possible scenarios:

• setting up SIP trunks (communication channels between two systems) directly between IP-PBX and SfB;
• setting up interaction between systems via SBC (Session Border Controller).

Our project uses the second scenario for several reasons.

1. At the customer’s sites – a large number of IP-PBXs from different manufacturers with different firmware versions. Not all of them had the technical ability to install a direct SIP trunk with SfB.
2. The solution should be typical at all sites.
3. One of the requirements is to minimize changes in IP-PBX configurations.

Planning

For the SBC, we used a solution from AudioCodes. The product line of this manufacturer includes AudioCodes Mediant Virtual Edition (VE). In our case, it suited better than the others, since the sites already had virtualization hosts with a sufficient amount of free capacity. If we deploy two virtual machines at each site and place them on different hosts, then we will get a fault-tolerant solution at the service level – this is what we needed. This solution eliminated the need to purchase and install additional equipment.

As a result, the scheme for constructing SIP trunks and placing SBCs was as follows:

The placement of SBC at each site is due to several reasons:

• in the future, it is possible to use SBC for integration with local telecom operators;
• a failure at one site should not affect the work of the rest in any way;
• Site administrators must fully manage their SBCs without affecting other sites.

The scheme was agreed upon, and we started to deploy the stand and test it.

Testing

When testing, we needed:

• find a working configuration of equipment for building a SIP trunk with each type and version of the customer’s IP-PBX firmware;
• check the operation of the required call scenarios with each type and version of the IP-PBX firmware;
• describe the required changes.

A test infrastructure was deployed with Skype for Business, several IP-PBXs of the required versions and user stations. We started configuring. Direct calls between SfB clients and each IP-PBX worked without problems after setting up call routing. We found some subtle points when testing the forking of a call (when, when a user calls a landline phone, a call comes to both the phone and the SfB client). For a better understanding of call fork, I will give an example. We have user # 1 with phone number 201 and user # 2, who has phone number 202. There is a Skype For Business account with number 5202. User # 1 decided to call user # 2 and dialed 202 on the phone. the call should go as follows.

1. The IP-PBX looks for a subscriber with number 202 and finds him. In the settings of this subscriber, there is a simultaneous call to the number 5202.
2. The call goes to telephone 202 and the call is routed to the SIP trunk with the SBC.
3. SBC routes the call to SfB.
4. SfB locates user number 5202 and routes the call to that user’s SfB client.

As a result, user # 2 has both his phone and SfB ringing, and he himself decides where it is more convenient for him to answer the call.

Forked call pattern:

Underwater rocks

There are four possible scenarios for handling an incoming call:

1. the user picks up the phone on the phone;
2. the user replies to SfB;
3. the user never picks up the phone and the call is dropped by timeout;
4. the caller hangs up before the call is answered or the call is timed out.

And here pitfalls appear. During testing, it was found that the behavior of the system almost always does not meet expectations. I would like to dwell on each scenario in more detail, describe the problems and propose solutions.

User picks up the phone on the phone

Problem: In SfB, a call can be marked as missed in the call log. Why is this happening? The fact is that when forking, an IP-PBX sends a call to two numbers at once: to the subscriber of the IP-PBX and to the SIP trunk. And when the call is removed on the subscriber’s phone, the IP-PBX sends a SIP-request “CANCEL” towards SfB, as if saying that there is no need to call anymore.

The IP-PBX may not include in the CANCEL request the information that the handset is off-hook elsewhere. In this case, SfB thinks that this is a call that the caller dropped himself and marks it as missed, but this is not true. After a detailed analysis of the call logs and studying the documentation, an RFC was found, which describes the Reason header for CANCEL requests. It is in this heading that the information that the call was received elsewhere should be contained.

RFC link: https://tools.ietf.org/html/rfc3326

Most of the customer’s IP PBX did not support RFC 3326.

Decision: It turned out that most often the latest versions of IP-PBX firmware include support for RFC 3326. After updating to the latest version, the problem disappeared.

For the same IP-PBXs that do not support RFC 3326, a workaround was found: SBC Audiocodes allows you to modify the sent SIP packets. In this scenario, we need to add a header to the CANCEL requests with information that the call was received elsewhere. In our case, for this it was necessary to create a new Message Manipulations in Audiocodes, which adds a Reason header with the value 'SIP;cause=200;text="Call completed elswhere";ms-acceptedby="sip:OnPBX@domain.local"' and bind this rule to the corresponding IP Group.

User replies to SfB

In this scenario, there was no problem displaying the call as missed.

The user never picks up the phone – the call is dropped by timeout

Problem: After the call is dropped by timeout, the SfB client can continue to call, although the caller’s session from the IP-PBX has already been terminated.

This happens because when the timeout is triggered on some IP-PBXs, they do not send any information towards SfB, and SfB does not know that the session has already ended.

Decision: Change the settings so that the SfB timeout time is less than the timeout time on the IP-PBX. In case the call ends by timeout from the SfB side, the call ends on the phone. Missed call information is displayed correctly everywhere.

The caller hangs up before the call is answered or the call is timed out.

Problem: If the caller hangs up before answering, and if the call is received on an IP-PBX phone without RFC 3326 support, then absolutely identical SIP-requests “CANCEL” are sent to the SfB side. SBC processes these requests according to the rule that was created earlier, and the call does not appear on SfB as a missed call.

Decision: Using IP-PBX with RFC 3326 support.

In our project, the customer decided to temporarily use the addition of the Reason header and further abandon the use of IP-PBX without RFC 3326.

Eventually

Detailed preliminary testing of the solution with all types of IP-PBX made it possible to learn in advance about most of the subtle points. The implementation took place relatively quickly – one or two days per site.

Although the article described one case for integrating Skype For Business with telephony, the principles and solutions are suitable for any such integrations. For example, we have successfully applied similar solutions in telephony integration projects with Microsoft Teams. I hope the solutions described in this article will help you save time during implementation.