Connectivité pour Azure Communications Gateway
Chaque région Azure de votre déploiement se connecte à votre réseau principal. Vous devez choisir le type de connexion (par exemple, Microsoft Azure Peering Service Voice). Vous devez utiliser des adresses IP et des noms de domaine spécifiques pour acheminer le trafic entre votre réseau et Azure Communications Gateway.
Cet article aborde les points suivants :
- Les types de connexion que vous pouvez utiliser.
- Les adresses IP et les noms de domaine que vous devez connaître.
- Vos options de choix des noms de domaine pour Azure Communications Gateway.
Connexion à votre réseau
Azure Communications Gateway prend en charge plusieurs types de connexion à votre réseau.
- Nous vous recommandons vivement d’utiliser Microsoft Azure Peering Service Voice (également appelé MAPS Voice ou MAPSV).
- Si vous ne pouvez pas utiliser MAPS Voice, nous vous recommandons ExpressRoute Microsoft Peering.
La passerelle de communication Azure est normalement déployée avec des adresses IP publiques sur toutes les interfaces. Cela signifie que vous pouvez utiliser des méthodes de connectivité prenant en charge les adresses IP publiques pour connecter votre réseau à Azure Communications Gateway, comme MAPS Voice, ExpressRoute Microsoft Peering et l’Internet public. Si vous voulez contrôler et gérer le trafic entre votre réseau et Azure Communications Gateway, vous pouvez utiliser l’injection de réseau virtuel pour Azure Communications Gateway (préversion) pour déployer les interfaces qui se connectent à votre réseau dans votre propre sous-réseau.
Le tableau suivant répertorie tous les types de connexion disponibles et indique s'ils sont pris en charge pour chaque service de communication. Les types de connexion sont dans l’ordre que nous recommandons (les types recommandés en premier).
| Type de connexion | Operator Connect / Teams Téléphone Mobile | Routage direct Microsoft Teams | Zoom Phone Cloud Peering | Notes |
|---|---|---|---|---|
| Voice MAPS | ✅ | ✅ | ✅ | – Meilleure qualité multimédia grâce à la priorisation avec le réseau Microsoft – Pas de frais supplémentaires – Voir Peering Internet pour la procédure pas à pas Peering Service Voice |
| Peering Microsoft ExpressRoute | ✅ | ✅ | ✅ | – Facile à déployer – Coût supplémentaire – Consultez votre équipe d'intégration et assurez-vous qu'elle est disponible dans votre région – Voir Utilisation d'ExpressRoute pour les services Microsoft PSTN |
| Injection de réseau virtuel (préversion) | ️⚠Peering privé ExpressRoute doit être utilisé pour les déploiements de production | ✅ | ✅ | - Contrôler la connectivité à votre réseau à partir de votre propre réseau virtuel - Active l’utilisation du peering privé ExpressRoute et des passerelles VPN Azure - Étapes de déploiement supplémentaires -Coût supplémentaire |
| Internet public | ⚠️ Déploiements en laboratoire uniquement | ✅ | ✅ | – Aucune configuration supplémentaire – Lorsque disponible, non recommandé pour la production |
Remarque
Les programmes Opérateur Connect et Teams Phone Mobile n’autorisent pas les déploiements de production à utiliser l’Internet public, y compris les VPN sur l’Internet public.
Configurez votre réseau comme dans le schéma suivant et configurez-le conformément aux spécifications de connectivité réseau pour les services de communication que vous avez choisis. Pour les déploiements de production, votre réseau doit disposer de deux sites dotés d'une fonctionnalité de connexion croisée. Pour plus d'informations sur la conception de la fiabilité pour Azure Communications Gateway, consultez Fiabilité dans Azure Communications Gateway.
Les déploiements de laboratoire ont une région de service Azure et doivent se connecter à un site de votre réseau.
Adresses IP et noms de domaine
Les déploiements Azure Communications Gateway nécessitent plusieurs adresses IP et noms de domaine complets (Fully Qualified Domain Names/FQDN). Le diagramme et le tableau suivants décrivent les adresses IP et les noms de domaine complets que vous pourriez avoir besoin de connaître.
| Adresse IP ou plage sur le schéma | Description | Notes |
|---|---|---|
| 1 | Plage d'adresses IP dans le site de l'opérateur A pour l'envoi du trafic de signalisation à Azure Communications Gateway | Spécifiez ces informations lorsque vous déployez votre ressource. |
| 2 | Plage d’adresses IP ou FQDN dans le site A pour recevoir le trafic de signalisation depuis Azure Communications Gateway | Spécifiez ces informations lorsque vous déployez votre ressource. |
| 3 | Adresses IP ou plages d'adresses dans le site opérateur A pour l'envoi et la réception du trafic multimédia | Spécifiez ces informations lorsque vous déployez votre ressource. |
| 4 | Plage d'adresses IP dans le site de l'opérateur B pour l'envoi du trafic de signalisation à Azure Communications Gateway | Spécifiez ces informations lorsque vous déployez votre ressource. |
| 5 | Plage d’adresses IP ou FQDN dans le site opérateur A pour recevoir le trafic de signalisation depuis Azure Communications Gateway | Spécifiez ces informations lorsque vous déployez votre ressource. |
| 6 | Adresses IP ou plages d'adresses dans le site de l'opérateur B pour l'envoi et la réception du trafic multimédia | Spécifiez ces informations lorsque vous déployez votre ressource. |
| 7 | FQDN Azure Communications Gateway région 1 pour la réception du trafic de signalisation depuis le réseau opérateur | Obtenez le FQDN à partir du champ Nom d'hôte pour la région 1 dans le Portail Microsoft Azure. Configurez votre réseau pour acheminer les appels vers ce FQDN. |
| 8 | Adresses IP ou plages d'adresses IP Azure Communications Gateway région 1 pour l’envoi du trafic de signalisation vers votre réseau | Demandez les valeurs à votre équipe d’intégration. Configurez-les dans les listes de contrôle d'accès (ACL) de votre réseau. |
| 9 | Adresses IP ou plages d’adresses IP Azure Communications Gateway région 1 pour le trafic multimédia entre le réseau opérateur et Azure Communications Gateway | Demandez les valeurs à votre équipe d’intégration. Configurez-les dans les listes de contrôle d'accès (ACL) de votre réseau. |
| 10 | FQDN Azure Communications Gateway région 2 pour la réception du trafic de signalisation depuis le réseau opérateur | Obtenez le nom de domaine complet à partir du champ Nom d'hôte pour la région 2 dans le Portail Microsoft Azure. Configurez votre réseau pour acheminer les appels vers ce FQDN. |
| 11 | Adresses IP ou plages d'adresses IP Azure Communications Gateway région 2 pour l’envoi du trafic de signalisation vers votre réseau | Demandez les valeurs à votre équipe d’intégration. Configurez-les dans les listes de contrôle d'accès (ACL) de votre réseau. |
| 12 | Adresses IP ou plages d’adresses IP Azure Communications Gateway région 2 pour le trafic multimédia entre le réseau opérateur et Azure Communications Gateway | Demandez les valeurs à votre équipe d’intégration. Configurez-les dans les listes de contrôle d'accès (ACL) de votre réseau. |
| 13 | Domaine de base Azure Communications Gateway fournissant l’API d’approvisionnement | Obtenez le FQDN à partir du champ Présentation du Portail Microsoft Azure. |
| 14 | Adresses IP ou plages d'adresses IP Azure Communications Gateway région 1 pour l'envoi du trafic de signalisation vers les services de communication | – Pour Zoom Phone Cloud Peering, demandez ces informations à votre équipe d’intégration et fournissez-les à Zoom. – Microsoft gère ces informations pour d'autres services de communication. |
| 15 | FQDN ou adresses IP Azure Communications Gateway région 1 pour la réception du trafic de signalisation provenant des services de communication | – Pour Zoom Phone Cloud Peering, demandez ces informations à votre équipe d’intégration et fournissez-les à Zoom. – Microsoft gère ces informations pour d'autres services de communication. |
| 16 | Adresses IP ou plages d’adresses IP Azure Communications Gateway région 1 pour le trafic multimédia entre les services de communication et Azure Communications Gateway | – Pour Zoom Phone Cloud Peering, demandez ces informations à votre équipe d’intégration et fournissez-les à Zoom. – Microsoft gère ces informations pour d'autres services de communication. |
| 17 | Adresses IP ou plages d'adresses IP Azure Communications Gateway région 2 pour l'envoi du trafic de signalisation vers les services de communication | – Pour Zoom Phone Cloud Peering, demandez ces informations à votre équipe d’intégration et fournissez-les à Zoom. – Microsoft gère ces informations pour d'autres services de communication. |
| 18 | FQDN ou adresses IP Azure Communications Gateway région 2 pour la réception du trafic de signalisation provenant des services de communication | – Pour Zoom Phone Cloud Peering, demandez ces informations à votre équipe d’intégration et fournissez-les à Zoom. – Microsoft gère ces informations pour d'autres services de communication. |
| 19 | Adresses IP ou plages d’adresses IP Azure Communications Gateway région 2 pour le trafic multimédia entre les services de communication et Azure Communications Gateway | – Pour Zoom Phone Cloud Peering, demandez ces informations à votre équipe d’intégration et fournissez-les à Zoom. – Microsoft gère ces informations pour d'autres services de communication. |
| 20 | Adresses IP ou FQDN utilisés par les services de communication pour recevoir le trafic de signalisation | Vous n'avez pas besoin de gérer ces informations. |
| 21 | Adresses IP ou FQDN utilisés par les services de communication pour envoyer du trafic de signalisation | Vous n'avez pas besoin de gérer ces informations. |
| 22 | Adresses IP utilisées par les services de communication pour envoyer et recevoir du trafic multimédia | Vous n'avez pas besoin de gérer ces informations. |
Conseil
Ce diagramme montre trois ensembles d'adresses IP pour le service de communication par souci de simplicité. Les détails peuvent varier pour chaque service de communication, mais vous n’aurez pas besoin de gérer les détails car nous gérons la connexion d’Azure Communications Gateway aux services de communication.
Chaque site de votre réseau doit envoyer le trafic vers sa région de service Azure Communications Gateway locale par défaut et basculer vers l'autre région si la région locale n'est pas disponible. Par exemple, le site A doit acheminer le trafic vers la région 1 et, s'il détecte que la région 1 n'est pas disponible, rediriger le trafic vers la région 2. Pour plus d'informations sur les exigences de routage des appels, voir Exigences de routage des appels.
Noms de domaine générés automatiquement
Azure Communications Gateway fournit plusieurs noms de domaine complets :
- Un domaine de base
<deployment-id>.commsgw.azure.compour votre déploiement, où<deployment-id>est généré automatiquement et unique au déploiement. Ce domaine fournit l'API Provisioning. Il s'agit du point 13 dans les adresses IP et les noms de domaine. - Noms de domaine par région qui correspondent aux adresses IP de signalisation vers lesquelles votre réseau doit acheminer le trafic de signalisation. Ces noms de domaine sont des sous-domaines du domaine de base. Il s'agit des éléments 7 et 10 des adresses IP et des noms de domaine.
Plages de ports utilisées par Azure Communications Gateway
Azure Communications Gateway utilise les plages de ports local suivantes. Ces plages doivent être accessibles depuis votre réseau, en fonction du type de connectivité choisi.
| Plage de ports | Protocol | Transport |
|---|---|---|
| 16384-23983 | RTP/RTCP SRTP/SRTCP |
UDP |
| 5060 | SIP | UDP/TCP |
| 5061 | SIP sur TLS | TCP |
Toutes les adresses IP de la passerelle de communication Azure peuvent être utilisées pour la signalisation (SIP) et le média (RTP/RTCP). Lors de la connexion à plusieurs réseaux, des ports locaux SIP supplémentaires sont utilisés. Pour plus d’informations, consultez votre ressource Azure Communications Gateway dans le portail Azure.
Injection de réseau virtuel pour Azure Communications Gateway (préversion)
L’injection de réseau virtuel pour Azure Communications Gateway (préversion) permet aux interfaces réseau de votre passerelle de communication Azure qui se connectent à votre réseau d’être déployées dans des réseaux virtuels dans votre abonnement. Cela vous permet de contrôler le trafic transitant entre votre réseau et votre instance Azure Communications Gateway à l’aide de sous-réseaux privés, et vous permet d’utiliser la connectivité privée à vos locaux tels que le Peering privé ExpressRoute et les VPN.
Si vous utilisez l’injection de réseau virtuel (préversion) avec Operator Connect ou Teams Phone Mobile, votre réseau doit toujours répondre aux exigences de redondance et de résilience décrites dans la spécification de connectivité réseau fournie par votre équipe d’intégration. Cela impose que votre réseau soit connecté à Azure par au moins 2 circuits ExpressRoute, chacun déployé avec redondance locale et configuré afin que chaque région puisse utiliser les deux circuits en cas de défaillance, comme décrit dans le diagramme suivant.
Avertissement
Tout trafic de votre propre réseau virtuel est soumis à des frais de bande passante et de réseau virtuel Azure standard.
Contenu connexe
- Découvrez comment acheminer les appels vers Azure Communications Gateway.
- En savoir plus sur la planification d’un déploiement Azure Communications Gateway