Expliquer le routage d’appels Cisco IOS et IOS XE

Introduction

Ce document présente une explication du routage d’appels de Cisco IOS® et de Cisco IOS XE.

Conditions préalables

Exigences

Bien qu'il n'y ait aucune condition formelle requise pour lire ce document, il est écrit avec l'espoir que le lecteur a déjà une certaine connaissance des protocoles de signalisation vocale sous-jacents qui sont utilisés pour établir et connecter des appels téléphoniques. Ces protocoles sont référencés plusieurs fois tout au long du processus.

Protocoles de signalisation : SIP (Session Initiation Protocol), H323 (h225 / h245), MGCP (Media Gateway Control Protocol), SCCP (Skinny Client Control Protocol), RNIS Q931, E1 R2.

Protocoles multimédias : RTP (Real Time Protocol), codecs vocaux, codecs vidéo.

Technologies analogiques : Ear and Mouth (E&M), Foreign Exchange Subscriber (FXS) et Foreign Exchange Office (FXO).

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Passerelles Cisco IOS et IOS XE
• 2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / CAT8000v / ASR100X / C8200 / C8300 / ISR1100

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Ce document traite des mécanismes qui sous-tendent la correspondance dial-peer entrante et sortante avec les tronçons d'appel des réseaux POTS (Plain Old Telephone Service) et VoIP (Voice over IP).

En plus des informations sur les terminaux de numérotation dial-peer, ce document couvre des sujets importants relatifs au routage des appels. Il s’agit notamment de la manipulation des chiffres, d’une présentation rapide de la manipulation des messages SIP (Session Initiation Protocol), de quelques méthodes de restriction des capacités d’appel, d’une présentation rapide des liaisons de signalisation et de support, et enfin d’un peu de dépannage.

Ce document utilise des exemples de configuration ainsi que des sorties de commande debug et show comme points de référence. Les nombreuses fonctionnalités de ce document sont clairement identifiées par la version de la fonctionnalité introduite dans Cisco IOS et Cisco IOS XE. Ces informations peuvent également être référencées rapidement dans la section Command and Feature Roadmap. S'il y a un défaut très notable, il est lié à l'intérieur du texte afin que les lecteurs soient conscients.

Définitions communes

Feuille de route des commandes et des fonctionnalités

Notions de base sur le routage des appels Cisco IOS/Cisco IOS XE

Les passerelles Cisco IOS et Cisco IOS XE utilisent un concept de terminal de numérotation dial-peer pour contrôler le routage des appels et la négociation des fonctionnalités pour chaque segment d'un appel. Une branche d'appel est la communication bidirectionnelle entre deux agents d'appel. Un agent d'appel est un périphérique qui initie, traite ou transfère des appels téléphoniques. Ceci peut être et n'est pas limité à l'équipement du fournisseur de téléphonie, à une passerelle Cisco, à un téléphone IP, à un Cisco Unified Communication Manager (CUCM), à une connexion Cisco Unity (CUC), etc. Il y a beaucoup trop d'agents d'appel à lister.

Scénario : un appel arrive sur une passerelle Cisco en provenance d'un autre agent d'appel et constitue le tronçon d'appel entrant (dans le tronçon). La passerelle traite l'appel et, en fonction de son traitement, envoie l'appel à l'agent d'appel suivant. Il s'agit de la branche d'appel sortant (out-leg).

L'image 1 montre un appel du RTPC vers le routage CUCM via une passerelle vocale Cisco et les informations de tronçon d'appel entrant et sortant respectives.

Image 1 : illustration des segments d'appel entrant et sortant

Un appel réussi via une passerelle Cisco TOUJOURS (voir remarque) correspond à un terminal de numérotation dial-peer entrant ou sortant pour être routé correctement. Les terminaux de numérotation dial-peer entrants et sortants sont similaires aux tronçons d'appel mentionnés précédemment. Dans l'image 1, l'appel arrive du RTPC au niveau de la passerelle Cisco et doit correspondre à un terminal de numérotation dial-peer entrant. La passerelle utilise ensuite un terminal de numérotation dial-peer sortant pour acheminer l'appel vers l'agent d'appel suivant. Il est important de se rappeler que ces termes sont définis du point de vue de la passerelle Cisco.

En faisant correspondre un terminal de numérotation dial-peer pour chaque côté de l'appel, un administrateur a le pouvoir de contrôler de nombreux aspects de chaque branche d'appel spécifique. Les codecs vocaux, les préférences DTMF, la manipulation des chiffres, l'emplacement de routage de l'appel et de nombreux autres paramètres sont des exemples de ces paramètres. Les terminaux de numérotation dial-peer peuvent être configurés avec des instructions de correspondance entrantes et sortantes, de sorte qu'il est possible de faire correspondre le même terminal de numérotation dial-peer pour le tronçon entrant et le tronçon sortant si une configuration de correspondance entrante et sortante valide est appliquée à ce terminal de numérotation dial-peer spécifique.

L'image 2 illustre les mêmes segments d'appel entrant et sortant que l'image 1, mais avec les terminaux de numérotation dial-peer respectifs pour un appel du RTPC vers le routage CUCM via une passerelle vocale Cisco.

Image 2 - Homologues de numérotation entrants et sortants illustrés

Les passerelles vocales Cisco peuvent interagir avec de nombreux types d'appels et de protocoles vocaux, notamment IP à IP, POTS à POTS et IP à POTS ou vice versa.

L'image 3 illustre un appel VoIP à VoIP via Cisco Unified Border Element (CUBE).

Image 3 : terminaux de numérotation dial-peer entrants et sortants pour un appel Voip vers VoIP

L'image 4 affiche un appel POTS à POTS via une passerelle Cisco.

Image 4 - Homologues de numérotation entrants et sortants pour un appel POTS à POTS

Types d'homologues de numérotation vocale

Remarque : le nombre maximal d'homologues de numérotation pouvant être configurés sur une passerelle Cisco dépend de la mémoire disponible (DRAM). Chaque terminal de numérotation dial-peer consomme environ 6 Ko de mémoire. Assurez-vous donc que la passerelle dispose d'au moins 20 % de la mémoire totale réservée aux autres processus du processeur. Un grand nombre de terminaux de numérotation dial-peer configurés peuvent augmenter le délai d'acheminement d'un appel. Cela peut être important, car l'application vocale Cisco examine les terminaux de numérotation dial-peer de haut en bas, comme une liste de contrôle d'accès (ACL). Ce n'est généralement pas un problème sur les passerelles Cisco plus récentes.

Exemple d'erreur :

May 26 12:59:46.406: %DIALPEER_DB-3-ADDPEER_MEM_THRESHOLD: Addition of dial-peers limited by available memory

Correspondance Dial-Peer entrant

Lorsqu'une passerelle Cisco reçoit une demande d'établissement d'appel, elle commence à rechercher un terminal de numérotation dial-peer entrant applicable pour cet appel. Il ne s'agit pas d'une analyse chiffre par chiffre ; le message complet est plutôt utilisé pour déterminer quel terminal de numérotation dial-peer entrant est sélectionné. L'ordre des éléments du message vérifié dépend largement du protocole de l'appel, comme indiqué par les listes de préférences définies dans les tableaux 1, 2 et 3. Un terminal de numérotation dial-peer doit uniquement satisfaire à l'une des conditions de mise en correspondance. Il n'est pas nécessaire que tous les attributs soient configurés dans le terminal de numérotation dial-peer ou que chaque attribut corresponde aux informations de configuration d'appel. Tous les terminaux de numérotation dial-peer sont recherchés en fonction du premier critère de correspondance. La passerelle passe aux critères suivants uniquement si aucune correspondance n'est trouvée.

Tableau 1 . Préférence de sélection de terminal de numérotation dial-peer SIP entrant

Remarque : les terminaux de numérotation dial-peer entrants éligibles peuvent être filtrés par VRF ou par locataire. Si la fonctionnalité applicable est configurée. Pour plus d'informations, consultez les sections Routage et transfert virtuels (VRF), Recherche de postes de numérotation et Locataires de classe vocale.

Tableau 2 . Préférence de sélection de terminal de numérotation dial-peer H323 entrant

Tableau 3 . Préférence de sélection de terminal de numérotation dial-peer POTS Enblock entrant

En l'absence de correspondance / Poste de numérotation par défaut 0 peer_tag=0, pid:0

Lorsqu'il n'existe aucune correspondance admissible pour un terminal de numérotation dial-peer entrant pour les appels POTS ou VoIP, la passerelle attribue le terminal de numérotation dial-peer 0. Ce n'est pas idéal, car le terminal de numérotation dial-peer 0 a des capacités limitées et peut provoquer des problèmes avec les appels. Les protocoles SCCP et MGCP qui n'utilisent pas de terminaux de numérotation dial-peer pour le routage des appels constituent une exception. Consultez la section MGCP et SCCP pour plus de détails.

fonctionnalités de dial-peer 0

• Aucun mécanisme de relais dtmf.
• Annonce de tous les codecs vocaux pour les appels VoIP.
• Voix de télécopie-débit.
• La détection d'activité vocale (VAD) est activée.
• aucun support de rsvp.
• Aucune prise en charge des applications IVR pour les appels POTS.
• La numérotation directe entrante est activée.
• Ne prend pas en charge VRF.

Correspondance Dial-Peer sortant

Les terminaux de numérotation dial-peer sortants sont utilisés pour acheminer les appels POTS ou VoIP de la passerelle vers l'agent d'appel suivant. Tout comme la mise en correspondance des terminaux de numérotation dial-peer entrants, la passerelle peut utiliser une liste d'éléments pour mettre en correspondance les terminaux de numérotation dial-peer en fonction de l'ordre de préférence du protocole spécifique. Cependant, contrairement aux terminaux de numérotation dial-peer entrants, s'il n'existe aucun terminal de numérotation dial-peer sortant éligible pour acheminer l'appel, celui-ci échoue. Tout comme la mise en correspondance de terminaux de numérotation dial-peer entrants, tous les terminaux de numérotation dial-peer sont recherchés en fonction des premiers critères de correspondance. La passerelle passe aux critères suivants uniquement si aucune correspondance n'est trouvée.

Tableau 4 . Préférence de sélection de terminal de numérotation dial-peer SIP sortant

Tableau 5 . Préférence de sélection de terminal de numérotation dial-peer H323 sortant

Tableau 6 . Préférence de sélection de terminal de numérotation dial-peer POTS sortant

Remarque : la section Chaîne de numéro - Recherche d'homologue de numérotation et Recherche d'homologue de numérotation URI explique comment la passerelle évalue une liste de commandes potentielles pour chaque ligne de critère de correspondance avant de passer au critère de correspondance suivant. Par exemple, il évalue toutes les commandes destination-pattern et destination e164-pattern-map match potentielles avant d'examiner les commandes du numéro appelant.

Chaîne de numéro Recherche de terminal de numérotation dial-peer

Préférence de chaîne numérique :

Tout comme les URI ont un ordre spécifique d'opérations pour évaluer les correspondances, il y a aussi un ensemble de règles utilisées lors de l'évaluation d'une chaîne numérique. Le schéma de recherche de terminal de numérotation dial-peer par défaut pour une passerelle Cisco est défini sur 0. Cela signifie que la passerelle recherche un modèle avec la plus longue correspondance (la plus spécifique). Si deux terminaux de numérotation dial-peer ont la même longueur de correspondance, la passerelle examine la préférence de terminal de numérotation dial-peer explicitement définie. Enfin, si les deux sont identiques, elle en choisit un dans un ordre aléatoire.

D'autres schémas de recherche de terminal de numérotation dial-peer sont disponibles pour la configuration. Toutefois, la plupart des déploiements conservent la valeur par défaut 0.

Conseil : si les terminaux de numérotation dial-peer sont mis en correspondance en dehors de l'ordre par défaut, un administrateur peut examiner la configuration en cours pour rechercher un schéma de recherche de terminal de numérotation dial-peer autre que celui par défaut.

Gateway(config)# dial-peer hunt ?
  <0-7>  Dial-peer hunting choices, listed in hunting order within each choice:
  0 - Longest match in phone number, explicit preference, random selection.
  1 - Longest match in phone number, explicit preference, least recent use.
  2 - Explicit preference, longest match in phone number, random selection.
  3 - Explicit preference, longest match in phone number, least recent use.
  4 - Least recent use, longest match in phone number, explicit preference.
  5 - Least recent use, explicit preference, longest match in phone number.
  6 - Random selection.
  7 - Least recent use.

Scénario : des terminaux de numérotation dial-peer éligibles ont été configurés avec ces correspondances possibles, et la passerelle évalue une chaîne de chiffres de 2001. Le terminal de numérotation dial-peer 1 peut correspondre à n'importe quel numéro compris entre 2000 et 2999, tandis que le terminal de numérotation dial-peer 2 peut correspondre entre 2000 et 2009. Dial-Peer 2 serait mis en correspondance pour cet appel, car il s'agit de la plus longue correspondance (la plus spécifique) pour la chaîne de chiffres 2001 lorsque les mécanismes de recherche de terminal de numérotation dial-peer par défaut sont utilisés (dial-peer hunt 0). En d'autres termes, la séquence de nombres 200 est la plus grande séquence qui correspond exactement à une séquence de nombres dans la chaîne numérique 2001.

!
dial-peer voice 1 voip
 destination-pattern 2...
!
dial-peer voice 2 voip
 destination-pattern 200.
!

La préférence correspond au poids défini par l'administrateur pour chaque terminal de numérotation dial-peer. Les administrateurs peuvent configurer une préférence de sorte que l'appel utilise toujours un terminal de numérotation dial-peer spécifique avant les autres. Par défaut, tous les terminaux de numérotation dial-peer sont de préférence 0. Un terminal de numérotation dial-peer de préférence 0 est mis en correspondance avant un autre terminal de numérotation dial-peer de préférence 1 à 10. La plupart des administrateurs configurent plusieurs terminaux de numérotation dial-peer pour envoyer un appel à un abonné CUCM spécifique avec un abonné de secours ou un autre agent d'appel configuré à l'aide d'un autre terminal de numérotation dial-peer avec une préférence inférieure (qui est configuré avec un numéro supérieur).

Scénario : deux terminaux de numérotation dial-peer sont configurés avec la même longueur de correspondance pour la chaîne de chiffres 2001. L'administrateur définit une préférence explicite. La passerelle évalue les deux terminaux de numérotation dial-peer de la même manière, car leur longueur de correspondance est identique. Cependant, l'administrateur définit le terminal de numérotation dial-peer 1 avec une préférence plus élevée de sorte que le terminal de numérotation dial-peer soit choisi comme premier terminal de numérotation dial-peer utilisé pour le routage de l'appel. Dial-Peer 2 reste une option secondaire si un échec se produit sur le premier terminal de numérotation dial-peer.

!
dial-peer voice 1 voip
 destination-pattern 2...
 preference 1
!
dial-peer voice 2 voip
 destination-pattern 2...
 preference 2
!

Une passerelle Cisco tente uniquement d'acheminer un appel via un terminal de numérotation dial-peer sortant admissible à la fois. Si une condition d'échec est observée sur le premier terminal de numérotation dial-peer sélectionné, la passerelle tente d'acheminer l'appel vers le prochain terminal de numérotation dial-peer éligible. Cette opération se poursuit jusqu'à ce que l'appel réussisse ou échoue, car il ne reste plus aucun terminal de numérotation dial-peer éligible à essayer. Un symptôme fréquent de recherche et d'échec de terminal de numérotation dial-peer est un retard notable dans le retour d'appel lors de l'établissement des appels. Les débogages sont généralement nécessaires pour vérifier exactement pourquoi l'appel échoue sur un terminal de numérotation dial-peer donné. La commande huntstop peut être utilisée sur un terminal de numérotation dial-peer si un administrateur ne veut pas qu'une passerelle recherche un autre terminal de numérotation dial-peer lorsqu'une condition d'échec est observée.

Scénario : deux terminaux de numérotation dial-peer sont configurés avec la même longueur de correspondance pour la chaîne de chiffres 2001. L'administrateur a défini une préférence explicite et ne souhaite pas faire correspondre le terminal de numérotation dial-peer 2 pour cet appel particulier. Puisqu'il existe deux terminaux de numérotation dial-peer avec la même longueur de correspondance, la préférence est utilisée pour déterminer le terminal de numérotation dial-peer. Dial-Peer 1 a le numéro de préférence configuré le plus bas, il est donc utilisé pour acheminer l'appel. Si une condition d'échec se produit sur le tronçon d'appel sortant à l'aide de dial-peer 1, alors la passerelle arrête immédiatement la recherche de dial-peer puisque la commande huntstop est configurée. Dans ce scénario, le terminal de numérotation dial-peer 2 n'est jamais utilisé pour le routage sortant. 

!
dial-peer voice 1 voip
 destination-pattern 2...
 preference 1
 huntstop
!
dial-peer voice 2 voip
 destination-pattern 2...
 preference 2
!

Remarque : les commandes huntstop et preference peuvent également être utilisées conjointement avec des instructions de correspondance URI, car il s'agit de commandes de configuration dial-peer générales. En outre, les configurations voice class server-group peuvent utiliser les commandes huntstop dans 17.4.1a. Référez-vous à la section Groupes de serveurs de destination pour plus de détails à ce sujet.

Recherche d'homologue de numérotation URI

La passerelle examine chaque critère de correspondance et l'épuise avant de passer au critère de correspondance suivant. Par exemple, pour un appel SIP entrant. Selon le tableau 1. Inbound SIP Dial-Peer Selection Preference, la première chose que la passerelle Cisco vérifie est l'URI et évalue toutes les commandes URI potentielles pour trouver celle qui convient. S'il n'y a aucune correspondance ou si aucune correspondance n'est configurée, la passerelle passe à l'élément correspondant suivant et effectue une évaluation sur ce critère. Ce processus se répète jusqu'à ce que l'appel soit routé sur la base d'une correspondance ou que la passerelle soit à court de critères de correspondance à vérifier.

Lorsqu'un terminal de numérotation dial-peer entrant ou sortant est configuré avec une commande URI, la passerelle examine l'URI qui a été reçu dans plusieurs en-têtes pour rechercher une correspondance potentielle. La préférence de correspondance est basée sur la correspondance la plus spécifique et la préférence exacte correspond à la correspondance URI complète, à la partie hôte, à la partie utilisateur ou à l'URI du téléphone. La connaissance de l'ordre des opérations pour la correspondance URI peut grandement aider à la correspondance dial-peer avec les déploiements SIP et CUBE.

Cet ordre de préférence peut être manipulé à l'aide de la commande voice class uri sip preference pour spécifier l'id-utilisateur comme première option au lieu de host.

Préférence URI :

1. Partie hôte de l'URI. Exemples : (@a.b.c.d ou @host.domain.name)
2. Partie utilisateur de l'URI. Exemples : (sip:8675309 ou sip:user)
3. Le télé-uri. Exemple : (tél : 18005532447)
4. Correspondance exacte pour l'URI complet. Exemples : user@host.domain.name, user@a.b.c.d, 8675309@host.domain.name, 8675309@host.domain.name

Document de support : Guide de configuration de Cisco Unified Border Element - Cisco IOS XE 17.6 et versions ultérieures

Scénario : un administrateur a configuré ces terminaux de numérotation dial-peer et envoie un appel à la passerelle. L'en-tête From de l'invitation reçue est From: <sip:testuser@10.10.10.10>. La passerelle peut faire correspondre deux terminaux de numérotation dial-peer différents en fonction de cet en-tête. Dial-Peer 1 basé sur la partie utilisateur et dial-peer 2 basé sur la partie hôte. Cependant, étant donné qu'une correspondance d'hôte est une préférence par rapport à une correspondance d'utilisateur, le terminal de numérotation dial-peer 2 est utilisé pour le terminal de numérotation dial-peer entrant dans l'appel.

!
voice class uri URI1 sip
 user-id testuser 
!
voice class uri URI2 sip
 host ipv4:10.10.10.10
!
dial-peer voice 1 voip
 sess protocol sipv2
 incoming uri FROM URI1
!
dial-peer voice 2 voip
 sess protocol sipv2
 incoming uri FROM URI2
!

URI de classe vocale 

La correspondance URI pour les terminaux de numérotation dial-peer entrants et sortants permet à un administrateur d'effectuer des correspondances sur plusieurs chaînes de numéros de téléphone pour les protocoles VoIP prenant en charge les URI dans leur messagerie. Avant IOS 15.4(1)T et IOS-XE 3.11S, un URI de requête devait contenir un user@host alphanumérique, sinon une passerelle Cisco rejetterait l'appel avec un message 4xx. Désormais, un URI peut contenir uniquement la partie hôte et la passerelle achemine l'appel en fonction de l'hôte fourni. Par exemple, sip:cisco.com.

En outre, avant IOS 15.4(1)T et IOS-XE 3.11S, les ID utilisateur de l'URI de classe vocale ne pouvaient être que des valeurs numériques e.164 (sip:1234@host.com). Cela a été modifié afin que les administrateurs puissent configurer des ID utilisateur alphanumériques sur CUBE (sip:user@host.com).

La partie hôte ou utilisateur d'un URI de classe vocale peut contenir des modèles d'expressions régulières (regex) qui développent considérablement les valeurs possibles pouvant être mises en correspondance.

Gateway(config-voice-uri-class)# user-id .)
% unmatched ()user-id pattern can be of format ^([][0-9A-Za-z\|\/()*+^$&?#--.])*$

Gateway(config-voice-uri-class)# host .)
% unmatched ()host pattern can be of format ^([][0-9A-Za-z\|@\/()*+^$&?#--.])*$

Gateway(config-voice-uri-class)# pattern .)
% unmatched ()pattern pattern can be of format ^([][0-9A-Za-z\|@;:=%!~\/()*+^$&?#--.])*$

Exemple : URI de classe vocale

!
voice class uri HOST sip
 host webex.com
 host dns:cisco.webex.com
 host ipv4:10.50.244.2
 host ipv6:[2001:4860:4860::8888]
!
voice class uri USER sip
 user-id username
!
voice class uri PATTERN sip
 pattern 8675309
!
voice class uri HostRegex sip
 host (.*)cisco.com
!
voice class uri ipRegex sip
 host 172\.18\.110\.20[567]
!
voice class uri PatternRegex sip
 pattern 555(.*)
!
voice class uri ipRegex sip
 pattern (172\.18\.110\.10[134]|10\.10\.10\.10)
 ! One Line that matches 172.18.110.101, 172.18.110.103, 172.18.110.104 OR 10.10.10.10
!
voice class uri UserRegex sip
 user-id test(.*)
!

Seuls 10 hôtes, 1 modèle ou 1 ID utilisateur peuvent être configurés par URI de classe vocale, comme le montre cet exemple. Si d'autres éléments doivent être associés, il est recommandé d'utiliser Regex.

Gateway(config)# voice class uri TEST sip
Gateway(config-voice-uri-class)#host ipv4:10.1.1.1
Gateway(config-voice-uri-class)#host ipv4:10.2.2.2
Gateway(config-voice-uri-class)#host ipv4:10.3.3.3
Gateway(config-voice-uri-class)#host ipv4:10.4.4.4
Gateway(config-voice-uri-class)#host ipv4:10.5.5.5
Gateway(config-voice-uri-class)#host ipv4:10.6.6.6
Gateway(config-voice-uri-class)#host ipv4:10.7.7.7
Gateway(config-voice-uri-class)#host ipv4:10.8.8.8
Gateway(config-voice-uri-class)#host ipv4:10.9.9.9
Gateway(config-voice-uri-class)#host ipv4:10.10.10.10
Gateway(config-voice-uri-class)#host ipv4:10.11.11.11
Error:Maximum of 10 hosts can only be configured.
 
Gateway(config)# voice class uri TEST2 sip
Gateway(config-voice-uri-class)#host dns:1.com
Gateway(config-voice-uri-class)#host dns:2.com
Gateway(config-voice-uri-class)#host dns:3.com
Gateway(config-voice-uri-class)#host dns:4.com
Gateway(config-voice-uri-class)#host dns:5.com
Gateway(config-voice-uri-class)#host dns:6.com
Gateway(config-voice-uri-class)#host dns:7.com
Gateway(config-voice-uri-class)#host dns:8.com
Gateway(config-voice-uri-class)#host dns:9.com
Gateway(config-voice-uri-class)#host dns:10.com
Gateway(config-voice-uri-class)#host dns:11.com
Error:Maximum of 10 hosts can only be configured.
 
Gateway(config)# voice class uri TEST3 sip
Gateway(config-voice-uri-class)#user-id 8675309
Gateway(config-voice-uri-class)#user-id 123456789
Gateway(config-voice-uri-class)#do sh run | s TEST3
voice class uri TEST3 sip
user-id 123456789
 
Gateway(config)# voice class uri TEST4 sip
Gateway(config-voice-uri-class)#pattern 8675309
Gateway(config-voice-uri-class)#pattern 123456789
Gateway(config-voice-uri-class)#do sh run | s TEST4
voice class uri TEST4 sip
pattern 123456789

Correspondance entre homologues de numérotation URI entrants

Cette fonctionnalité a été ajoutée dans IOS 15.1(2)T et IOS-XE 3.8S et utilise un URI de classe vocale configuré et appliqué à un terminal de numérotation dial-peer entrant. L'URI entrant a été adopté par de nombreuses personnes sur l'instruction incoming called-number traditionnelle pour les appels SIP, car il s'agit du premier critère de correspondance vérifié lors de la sélection des terminaux de numérotation dial-peer entrants. La commande permet également aux administrateurs de mieux faire correspondre les appels provenant d'un agent d'appel ou d'un utilisateur particulier.

Documentation complète : Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 et versions ultérieures

Cas d'utilisation courante

1. Un terminal de numérotation dial-peer entrant correspondant à la partie hôte de l'URI pour répondre aux requêtes ping OPTIONS de CUCM.
2. Un terminal de numérotation dial-peer entrant correspondant à la partie hôte de l'URI pour contrôler les appels entrants d'un fournisseur de services de téléphonie Internet (ITSP)
3. Correspondance de terminal de numérotation dial-peer entrant sur la partie ID d'utilisateur de l'URI pour le traitement des appels de certains utilisateurs ou numéros.

Exemple de configuration

Cet exemple de sortie correspond au terminal de numérotation dial-peer 777 pour toute requête SIP provenant des deux adresses IP HOST définies dans l'URI de classe de voix. L'en-tête surveillé est défini comme l'en-tête From sur le terminal de numérotation dial-peer. Toutefois, un administrateur peut en définir plusieurs autres, notamment VIA, TO et REQUEST (URI de requête). Si le CUCM envoie une requête ping OPTIONS au CUBE correspond maintenant au terminal de numérotation dial-peer 777 et envoie ma réponse 200 OK aux OPTIONS à partir de l'interface spécifiée. Si CUCM envoie une invitation au CUBE, le terminal de numérotation dial-peer 777 est associé au terminal de numérotation dial-peer entrant.

!
voice class uri CUCM sip
 host ipv4:10.50.244.2
 host ipv4:10.50.244.20
!
dial-peer voice 777 voip
 description INCOMING URI
 session protocol sipv2
 incoming uri from CUCM
 voice-class sip bind control source-interface Loopback777
 voice-class sip bind media source-interface Loopback777
!

Correspondance de terminal de numérotation dial-peer URI sortant

Les passerelles Cisco IOS peuvent faire correspondre un terminal de numérotation dial-peer sortant à l'aide d'un URI en appliquant un URI de classe vocale à un terminal de numérotation dial-peer sortant et en ajoutant l'URL de routage d'appel à la configuration globale. Lorsque cela est présent, le CUBE peut essayer d'acheminer les appels en fonction de l'URI de requête. Cette fonctionnalité a été ajoutée dans IOS 12.3(4)T et est présente dans toutes les versions d'IOS XE. Par défaut, les URI de requête SIP sortante et d'en-tête To ont la cible de session de l'homologue de numérotation sortante. Cette option peut être désactivée à l'aide de la commande requri-pass qui permet à la passerelle de passer la partie hôte de l'URI dans la branche vers la branche sortante au lieu de remplacer la partie hôte de l'URI par la cible de session. La commande requri-pass a été ajoutée dans 15.4(1)T et IOS XE 3.11S.

Exemple de configuration

voice service voip
 sip
  call-route url
  requri-passing
!
voice class uri CUCM sip
 host dns:.*.com
!
dial-peer voice 777 voip
 description OUTGOING URI
 session protocol sipv2
 destination uri CUCM
 session target sip-uri
!

Source : Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 et versions ultérieures

En plus de l'URI de classe vocale, les administrateurs peuvent utiliser une stratégie DPP (dial-peer provision-policy) pour faire correspondre un URI de branche pour une correspondance de terminal de numérotation dial-peer sortante. Cette fonctionnalité a été ajoutée dans IOS 15.4(2)T et IOS XE 3.12S. Une stratégie de fourniture d'homologue de numérotation nécessite la définition d'un attribut de correspondance principal avec un attribut de correspondance secondaire facultatif. La stratégie de mise en service est appliquée à un terminal de numérotation dial-peer entrant, et lorsque ce terminal de numérotation dial-peer est sélectionné pour être utilisé sur un tronçon d'appel entrant, la stratégie est appelée. Le résultat est une sélection de terminal de numérotation dial-peer sortant basée sur l'attribut de la stratégie de configuration de terminal de numérotation dial-peer.

La correspondance sortante peut être un seul en-tête ou plusieurs en-têtes qui doivent tous être vrais pour correspondre au terminal de numérotation dial-peer.

Dans l'exemple, il existe un URI de classe vocale pour les en-têtes From et To. Pour une correspondance OR, une stratégie de configuration dial-peer contenant deux préférences est configurée. L'en-tête De est la première préférence et l'en-tête À est la préférence de sauvegarde. Dial-Peer 1234 est conçu pour appliquer la stratégie de mise à disposition pour la correspondance entrante. Ensuite, un terminal de numérotation dial-peer 11111 et 22222 qui appliquent respectivement les commandes destination uri-from et destination uri-to. Ces commandes pointent vers leur URI de classe vocale. Pour l'appel, vous pouvez recevoir l'invitation, faire correspondre le terminal de numérotation dial-peer 1234 et vérifier la stratégie de mise à disposition. Le périphérique peut ensuite essayer d'acheminer d'abord l'en-tête From qui correspond au terminal de numérotation dial-peer 11111. Si cela échoue, vous pouvez également essayer d'acheminer sur l'en-tête de destination avec 22222.

L'exemple montre également comment obtenir une correspondance And avec les politiques de configuration dial-peer. En supposant que la même invitation est reçue, vous pouvez définir deux en-têtes sous une préférence et l'appliquer au terminal de numérotation dial-peer entrant.

À présent, lorsque l'invitation est reçue, il peut rechercher des terminaux de numérotation dial-peer sortants éligibles qui répondent aux deux critères de correspondance définis dans la politique de fourniture. Dans cet exemple, votre terminal de numérotation dial-peer sortant doit être défini avec les en-têtes TO et FROM pour pouvoir être mis en correspondance. Si l'un des deux n'est pas une correspondance valide, ce terminal de numérotation dial-peer 12345 n'est pas utilisé.

Remarque : bien que nous acheminions l'appel sur l'en-tête From, l'invite qui quitte la passerelle a toujours l'URI de requête d'origine. Nous utilisons simplement la stratégie de configuration de terminal de numérotation dial-peer pour faire correspondre un terminal de numérotation dial-peer sortant et ne pas modifier l'URI de la demande.

Exemple de configuration :

### Received INVITE
Received: 
INVITE sip:8675309@172.18.110.58:5060 SIP/2.0
From: sipp <sip:sipp@172.18.110.65>;tag=1
To: sut <sip:cube@172.18.110.58:5060>

### Common Configurations
!
voice class uri FROM sip
 user-id sipp
!
voice class uri TO sip
 user-id cube
!

### OR Match
!
voice class dial-peer provision-policy 1
 description match from header. If false, try to header
 preference 1 from
 preference 2 to
!
dial-peer voice 1234 voip
 session protocol sipv2
 destination provision-policy 1
 incoming called-number .
!
dial-peer voice 11111 voip
 destination uri-from FROM
 session protocol sipv2
 session target ipv4:172.18.110.48
!
dial-peer voice 22222 voip
 destination uri-to TO
 session protocol sipv2
 session target ipv4:172.18.110.48
!

### AND Match
!
voice class dial-peer provision-policy 2
 description match from AND to headers
 preference 1 from to
!
dial-peer voice 1234 voip
 session protocol sipv2
 destination provision-policy 2
 incoming called-number .
!
dial-peer voice 12345 voip
 destination uri-from FROM
 destination uri-to TO
 session protocol sipv2
 session target ipv4:172.18.110.48
!

Source : Guide de configuration de Cisco Unified Border Element via Cisco IOS XE 17.5

session target sip-uri

Avant IOS 15.4(1)T et IOS XE 3.11S, si la partie hôte d'un URI était différente, mais que l'utilisateur était le même, cela nécessitait deux terminaux de numérotation dial-peer sortants distincts.

Après cette version, un administrateur peut configurer un terminal de numérotation dial-peer pour desservir plusieurs hôtes pour le même utilisateur. Par exemple, testuser@cisco.com et testuser@webex.com sous le même terminal de numérotation dial-peer. L'utilisation de l'URI-sip cible de session déclenche la résolution DNS du domaine de l'URI de demande d'invitation entrant et détermine dynamiquement l'adresse IP cible de session.

Exemple de configuration :

La passerelle reçoit deux invitations SIP avec ces en-têtes Invite sip:testuser@cisco.com:5060 SIP/2.0 Invite sip:testuser@webex.com:5060 SIP/2.0 La passerelle correspond à la requête SIP entrante de testuser@cisco.com et testuser@webex.com sur dial-peer 1 en raison de la commande entrante URI et de la définition d'ID utilisateur match testuser. La commande voice-class sip call-route url is present signifie que vous évaluez les terminaux de numérotation dial-peer sortants sur la base de l'URI de demande de cette invitation entrante. Vous faites correspondre le terminal de numérotation dial-peer 2 pour les mêmes raisons que vous avez fait correspondre le terminal de numérotation dial-peer 1, l'ID utilisateur de testuser. La cible de session de ce terminal de numérotation dial-peer est l'uri-sip d'origine, tel que défini par l'uri-sip cible de session, qui était un nom de domaine complet (FQDN). Une fois la résolution DNS effectuée, et après avoir remplacé cisco.com et webex.com par une adresse IP pour le routage de couche 3, vous envoyez un message à partir de la passerelle.

!
ip host cisco.com 10.10.10.10
ip host webex.com 10.10.10.10
!
voice class uri TEST-IN sip
 user-id testuser
!
dial-peer voice 1 voip
 description INCOMING dial-peer
 incoming uri request TEST
 session protocol sipv2
 voice-class sip call-route url
!
dial-peer voice 2 voip
 description OUTBOUND dial-peer
 destination uri TEST
 session protocol sipv2
 session target sip-uri
!

Vérification : 

show voice class uri <uri-name>
show voice class dial-peer provision-policy <number>
debug voip uri

Caractères génériques Dial-Peer

Un administrateur peut utiliser des caractères génériques de terminal de numérotation dial-peer lors de la définition de mécanismes de correspondance entrants et sortants impliquant une chaîne numérique. Il s’agit notamment de destination-pattern, incoming called-number, e164-pattern-maps et answer-address, ainsi que de la commande prefix. Les caractères génériques de terminal de numérotation dial-peer sont des expressions régulières (regex) disponibles pour la configuration, qui offrent une plus grande flexibilité sur la mise en correspondance des terminaux de numérotation dial-peer.

Tableau générique

Sortie de la passerelle qui affiche les entrées d'expression régulière possibles.

Gateway(config-dial-peer)# destination-pattern asdfqw4r3~2
Incorrect format for E.164 Number
        regular expression must be of the form  ^[][^0-9,A-F#*.?+%()-]*T?(\$)?$

États Dial-Peer

Les terminaux de numérotation dial-peer peuvent être dans l'un des deux états opérationnels.

1. Haut
2. En Bas

Pour qu'un terminal de numérotation dial-peer soit dans un état opérationnel valide et puisse être utilisé avec le routage d'appels, il doit être dans l'état UP. Pour les terminaux de numérotation dial-peer VOIP sortants, cela signifie qu'il peut y avoir des mécanismes de correspondance sortants valides ainsi qu'une cible de session valide vers laquelle acheminer l'appel. Pour les terminaux de numérotation dial-peer POTS sortants, un mécanisme de correspondance sortant valide ainsi qu'un port vocal valide peuvent être configurés. Avec des terminaux de numérotation dial-peer entrants uniquement, des mécanismes de correspondance entrants valides doivent être configurés.

L'état d'occupation apparaît lorsqu'un terminal de numérotation dial-peer est configuré avec des mécanismes de test d'activité et que la cible distante a échoué dans les paramètres de ce mécanisme. La passerelle fait passer le terminal de numérotation dial-peer à l'état occupé afin qu'il ne soit plus utilisé pour les décisions de routage d'appels. Lorsque le mécanisme de test d'activité est à nouveau exécuté, la passerelle remet le terminal de numérotation dial-peer à l'état actif. Si un terminal de numérotation dial-peer est sélectionné comme terminal de numérotation dial-peer sortant et que ce terminal de numérotation dial-peer est en état de disponibilité, la passerelle échoue l'appel avec un code de cause 188.

Outre les états opérationnels, il existe des états administratifs.

1. Haut
2. En Bas

Un administrateur peut désactiver un terminal de numérotation dial-peer sans le supprimer de la configuration en entrant la commande shutdown sur le terminal de numérotation dial-peer. Pour réactiver la numérotation par utilisateur, entrez no shutdown.

Remarque : un terminal de numérotation dial-peer dont le port vocal est désactivé, arrêté ou non opérationnel, reste dans l'état opérationnel Up, mais l'état Out indique Down.

 Vérification 

Gateway# show dial-peer voice summary
dial-peer hunt 0
             AD                                    PRE PASS                OUT
TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE
1      voip  up   up                                0  syst
777    voip  up   up             9...               0  syst ipv4:10.50.244.2
555    voip  up   down           555                0  syst
888    pots  up   up             888                0                      up   0/2/0
999    pots  up   up             999                0                      down 0/2/0
123    voip  up   up             123                0  syst ipv4:10.10.10.10            busyout

Routage et transfert virtuels (VRF) et recherche d'homologues de numérotation

Correspondance de terminal de numérotation dial-peer entrant avec VRF

À partir des versions IOS 15.6(3)M et IOS-XE 16.3.1, les passerelles Cisco peuvent faire correspondre des terminaux de numérotation dial-peer entrants à l'aide d'ID VRF. Pour tirer parti de cette fonctionnalité, un administrateur doit lier le terminal de numérotation dial-peer entrant à une interface qui, à son tour, lie le terminal de numérotation dial-peer à l'ID VRF sur l'interface spécifiée. Une fois la liaison terminée, les appels entrants sont filtrés par la passerelle Cisco afin d'inclure uniquement les terminaux de numérotation dial-peer entrants éligibles qui correspondent à l'ID VRF de l'interface sur laquelle le paquet a été reçu. À partir de là, le terminal de numérotation dial-peer entrant est mis en correspondance en fonction de l'ordre des opérations de mise en correspondance de terminal de numérotation dial-peer standard.

Avant ces versions IOS / IOS-XE, la passerelle Cisco effectuait une sélection entrante basée sur une correspondance de terminal de numérotation dial-peer entrante normale sans aucun filtrage. Cela signifie qu'un terminal de numérotation dial-peer VRF2 peut faire correspondre un appel VRF1. En outre, étant donné qu'un seul VRF était pris en charge par H323 et SIP avant ces versions, d'autres problèmes surviennent lors de la tentative d'utilisation de fonctions VRF multiples. L'utilisation d'un seul VRF pour les applications vocales était connue sous le nom de configuration compatible VRF.

Documentation VRF complète : VRF-Aware H.323 et SIP pour passerelles vocales

Documentation Multi-VRF complète : Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 et versions ultérieures

Correspondance Dial-Peer sortant avec VRF

Les passerelles Cisco permettent de relier des appels entre des VRF sans qu'il soit nécessaire de configurer des fuites de route. Cela signifie qu'un appel entrant sur VRF1 peut être routé vers l'extérieur sur un terminal de numérotation dial-peer pour VRF2 si la sélection normale de terminal de numérotation dial-peer sortant correspondant est satisfaite. Les groupes de terminaux de numérotation dial-peer peuvent être utilisés pour forcer la passerelle Cisco à maintenir l'appel dans le même VRF.

Exemple de configuration de VRF et de groupe de terminaux de numérotation dial-peer

Dans cet exemple de configuration, VRF1 et VRF2 se chevauchent avec deux plages IP et deux plages de numéros de téléphone.

Utilisez la liaison VRF pour vous assurer que le terminal de numérotation dial-peer entrant correct correspond et Dial-peer Groups pour vous assurer que le terminal de numérotation dial-peer sortant VRF correct correspond. Si un paquet SIP pour un appel vers 8675309 arrive sur gig0/0/1.2, alors la passerelle filtre tous les terminaux de numérotation dial-peer entrants disponibles en fonction de l'ID VRF2. Cela signifie que vous ne pouvez pas faire correspondre le terminal de numérotation dial-peer 10. Maintenant, lorsque vous vérifiez la chaîne de chiffres, vous pouvez faire correspondre le terminal de numérotation dial-peer 20. Le terminal de numérotation dial-peer 20 possède un groupe de terminaux de numérotation dial-peer qui indique à la passerelle que le seul terminal de numérotation dial-peer sortant pouvant être mis en correspondance est également le terminal de numérotation dial-peer 20. Ce groupe de terminaux de numérotation dial-peer vous permet d'éviter de faire correspondre le terminal de numérotation dial-peer 10 et de croiser un appel provenant de VRF1 vers VRF2. À partir de là, l'appel peut continuer normalement.

!
interface GigabitEthernet0/0/1.1
 description VRF1
 encapsulation dot1Q 10
 ip vrf forwarding VRF1
 ip address 10.10.10.10 255.255.255.0
!
interface GigabitEthernet0/0/1.2
 description VRF2
 encapsulation dot1Q 20
 ip vrf forwarding VRF2
 ip address 10.10.10.10 255.255.255.0
!
voice service voip
 no ip address trusted authenticate
 media-address voice-vrf VRF1
 media-address voice-vrf VRF2
 allow-connections sip to sip
 sip
!
voice class dpg 10
 description INBOUND VRF1 to OUTBOUND VRF1
 dial-peer 10 preference 1
!
voice class dpg 20
 description INBOUND VRF2 to OUTBOUND VRF2
 dial-peer 20 preference 1
!
dial-peer voice 10 voip
 description VRF1
 destination-pattern 8675309
 session protocol sipv2
 session target ipv4:10.10.10.20
 destination dpg 10
 incoming called-number 8675309
 voice-class sip bind control source-interface GigabitEthernet0/0/1.1
 voice-class sip bind media source-interface GigabitEthernet0/0/1.1
!
dial-peer voice 20 voip
 description VRF2
 destination-pattern 8675309
 session protocol sipv2
 session target ipv4:10.10.10.20
 destination dpg 20
 incoming called-number 8675309
 voice-class sip bind control source-interface GigabitEthernet0/0/1.2
 voice-class sip bind media source-interface GigabitEthernet0/0/1.2
!

Vérification

Gateway# show vrf brief | i VRF
  VRF1                             1:1                   ipv4        Gi0/0/1.1
  VRF2                             2:2                   ipv4        Gi0/0/1.2

Gateway# show dial-peer voice summary
TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE    VRF
10     voip  up   up             8675309            0  syst ipv4:10.10.10.20                         VRF1
20     voip  up   up             8675309            0  syst ipv4:10.10.10.20                         VRF2

Gateway# show voice class dpg 10
Voice class dpg: 10      AdminStatus: Up
 Description: INBOUND to OUTBOUND VRF1
 Total dial-peer entries: 1

 Peer Tag       Pref
 --------       ----
 10             1
-------------------------------------

Gateway# show voice class dpg 20
Voice class dpg: 20      AdminStatus: Up
 Description: INBOUND to OUTBOUND VRF2
 Total dial-peer entries: 1

 Peer Tag       Pref
 --------       ----
 20             1
-------------------------------------

Techniques avancées de routage des appels

Au fil des ans, à mesure que les besoins de l'entreprise augmentent, l'entreprise se développe et nécessite davantage de DID. Les administrateurs de l'entreprise peuvent constater que les terminaux de numérotation dial-peer de base ne répondent pas bien aux besoins d'évolutivité. Il peut y avoir des situations de marche-arrêt qui doivent être traitées, ou peut-être il y a juste trop de terminaux de numérotation dial-peer en général. Le fait d'avoir des milliers d'homologues de numérotation ne facilite pas l'administration et le dépannage. Le fait d'avoir un terminal de numérotation dial-peer pour chaque serveur CUCM ou agent d'appel spécifique commence à aggraver le problème du trop grand nombre de terminaux de numérotation dial-peer, car un administrateur doit maintenant configurer un terminal de numérotation dial-peer pour chaque chaîne de chiffres. Si plusieurs fournisseurs SIP se connectent à une passerelle ou si plusieurs personnes utilisent le même CUBE, il est très difficile d'isoler un locataire spécifique.

Cisco a pris en compte ces commentaires et a créé un ensemble d'éléments capables de résoudre des problèmes complexes et bien plus encore. Les groupes de terminaux de numérotation dial-peer, les locataires de classe vocale, les groupes de serveurs de destination, les mappages de modèles e164 et les groupes de faisceaux POTS permettent à un administrateur de résoudre tous les problèmes répertoriés et bien d'autres qui ne le sont pas.

Groupes de terminaux de numérotation

Des groupes de terminaux de numérotation dial-peer ont été ajoutés dans IOS 15.4(1)T et IOS-XE 3.11S et des terminaux de numérotation dial-peer POTS ont été ajoutés en tant qu'option dans IOS 15.5(1)T et IOS-XE 3.14S. Un groupe de terminaux de numérotation dial-peer permet aux administrateurs de spécifier un terminal de numérotation dial-peer exact pour le routage sortant en fonction du terminal de numérotation dial-peer entrant correspondant. Une fois qu'un terminal de numérotation dial-peer entrant avec un groupe de terminaux de numérotation dial-peer configuré est mis en correspondance, l'appel utilise le terminal de numérotation dial-peer défini dans le groupe de terminaux de numérotation dial-peer, même si le modèle de destination ne correspond pas. Le seul prérequis est que le terminal de numérotation dial-peer sortant doit être actif, de sorte qu'une méthode de correspondance sortante doit être configurée. Toutefois, cette méthode n'est pas réellement utilisée pour acheminer l'appel.

La meilleure façon de décrire les groupes de terminaux de numérotation dial-peer consiste à les comparer au concept de routes statiques dans une table de routage. Il s'agit de décisions de routage statique entrantes vers sortantes qui enlèvent certaines conjectures à la passerelle, car elles lui indiquent exactement comment acheminer l'appel. 

Documentation complète : Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 et versions ultérieures

Exemple de configuration

Dans cet exemple, le numéro appelé est 8675309. Correspond au terminal de numérotation dial-peer 1234 basé sur l'instruction de numéro appelé entrant. Ce terminal de numérotation dial-peer est configuré avec un groupe de terminaux de numérotation dial-peer qui indique que l'appel peut désormais être acheminé vers les terminaux de numérotation dial-peer 2, puis 3, et enfin 1 si le terminal de numérotation dial-peer 2 échoue. La passerelle essaie donc à présent d'acheminer l'appel vers le terminal de numérotation dial-peer 2, car il a été explicitement indiqué par le groupe de terminaux de numérotation dial-peer que c'est ce qu'il peut faire.

Remarque : le modèle de destination sur le terminal de numérotation dial-peer 1, 2 et 3 n'est pas le numéro appelé 8675309. C'est très bien et l'appel est toujours acheminé sans problème.

N'oubliez pas que, comme indiqué dans la section sur les états des terminaux de numérotation dial-peer, vous devez configurer quelque chose/quoi que ce soit comme instruction de correspondance sortante. Dans ce cas, le modèle de destination est uniquement destiné à faire passer le terminal de numérotation dial-peer à l'état opérationnel Up, et la chaîne de chiffres de cette commande n'est jamais évaluée. Il est recommandé de configurer un modèle comme destination-pattern AAAA car il s'agit d'un modèle de destination valide. Comme il s'agit techniquement d'un terminal de numérotation dial-peer valide, d'autres appels peuvent correspondre. Ainsi, la chaîne de chiffres AAAA signifie que vous ne pouvez jamais l'utiliser pour autre chose qu'un scénario spécifique impliquant un groupe de terminaux de numérotation dial-peer, car la probabilité qu'un appel arrive pour AAAA est très, très faible.

!
dial-peer voice 1 voip
 description Server 1
 destination-pattern ^1234$
 session target ipv4:1.1.1.1
!
dial-peer voice 2 voip
 description Server 2
 destination-pattern ^5678$
 session target ipv4:2.2.2.2
!
dial-peer voice 3 voip
 description Server 3
 destination-pattern AAAA
 session target ipv4:3.3.3.3
!
voice class dpg 1
 description Dial-peer Group for specific called number 8675309
 dial-peer 2 preference 1
 dial-peer 3 preference 2
 dial-peer 1 preference 3
!
dial-peer voice 1234 voip
 description INCOMING dial-peer with DPG
 incoming called-number ^8675309$
 destination dpg 1
!

Vérification

Gateway# show voice class dpg 1
Voice class dpg: 1       AdminStatus: Up
 Description: Dial-peer Group for specific called number 1234
 Total dial-peer entries: 3

 Peer Tag       Pref
 --------       ----
 2              1
 3              2
 1              3
-------------------------------------

E164-Cartes-Modèles

Cette fonctionnalité permet aux administrateurs de réduire le nombre total de terminaux de numérotation dial-peer en combinant de nombreuses correspondances de numéros possibles (modèles de destination, numéros appelés entrants, etc.) dans un seul mappage de modèles. La prise en charge du mappage de modèle e164 de terminal de numérotation dial-peer sortant a été ajoutée dans IOS 15.2(4)M et IOS-XE 3.7S, tandis que la prise en charge du mappage de modèle e164 de terminal de numérotation dial-peer entrant a été ajoutée dans IOS 15.4(1)T et IOS-XE 3.11S.

Un e164-pattern-map peut être configuré via l'interface de ligne de commande ou préconfiguré et enregistré sous la forme d'un fichier .cfg. Le fichier .cfg est ensuite ajouté à la mémoire flash de la passerelle, puis référencé lors de la configuration du reste de la commande. Le fichier .cfg peut utiliser 5 000 entrées.

Les entrées des deux méthodes de configuration peuvent utiliser tous les caractères génériques normaux des terminaux de numérotation dial-peer pour une agrégation plus poussée !

Documentation complète : Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 et versions ultérieures

Exemple de configuration CLI - Numéros appelants

!
voice class e164-pattern-map 1
 description E164 Pattern Map for calling numbers
 e164 919574100.
 e164 919574300.
 e164 8675309
!
dial-peer voice 1 voip
 description INBOUND Dial-peer based on CALLING #
 incoming calling e164-pattern-map 1
!
dial-peer voice 11 voip
 description OUTBOUND Dial-peer based on CALLING #
 destination calling e164-pattern-map 1
!

Exemple de configuration CLI - Numéro appelé

!
voice class e164-pattern-map 2
 description E164 Pattern Map for called 800 numbers
 e164 91800T
 e164 91855T
 e164 91888T
!
dial-peer voice 2 voip
 description INBOUND Dial-peer based on CALLED #
 incoming called e164-pattern-map 2
!
dial-peer voice 22 voip
 description OUTBOUND Dial-peer based on CALLED #
 destination e164-pattern-map 2
!

Exemple de configuration Flash

!
voice class e164-pattern-map <tag>
 description FILEPATH for E164 Pattern Map
 url flash:<filepath>/e164-pattern-list.cfg
!
dial-peer voice ### voip
 description E164 Pattern Map Dial-peer
 incoming calling e164-pattern-map <tag>
!

voice class e164-pattern-map load <tag>

Vérification

Gateway# show voice class e164-pattern-map 1

e164-pattern-map 1
-----------------------------------------
  Description: CUCM phones
  It has 3 entries
  It is not populated from a file.
  Map is valid.

E164 pattern
-------------------
8675309
1...
[2-5]...$

Défauts notables

L'ID de bogue Cisco CSCva64393e164-pattern-map n'analyse pas la dernière ligne du fichier de configuration.

Groupes de serveurs de destination

Les groupes de serveurs permettent aux administrateurs de configurer plusieurs destinations (cibles de session) sur le même terminal de numérotation dial-peer VOIP. Par défaut, l'ordre de tri est la préférence définie dans les entrées du groupe de serveurs. La recherche circulaire peut être utilisée lorsque vous utilisez la commande hunt-scheme round-robin. Les groupes de serveurs ont été ajoutés dans Cisco IOS 15.4(1)T et Cisco IOS XE 3.11S. Dans Cisco IOS XE 17.4.1a, des codes d'erreur huntstop configurables ont été ajoutés aux configurations de groupes de serveurs de classe vocale. Autrement dit, vous pouvez configurer un code d'erreur unique, par exemple 404 Not Found, et une erreur SIP déclencherait normalement le périphérique pour essayer l'option suivante dans le groupe de serveurs. Lorsque le code resp-code 404 de la commande config huntstop 1 est en place dans le groupe de serveurs, la recherche peut s'arrêter. Ces derniers peuvent également être configurés pour une plage comme : huntstop 1 resp-code 401 à 599.

Remarque : le nombre maximal d'entrées est de 5 par groupe de serveurs.

Documentation complète : Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 et versions ultérieures

Exemple de configuration - Normal

!
voice class server-group 1
 hunt-scheme round-robin
 ipv4 10.50.244.2 port 5060 preference 1
 ipv4 10.50.244.62
 ipv6 2010:AB8:0:2::1 port 2323 preference 3
 ipv6 2010:AB8:0:2::2 port 2222
!
dial-peer voice 1 voip
 session protocol sipv2
 destination-pattern 8675309
 session server-group 1
!

Vérification

Gateway# show voice class server-group 1
Voice class server-group: 1
 AdminStatus: Up OperStatus: Up
 Hunt-Scheme: round-robin Last returned server:
 Description:
 Total server entries: 4

 Pref Type IP Address IP Port
 ---- ---- ---------- -------
 1 ipv4 10.50.244.2     5060
 0 ipv4 10.50.244.62
 3 ipv6 2010:AB8:0:2::1 2323
 0 ipv6 2010:AB8:0:2::2 2222
[..truncated..]

Groupe de serveurs de destination et maintien de la connexion OPTIONS

Sachez que les groupes de serveurs ne suivent pas les mécanismes habituels de maintien de la connexion OPTIONS Out-of-dialog. Ils utilisent une fonctionnalité appelée profil de test d'activité d'option. Cela permet à la passerelle de surveiller chaque agent d'appel défini dans le groupe de serveurs spécifique.

Exemple de keepalive d'option avec un groupe de serveurs

!
voice class server-group 1
 hunt-scheme round-robin
 ipv4 10.50.244.2
 ipv4 10.50.244.62
!
dial-peer voice 1 voip
 session protocol sipv2
 session server-group 1
 voice-class sip options-keepalive profile 1
!

Vérification

Gateway# show voice class sip-options-keepalive 1
Voice class sip-options-keepalive: 1             AdminStat: Up
 Description:
 Transport: system               Sip Profiles: 0
 Interval(seconds) Up: 5                 Down: 5
 Retry: 5

  Peer Tag      Server Group    OOD SessID      OOD Stat        IfIndex
  --------      ------------    ----------      --------        -------
  1             1                               Active          87

  Server Group: 1                OOD Stat: Active
   OOD SessID   OOD Stat
   ----------   --------
   1            Active
   2            Active

 OOD SessID: 1                   OOD Stat: Active
  Target: ipv4:10.50.244.2
  Transport: system              Sip Profiles: 0

 OOD SessID: 2                   OOD Stat: Active
  Target: ipv4:10.50.244.62
  Transport: system              Sip Profiles: 0

Proxy sortant

La configuration du proxy de sortie SIP peut être ajoutée aux configurations de service vocal voip, de locataire de classe vocale ou de terminal de numérotation dial-peer pour spécifier la destination d'un paquet SIP de couche 3.

En d’autres termes, la cible de session sur un terminal de numérotation dial-peer peut être utilisée pour créer le paquet SIP, mais le proxy sortant peut être l’emplacement où le paquet est envoyé au niveau de la couche 3.

!
voice service voip
 sip
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!
voice class tenant 100
 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!
dial-peer voice 100 voip
 session target ipv4:192.168.1.1
 voice-class sip outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!

Il est à noter que la configuration par défaut d'un terminal de numérotation dial-peer est voice-class sip outbound-proxy system, ce qui peut amener un terminal de numérotation dial-peer à utiliser la configuration globale voice service voip > sip.

Ce comportement peut être désactivé et forcer un terminal de numérotation dial-peer à revenir en arrière et à utiliser la cible de session comme destination de couche 3 par terminal de numérotation dial-peer avec cette configuration :

dial-peer voice 777 voip
 no voice-class sip outbound-proxy

Groupes de faisceaux POTS

Les groupes de faisceaux sont un ensemble de ports vocaux physiques dotés de fonctionnalités de signalisation similaires. Il s'agit d'une fonctionnalité qui peut être utilisée pour réduire le nombre total d'homologues de numérotation POTS devant être configurés. Les groupes de faisceaux ont été introduits dans IOS dans 12.1(3)T et sont présents dans toutes les versions de Cisco IOS XE.

Documentation complète : Améliorations des liaisons de passerelle et du routage par opérateur

Exemple de configuration

!
trunk group PSTN
 description PSTN voice-ports
!
trunk group FXO
 description FXO voice-ports
!
voice-port 0/2/0
 trunk-group PSTN 1
!
voice-port 0/2/1
 trunk-group PSTN 2
!
voice-port 0/2/2
 trunk-group FXO 1
!
voice-port 0/2/3
 trunk-group FXO 2
!
dial-peer voice 1234 pots
 trunkgroup PSTN 1
 trunkgroup FXO 2
!

Locataires de classe vocale

Cisco IOS 15.6(2)T et Cisco IOS XE 16.3.1 ont introduit les locataires de classe vocale qui permettent à chaque locataire d'avoir ses propres configurations individuelles. Un locataire peut être un fournisseur de téléphonie, Cisco Unified Communication Manager (CUCM) ou tout autre agent d'appel tiers pour lequel un administrateur souhaite disposer de paramètres globaux spécifiques. Tout d'abord, un administrateur crée un locataire de classe vocale et définit les paramètres. Le locataire de classe vocale est ensuite appliqué au terminal de numérotation dial-peer ou au choix spécifique. Cette nouvelle configuration offre aux administrateurs un niveau de contrôle supplémentaire sur les appels au-delà des terminaux de numérotation dial-peer et de la configuration globale.

Avec la version 17.8.1a, les configurations de locataire de classe vocale peuvent être configurées avec une commande sip-listen (associée à la commande de liaison de contrôle SIP appropriée) pour définir le port non sécurisé ou sécurisé de ce locataire. Cela signifie que le locataire 1 peut écouter le SIP non sécurisé sur UDP 5060 + VRF Rouge tandis que le locataire 2 écoute le SIP sur TCP TLS 5070 + VRF Bleu. Une fois que le locataire a été mis en correspondance en fonction de listen-port + bind + facultative vrf, les terminaux de numérotation dial-peer entrants sont filtrés vers ceux auxquels le locataire est appliqué.

Documentation complète : Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 et versions ultérieures

Ordre normal des préférences de commande sans locataires

1. Dial-peer, commande
2. Commande globale (voice service voip et sip-ua)

Ordre de préférence des commandes avec les locataires

1. Dial-peer, commande
2. Tenant, commande
3. Commande globale (voice service voip et sip-ua)

Exemple de configuration multilocataire

Vous avez deux locataires 777 et 999. Vous les avez configurés avec des configurations légèrement différentes et les avez appliqués aux terminaux de numérotation dial-peer. Cela signifie que les appels utilisant les différents terminaux de numérotation dial-peer ont les configurations basées sur les terminaux de numérotation dial-peer ainsi que les configurations spécifiques aux locataires. Les options répertoriées ne sont qu'un extrait de la puissance des locataires de classe vocale. Reportez-vous à la documentation pour voir ce qui peut être configuré sur un service partagé. Il est recommandé d'utiliser des mécanismes de correspondance stricts comme l'URI de classe vocale ou le balisage de numéros avec certaines chaînes de numéros pour séparer la correspondance de terminal de numérotation dial-peer du locataire, ou même de configurer des VRF de sorte que le locataire A ne chevauche jamais le locataire B et ne fasse accidentellement correspondre un terminal de numérotation dial-peer qu'il ne peut pas.

!
voice class tenant 999
 asymmetric payload full
 bind control source-interface GigabitEthernet0/0/0.228
 bind media source-interface GigabitEthernet0/0/0.228
 g729 annexb-all
!
voice class tenant 777
 sip-server ipv4:192.168.1.2
 bind control source-interface Loopback0
 bind media source-interface Loopback0
 pass-thru content sdp
!
dial-peer voice 999 voip
 destination-pattern 8675309
 session protocol sipv2
 incoming called-number 8675309
 voice-class sip tenant 999
!
dial-peer voice 777 voip
 destination-pattern 8675309
 session protocol sipv2
 session target sip-server
 voice-class sip tenant 777
!

Vérification

Actuellement, il n'y a aucune commande individuelle pour voir les configurations de locataire de classe vocale. Cette commande peut être suffisante pour filtrer la configuration en cours uniquement sur les informations du service partagé.

show run | sec tenant

Remarque : le bogue Cisco ayant l'ID CSCvf28730 est l'emplacement où show sip-ua register status ne reflète pas l'état de l'enregistrement de la ligne principale SIP sur un locataire de classe vocale.

Appels URI ILS CUBE (Voice Class Route-String)

Les chaînes de routage sont utilisées avec le service de recherche intercluster CUCM (ILS) et peuvent être configurées pour permettre aux passerelles Cisco d'acheminer les appels VoIP via la chaîne de routage incluse dans l'invitation SIP reçue d'un CUCM 9.5+ exécutant le service ILS. Cette fonctionnalité a été ajoutée dans Cisco IOS 15.3(3)M et Cisco IOS XE 3.10S. La plupart des connexions ILS sont CUCM à CUCM et les administrateurs ne prennent pas la peine d'impliquer un CUBE pour l'agrégation intercluster. Cependant, si vous devez exécuter la fonction avec CUBE au milieu, les options sont là. CUCM doit avoir le paramètre Send ILS Learned Destination Route String activé sur le profil SIP appliqué à la ligne principale SIP pour envoyer l'en-tête x-cisco-dest-route-string à CUBE

Documentation complète : Guide de configuration Enterprise Application Interoperability for H.323-to-SIP and SIP-to-SIP, Cisco IOS Release 15M&T

Exemple de configuration CUCM - SIP - CUBE - SIP - CUCM

!
voice service voip
 sip
  call-route dest-route-string
!
voice class route-string rt1
 pattern london.uk.eu
!
voice class sip route-string rt2
 pattern *.eu
!
voice class sip-hdr-passthrulist hdr1
 passthru-hdr x-cisco-dest-route-string
!
dial-peer voice 1 voip
 description INBOUND dial-peer
 session protocol sipv2
 voice-class sip pass-thru headers hdr1
 incoming called-number .
!
dial-peer voice 2 voip
 description OUTBOUND dial-peer
 destination route-string rt2
 session protocol sipv2
 session target ipv4:172.16.104.178
!

Vérification

show voice class route-string

Techniques de routage des appels héritées

Les éléments traités dans cette section sont considérés comme des techniques héritées. Bien que la possibilité de les configurer soit toujours présente dans une passerelle Cisco, il n'est pas recommandé d'utiliser ces commandes dans les configurations modernes. Ce document ne les couvre que parce qu'ils peuvent être rencontrés lors de l'utilisation de configurations héritées ou lors de mises à niveau.

DNIS-Map

DNIS-maps pourrait être considéré comme le précurseur de ce qui serait maintenant une E164-pattern-map. Les cartes DNIS ont été ajoutées à Cisco IOS dans la version 12.2(2)XB et ont toujours existé dans Cisco IOS XE.

Si des DNIS-maps sont configurées, il serait intéressant de les convertir en la fonctionnalité e164-pattern-map plus robuste.

Syntaxe de commande : Référence des commandes vocales Cisco IOS - D à I

Exemple de configuration

!
voice dnis-map 34
 dnis 8675309
!
dial-peer voice 88 voip
 dnis-map 34
!

Étiquettes de groupe de faisceaux

Les étiquettes de groupe de faisceaux ont été ajoutées dans Cisco IOS 12.2(11)T et existent dans toutes les versions de Cisco IOS XE. L'objectif d'une étiquette de groupe de faisceaux est similaire à celui d'un ID de porteuse dans le sens où il peut être utilisé pour augmenter la correspondance des terminaux de numérotation dial-peer. Cette option est disponible pour la configuration au sein des groupes de liaison POTS, des terminaux de numérotation dial-peer VOIP et POTS, ainsi que des groupes de sources vocales. L'utilisation d'étiquettes de groupe de faisceaux est rarement utilisée dans les configurations de passerelle Cisco modernes.

Syntaxe de commande : Référence des commandes vocales Cisco IOS - T à Z

Exemple de configuration

!
dial-peer voice 112 pots
 trunk-group-label source north3
 trunk-group-label target east17
!

Type de numérotation

Avec les intégrations RNIS Q.931, il est possible de faire correspondre un terminal de numérotation dial-peer en fonction du numéro appelant ou appelé, ainsi que du type de numéro ITU spécifique de la messagerie Q.931 SETUP. Ceci est configurable via la commande numbering-type sur un terminal de numérotation dial-peer VOIP ou POTS. Le type de numérotation ne peut pas être utilisé seul et doit être utilisé conjointement avec le modèle de destination, l'adresse de réponse ou le numéro appelé entrant. Cela signifie que la condition de l'instruction de correspondance entrante / sortante et le type de numéro doivent correspondre pour que le terminal de numérotation dial-peer soit pris en compte pour le routage des appels entrants et sortants.

La numérotation-correspondance peut être considérée comme un mécanisme de filtrage de terminal de numérotation dial-peer plutôt que comme un mécanisme de correspondance. En effet, un terminal de numérotation dial-peer avec et sans commande de type de numérotation appliquée est considéré comme ayant le même poids de préférence par défaut si aucune préférence administrateur n'est appliquée. Ceci est différent de carrier-id qui, lorsqu'il est appliqué à un terminal de numérotation dial-peer avec d'autres mécanismes de correspondance, ajoute la préférence à ce terminal de numérotation dial-peer par rapport aux autres si les deux conditions sont vraies.

La correspondance de type de numérotation a été ajoutée dans Cisco IOS 12.0(7)XR1 et est présente dans toutes les versions de Cisco IOS XE. Avec le déclin des lignes RNIS POTS traditionnelles déployées dans les réseaux de collaboration, l'utilisation du type de numérotation est rarement observée dans les déploiements modernes.

Syntaxe de commande : Référence des commandes vocales Cisco IOS - K à R

Exemple de configuration

Ce terminal de numérotation dial-peer peut correspondre à 4085150000 à 4085159999 uniquement si le type de numéro RNIS est National.

!
dial-peer voice 408 voip
 numbering-type national
 destination-pattern 408515....
 session target ipv4:10.1.1.2
!

Types de numéros possibles :

Données Dial-Peer

Les terminaux de numérotation dial-peer de données ont été introduits dans la plate-forme logicielle Cisco IOS 12.2(13)T et l'utilisation de tels terminaux de numérotation dial-peer était prévue pour les appels entrants de modem de données sur une passerelle Cisco. Ce terminal de numérotation dial-peer est uniquement destiné à être utilisé dans la direction entrante et est rarement utilisé dans les déploiements modernes.

Syntaxe de commande : Référence des commandes vocales Cisco IOS - D à I

Exemple de configuration

!
dial-peer data 100 pots
 incoming called-number 100
!

Voice Source-Group

Cette fonctionnalité a été ajoutée dans la version 15.1(2)T, mais n'est pas implémentée dans de nombreux déploiements modernes. D'autres méthodes de sécurité pour IOS/CUBE sont généralement déployées.

La présentation de CUBE Application Security est disponible dans ce livre blanc, à partir de la section 4.2.

Spécification de gestion et de facilité de gestion de Cisco Unified Border Element (CUBE)

Syntaxe de commande : Fonction Voice Source-Group

Autorisations de numérotation dial-peer

Cette configuration permet à un administrateur de restreindre un terminal de numérotation dial-peer pour autoriser uniquement les connexions entrantes (durée/fin) ou les connexions de sortie (origine/origine). Cela reviendrait à configurer explicitement un terminal de numérotation dial-peer entrant pour qu'il ne soit utilisé que pour les appels entrants et un terminal de numérotation dial-peer sortant pour les appels sortants. Par défaut, tout terminal de numérotation dial-peer autorise les connexions entrantes et sortantes. Cette interface de ligne de commande n'est pas souvent déployée dans les déploiements modernes.

Router(config)# dial-peer voice 1 voip
Router(config-dial-peer)# permission ?
 both allow both orig/term on this dialpeer
 none no orig/term allowed on this dialpeer
 orig allow only orig on this dialpeer
 term allow only term on this dialpeer

Manipulation URI et numérique

À un moment donné dans un déploiement de collaboration, un administrateur peut avoir besoin de manipuler des chiffres ou un en-tête URI / SIP. Les passerelles Cisco proposent de nombreuses méthodes de manipulation des chiffres qui permettent à un administrateur de contrôler entièrement la manière et le moment de manipuler un chiffre. Cependant, ce n'est pas toujours facile et certaines personnes deviennent submergées par les différentes options ou l'administrateur ne sait pas qu'une option existe.

Manipulation de chiffres via des terminaux de numérotation dial-peer POTS

Les terminaux de numérotation dial-peer POTS disposent de quelques techniques de manipulation de chiffres uniques que les terminaux de numérotation dial-peer VOIP ne possèdent pas.

La première est le démontage des chiffres explicitement définis justifiés à gauche dans un modèle de destination. Vous pouvez désactiver cette option à l'aide de la commande no digit-strip sur le terminal de numérotation dial-peer POTS.

Exemple :

Dans cet exemple, 9011T est défini comme la chaîne du modèle de destination.

Une fois cette configuration en place, vous pouvez recevoir un appel pour 90113227045555. Cela correspond au terminal de numérotation dial-peer pour le routage des appels sortants, et les chiffres explicitement définis du 9011 sont supprimés avant que l'appel ne soit routé par le port vocal. 

!
dial-peer voice 1 pots
 destination-pattern 9011T
 port 0/0/0:23
!

Cet exemple montre une configuration sans barrette de chiffres.

Si le même numéro est appelé, le 9011 est envoyé .

!
dial-peer voice 1 pots
 destination-pattern 9011T
 port 0/0/0:23
 no digit-strip
!

Le second est la possibilité de spécifier le nombre de chiffres que vous souhaitez transférer sur le terminal de numérotation dial-peer POTS.

Prenons cet exemple où vous recevez un appel pour le 918005532447 de CUCM. Dans cette situation, vous souhaitez supprimer le 9, mais envoyer le reste du nombre en commençant par le 1.

Si vous configurez la commande forward-digits sur le terminal de numérotation dial-peer POTS, vous pouvez spécifier exactement combien de chiffres vous envoyez.

!
dial-peer voice 1 pots
 destination-pattern 918005532447
 forward-digits 11
 port 0/2/0
!

Enfin, les terminaux de numérotation dial-peer POTS peuvent utiliser la commande prefix pour ajouter des chiffres à un appel avant de router le port vocal. Cet exemple montre comment supprimer le préfixe 007 et le préfixe 91 explicitement définis pour le numéro avant d'envoyer l'appel via le port vocal.

!
dial-peer voice 1 pots
 destination-pattern 91T
 prefix 007
 port 0/1/0:15
!

Manipulation de chiffres via des règles et des profils de traduction vocale

Les règles de traduction vocale sont des expressions régulières (regex) utilisées pour transformer des chiffres. Les profils et les règles de traduction ont été ajoutés à Cisco IOS dans 12.0(7)XR1. Une règle de traduction est appliquée aux profils de traduction vocale qui sont ensuite appliqués à un terminal de numérotation dial-peer ou à un port vocal. Les règles de traduction contiennent une entrée de correspondance et une sortie de modification. En plus de l’entrée de correspondance sur le numéro, il existe une entrée de correspondance et de modification pour le plan et le type RNIS. La combinaison chaîne de numéro de correspondance, plan et type est considérée comme une correspondance. Cela signifie que toutes les entrées de correspondance définies doivent être vraies pour que la traduction ait lieu. 

Les règles de traduction permettent de modifier Called, Calling, redirect-called, redirect-target et callback-number dans les protocoles de signalisation ISDN, SIP et H323. Les règles de traduction correspondent en fonction d'une recherche descendante. L'ordre des règles est donc de la plus haute importance. Si une correspondance est trouvée dans une règle supérieure, la passerelle arrête immédiatement la recherche et traite la traduction. Les règles de conversion ne peuvent pas modifier les en-têtes sip non numériques tels que testuser@10.10.10.10. Pour cette manipulation, utilisez un profil SIP.

Les règles de transition peuvent être utilisées pour bloquer les appels sur les passerelles Cisco.

Préférence De Sélection Du Profil De Traduction

1. Profil de traduction vocale entrant sur le port vocal
2. Profil de traduction vocale entrante sur le groupe de faisceaux appliqué à l’interface série
3. Profil de traduction vocale entrant sur le terminal de numérotation dial-peer entrant
4. Profil de traduction vocale entrant défini via les ports de service vocal
5. Profil de traduction vocale entrante défini via le « voip-incoming translation-profile » global
6. Profil de traduction vocale sortante défini via les ports de service vocal
7. Outbound voice translation-profile ou translate-outgoing sur le terminal de numérotation dial-peer sortant
8. Profil de traduction vocale sortante sur le groupe de faisceaux appliqué à l'interface série
9. Outbound voice translation-profile sur le port vocal

Outre les règles de conversion de caractères génériques et d'expressions rationnelles de terminal de numérotation dial-peer, les règles de conversion possèdent leurs propres caractères d'expressions rationnelles.

Ensembles de modification

• Les jeux sont spécifiés en tant que \0, \1, \2, etc.
• \0 correspond à tout ce qui se trouve entre le premier jeu de correspondances. Ceci peut également être réalisé par un caractère esperluette : &.
• \1 correspond au premier ensemble de ( ) dans le jeu de correspondances
• \2 correspond au deuxième ensemble de ( ) dans le jeu de correspondances
• Et ainsi de suite.

Exemple de règle de traduction avec deux ensembles

Dans cet exemple, vous pouvez examiner le numéro 000111000222.

Vous voulez supprimer les 0 du nombre et obtenir un nombre final de 111222.

Pour ce faire, vous configurez l'ensemble 1 et 2 pour qu'ils prennent respectivement les 111 et 222 tout en supprimant les 0.

!
voice translation-rule 333
 rule 1 /000\(111\)000\(222\)/ /\1\2/
!
voice translation-profile SET-EXAMPLE
 translate called 333
!

Gateway# test voice translation-rule 333 000111000222
Matched with rule 1
Original number: 000111000222   Translated number: 111222
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

Exemple pour supprimer le modèle de numérotation sortante 9 d'un numéro appelé

!
voice translation-rule 9
 rule 1 /^9\(.*\)/ /\1/
!
voice translation-profile STRIP-9
 translate called 9
!
dial-peer voice 9 voip
 translation-profile outgoing STRIP-9
!
voice-port 0/0/0
 translation-profile outgoing STRIP-9
!

Gateway# test voice translation-rule 9 918675309
Matched with rule 1
Original number: 918675309      Translated number: 18675309
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

Tronquer le numéro appelé à 4 chiffres

!
voice translation-rule 4
 rule 1 /.*\(....\)/ /\1/
!
voice translation-profile STRIP-TO-4
 translate called 4
!

Gateway# test voice translation-rule 4 8675309
Matched with rule 1
Original number: 8675309        Translated number: 5309
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

Retrait de Plus + du numéro appelé

!
voice translation-rule 999
 rule 1 /\+\(.*\)/ /\1/
!
voice translation-profile STRIP-PLUS
 translate called 999
!
Gateway# test voice translation-rule 999 +8675309
Matched with rule 1
Original number: +8675309       Translated number: 8675309
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none 

Les règles de traduction peuvent également être appliquées directement à un terminal de numérotation dial-peer sans être d'abord appliquées à un profil de traduction.

!
voice translation-rule 1
 rule 1 /1234/ /8678309/
!
voice translation-rule 2
 rule 2 /^4...$/ /1408515\0/
!
dial-peer voice 1 voip
 translate-outgoing called 1
!
dial-peer voice 2 voip
 translate-outgoing calling 2
!

Profil de traduction sur le groupe de faisceaux

!
trunk group <name>
 translation-profile incoming <profile-name>
 translation-profile outgoing <profile-name>
!

Déboguer les règles et profils de traduction vocale

debug voip ccapi inout
debug voice translation
debug dialpeer
test voice translation-rule <number> <string> type <type> plan <plan>

Classe vocale e164-translation

La fonction de traduction vocale de classe e164 est une nouvelle fonction de Cisco IOS XE qui permet à un administrateur de créer une liste d'instructions de correspondance et de modifier les instructions à charger via un fichier de configuration à partir de la mémoire flash ou d'un répertoire réseau. Ceci est similaire au concept de la fonctionnalité e164-pattern-map présenté dans ce document. Cela permet à un administrateur de configurer jusqu'à 100 traductions dans un fichier de configuration et de les appliquer dans un seul profil de traduction. Pour plus d'informations, reportez-vous au document Cisco IOS Voice Command Reference

Respectez la syntaxe suivante pour le fichier .cfg :

pattern1_to_be_matched<tab>replaced_pattern<space><enter>
pattern1_to_be_matched<tab>replaced_pattern<space><enter>

Remarque : l'espace de fin est très important et l'importation peut échouer sans cette étape de mise en forme supplémentaire.

Exemple.cfg

+111111	8897 
+222222	8312 
928747	+123456789 
737362	+987654321 

Ce fichier fait alors référence comme suit :

voice class e164-translation 164
 url ftp://username:password@10.10.10.10/sample.cfg

Maintenant, vous appliquez normalement à un profil de traduction, puis à partir de là, vous appliquez aux terminaux de numérotation dial-peer en utilisant la syntaxe de profil de traduction normale.

voice translation-profile e164
 translate calling voice-class e164-translation 164
 translate called voice-class e164-translation 164

La commande show voice class e164-translation e164-translation-number peut être utilisée pour afficher le contenu du profil de traduction.

Manipulation de chiffres via des cartes RNIS

Les cartes RNIS sont une technique plus ancienne de modification des chiffres. Cette fonctionnalité a été ajoutée dans Cisco IOS 12.0(6)T et la plupart des nouvelles configurations n'utilisent pas cette fonctionnalité car elles ne sont pas aussi robustes que les règles et profils de traduction vocale. Les cartes RNIS sont définies sous l’interface série.

Exemple de configuration

Serial0/0/0:23
 isdn map address ^911 plan isdn type unknown
 isdn map address ^1.......... plan isdn type national
 isdn map address ^2......... plan isdn type national
 isdn map address ^3......... plan isdn type national
 isdn map address ^4......... plan isdn type national
 isdn map address ^5......... plan isdn type national
 isdn map address ^6......... plan isdn type national
 isdn map address ^7......... plan isdn type national
 isdn map address ^8......... plan isdn type national
 isdn map address ^9......... plan isdn type national

Manipulation de chiffres par extension de numéro (num-exp)

Comme les cartes RNIS, l'extension de numéro est une technique plus ancienne ajoutée à Cisco IOS 11.3(1)T et peu utilisée dans les nouveaux réseaux. Cette fonctionnalité a été ajoutée avant que les règles et profils de traduction vocale n'existent. L'extension de numéro est un changement global de chiffres appliqué à tous les terminaux de numérotation dial-peer sur une passerelle Cisco. La modification est appliquée au numéro appelé après la mise en correspondance du terminal de numérotation dial-peer et juste avant l'envoi de l'appel au prochain agent d'appel.

Exemple de configuration

num-exp 4... 18005554...
num-exp 1234 8675309

Profils SIP entrants/sortants

Les profils SIP sont de solides instructions de correspondance d'expression régulière (regex) qui permettent à un administrateur de modifier n'importe quel aspect d'un message SIP qui inclut des en-têtes SDP et SIP. Ils peuvent être activés globalement, par terminal de numérotation dial-peer ou par locataire. Les profils SIP sont disponibles pour les modifications entrantes à partir de Cisco IOS 15.4(2)T et Cisco IOS XE 3.12S . Les profils SIP étant très robustes, ce document ne couvre que quelques exemples spécifiques. Les profils SIP permettent également de modifier ou d'ajouter des en-têtes SIP personnalisés dans IOS 15.5(2)T et IOS-XE 3.13S.

Points clés concernant les profils SIP entrants et sortants

• Les profils SIP entrants modifient le message AVANT que le CUBE ne traite le message pour le routage des appels.
• Les profils SIP sortants modifient le message APRÈS que le CUBE a traité le routage des appels et avant que le message ne soit envoyé au saut suivant.

Autres remarques sur la configuration sip-profile : 

• Les profils SIP ne peuvent pas manipuler les attributs m=image SDP. L'amélioration pour cela a été enregistrée sous l'ID de bogue Cisco CSCsr20474  De plus, les profils SIP ne peuvent pas supprimer ou ajouter des valeurs à SDP. Vous seul pouvez modifier ces valeurs. Cependant, il est possible de modifier une valeur SDP en une valeur nulle en spécifiant la valeur entière, puis en définissant la sortie sur un ensemble de guillemets vides sans espace.
• Aucune vérification n'est effectuée pour voir si la commande en cours d'entrée existe déjà ou si une version de cette commande existe déjà lors de l'entrée de commandes dans voice class sip-profile. Si un administrateur colle une ligne 7 fois dans un profil sip, il affiche 7 fois dans la configuration en cours. Il est conseillé de supprimer la commande en cours de modification, puis d'entrer la nouvelle commande lors de l'édition des profils SIP afin d'éviter la présence de plusieurs commandes.

Documentation complète : Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 et versions ultérieures

Outil de test de profil SIP : Outil de test de profil SIP

Exemple de syntaxe de profil SIP entrant/sortant

!
voice class sip-profiles <number>
 request <message-type> sip-header <header> modify "match-pattern" "replace-pattern"
 request <message-type> sip-header <header> add "add-pattern"
 request <message-type> sip-header <header> remove 

 request <message-type> sdp-header <header> modify "match-pattern" "replace-pattern"
 request <message-type> sdp-header <header> add "add-pattern"
 request <message-type> sdp-header <header> remove

 response <number> sip-header <header> modify "match-pattern" "replace-pattern"
 response <number> sip-header <header> add "add-pattern"
 response <number> sip-header <header> remove

 response <number> sdp-header <header> modify "match-pattern" "replace-pattern"
 response <number> sdp-header <header> add "add-pattern"
 response <number> sdp-header <header> remove
!

Exemple de profil SIP entrant/sortant avec des numéros

voice class sip-profiles 200
 rule 1 response ANY sip-header Remote-Party-ID modify "match-pattern" "replace-pattern"
 rule 2 response ANY sdp-header Audio-Attribute modify "match-pattern" "replace-pattern"

Méthodes d'application Profil SIP sortant

! Global Application 
voice service voip
 sip
  sip-profiles <number>
!
! Tenant Application
voice class tenant <tag>
 sip-profiles <tag>
!
! Dial-peer Application
dial-peer voice <tag> voip
 voice-class sip profiles <number>
!

Méthodes d'application Profil SIP entrant

Remarque : il est nécessaire d'activer sip-profile inbound sous voice service voip sip, que l'application globale, le service partagé ou l'application dial-peer soit utilisée.

! Global Application 
voice service voip
 sip
  sip-profiles inbound
  sip-profiles <number> inbound
!

! Tenant Application
voice service voip
 sip
  sip-profiles inbound
!
voice class tenant <tag>
 sip-profiles <tag> inbound
!

! Dial-Peer Application
voice service voip
 sip
  sip-profiles inbound
!
dial-peer voice <tag> voip
 voice-class sip profiles <number> inbound
!

Exemple de profil SIP pour modifier les messages de test d'activité OPTIONS.

!
voice class sip-options-keepalive 200
 transport tcp tls
 sip-profiles 299
!

Exemple de profil SIP pour modifier l'hôte, le domaine ou les deux parties d'un URI.

! Host
!
voice class sip-profiles 1
 request ANY sip-header Contact modify "sip:(.*)@" "sip:8675309@"
!
! Domain
!
voice class sip-profiles 2
 request ANY sip-header Contact modify "10.67.138.241:5060" "cisco.com"
!
! Note: Port is optional
!
! Modify Both User and Host
!
voice class sip-profiles 3
 request ANY sip-header Contact modify "sip:(.*)>" "sip:8675309@cisco.com>"
!

Exemple de profil SIP pour ajouter, modifier ou supprimer des en-têtes de déviation.

! Add
!
voice class sip-profiles 777
 request INVITE sip-header Diversion add "Diversion: <sip:1234@cisco.com>"
!
!
! Modify
!
voice class sip-profiles 888
 request INVITE sip-header Diversion modify "sip:(.*)>" "sip:1234@cisco.com>"
!
!
! Remove
!
voice class sip-profiles 999
 request INVITE sip-header Diversion remove
!

Exemple de profil SIP pour modifier la partie Nom de l'ID appelant des en-têtes SIP.

!
voice class sip-profiles 123
 request INVITE sip-header From modify "\".*\"" "\"TEST CLID*\""
!

Exemple de profil SIP pour remplacer une session 183 en cours par une sonnerie 180.

!
voice class sip-profiles 789
 response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session in Progress" "SIP/2.0 180 Ringing"
!

Exemple de profil SIP pour une interopérabilité audio unidirectionnelle ou non avec un fournisseur.

!
voice class sip-profiles 200
 request ANY sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv"
 request ANY sdp-header Audio-Connection-Info modify "0.0.0.0" "10.10.10.10" 
!
! where 10.10.10.10 is CUBE's provider facing IP address

Exemple de profil SIP pour supprimer la méthode UPDATE pour les problèmes d'interopérabilité.

!
voice class sip-profiles 200
 request ANY sip-header Allow-Header modify ", UPDATE" ""
!

Exemple de profil SIP montrant l'utilisation de SET dans le profil SIP. Il s'agit du même concept d'ensembles décrit dans la section voice translation-rule.

!
voice class sip-profiles 1
 request ANY sip-header Contact modify "sip:(.*)@" "sip:\1@"
!

Configuration de la logique IF et des sauts de ligne avec un profil SIP.

Les sauts de nouvelle ligne sont pris en charge dans les profils SIP, mais il n'existe qu'un cas d'utilisation très spécifique pour ces profils. Puisque les profils SIP n'ont aucune logique If, Then, Else, il est maintenant possible d'apporter des modifications à un en-tête en fonction d'une entrée d'un autre en-tête. Par exemple, un administrateur ne souhaite modifier un en-tête de dérivation que si l'en-tête FROM contient 1234@cisco.com. En utilisant le saut de nouvelle ligne, nous pouvons usurper l'instruction IF dans un profil SIP. Reportez-vous à l'exemple de configuration : vous faites correspondre 1234 à n'importe quel domaine dans l'en-tête From. Ensuite, vous placez le curseur sur le premier ensemble et ajoutez un nouveau saut de ligne \x0D\x0AD. Enfin, vous ajoutez l'en-tête souhaité. Cette méthode vous permet uniquement d'AJOUTER un en-tête. Il est impossible de modifier un autre en-tête. Cela ne répond donc qu'en partie aux exigences qu'un administrateur souhaitait atteindre précédemment.

!
voice class sip-profiles 1
 request INVITE sip-header From modify “(.*sip:1234@.*)” “\1\x0D\x0ADiversion: <sip:5678@example.com>”
!

Exemple de profil SIP avec logique OU.

!
voice class sip-profiles 123
 request ANY sdp-header Audio-Attribute modify "(a=sendonly|a=recvonly|a=inactive)" "a=sendrecv"
 response ANY sdp-header Audio-Attribute modify "(a=sendonly|a=recvonly|a=inactive)" "a=sendrecv"
!

Exemple d'inspection SIP de couche 7 via SIP-Profile.

### Usage
10.21.15.10 replace with private IP of CUBE
a.b.c.d replace with public IP
------------------------------------------------------

### Inbound from ITSP Layer 7 Fixup
!
voice class sip-profiles 888
 request INVITE sip-header SIP-Req-URI modify "@.*;" "@10.21.15.100;"
!
voice service voip
 sip
  sip-profiles inbound
!

### Outbound Layer 7 Fixup
!
voice class sip-profiles 777
 request ANY sip-header Contact modify "<sip:(.*)@10.21.15.100:5060>" "<sip:\1 a.b.c.d:5060>" 
 response ANY sip-header Contact modify "<sip:(.*)@10.21.15.100:5060>" "<sip:\1 a.b.c.d:5060>" 
 request ANY sip-header Via modify "SIP(.*) 10.21.15.100(.*)" "SIP\1 a.b.c.d\2" 
 request ANY sdp-header Session-Owner modify "(.*IP4 ).*" "\1a.b.c.d" 
 request ANY sdp-header Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" 
 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" 
 response ANY sdp-header Session-Owner modify "(.*IP4 ).*" "\1a.b.c.d" 
 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" 
 response ANY sdp-header Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d"
 request ANY sip-header Remote-Party-ID modify "<sip:(.*)@10.21.15.100>" "<sip:\1 a.b.c.d>" 
 response ANY sip-header Remote-Party-ID modify "<sip:(.*)@10.21.15.100>" "<sip:\1 a.b.c.d>"
!

### Apply to dial-peers for the side of the CUBE facing the ITSP
!
dial-peer voice 1 voip
 voice-class sip profiles 777
 voice-class sip profile 888 inbound
!
dial-peer voice 2 voip
 voice-class sip profiles 777
 voice-class sip profile 888 inbound
!

Liste de copie SIP

Les listes de copies SIP sont une extension des profils SIP qui permet à la passerelle de COPIER un en-tête à partir du segment entrant d'un appel, puis de COLLER vers un autre emplacement du message SIP de sortie sur le segment sortant. La prise en charge de la liste de copie SIP a été ajoutée dans Cisco IOS 15.1(3)T et Cisco IOS XE 3.6S. Il s'agit d'une méthode très efficace de création d'en-têtes dynamiques basés sur d'autres en-têtes du segment de l'appel.

Le cas d'utilisation le plus courant est la copie dynamique d'un en-tête FROM vers un en-tête différent comme dérivation ou p-asserted-id de sorte que la valeur de la partie utilisateur est l'utilisateur FROM. Cette opération est principalement effectuée à des fins d'authentification et d'identification de l'appelant.

Documentation complète : Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 et versions ultérieures

Exemple de liste de copie SIP

!
! Create Copylist to copy the FROM header on the inbound message specified later.
!
voice class sip-copylist <number>
 sip-header From
!
! Apply this to the inbound dial-peer of the call.
!
dial-peer voice <tag> voip
 voice-class sip copy-list <number>
!
! Create SIP Profile to take From (peer-header) stored as variable "u01" and apply to a header of choice.
! This example modifies the user portion of the Contact by copying the user portion of the From header to the user portion of the Contact header.
!
voice class sip-profiles <number>
 request INVITE peer-header sip From copy "<sip:(.*)@" u01
 request INVITE sip-header Contact modify "<sip:(.*)>" "<sip:\u01@10.50.244.2>" 
!
! Apply the SIP profile to an outbound dial-peer
!
dial-peer voice <tag> voip
 voice-class sip profiles <number>
!

Débogage des profils SIP et de la liste de copie

debug voip ccapi inout
debug ccsip mess
debug ccsip info
debug ccsip feature sip-profile 

Sortie de débogage de l'exemple de liste de copie SIP

### Ingress from CUCM
Received:
INVITE sip:1001@10.50.228.61:5060 SIP/2.0
Via: SIP/2.0/TCP 10.50.244.3:5060;branch=z9hG4bKaad21bc3ae7e
From: "5001" <sip:5001@10.50.244.3>;tag=100442~cdffff43-5020-4e79-a10b-99d406971010-36470319
Contact: <sip:5001@10.50.244.3:5060;transport=tcp>

### Copylist Details
00440: Mar  8 18:59:49.796: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: sed_match succeeded
000441: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variables AVL tree created
000442: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_prefix_slash_in_copy_var_val: ret_dst: 5001
000443: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variable: u1 val: 5001
000444: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header before modification : Contact: <sip:5001@10.50.228.61:5060>
000445: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Node found: COPY variable: u1 val: 5001
000446: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: substituted_replace_pattern :  : @168.117.64.94>
000448: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Final substituted_replace_pattern : <sip:5001@168.117.64.94>
000449: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_app_modify_header: Passing substituted replace pattern
000450: Mar  8 18:59:49.798: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header after modification : Contact: <sip:5001@168.117.64.94>
000451: Mar  8 18:59:49.798: //187/D6138E000000/SIP/Msg/ccsipDisplayMsg:

### Egress from CUBE
Sent:
INVITE sip:1001@14.50.228.63:5060 SIP/2.0
Via: SIP/2.0/UDP 10.50.228.61:5060;branch=z9hG4bK3C7CD
Remote-Party-ID: "5001" <sip:5001@10.50.228.61>;party=calling;screen=yes;privacy=off
From: "5001" <sip:5001@10.50.228.61>;tag=34C458-D6
Contact: <sip:5001@168.117.64.94>

Remarques spéciales

Signalisation de protocole et liaison de support

Tous les protocoles de signalisation permettent aux administrateurs de lier la signalisation à une interface spécifique. Par défaut, une passerelle sans liaison statique définie génère la signalisation d'un appel à partir de l'interface physique traversée par le paquet. Avec la liaison sur un terminal de numérotation dial-peer, le paquet comporte des en-têtes source, des messages et des paquets provenant de l'interface spécifiée, mais le paquet réel est toujours routé sur l'interface physique. La liaison de terminal de numérotation dial-peer remplace toujours la liaison vocale de locataire de classe et de service vocal global avec le protocole SIP (Session Initiation Protocol).

Souvent, les administrateurs lient la signalisation à une boucle. Étant une interface logique, aucun paquet ne traverse cette interface. Pour effectuer des captures de paquets, la capture doit être effectuée sur une interface physique. La commande show ip cef <remote-ip> affiche l'interface physique qu'un paquet utilise pour acheminer vers l'adresse IP de destination / distante même si la configuration est liée à une interface virtuelle.

La liaison de support et de signalisation ne doit pas toujours être la même adresse IP. Si un administrateur a besoin de se lier à une interface spécifique pour la signalisation vers / depuis un CUCM, mais que l'audio / le média entre le téléphone et la passerelle peut avoir besoin de se lier à une autre interface.

Exemple de configuration

Cet exemple montre un terminal de numérotation dial-peer lié au bouclage 1 et il reçoit un appel de CUCM.

Même si le support et la signalisation (contrôle) sont liés au bouclage 1, la commande show ip cef montre que tous les paquets envoyés à CUCM quittent l'interface physique GigabitEthernet0/0/1.

!
dial-peer voice 2 voip
 description "Incoming call from CUCM"
 session protocol sipv2
 incoming called-number .
 voice-class sip bind control source-interface Loopback1
 voice-class sip bind media source-interface Loopback1
!

Ordre des opérations pour la liaison des applications de couche 7

1. Selon l'instruction bind sur le terminal de numérotation dial-peer entrant/sortant correspondant.
2. En fonction des liaisons sous le locataire de classe vocale affecté au terminal de numérotation dial-peer entrant/sortant correspondant.
3. Selon la déclaration de liaison globale.
4. En fonction de l’interface de couche physique 3, le paquet est supposé quitter sur la base de la table de routage.

Commandes de liaison SIP

! Per Dial-peer
!
dial-peer voice 1 voip
 voice-class sip bind control source-interface <interface>
 voice-class sip bind media source-interface <interface>
!
! Global Binding
!
voice service voip
 sip
   bind control source-interface <interface>
   bind media source-interface <interface>
!

Commandes de liaison MGCP

!
mgcp bind control source-interface <interface>
mgcp bind media source-interface <interface>
!

Commandes de liaison SCCP

!
sccp local <interface>
!
sccp ccm group <number>
 bind interface <interface>
!

Commandes de liaison H323

!
inteface <interface>
 !
 ! Media Bind Command:
 h323-gateway voip interface
 !
 ! Signaling Bind Command:
 h323-gateway voip bind srcaddr <a.b.c.d>
!

Homologues de numérotation DNS et VoIP

DNS avec VOIP est utilisé comme toute autre solution DNS. Une configuration courante consiste à utiliser la cible de session dns:FQDN.com.

Une passerelle Cisco exécute une résolution DNS même si aucune recherche de domaine IP n'est configurée globalement sur la passerelle. Cela signifie que même si vous désactivez DNS, les terminaux de numérotation dial-peer VOIP résolvent toujours l'entrée DNS. Cependant, récemment, dans Cisco IOS XE 3.16S, certaines modifications ont été apportées à la fonctionnalité DNS globale au sein des plates-formes Cisco IOS XE.

Après cette modification, les terminaux de numérotation dial-peer configurés avec la cible de session dns:FQDN.com obéissent maintenant au fait que DNS est désactivé sans recherche de domaine IP.
Je recommande de toujours vérifier que la commande « ip domain lookup » est configurée lorsque vous travaillez avec DNS pour éviter ce problème.

Pour les connexions SIP sortantes, CUBE effectue cet ordre d'opérations pour la résolution DNS.

1. Recherche de requête SRV
2. Recherche d'enregistrement
3. Recherche d'enregistrement AAAA

Pour plus d'informations sur la façon dont le SRV est créé, ou comment ignorer le SRV et exécuter une requête d'enregistrement A sur une cible de session, référez-vous à la documentation complète : Guide de configuration de Cisco Unified Border Element - Cisco IOS XE 17.6 Onwards

Pour les connexions SIP entrantes où une passerelle IOS doit résoudre un en-tête pour répondre à un message, la passerelle peut utiliser cet ordre d'opérations pour la résolution DNS

1. Recherche d'enregistrement
2. Recherche d'enregistrement AAAA

Dans Cisco IOS XE 17.9.1, CUBE peut vérifier l'accessibilité des cibles de session DNS au moyen des mécanismes de test d'activité des options. Voir la documentation complète :

Guide de configuration de Cisco Unified Border Element - Cisco IOS XE 17.6 et versions ultérieures

Exemples de configuration IOS DNS

ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm1.lab.local
ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm2.lab.local
ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm3.lab.local

ip host cucm1.lab.local 10.0.0.1
ip host cucm2.lab.local 10.0.0.2
ip host cucm3.lab.local 10.0.0.3

ip domain name lab.local
ip name-server 8.8.8.8

Remarque : la prise en charge de DNS SRV sur Cisco IOS XE est prise en charge sur 15.6(1)S / 3.17.00.S et versions ultérieures.

Commandes de débogage et de vérification DNS

show host
clear host all *
!
debug ip dns view
debug ip domain
debug ccsip info
debug ccsip error

Test DNS 3.15S et versions ultérieures

### Domain Name Verification
Gateway# sh run | s lookup
no ip domain lookup

### Checking the host table for no entry
Gateway# show host
Name lookup view: Global
Default domain is cisco.com
Name/address lookup uses static mappings

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
       temp - temporary, perm - permanent
       NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)

### Verification of no PING on a FQDN
Gateway# ping cucm.cisco.com
Translating "cucm.cisco.com"
% Unrecognized host or address, or protocol not running.

### Made a test call here

### Checking logs to see if it worked
Gateway# sh log | s INVITE sip:
INVITE sip:9001@14.50.228.70:5060 SIP/2.0
INVITE sip:5001@cucm.cisco.com:5060 SIP/2.0

### Host Table now has an entry
Gateway# sh host
Name lookup view: Global
Default domain is cisco.com
Name/address lookup uses static mappings

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
       temp - temporary, perm - permanent
       NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)
cucm.cisco.com            None  (temp, OK)  0   IP    10.50.244.2

### CCSIP All output showing a proper DNS Query for the FQDN on the dial-peer.
001338: Mar  9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FE9873AE560
001339: Mar  9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1
001340: Mar  9 15:29:07.438: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1
001341: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_a_query: TYPE A query successful for cucm.cisco.com
001342: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_query: ttl for A records = 3600 seconds
001343: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: IP Address of cucm.cisco.com is:
001344: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: 10.50.244.2

Test DNS 3.16S et versions ultérieures.

### Checking the command is present
Gateway# sh run | s lookup
no ip domain lookup

### Verifying the gateway cannot ping a FQDN
Gateway# ping cucm.cisco.com
% Unrecognized host or address, or protocol not running.

### Checking the Host Table for entries
Gateway# sh host
Default domain is cisco.com
Name servers are 10.50.244.52
NAME  TTL  CLASS   TYPE      DATA/ADDRESS
-----------------------------------------

### Made a test call here

### CCSIP All Outbound showing the failed call
000974: *Mar  9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FF31DAAA848
000975: *Mar  9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1
000976: *Mar  9 15:53:01.224: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1
000977: *Mar  9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query:
 TYPE A query failed for cucm.cisco.com
000978: *Mar  9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/_send_dns_fail:
 DNS Query for cucm.cisco.com failed
000984: *Mar  9 20:53:01.225: %VOICE_IEC-3-GW: SIP: Internal Error (DNS query fail): IEC=10.1.128.7.47.0 on callID 6 GUID=37B668DF044111E7A950D832C82B325C

Nombre maximal de connexions et bande passante

Par défaut, les terminaux de numérotation dial-peer VOIP et POTS autorisent des connexions (appels) et une bande passante illimitées (terminaux de numérotation dial-peer VOIP uniquement). Pour les agrégations qui ont une limite sur le nombre d'appels ou la bande passante qui peuvent être utilisés, il peut être utile d'employer les commandes max-conn ou max-bandwidth. max-conn a été ajouté dans Cisco IOS 11.3(1)T et est présent dans toutes les versions de Cisco IOS XE tandis que max-bandwidth a été ajouté dans 15.2(2)T et IOS-XE 3.7S.

Exemple de configuration :

Ici, vous indiquez à la passerelle de limiter les appels du terminal de numérotation dial-peer 1 à 30 en utilisant « max-conn 30 ».
Le terminal de numérotation dial-peer 2 limite la bande passante pour ce terminal de numérotation dial-peer afin de ne pas dépasser la limite allouée.

!
dial-peer voice 1 voip
 description ITSP SIP Trunk - 30 Max Calls!
 session protocol sipv2
 sess target ipv4:10.10.10.10
 destination-pattern 8675309$
 max-conn 30
!
dial-peer voice 2 voip
 description SIP Trunk with Bandwidth Restrictions!
 session protocol sipv2
 sess target ipv4:10.10.10.10
 destination-pattern 123456789$
 max-bandwidth 400
!

Exemple d'erreur lorsque le seuil max-conn est dépassé.

000308: Oct  5 19:01:02.603: %CALL_CONTROL-6-MAX_CONNECTIONS: Maximum number of connections reached for dial-peer 1
 
000309: Oct  5 19:01:02.603: %VOICE_IEC-3-GW: CCAPI: Internal Error (Dial-peer connections exceeded): IEC=10.1.181.1.21.0 on callID 0
000310: Oct  5 19:01:02.604: %SIP-3-MAXCONNCAC: Call rejected due to CAC based on maximum number of connections on dial-peer 1, sent response 503

000311: Oct  5 19:01:02.604: //17084/86B070800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TCP 10.50.244.62:5060;branch=z9hG4bKb78c35aa21b0
From: <sip:9001@10.50.244.62>;tag=72531~2e8ca155-3f0b-4f07-a1b2-b14ef77ceb7f-26250846
To: <sip:1234@10.50.245.70>;tag=3E19564D-1684
Date: Thu, 05 Oct 2017 19:01:02 GMT
Call-ID: 86b07080-9d61816e-b762-3ef4320e@10.50.244.62
CSeq: 101 INVITE
Allow-Events: telephone-event
Warning: 399 10.50.245.70 "Maximum Number of Connections reached for dial-peer 1"
Server: Cisco-SIPGateway/IOS-15.4.3.S4
Content-Length: 0

Sélection directe à l'arrivée

Numérotation en une étape

Lorsque la numérotation entrante directe est activée sur les terminaux de numérotation dial-peer POTS, la messagerie entrante peut contenir tous les chiffres nécessaires pour acheminer l'appel. La passerelle Cisco ne peut pas procéder à la collecte de chiffres suivante. Lorsque le routeur ou la passerelle recherche un terminal de numérotation dial-peer sortant, le périphérique utilise l'intégralité de la chaîne de numérotation entrante. Cette mise en correspondance a une longueur variable par défaut. Cette mise en correspondance n'est pas effectuée par chiffre-par-chiffre parce que selon la définition du DID, tous les chiffres ont été reçues. Il s'agit de la configuration par défaut pour les terminaux de numérotation dial-peer POTS.

Documentation complète : Présentation du DID (Direct-Inward-Dial) sur les interfaces vocales numériques (T1/E1) IOS

Exemple de configuration

!
dial-peer voice 1 pots
 incoming called-number 8675309
 voice-port 0/0/0
 direct-inward-dial
!

Numérotation en deux étapes

Si le terminal de numérotation dial-peer POTS entrant est configuré avec aucune numérotation entrante directe, le routeur ou la passerelle passe en mode de collecte de chiffres (les chiffres sont collectés en bande). La mise en correspondance de terminal de numérotation dial-peer sortant s'effectue chiffre par chiffre. Le routeur ou la passerelle recherche les correspondances de terminal de numérotation dial-peer une fois que le périphérique a reçu chaque chiffre, puis achemine l'appel lorsqu'une correspondance complète est établie.

Exemple de configuration

!
dial-peer voice 1 pots
 incoming called-number 8675309
 voice-port 0/0/0
 no direct-inward-dial
!

Blocage des appels

Chaque protocole gère le blocage des appels différemment. La plupart des protocoles peuvent utiliser le modèle de rejet de règle de traduction qui bloque en fonction d'une chaîne de chiffres. Si un administrateur veut toujours appliquer un profil de traduction entrant pour la manipulation normale de chiffres, mais ne bloque aucun numéro dans, il y a une option d'implémentation d'un bloc d'appel à l'aide de la commande call-block translation-profile.

!
voice translation-rule 164
 rule 1 reject /8675309/
!
voice translation-profile CALLBLOCK
 translate calling 164
!
dial-peer voice 1 pots
 desc INCOMING VOICE-PORT with BLOCK
 translation-profile incoming ANOTHER
 call-block translation-profile incoming CALLBLOCK
 call-block disconnect-cause incoming invalid-number
 incoming called-number .
 port 0/0/0:23
!

Gateway#test voice translation-rule 164 8675309
8675309 blocked on rule 1

Dans E1 R2, un administrateur peut bloquer les appels de collecte. Ceci est principalement vu et employé dans les déploiements au Brésil, mais peut être configuré via n'importe quel groupe cas-custom.

Les deux options sont les suivantes :

1. Bloquez l'appel en PCV entrant en fonction de la catégorie II-8 reçue du commutateur de l'opérateur téléphonique. Il s'agit du mécanisme par défaut et toutes les passerelles Cisco le font sans aucune configuration. Cette méthode de blocage nécessite un commutateur Telco plus récent qui prend en charge le marquage basé sur la catégorie. Pour désactiver cette méthode, utilisez la commande collect-call-enable sur le groupe cas-customer.
2. Utilisez la fonction double réponse sur un groupe personnalisé de cas R2-digital E1 R2. La configuration à double réponse désactive le blocage par catégorie et la remplace par la fonctionnalité de double réponse. Cela fonctionne en répondant d'abord à l'appel entrant et en démarrant un minuteur de 1 seconde. Au bout d'une seconde, la passerelle envoie une libération sous la forme d'une commande CLEAR BWD. L'opérateur téléphonique peut alors envoyer un message CLEAR FWD à la passerelle et l'appel peut être déconnecté. Un compteur démarre après que la passerelle a envoyé le message CLEAR BWD, et si ce compteur expire, la passerelle envoie un autre signal ANSWER, supposant ainsi que l'appel n'est pas un appel à frais virés et que l'appel se poursuit normalement. Ce minuteur peut être configuré à l'aide de cc-reanswer-to dans le groupe cas-custom.

Catégorie II-8 Bloquer le message (debug vpm signal)

009228: Nov 21 12:02:00.955 GMT: //-1/BF12BE36BAC8/VTSP:(0/0/0:0):-1:1:2/vtsp_report_cas_digit: 
   Begin Digit=8, Mode=CC_TONE_R2_MF_BACKWARD_MODE
009229: Nov 21 12:02:00.955 GMT: htsp_digit_ready_up(0/0/0:0(2)): Rx digit='8'
009230: Nov 21 12:02:00.955 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event 8
009231: Nov 21 12:02:00.955 GMT: Enter r2_comp_category
009232: Nov 21 12:02:00.955 GMT:  R2 Event : 8
009233: Nov 21 12:02:00.955 GMT:  #######R2_II8 TRUE########
009234: Nov 21 12:02:00.955 GMT:  ####### collect_call_enable = 0
009235: Nov 21 12:02:00.955 GMT:  ############sending B7 ##########
009236: Nov 21 12:02:00.955 GMT: r2_reg_generate_digits(0/0/0:0(2)): Tx digit '7'
009237: Nov 21 12:02:01.055 GMT: //-1/BF12BE36BAC8/VTSP:(0/0/0:0):-1:1:2/vtsp_report_cas_digit: 
   End Digit=8, Mode=CC_TONE_R2_MF_BACKWARD_MODE
009238: Nov 21 12:02:01.055 GMT: htsp_digit_ready(0/0/0:0(2)): Rx digit='#'
009239: Nov 21 12:02:01.055 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event R2_TONE_OFF
009240: Nov 21 12:02:01.055 GMT: Enter r2_comp_category
009241: Nov 21 12:02:01.055 GMT: r2_reg_generate_digits(0/0/0:0(2)): Tx digit '#'
009242: Nov 21 12:02:01.359 GMT: htsp_dsp_message: SEND_SIG_STATUS: state=0x8 timestamp=22365 systime=225097425
009243: Nov 21 12:02:01.359 GMT: htsp_process_event: [0/0/0:0(2), R2_Q421_IC_WAIT_ANSWER, E_DSP_SIG_1000]
009244: Nov 21 12:02:01.359 GMT: r2_q421_ic_clr_fwd_idle(0/0/0:0(2)) Rx CLEAR FWD
009245: Nov 21 12:02:01.359 GMT: r2_reg_channel_disconnected(0/0/0:0(2))
009246: Nov 21 12:02:01.359 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event R2_STOP
009247: Nov 21 12:02:01.359 GMT: Enter r2_comp_category
009248: Nov 21 12:02:01.359 GMT: htsp_timer - 2000 msec
009249: Nov 21 12:02:01.359 GMT: htsp_process_event: [0/0/0:0(2), R2_Q421_IC_CLR_FWD, E_HTSP_RELEASE_REQ]
009250: Nov 21 12:02:01.359 GMT: r2_q421_null_release(0/0/0:0(2)) E_HTSP_RELEASE_REQ
009251: Nov 21 12:02:01.359 GMT: r2_reg_process_event: [0/0/0:0(2), R2_REG_COLLECTING, E_R2_REG_DISCONNECT(91)]
009252: Nov 21 12:02:01.359 GMT: r2_reg_disconnect_collect(0/0/0:0(2))
009253: Nov 21 12:02:01.359 GMT: r2_reg_timer_stop(0/0/0:0(2))
009254: Nov 21 12:02:01.711 GMT: htsp_process_event: [0/0/0:0(1), R2_Q421_IC_CLR_FWD, E_HTSP_EVENT_TIMER]
009255: Nov 21 12:02:01.711 GMT: htsp_timer_stop
009256: Nov 21 12:02:01.711 GMT: r2_q421_clr_fwd_idle(0/0/0:0(1)) Tx IDLEvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(1)] set signal state = 0x8
009257: Nov 21 12:02:01.711 GMT: r2_reg_channel_disconnected(0/0/0:0(1))
009258: Nov 21 12:02:01.711 GMT: //682206/0C63B263B9C9/VTSP:(0/0/0:0):0:1:1/vtsp_do_call_history: 
   Coder Rate=5
009259: Nov 21 12:02:01.711 GMT: r2_reg_process_event: [0/0/0:0(1), R2_REG_IDLE, E_R2_REG_DISCONNECT(91)]

Exemple de configuration de la double réponse

!
controller e1 0/0/0
 ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani
 cas-custom 0
  country brazil
  double-answer
  cc-reanswer-to 3000
!

Double-Answer Debugs (signal debug vpm)

### Answer the call and start a 1 second timer
May 23 09:52:59.180 BR: r2_q421_ic_answer(0/0/0:0(18)) Tx ANSWER seizure: delay 0 ms,elapsed 12404 msvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(18)] set signal state = 0x4
May 23 09:52:59.180 BR: r2_reg_channel_connected(0/0/0:0(18))
May 23 09:52:59.180 BR: htsp_timer - 1000 msec
May 23 09:52:59.180 BR: //23899578/92233E71B421/CCAPI/cc_api_voice_mode_event:
   Call Id=23899578
May 23 09:52:59.180 BR: //23899578/92233E71B421/CCAPI/cc_api_voice_mode_event:
   Call Entry(Context=0x1E73AD8)
May 23 09:52:59.180 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_ANS, E_HTSP_VOICE_CUT_THROUGH] all
May 23 09:52:59.184 BR: //23899578/92233E71B421/CCAPI/cc_process_notify_bridge_done:
   Conference Id=0x10AD1, Call Id1=23899578, Call Id2=23899579
May 23 09:52:59.184 BR: r2_reg_process_event: [0/0/0:0(18), R2_REG_WAIT_FOR_CONNECT, E_R2_REG_CONNECT(90)] 
May 23 09:52:59.184 BR: r2_reg_connect(0/0/0:0(18))

### One Second Passes and we clear the call and start a 2 second timer
May 23 09:53:00.180 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_ANS, E_HTSP_EVENT_TIMER]
May 23 09:53:00.180 BR: r2_q421_ic_d_answ_answ_to(0/0/0:0(18)) E_TIMER_EVENT
May 23 09:53:00.180 BR: htsp_timer - 2000 msec
May 23 09:53:00.180 BR: r2_q421_ic_d_answ_answ_to(0/0/0:0(18)) Tx CLEAR BWDvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(18)] set signal state = 0xC
May 23 09:53:00.824 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_RLS, E_DSP_SIG_1000]
May 23 09:53:00.824 BR: r2_q421_ic_answer_clr_fwd(0/0/0:0(18)) Rx CLEAR FWD
May 23 09:53:00.824 BR: r2_reg_channel_disconnected(0/0/0:0(18))
May 23 09:53:00.824 BR: htsp_timer - 2000 msec
May 23 09:53:00.824 BR: r2_reg_process_event: [0/0/0:0(18), R2_REG_CONNECTED, E_R2_REG_DISCONNECT(91)] 
May 23 09:53:00.824 BR: r2_reg_disconnect_idle(0/0/0:0(18))
May 23 09:53:00.824 BR: R2 Incoming Voice(0/0): DSX (E1 0/0/0:17): STATE: R2_IN_IDLE R2 Got Event R2_STOP
May 23 09:53:00.824 BR: r2_reg_timer_stop(0/0/0:0(18))

### 2 second passes and the gateway release the call
May 23 09:53:02.824 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_CLR_FWD, E_HTSP_EVENT_TIMER]
May 23 09:53:02.824 BR: htsp_timer_stop 
May 23 09:53:02.824 BR: r2_reg_channel_disconnected(0/0/0:0(18))
May 23 09:53:02.824 BR: //23899578/92233E71B421/VTSP:(0/0/0:0):17:1:1/vtsp_cc_call_disconnected:  
   Cause Value=16
May 23 09:53:02.824 BR: //23899578/92233E71B421/CCAPI/cc_api_call_disconnected:
   Cause Value=16, Interface=0xB41CEBC, Call Id=23899578

réception avec chevauchement RNIS

Il y a des implications pour la correspondance dial-peer entrante quand la commande isdn overpeer-receive est configurée sur les interfaces RNIS. Une fois que chaque chiffre est reçu au niveau de la couche RNIS, les terminaux de numérotation dial-peer sont vérifiés pour rechercher des correspondances. Si une correspondance complète est établie, l'appel est conduit immédiatement (à l'application de session dans ce cas) sans attendre les chiffres supplémentaires. Le terminateur T peut être utilisé pour suspendre cette correspondance chiffre par chiffre et forcer le routeur ou la passerelle à attendre que tous les chiffres soient reçus. La lettre T fait référence au temporisateur interchiffre T302 au niveau RNIS, configurable sous l’interface série associée à l’interface RNIS. Le RNIS fournit également d'autres mécanismes pour indiquer l'extrémité des chiffres, tels que définir l'élément d'information complet l'envoyant (IE) dans des messages de l'information Q.931.

Numéro appelé vide

Le message d'avertissement affiché s'affiche lorsque le terminal de numérotation dial-peer est configuré avec le numéro appelé entrant T.

Exemple de sortie

Gateway(config)# dial-peer voice 1 pots
Gateway(config-dial-peer)# incoming called-number T
Warning: Pattern T defines a match with zero or more digits and hence could 
match with an empty number. If this is not the desired behaviour please 
configure pattern .T instead to match on one or more digits

Remarques spéciales sur la correspondance dial-peer entrante avec un numéro appelé vide.

• Un numéro appelé nul est considéré comme moins qualifié qu'un port vocal et/ou dans certains cas, une adresse de réponse. Par conséquent, une correspondance basée sur un numéro appelé nul ne peut se produire que s'il n'y a pas de correspondance basée sur l'adresse de réponse ou le numéro de port.

• En cas de numérotation avec chevauchement, un numéro appelé nul ne correspond pas au numéro appelé entrant T car aucun délai d'attente n'a été dépassé.

• Un numéro appelé nul ne peut correspondre au numéro appelé entrant T qu'en cas d'ENBLOCK et il n'y a aucune correspondance en raison de l'adresse de réponse et du numéro de port. L'avertissement affiché lorsqu'un administrateur configure le numéro appelé entrant T fait référence à ce cas spécifique.

Catégorie de restriction

La classe de restriction (COR) permet de limiter les appels sur une passerelle Cisco. COR est souvent décrit comme un mécanisme de serrure et de clé. Les verrous sont attribués aux terminaux de numérotation dial-peer avec une liste COR sortante. Les clés sont attribuées aux terminaux de numérotation dial-peer avec une liste COR entrante. Lorsque des listes COR sont appliquées, les terminaux de numérotation dial-peer sortants disponibles sont ceux que la clé peut déverrouiller. Ce filtrage se produit avant que le reste des méthodes de correspondance de terminal de numérotation dial-peer sortant ne soit vérifié.

Deux règles importantes avec la catégorie de restriction :

1. Si aucune liste COR sortante n'est appliquée, l'appel est toujours routé.
2. S'il n'y a pas de liste COR entrante, l'appel est toujours acheminé.

La configuration de la classe de restriction (COR), de la classe de restriction de partitionnement logique (LPCOR) et de la classe de restriction LPCOR avec codes d'autorisation forcée (FAC) sort du cadre de ce document, mais ces documents peuvent être référencés pour une lecture plus approfondie.

Homologues de numérotation Cisco Unified Communications Manager Express (CUCME)

CME crée des terminaux de numérotation dial-peer système pour les ephones et les pools d'enregistreurs vocaux. Elles ne sont pas visibles dans la configuration en cours. Pour apporter des modifications aux terminaux de numérotation dial-peer CME, vous devez effectuer ces modifications sur l'ephone ou le pool d'enregistreurs vocaux. Lorsque vous affichez les sorties de résumé vocal de show dial-peer, les terminaux de numérotation dial-peer commençant par 2000 sont des ephones SCCP et les terminaux de numérotation dial-peer commençant par 4000 sont des pools d'enregistrements vocaux SIP. Ce terminal de numérotation dial-peer apparaît comme terminal de numérotation dial-peer entrant pour les appels des téléphones enregistrés CME et comme terminal de numérotation dial-peer sortant dans les débogages pour les appels vers les téléphones enregistrés CME.

Exemple de sortie de show dial-peer voice summary avec CME.

Gateway# show dial-peer voice sum | s 2000|4000
20001  pots  up   up             1001$              0                           50/0/1
20002  pots  up   up             4001$              0                           50/0/2
20003  pots  up   up             4002$              0                           50/0/3
20004  pots  up   up             7001$              0                           50/0/4
20005  pots  up   up             3009$              0                           50/0/5
20006  pots  up   up             8810....$          0                           50/0/10
20007  pots  up   up             8811....$          0                           50/0/11
40001  voip  up   up             14085151111$       0  syst ipv4:14.50.214.67:50
40002  voip  up   up             19725252222$       0  syst ipv4:14.50.214.67:50
40003  voip  up   up             85225353333$       0  syst ipv4:14.50.214.67:50
40004  voip  up   up             442084445555$      0  syst ipv4:14.50.214.67:50
40005  voip  up   up             911$               0  syst ipv4:14.50.214.67:50
40006  voip  up   up             18005550100$       0  syst ipv4:14.50.214.67:50
40008  voip  up   up             2001$              0  syst ipv4:14.50.214.51:50

 Exemple de sortie pour show voice register dial-peer avec SIP CME.

Gateway# show voice register dial-peers
Dial-peers for Pool 2:

dial-peer voice 40006 voip
 destination-pattern 14085151111$
 session target ipv4:14.50.214.67:5060
 session protocol sipv2
 dtmf-relay rtp-nte
 digit collect kpml
 codec  g711ulaw bytes 160
 no vad
  call-fwd-all         8888
  after-hours-exempt   FALSE

dial-peer voice 40005 voip
 destination-pattern 19725252222$
 session target ipv4:14.50.214.67:5060
 session protocol sipv2
 dtmf-relay rtp-nte
 digit collect kpml
 codec  g711ulaw bytes 160
 no vad
  after-hours-exempt   FALSE

MGCP et SCCP avec terminaux de numérotation dial-peer

MGCP et SCCP suivent leurs propres règles pour les terminaux de numérotation dial-peer. Le seul concept qu'ils utilisent est qu'ils doivent être configurés avec le port vocal souhaité pour l'appel. Le reste est géré par les processus STCAPP et MGCPAPP. Lorsque vous examinez la configuration de ces terminaux de numérotation dial-peer, ils ont la commande service mgcpapp ou service stcapp. Ils activent le terminal de numérotation dial-peer pour l'application de votre choix et indiquent à l'application quel terminal de numérotation dial-peer il peut gérer.

Lors du débogage de ces protocoles, le résultat n'affiche jamais de correspondance de terminal de numérotation dial-peer entrant. Cela peut toujours apparaître comme dial-peer 0. Parce qu'il n'existe pas. L'agent d'appel qui gère l'application a déjà choisi le port auquel envoyer l'appel et la correspondance de terminal de numérotation dial-peer entrant est inutile, car la passerelle n'a aucun contrôle sur ce segment de l'appel. Cependant, une correspondance de terminal de numérotation dial-peer sortant peut être observée. Il s'agit simplement d'une commande show, car l'agent d'appel qui gère le processus contrôle également ce côté de l'appel.

N’oubliez pas que le terminal de numérotation dial-peer indique uniquement à l’application de votre choix le port vocal physique à contrôler. Comme la majorité de ces opérations est contrôlée par un agent d'appel externe et la passerelle, elle ne fait que ce qu'on lui dit. Vous allez ignorer la procédure sous-jacente de cette section et fournir quelques configurations pour commencer.

Exemple de configuration MGCP [avec configuration automatique CUCM*]

!
mgcp call-agent 10.10.10.10
mgcp
!
ccm-manager mgcp [codec-all]
ccm-manager config server 10.10.10.10
ccm-manager config
ccm-manger redundant-host 10.10.10.20
!
voice-port 0/0/0
 description The MGCP port to register
 no shut
!
dial-peer voice 1 pots
 description Defining the Port for the MGCP application
 service mgcpapp
 port 0/0/0
!
hostname myrouter
ip domain name cisco.com
ip name server 10.10.10.30
!
ip tftp source-interface gig0/0/0
!

Documentation MGCP complète : Cisco Unified Communications Manager and Interoperability Configuration Guide, Cisco IOS Release 15M&T

Exemple de configuration SCCP / STCAPP [avec configuration automatique CUCM*]

!
stcapp ccm-group 1
stcapp
!
sccp local gig0/0/0
sccp ccm 10.10.10.10 id 1 priority 1 version 7.0+
sccp ccm 10.10.10.20 id 1 priority 2 version 7.0+
sccp
!
sccp ccm group 1
 bind interface gig0/0/0
 associate ccm 1 priority 1
 associate ccm 2 priority 2
!
ccm-manager config server 10.10.10.10
ccm-manager sccp local gig0/0/0
ccm-manager sccp
!
voice-port 0/0/0
 description The SCCP port to register
 no shut
!
dial-peer voice 1 pots
 description Defining the Port for the SCCP application
 service stcapp
 port 0/0/0
!
ip tftp source-interface gig0/0/0
!

Si un administrateur ne veut pas que CUCM configure la passerelle, supprimez simplement les commandes ccm-manager. La configuration de terminal de numérotation dial-peer est incluse pour vous faire comprendre comment fonctionne le concept. Avec les configurations de gestionnaire de ccm présentes, CUCM crée ces terminaux de numérotation dial-peer en fonction de la configuration de port dans CUCM, de sorte qu'il n'est pas nécessaire de définir réellement le terminal de numérotation dial-peer. Les terminaux de numérotation dial-peer créés par CUCM commencent généralement par 999 et comportent trois chiffres supplémentaires.

SIP DSAPP avec terminaux de numérotation dial-peer

SIP DSAPP a été ajouté dans Cisco IOS XE 16.12.1+ et CUCM 12.5.1SU+

Grâce à cette fonctionnalité, les ports vocaux analogiques tels que FXS peuvent être enregistrés et gérés par CUCM. Le routage des appels avec DSAP est légèrement différent de MGCP ou SCCP car les terminaux de numérotation dial-peer sont toujours normalement mis en correspondance. En d'autres termes, la passerelle peut collecter des chiffres à partir du port FXS et effectuer une recherche de terminal de numérotation dial-peer sur les terminaux de numérotation dial-peer VOIP. Une fois qu'une correspondance est trouvée, l'invitation est envoyée à CUCM enblock pour que CUCM effectue une analyse de chiffres supplémentaire.

Exemple de configuration SIP DSAP [avec configuration automatique CUCM*] | IOS-XE 16.12.1+ et CUCM 12.5.1SU+

!
dsapp line
!
voice service voip
 sip
  bind control source-interface GigabitEthernet0/0/0
  bind media source-interface GigabitEthernet0/0/0
  session transport tcp
!
application
 service dsapp
  param dialpeer 777
!
global
 service default dsapp
!
ccm-manager config server 10.10.10.10
ccm-manager sipana auto-config local GigabitEthernet0/0/0
!
dial-peer voice 777 voip
 destination-pattern 9T
 session protocol sipv2
 session target ipv4:10.10.10.10
 session transport tcp
 incoming called-number .
 voice-class sip extension gw-ana
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711ulaw
!
dial-peer voice 19990100 pots
 service dsapp
 destination-pattern 7776
 voice-class sip extension gw-ana
 port 0/1/0
!
sip-ua
 registrar ipv4:10.10.10.10 expires 3600 tcp
!

Documentation complète sur SIP DSAPP : Guide de configuration du logiciel de passerelle vocale Cisco VG450

Dépannage et vérification du routage des appels

Consultez ce document pour plus d'informations.

Configurer la collecte de débogage pour les passerelles CUBE (Unified Border Element) et TDM (Time-Division Multiplexing)