Cisco Interfaces and Modules : Cisco Unified SIP Proxy

Cisco unificou o Processamento de chamadas do proxy do SORVO

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como o proxy unificado Cisco do Session Initiation Protocol (SIP) faz decisões de roteamento de chamada.

Contribuído por Ajeet Singh, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

Cisco recomenda que você tem o conhecimento de Cisco unificou o proxy do SORVO (LIMITE).

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Modelo de processamento do LIMITE

Rede

Esta seção descreve o conceito da rede usado no fluxo do Processamento de chamadas do LIMITE.

  • A rede contém uma coleção lógica das interfaces local que são tratadas o mesmos para propósitos de roteamento gerais.
  • SORVA mensagens, em cima da chegada, são associados com a rede em que as mensagens são recebidas (rede entrante).
  • A rede que parte é ajustada como parte da lógica do roteamento do LIMITE e as mensagens são encaminhadas/enviadas à rede do grupo.
  • Cada rede do SORVO tem estas propriedades:
    • Escutam os pontos - pode mandar o múltiplo escutar pontos pela rede
    • Grupos de servidor - os elementos nos grupos de servidor (SG), como o gerente das comunicações unificadas de Cisco (CUCM) aglomeram-se
    • Temporizadores do SORVO - contagens da retransmissão
    • Opções do sibilo - monitora a saúde de cada elemento no SG e é configurado pela rede
    • Rota do registro - os estados da chamada não são armazenados porque há tabelas de roteamento
    • Através do descascamento do encabeçamento - a fim esconder a topologia

Aqui está um exemplo:

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
 !

Disparadores

Esta seção descreve o que provocam são e como eles é usado.

  • Um disparador é um conjunto de condição usado a fim determinar que política do roteamento e da normalização é aplicada a um pedido do SORVO.
  • Uma condição do disparador define regras de harmonização contra determinados encabeçamentos ou campos dentro de uma mensagem do SORVO, de uma rede, e de um tipo do transporte (UDP, TCP, Transport Layer Security (TLS)).
  • Um disparador é avaliado como verdadeiro ou falso para cada pedido recebido.
  • Se a circunstância é verdadeira, a seguir os comportamentos do pré-ajuste estão invocados.
  • E operação é conseguido especificando encabeçamentos ou os campos em uma única disparador-condição comandam.
  • OU operação é conseguido com diversas disparador-condições, cada um identificado por um número de sequência.
  • As circunstâncias são avaliadas no ordem crescente baseado no número de sequência.
  • A condição do meados de-diálogo é primeira, de modo que a etapa da política seja saltada para mensagens do meados de-diálogo.

Aqui está um exemplo:

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

Distribuindo a política da consulta

Esta seção descreve a política da consulta do roteamento para o fluxo do Processamento de chamadas do LIMITE. 

  • Cada política de roteamento é expressada enquanto uma sequência das etapas e de cada um é especificada a fim executar uma consulta em uma tabela.
  • O LIMITE executa cada etapa em ordem:
    • Cada etapa tem uma chave selecionável.
    • Se a etapa produz uma rota, essa rota está usada.
    • Se a etapa conduz a um “nenhum-fósforo,” a próxima etapa está tentada.
  • Um pedido do SORVO pode ser distribuído a um destino único ou a um grupo de rotas (RG).
  • A política tem o avanço da rota da Multi-camada dentro de um RG, e tem códigos configuráveis da resposta do SORVO do Failover.
  • A rejeção com base em política do pedido é incorporada (respostas 4xx e acima).
  • As políticas aninhadas são permitidas.
  • o roteamento Tabela-baseado é usado, que tem estas propriedades:
    • Apoia um grande número rotas em uma tabela (10,000+).
    • As rotas em uma tabela são povoadas através do CLI ou de um arquivo da rota.
    • As chaves da consulta são usadas, como a chamada e o número da parte chamada, os códigos do portador, e os números do roteamento do lugar.
    • A harmonização flexível da regra é usada, como “a correspondência de prefixo a mais longa.”

Política da normalização

Esta seção descreve a política da normalização do fluxo do Processamento de chamadas do LIMITE. 

  • Os encabeçamentos do SORVO são normalizados baseados em uma política configurada.
  • A normalização envolve a adição, a alteração, e a remoção de encabeçamentos do SORVO.
  • É aplicável aos pedidos e às respostas do SORVO.
  • É usada a fim resolver incompatibilidades ou edições da interoperação entre server diferentes do SORVO.
  • Pode ser executada antes ou depois distribuindo a lógica é executada (PRE-normalização e Cargo-normalização).
  • Lógica da normalização:
    • Política da normalização - Define que mudanças devem ser feitas à mensagem do SORVO.
    • Disparadores da normalização - Defina como uma política da normalização é escolhida.
  • A política consiste em etapas, e cada etapa especifica uma única mudança à mensagem do SORVO. Por exemplo:
    • Normalização do número
    • Conversões TEL/SIP
    • Conversões do domínio
    • Processamento da expressão regular

Está aqui um fluxograma que mostre o processo:

Fluxo da PRE-normalização do LIMITE

A PRE-normalização é a alteração de mensagens do SORVO após um pedido do SORVO está recebida e antes que as decisões de roteamento estiverem feitas.

Neste exemplo, a parcela do usuário do pedido do identificador de recurso uniforme (URI) do SORVO está substituída por 4082022222 se o valor que existe é 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
!

Está aqui um fluxograma da PRE-normalização:

Fluxo do roteamento do LIMITE

Esta seção ilustra o fluxo do roteamento do LIMITE. Está aqui um fluxograma do roteamento do LIMITE:

Fluxo do grupo de rotas do LIMITE

Esta seção descreve o LIMITE RG flui.

  • O RG especifica as rotas múltiplas que um pedido do SORVO pôde tomar (similar a um CUCM RG).
  • Cada rota é configurada como um elemento.
  • Quando uma condição do disparador do roteamento é avaliada como verdadeira, a política da consulta que lhe corresponde está usada a fim criar uma lista de tabelas de roteamento aplicáveis.
  • Cada entrada na tabela de roteamento aponta a um RG particular, a um SG, ou a um destino específico.
  • As rotas estão avançadas entre elementos até que bem sucedidas. Por exemplo, se você quer distribuir um atendimento a um conjunto CUCM, o subscritor pode ser um elemento quando o editor for o segundo.
  • Os avanços da rota entre elementos são controlados na resposta do SORVO recebida (resposta do Failover).
  • Os elementos do RG são heterogêneos. Por exemplo, uma rota dirige para CUCM e outro à rede telefônica pública comutada (PSTN).
  • Um elemento RG pode apontar a um SG.
  • Os pedidos do SORVO são distribuídos com base no Time Of Day.

O LIMITE apoia estas ações: 

  • Roteamento com base no período dentro de um RG
  • A porcentagem/peso-baseou o roteamento dentro de um RG ou de um SG
    • Isto permite a função de balanceamento de carga do tráfego entre elementos a jusante, com base no peso do pré-ajuste.
    • Fornece q-valores para a prioridade/menos roteamento baseado em custo.

Está aqui um exemplo de um RG com um SG configurado como o destino do alvo:

!
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
!

Está aqui um fluxograma do grupo de rotas do LIMITE:

Fluxo do grupo de servidor do LIMITE

Esta seção descreve o fluxo do LIMITE SG.

  • Um SG é um conjunto de elementos a jusante que o LIMITE trata como uma única rota lógica.
  • Os membros do SG são homogêneos, como a pilha/conjunto de Cisco Unified Border Element (cubos).
  • Os pedidos são função de balanceamento de carga entre membros.
  • A prioridade de cada membro (elemento) em um SG é atribuída pelos q-valores (0.0? 1.0), com os 1.0 como o mais alto.
  • O SG permite o monitoramento de funcionamento do membro (sibilo).
  • O SG permite a restauração automática na recuperação do membro.

    
Está aqui um exemplo de um SG com dois elementos (a publisher e subscriber CUCM)

!
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
!

Está aqui um fluxograma do grupo de servidor: 

Fluxo da Cargo-normalização do LIMITE

A Cargo-normalização é a alteração de mensagens do SORVO antes que estejam encaminhados ao salto seguinte.

Neste exemplo, a parcela do usuário do pedido do SORVO URI está substituída por 85224044444 se o valor que existe é 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
!

Está aqui um fluxograma da Cargo-normalização:

Informações Relacionadas


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 116251