Issues that affect outbound direct routing calls
You might experience various issues when you use direct routing to make outbound calls from an app built on Azure Communication Services (ACS) Software Development Kit (SDK) to a Session Border Controller (SBC). These issues include:
- An incorrect or anonymous caller ID is displayed to the call recipient.
- A connection to the SBC isn't established.
- Some users are unable to make calls.
- No users in a tenant are able to make calls.
This article discusses potential causes of these issues, and provides resolutions that you can try.
Incorrect caller ID displayed to the recipient
When you use direct routing, the caller ID information that is delivered to the call recipient is listed in the
P-Asserted-Identity headers in the Session Initiation Protocol (SIP) options message.
From header contains any of the following items:
- The phone number that's used as an
alternateCallerIdproperty of a
startCallmethod in Client Calling SDK. If an
alternateCallerIdwasn't provided, it's replaced with "anonymous".
- The phone number string that's passed when creating a
PhoneNumberIdentifierobject in Call Automation SDK
- The phone number of the original caller if an Call Automation SDK redirects the call.
- The phone number selected as a Caller ID in Omnichannel Agent client application.
P-Asserted-Identity header contains the phone number of the user who is billed for the call. The
Privacy:id indicates that the information in the header has to be hidden from the call recipient.
If the information in the
P-Asserted-Identity headers doesn't match, and if the Public Switched Telephone Network (PSTN) prioritizes the
P-Asserted-Identity header information over the
From header information, then incorrect information is displayed.
To make sure that the correct caller ID is displayed to the call recipient, configure the SBC to either remove the
P-Asserted-Identity header from the SIP INVITE message or modify its contents.
Connection to the SBC not established
Sometimes, calls reach the SBC but no connection is established. In this situation, when the SBC receives a SIP OPTIONS message from Microsoft, it returns a failure message that includes error codes in the range of 400 to 699.
Any of the following causes might prevent a connection to the SBC.
The SIP failure message is coming from another telephony device that is on the same network as the SBC.
Troubleshoot the other device to fix the error. If you need assistance, contact the device vendor.
Your PSTN provider is experiencing some issue and is sending the SIP failure message. This is most likely the case if the failure error code is SIP 403 or SIP 404.
Contact your PSTN provider for support to fix the issue.
The issue isn't coming from another device on the network or by your PSTN provider. However, the cause is otherwise unknown.
Contact the SBC vendor support to fix the issue.
Some users are unable to make calls
If the connection between the Microsoft and the SBC is working correctly, but some users or applications can't make calls, the issue might be an incorrect scope of an Azure Communication Services access token
Azure Communication Services access token was created with a chat scope.
Make sure that all the Azure Communication Services access tokens that are used for making calls are generated with a
None of the patterns in the Voice Routes match the dialed number.
Make sure that the following conditions are true:
- There's a pattern in the Voice Route that matches the dialed number.
- The SBC that's specified for the Voice Route is Online. If it's Inactive, either set it up to become Online or select a different SBC that is Online
The SBC isn't responding to SIP OPTIONS messages because some device on the network, such as a firewall, is blocking the messages.
Make sure that the SIP Signaling IPs and FQDNs are allowed on all network devices that connect the SBC to the internet. The IP addresses that must be allowed are listed at SIP Signaling: FQDNs.