Solucione problemas de áudio não-direcional com chamadas Hairpin no CUBE

Introdução

Este documento descreve como solucionar o problema de áudio não-direcional com chamadas de hairpin no Cisco Unified Border Element (CUBE).

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Protocolo de Iniciação da Sessão (SIP)
• Como configurar e usar o CUBE
• Fluxo de mídia através e ao redor

Componentes Utilizados

As informações neste documento são baseadas nas seguintes versões de hardware e software:

• Cisco Unified Communications Manager (CUCM) - 11.5.1.10000-5
• CUBE - 15.5(3)S5

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 rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Topologia de rede

Problema

Uma chamada de hairpin é uma chamada recebida de um provedor de serviços de telefonia via Internet (ITSP) encaminhada ou transferida de volta para o ITSP, o que resulta em áudio não-direcional, chamadas regulares para o ITSP de telefones IP funcionam bem.

De acordo com o SIP RFC 3264, as negociações de soquete de mídia entre o SIP User Agent Client (UAC) e o SIP User Agent Server (UAS) acontecem por meio do Session Description Protocol (SDP) no modelo Oferta/Resposta, seguido por todos os fabricantes de produtos Voice over IP (VoIP).

Alguns ITSPs não consideram as informações de endereço IP e porta no SDP devido à implementação do firewall, portanto, o soquete deve ser iniciado pela extremidade oposta (nesse caso, o CUBE). O ITSP exige que a extremidade oposta envie alguns pacotes RTP (Real-Time Transport Protocol) para ele, uma vez que o ITSP recebe os pacotes RTP, ele transmite os pacotes para o IP de origem dos pacotes recebidos.

Em uma chamada entre um telefone IP e o ITSP, que não apresenta o hairpin, esse problema não ocorre, porque o telefone IP envia pacotes RTP fictícios depois de abrir as portas necessárias. 

Quando uma chamada vem do ITSP e é enviada de volta para eles, tanto o iniciador como o receptor da chamada não enviam nenhum fluxo, a menos que recebam um fluxo de alguém no caminho da chamada, essa é uma situação de deadlock.

Verificar

Para validar se a conexão foi estabelecida com êxito, execute este comando: show voip rtp connections.

Max Ports Available: 19999, Ports Reserved: 101, Ports in Use: 4
Port range not configured, Min: 8000, Max: 48199

                                                Ports       Ports       Ports     
Media-Address Range                             Available   Reserved    In-use    

Default Address-Range                           19999       101         4         

VoIP RTP active connections :
No. CallId     dstCallId  LocalRTP RmtRTP LocalIP                                       RemoteIP                               
1     21         22         16424    16568  10.106.36.169                               10.106.108.72                          
2     22         21         16426    24602  10.106.36.169                               10.106.123.29                          
3     23         24         16428    24600  10.106.36.169                               10.106.123.29                          
4     24         23         16430    16570  10.106.36.169                               10.106.108.72                          
Found 4 active RTP connections

Execute o comando show call ative voice brief para ver os contadores Rx/Tx de todos os 4 segmentos de chamada da perspectiva do CUBE como 0/0.

Total call-legs: 4
35E9 : 21 7441740ms.1 (*13:00:22.857 UTC Sat May 20 2017) +4080 pid:123 Answer 5655 connected
 dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0                                            <<<<
 IP 10.106.108.72:16568 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a
 LostPacketRate:0.00 OutOfOrderRate:0.00

35E9 : 22 7441740ms.2 (*13:00:22.857 UTC Sat May 20 2017) +4080 pid:123 Originate 7961 connected
 dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0                                            <<<< 
 IP 10.106.123.29:24602 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a
 LostPacketRate:0.00 OutOfOrderRate:0.00

0    : 23 7441780ms.1 (*13:00:22.897 UTC Sat May 20 2017) +4020 pid:124 Answer 5655 connected
 dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0                                            <<<<
 IP 10.106.123.29:24600 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a
 LostPacketRate:0.00 OutOfOrderRate:0.00

0    : 24 7441780ms.2 (*13:00:22.897 UTC Sat May 20 2017) +4010 pid:124 Originate 7961 connected
 dur 00:24:17 tx:0/0 rx:0/0 dscp:0 media:0 audio tos:0xB8 video tos:0x0                                            <<<<
 IP 10.106.108.72:16570 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No
 media inactive detected:n media contrl rcvd:n/a timestamp:n/a
 long duration call detected:n long duration call duration:n/a timestamp:n/a
 LostPacketRate:0.00 OutOfOrderRate:0.00

Observação: caso os roteadores usem IOS-XE, execute este comando para validar os contadores Rx/Tx:

voice service voip
 media bulk-stats

Não é recomendável executar esse comando quando o volume de chamadas estiver alto. Certifique-se de executar esse comando quando a CPU estiver abaixo de 30%.

Solução

Ponto de terminação de mídia de software (MTP)

Esse é o método preferido para superar o problema. Os MTPs do software CUCM são capazes de enviar pacotes RTP fictícios. Em uma chamada hairpin, o MTP do software fornece pacotes RTP fictícios para ambos, o iniciador da chamada e o receptor da chamada, portanto, o ITSP recebe esses pacotes e responde com RTP ao MTP do software.

Certifique-se de que a caixa de seleção Media Termination Point Required esteja marcada na página Trunk Configuration. Navegue até Device > SIP trunk e selecione a Media Resource Group List (MRGL) desse tronco, confirme se ele contém pelo menos um MTP de software.

1. Observação: o MTP de hardware não pode enviar fluxos RTP fictícios. Certifique-se de que o MRGL associado ao tronco chame somente o MTP do software. O MTP de software só pode fazer a ponte de chamadas G711. Certifique-se de que o fluxo de chamadas de ponta a ponta use G711 para que essa solução funcione.

A próxima imagem mostra como a carga RTP fictícia parece no Wireshark:

Fluxo de mídia

Com o Media Flow-Around, os pacotes de sinalização terminam e se originam no CUBE, mas os pacotes de mídia ignoram o CUBE e fluem diretamente entre os endpoints.

voice service voip
 media flow-around

Chamada com fluxo de mídia

Cuidado: isso pode afetar a funcionalidade do CUBE, pois não pode encerrar a mídia em nenhuma chamada. O RTP ignora o CUBE e flui diretamente entre os endpoints. Nesse caso, ele flui diretamente entre os ITSPs.

O modo de configuração de peer de discagem para o Media Flow-Through não tem efeito se você tiver o Media Flow-Around configurado na configuração global.

Configuração

1. Configure o fluxo de mídia na configuração global.
2. Crie uma mídia de classe de voz com fluxo de mídia.
3. Aplique Mídia de Classe de Voz em todos os peers de discagem nos quais se espera que o Fluxo de Mídia seja usado.
4. Os peers de discagem que não têm essa configuração se enquadram no fluxo de mídia, já que ele é configurado globalmente.

Voice service voip
media flow-around

voice-class media 10
 media flow-through

dial-peer voice 1 voip
 Description ** Inbound dial-peer **
 voice class media 10

dial-peer voice 2 voip
 Description ** Outbound dial-peer **
 voice class media 10

Anti-Trombone de Mídia

Esse recurso funciona de forma semelhante ao Media Flow-Around, mas causa menos impacto. Primeiro, ele procura chamadas em loop ou hairpin; se uma chamada de hairpin for encontrada, esse recurso aciona outra rodada de negociação de mídia para a chamada identificada. Ao final dessa negociação, o CUBE não faz mais parte do caminho de mídia.

Ambas as partes, CUBE e ITSP, precisam oferecer suporte ao recurso Anti-Trombone para que isso funcione.

voice service voip
 media anti-trombone

Chamada com Mídia Anti-Trombone

Observação: valide as restrições antes de configurar o Media Anti-Trombone em http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/media-path.html

Permitir que o CUBE envie pacotes STUN na porta/IP de mídia negociada

Permita que o CUBE envie solicitações/pacotes STUN gerados localmente (esses pacotes stun são pacotes UDP com os mesmos números de porta/IP de mídia) a serem enviados pelo caminho de mídia negociado; os dispositivos no caminho de mídia podem limpar o caminho depois de obter esses pacotes stun depois de verificar o protocolo IP/Porta/transporte se esses dispositivos não estiverem verificando os dados reais do aplicativo:

voice service voip

stun

stun flowdata agent-id 1 boot-count 4

stun flowdata shared-secret 0 Password123$

voice class stun-usage 1

stun usage firewall-traversal flowdata

dial-peer voice 2000 voip

Descrição ** correspondente de discagem de entrada do ** ITSP

voice-class stun-usage 1

Isso pode ser feito no peer de discagem usado para receber a chamada do ITSP ou no peer de discagem usado para enviar a chamada para o ITSP ou para ambos.