Use direct routing to connect to existing telephony service
Azure Communication Services direct routing enables you to connect your existing telephony infrastructure to Azure. The article lists the high-level steps required for connecting a supported Session Border Controller (SBC) to direct routing and how voice routing works for the enabled Communication resource.
For information about whether Azure Communication Services direct routing is the right solution for your organization, see Azure telephony concepts. For information about prerequisites and planning your deployment, see Communication Services direct routing infrastructure requirements.
Connect the SBC with Azure Communication Services
Validate domain ownership
Follow these instructions to validate a domain ownership of your SBC
Configure outbound voice routing
Refer to Voice routing quickstart to add an SBC and configure outbound voice routing rules.
Session Border Controller connection status
The health of an SBC connection now exposed in Azure portal. It takes in account Transport Layer Security (TLS) status and SIP OPTIONS.
Possible values of each health indicator
TLS Status - Status of the TLS connections of a Trunk:
- Unknown - Indicates that SBC hasn't attempted a TLS handshake in the last 15 minutes.
- Active - Indicates that TLS connection is established.
- CertExpiring - Indicates that SBC certificate is expiring.
- CertExpired - Indicates that SBC certificate is expired.
SIP OPTIONS (Ping) - Status of SIP OPTIONS messages exchange:
- Unknown - Indicates that SBC hasn't sent any SIP options.
- Active - Indicates that OPTIONS are being sent and received.
- Expired - Indicates that SBC was sending SIP OPTIONS, but we haven't received any OPTIONS messages in the last 15 minutes.
- Error - Indicates an error in OPTIONS exchange.
Status - The overall health status of a Trunk:
- Unknown - Indicates an unknown health status.
- Online - Indicates that SBC connection is healthy.
- Warning - Indicates TLS or Ping is expired.
Note
If you've just configured a new trunk, it can take up to 15 minutes to update the status.
Important
Before placing or receiving calls, make sure that SBC status is Online
Outbound voice routing considerations
Azure Communication Services direct routing has a routing mechanism that allows a call to be sent to a specific SBC based on the called number pattern.
When you add a direct routing configuration to a resource, all calls made from this resource’s instances (identities) try a direct routing trunk first. The routing is based on a dialed number and a match in voice routes configured for the resource.
- If there's a match, the call goes through the direct routing trunk.
- If there's no match, the next step is to process the
alternateCallerId
parameter of thecallAgent.startCall
method. - If the resource is enabled for Voice Calling (PSTN) and has at least one number purchased from Microsoft, the
alternateCallerId
is checked. - If the
alternateCallerId
matches a purchased number for the resource, the call is routed through the Voice Calling (PSTN) using Microsoft infrastructure. - If
alternateCallerId
parameter doesn't match any of the purchased numbers, the call fails.
The diagram demonstrates the Azure Communication Services voice routing logic.
Voice routing examples
The following examples display voice routing in a call flow.
Note
In all examples, while the higher voice route has higher priority, the SBCs in a route are tried in random order.
One route example:
If you created one voice route with a pattern ^\+1(425|206)(\d{7})$
and added sbc1.contoso.biz
and sbc2.contoso.biz
to it, then when the user makes a call to +1 425 XXX XX XX
or +1 206 XXX XX XX
, the call is first routed to SBC sbc1.contoso.biz
or sbc2.contoso.biz
. If neither SBC is available, the call is dropped.
Two routes example:
If you created one voice route with a pattern ^\+1(425|206)(\d{7})$
and added sbc1.contoso.biz
and sbc2.contoso.biz
to it, and then created a second route with the same pattern with sbc3.contoso.biz
and sbc4.contoso.biz
. In this case, when the user makes a call to +1 425 XXX XX XX
or +1 206 XXX XX XX
, the call is first routed to SBC sbc1.contoso.biz
or sbc2.contoso.biz
. If both sbc1 and sbc2 are unavailable, the route with lower priority is tried (sbc3.contoso.biz
and sbc4.contoso.biz
). If none of the SBCs of the second route are available, the call is dropped.
Three routes example:
If you created one voice route with a pattern ^\+1(425|206)(\d{7})$
and added sbc1.contoso.biz
and sbc2.contoso.biz
to it, and then created a second route with the same pattern with sbc3.contoso.biz
and sbc4.contoso.biz
, and created a third route with ^\+1(\d{10})$
with sbc5.contoso.biz
. In this case, when the user makes a call to +1 425 XXX XX XX
or +1 206 XXX XX XX
, the call is first routed to SBC sbc1.contoso.biz
or sbc2.contoso.biz
. If both sbc1 nor sbc2 are unavailable, the route with lower priority is tried (sbc3.contoso.biz
and sbc4.contoso.biz
). If none of the SBCs of a second route are available, the third route is tried. If sbc5 is also not available, the call is dropped. Also, if a user dials +1 321 XXX XX XX
, the call goes to sbc5.contoso.biz
, and it isn't available, the call is dropped.
Note
Failover to the next SBC in voice routing works only for response codes 408, 503, and 504.
Note
In all the examples, if the dialed number does not match the pattern, the call will be dropped unless there is a purchased number exist for the communication resource, and this number was used as alternateCallerId
in the application.
Managing inbound calls
For general inbound call management use Call Automation SDKs to build an application that listens for and manage inbound calls placed to a phone number or received via Azure Communication Services direct routing. Omnichannel for Customer Service customers, refer to these instructions.
Next steps
Conceptual documentation
- Session Border Controllers certified for Azure Communication Services direct routing
- Call Automation overview
- Pricing
- Try Phone Calling