Match the presented phone number to a user SIP URI within the tenant found on the previous step.Īpply trunk settings. Using the phone number presented in the Request-URI, perform the reverse number lookup within the tenant found in Step 2 or 3. If found, the user lookup is performed in this tenant. Remove the host portion from the FQDN, presented in the Contact header (FQDN:, after removing the host portion: ), and check if this name is registered as a DNS name in any Microsoft 365 or Office 365 organization. If found, the lookup of the user is performed in the tenant that has the SBC FQDN registered as a Domain name.
#Configure sip client express talk full
Try to find a tenant using the full FQDN name presented in the Contact header.Ĭheck if the FQDN name from the Contact header () is registered as a DNS name in any Microsoft 365 or Office 365 organization. The domain portion of the FQDN name presented in the Contact header (for example of the FQDN name ) must match the wildcard value in Common Name/Subject Alternative Name (for example *.).
The full FQDN name presented in the Contact header must match the Common Name/Subject Alternative name of the presented certificate.
The SBC name must match one of the following options: On the initial connection, the Direct Routing service takes the FQDN name presented in the Contact header and matches it to the Common Name or Subject Alternative name of the presented certificate. On receiving the invite, the SIP proxy performs the following steps:Ĭheck the certificate. The following is an example of the SIP Invite message on an incoming call: Parameter name This section describes how the SIP proxy finds the tenant and the user, and performs authentication of the SBC on the incoming connection. Therefore, it is important to find the specific tenant on which to perform the number lookup because the non-DID numbers might be the same in multiple Microsoft 365 or Office 365 organizations. The tenant administrator might configure non-DID numbers, for example +1001, in multiple tenants. On an incoming call, the SIP proxy needs to find the tenant to which the call is destined and find the specific user within this tenant. Direct Routing will reject SIP requests that have Replaces headers defined. Please note, that SIPS URI should not be used with Direct Routing as it is not supported.Ĭheck your Session Border Controller configuration and make sure that you are not using "Replaces" headers in SIP requests. If the sign is present in a SIP URI, the user field MUST NOT be empty. As per RFC 3261, section 19.1.1, the userinfo part of a URI is optional and MAY be absent when the destination host does not have a notion of users or when the hosst itself is the resource being identified. The SIP headers do not contain userinfo in the SIP URI in use. The SIP headers in an OPTIONS messages to SIP Proxy are provided as an example below: Parameter name It is important for OPTIONS negotiation to be successful (200OK response), allowing for further communication between SBC and SIP Proxy for establishing calls. These OPTIONS messages allow SIP Proxy to provide the allowed capabilities to SBC. Processing the incoming request: finding the tenant and userīefore an incoming or outbound call can be processed, OPTIONS messages are exchanged between SIP Proxy and the SBC. This article is intended for voice administrators who are responsible for configuring the connection between the on-premises SBC and the SIP proxy service. To properly route traffic between a Session Border Controller (SBC) and the SIP proxy, some SIP parameters must have specific values. This article describes how Direct Routing implements the Session Initiation Protocol (SIP).
0 kommentar(er)
