Interfaces et modules Cisco : Mandataire SIP pour Cisco Unified

Traitement des appels de Cisco Unified SIP Proxy

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment le proxy de Protocole SIP (Session Initiation Protocol) de Cisco Unified prend des décisions de routage d'appels.

Contribué par Ajeet Singh, ingénieur TAC Cisco.

Conditions préalables

Conditions requises

Cisco recommande que vous ayez la connaissance du Cisco Unified SIP Proxy (TRANCHANT).

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Modèle de traitement de TRANCHANT

Réseau

Cette section décrit le concept du réseau utilisé dans l'écoulement de Traitement des appels de TRANCHANT.

  • Le réseau contient une collection logique d'interfaces locales qui sont traitées les mêmes pour le routage général.
  • Des messages SIP, sur l'arrivée, sont associés avec le réseau sur lequel les messages sont reçus (réseau entrant).
  • Le réseau sortant est placé pendant qu'une partie de la logique de acheminement du TRANCHANT et les messages sont expédiés/envoyés au réseau de positionnement.
  • Chaque réseau de SIP a ces propriétés :
    • Écoutent les points - peut faire écouter le multiple des points par réseau
    • Groupes de serveurs - éléments aux groupes de serveurs (GV), comme des batteries de Cisco Unified Communications Manager (CUCM)
    • Sip timer - comptes de retransmission
    • Des options de ping - surveille les santés de chaque élément dans le SG et est configuré par réseau
    • Artère record - des états d'appel ne sont pas enregistrés parce qu'il y a des tables de routage
    • Par l'intermédiaire d'éliminer d'en-tête - afin de masquer la topologie

Voici un exemple :

sip listen Net-PSTN udp 14.128.100.169 5060

 !
sip network Net-PSTN standard
  no non-invite-provisional
  allow-connections
  retransmit-count invite-client-transaction 3
  retransmit-count invite-server-transaction 5
  retransmit-count non-invite-client-transaction 3
  retransmit-timer T1 500
  retransmit-timer T2 4000
  retransmit-timer T4 5000
  retransmit-timer TU1 5000
  retransmit-timer TU2 32000
  retransmit-timer clientTn 64000
  retransmit-timer serverTn 64000
  tcp connection-setup-timeout 1000
  udp max-datagram-size 1500
  end network
 !

Déclencheurs

Cette section décrit ce qui déclenche est et comment ils sont utilisés.

  • Un déclencheur est un ensemble de conditions utilisé afin de déterminer quelle stratégie de routage et de normalisation est appliquée à une demande de SIP.
  • Un état de déclencheur définit des règles assorties contre certaines en-têtes ou des champs dans un message SIP, un réseau, et un type de transport (UDP, TCP, Transport Layer Security (TLS)).
  • Un déclencheur est évalué en tant que vrai ou faux pour chaque demande reçue.
  • Si la condition est vraie, alors des comportements de présélection sont appelés.
  • ET exécution est réalisé en spécifiant des en-têtes ou les champs en déclencheur-état simple commandent.
  • OU exécution est réalisé avec plusieurs déclencheur-états, chacun identifié par un numéro de séquence.
  • Les conditions sont évaluées dans la commande croissante basée sur le numéro de séquence.
  • L'état de mid-dialogue est le premier, de sorte que l'étape de stratégie soit ignorée pour des messages de mid-dialogue.

Voici un exemple :

trigger condition TC-from-CUCM
  sequence 1
   in-network Net-CUCM
    method INVITE
    end sequence
  sequence 2
   in-network Net-PSTN
   local-port 5060
   end sequence
end trigger condition

Acheminement de la stratégie de consultation

Cette section décrit la stratégie de consultation de routage pour l'écoulement de Traitement des appels de TRANCHANT. 

  • Chaque stratégie de routage est exprimée pendant qu'un ordre des étapes et de chacune est spécifié afin d'exécuter une consultation dans une table.
  • Le TRANCHANT exécute chaque étape dans la commande :
    • Chaque étape a une clé sélectionable.
    • Si l'étape produit une artère, cette artère est utilisée.
    • Si l'étape a comme conséquence une « absence de correspondance, » l'étape suivante est tentée.
  • Une demande de SIP peut être conduite à une destination simple ou à un groupe d'artère (RG).
  • La stratégie a l'avance multicouche d'artère dans un RG, et a des codes configurables de réponse de SIP de Basculement.
  • Le rejet basé sur la politique de demande est incorporé (réponses 4xx et ci-dessus).
  • On permet des stratégies imbriquées.
  • le routage basé sur table est utilisé, qui a ces propriétés :
    • Il prend en charge un grand nombre d'artères dans une table (10,000+).
    • Des artères dans une table sont remplies par l'intermédiaire du CLI ou d'un fichier d'artère.
    • Des clés de recherche sont utilisées, comme appeler et numéro appelé, codes de transporteur, et emplacement conduisant des nombres.
    • Apparier flexible de règle est utilisé, comme le « plus long préfixe s'assortissant. »

Stratégie de normalisation

Cette section décrit la stratégie de normalisation d'écoulement de Traitement des appels de TRANCHANT. 

  • Les en-têtes de SIP sont normales basées sur une stratégie configurée.
  • La normalisation comporte l'ajout, la modification, et la suppression des en-têtes de SIP.
  • Il s'applique aux demandes et aux réponses de SIP.
  • Il est utilisé afin de résoudre des incompatibilités ou des problèmes d'interopérabilité entre différents serveurs SIP.
  • Il peut être exécuté avant ou après que conduisant la logique est exécuté (Pré-normalisation et POST-normalisation).
  • Logique de normalisation :
    • Stratégie de normalisation - Définit quelles modifications doivent être apportées au message SIP.
    • Déclencheurs de normalisation - Définissez comment une stratégie de normalisation est choisie.
  • La stratégie se compose des étapes, et chaque étape spécifie une modification simple au message SIP. Exemple :
    • Normalisation de nombre
    • Conversions TEL/SIP
    • Conversions de domaine
    • Traitement d'expression régulière

Voici un organigramme qui affiche le processus :

Écoulement de Pré-normalisation de TRANCHANT

La Pré-normalisation est la modification des messages SIP après une demande de SIP est reçue et avant que conduisant des décisions sont faites.

Dans cet exemple, la partie d'utilisateur de la demande d'identifiant de ressource uniforme en SIP (URI) est remplacée par 4082022222 si la valeur qui existe est 2022222.

!trigger pre-normalization sequence 1 policy CUCM-Prefix-408 condition TC-from-CUCM
!
policy normalization CUCM-Prefix-408
 uri-component update request-uri user 2022222 4082022222
 end policy
!

Voici un organigramme de Pré-normalisation :

Écoulement de routage de TRANCHANT

Cette section montre l'écoulement de routage de TRANCHANT. Voici un organigramme de routage de TRANCHANT :

Écoulement de groupe d'artère de TRANCHANT

Cette section décrit le TRANCHANT RG circulent.

  • Le RG spécifie les plusieurs artères qu'une demande de SIP pourrait prendre (semblable à un CUCM RG).
  • Chaque artère est configurée comme élément.
  • Quand un état de déclencheur de routage est évalué comme vrai, la stratégie de consultation qui correspond à lui est utilisée afin de créer une liste de tables de routage applicables.
  • Chaque entrée dans la table de routage indique un RG particulier, un SG, ou une destination spécifique.
  • Les artères sont avancées entre les éléments jusqu'à ce que réussies. Par exemple, si vous voulez conduire un appel à une batterie CUCM, l'abonné peut être un élément tandis que Publisher est le deuxième.
  • Des avances d'artère entre les éléments sont contrôlées sur la réponse de SIP reçue (réponse de Basculement).
  • Les éléments du RG sont hétérogènes. Par exemple, une artère se dirige vers CUCM et des autres au réseau téléphonique public commuté (PSTN).
  • Un élément RG peut indiquer un SG.
  • Des demandes de SIP sont conduites ont basé l'heure.

Le TRANCHANT prend en charge ces actions : 

  • routage basé sur temps dans un RG
  • Pourcentage/routage basé sur poids dans un RG ou un SG
    • Ceci tient compte de l'Équilibrage de charge du trafic parmi les éléments en aval, basé sur le poids de présélection.
    • Il fournit des q-valeurs pour la priorité/moins routage basé sur coût.

Voici un exemple d'un RG avec un SG configuré comme destination de cible :

!
route group RG-UC520
 element target-destination SG-UC520 Net-UC520 q-value 1.0
  failover-codes 502 - 503
  weight 0
  end element
 end route
!
server-group sip group SG-UC520 Net-UC520
 element ip-address 14.128.100.161 5060 udp q-value 1.0 weight 0
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!

Voici un organigramme de groupe d'artère de TRANCHANT :

Écoulement de groupe de serveurs de TRANCHANT

Cette section décrit l'écoulement SG de TRANCHANT.

  • Un SG est une batterie des éléments en aval que le TRANCHANT traite comme artère logique simple.
  • Les membres du SG sont homogènes, comme la pile/batterie de Logiciels Cisco Unified Border Element (cubes).
  • Les demandes sont chargement-équilibrées parmi des membres.
  • La priorité de chaque membre (élément) dans un SG est assignée par les q-valeurs (0.0 ? 1.0), avec 1.0 en tant que plus élevé.
  • Le SG tient compte de la surveillance de la santé de membre (ping).
  • Le SG tient compte de la restauration automatique sur la reprise de membre.

    
Voici un exemple d'un SG avec deux éléments (CUCM Publisher et d'abonné)

!
server-group sip group SG-CUCM.ajeet.com Net-CUCM
 element ip-address 14.128.64.191 5060 udp q-value 1.0 weight 50
 element ip-address 14.128.64.192 5060 udp q-value 1.0 weight 100
 failover-resp-codes 503
 lbtype global
 ping
 end server-group
!

Voici un organigramme de groupe de serveurs : 

Écoulement de POST-normalisation de TRANCHANT

La POST-normalisation est la modification des messages SIP avant qu'ils soient expédiés au prochain saut.

Dans cet exemple, la partie d'utilisateur de la demande d'URI de SIP est remplacée par 85224044444 si la valeur qui existe est 4444 :

!
trigger post-normalization sequence 1 policy UC520-Four-to-Full
condition TC-UC520-to-PSTN
!
policy normalization UC520-Four-to-Full
 uri-component update request-uri user 4444 85224044444
 end policy
!

Voici un organigramme de POST-normalisation :

Informations connexes


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 116251