Asterisk® SCF™ - Utilizando PJSIP como Proxy

 

Existe muitos cenários de proxy diferentes nos quais o Asterisk® SCF™ pode estar envolvido. Nem todos podem ser explicados aqui, mas alguns exemplos podem ajudá-lo a se adaptar à sua situação específica. O primeiro e mais simples cenário é onde o Asterisk® SCF™ está funcionando como um PBX na mesma rede privada em que os telefones estão, mas precisa de conectividade com um Provedor de Serviços de Telefonia pela Internet (ITSP - Internet Telephony Service Provider).

Outbound Proxy (Proxy de Saída)

Assumiremos que o ITSP exige que o Asterisk® SCF™ se registre para receber chamadas. Claro, mesmo com o Asterisk® SCF™ atrás de um firewall ou roteador NAT, um proxy não é realmente necessário, mas a configuração é boa para começar. Embora a configuração de um proxy como o Kamailio® esteja além do escopo deste post, este cenário requer apenas as configurações de proxy mais simples e provavelmente funcionaria com os exemplos fornecidors pelo Kamailio®. Vamos assumir que o proxy é DUAL HOMED com uma interface na rede privada e uma inteface na rede pública. Também assumiremos que o proxy está retransmitindo mídia e sinalização. Usaremos 192.168.15.1 como endereço privado do proxy e 192.168.15.2 como endereço do Asterisk® SCF™ (atuando como um Softswitch PBX IP).

Configuração do Asterisk® SCF™

Existem vários objetos PJSIP que precisam ser configurados para esta situação.

• transport: Na verdade, esta é uma ação de desconfiguração 😂. Se o Asterisk® SCF™ não estiver usando um proxy, você pode ter parâmetros no transporte como external_signalling_address, external_media_address, local_net, etc. Estes NÃO deve ser configurados quando o Asterisk® SCF™ e o PROXY estiverm na mesma rede. O Asterisk® SCF™ não deve saber nada sobre o que está do outro lado do proxy, pois o trabalho do proxy é tornar isso invisível.

Examplo:

[ipv4-udp]

type = transport

protocol = udp

bind = 0.0.0.0:5060

• endpoint: Configure o endpoint do ITSP como faria normalmente, mas adicione um parâmetro outbound_proxy com um URI que aponta para o endereço interno do proxy. Isso direcionará (quase) todas as solicitações de saída desse endpoint para o proxy. Você também não deve ativar nenhum parâmetro reladionado ao NAT, como force_rport, ice_support, etc.

Examplo:

[myitsp]

type = aor

contact = sip:my.itsp.com:5060

outbound_proxy = sip:192.168.0.1\;lr

qualify_frequency = 60

• registration: O mesmo que aor. Os URIs do clinte e do servidor devem permanecer como estavam para a situação sem proxy e o parâmetro outbound_proxy deve ser incluído.

Examplo:

[myitsp]

type = registration

client_uri = sip:my_account@my.itsp.com

server_uri = sip:my.itsp.com

outbound_proxy = sip:192.168.0.1\;lr

• identify: agora as coisas ficam um pouco complicadas. A mairoria dos ITSPs não autentica de volta para seus clientes ao enviar as chamadas e eles podem estar enviando o CallerID do originador/chamador como o usuário do cabeçalho FROM: (DE), portanto, a (quase) única maneira de identificar as chamdas da ITSP é pelo endereço IP. Se não houvesse proxy no circuito, você provavelmente configuraria um objeto de identificação com um parãmetro match = my.itsp.com. No caso do proxy, porém, a correspondência precisa ser com o endereço privado do proxy, pois esse é o endereço IP de onde os pacotes virão.

          Examplo:

[myitsp]

type = identify 

match = 192.168.0.1

endpoint = myitsp

Você deve ter notado que os URIs do proxy têm o parâmetro " lr " adicionado. Isso ocorre porque a maioria dos proxies hoje em dia segue o RFC 3261 e, portanto, tem " loose-routing " (roteamento flexível). Se você não o tiver definido, provavelmente receberá uma reposta 404 do proxy. O objeto " \ " antes do ponto e vírgula é importante para evitar que o ponto e vírgula seja tratado como um caractere inicial de comentário no arquivo de configuração.

Bom, nesse ponto, você deve ter um tronco com sua ITSP funcionando para chamadas de Inbound (entradas) e Outbound (saídas). 

Direct Media

Se o seu proxy for compatível, você poderá ativar a mídia direta entre os telefones e o proxy definindo direct_media = yes no telefone (device) e nos terminais (endpoint) da ITSP. O proxy deve cuiadar  do resto. Tentar fazer mídia direta, diretamente entre os telefones (devices) e o terminais (endpoints) da ITSP provavelmente não funcionará.

Multiplas ITSPs

Há um pequeno problema com a configuração acima se você tiver mais de 1 tronco ITSP por meio do proxy. Na configuração acima, o objeto de identificação é usado para direcionar solicitações recebidas do proxy para um único endpoint e você não pode direcionar o mesmo endereço IP para vários endpoints por motivos óbvios. Você pode definir 1 endpoint e 1 identificador para o proxy atuar como o receptor de chamadas de todos os provedores de serviços, mas isso nem sempre é conveniente ou possível com algumas GUIs front-end.

Nesse caso, e se o seu ITSP suportar, você pode usar o parâmetro de linha do objeto de registro como o mecanismo para corresponder as solicitações recebidas a um terminal e eliminar completamente o uso de identificar. 

Veja como funciona: Quando você especifica line = true e endpoint = <endpoint> em um registro, o Asterisk® SCF™ acrescenta um parâmetro " line " ao URI de contato do REGISTER de saída que contém uma string exclusiva. Ficará assim: " Contact: <sip:s@192.168.0.2.245:5060;line=eylpkkv> ". Se a sua ITSP suportar, quando enviar uma solicitação INVITE para o Asterisk® SCF™, ele incluirá o parâmetro " line " no Request URI ou no cabeçalho To da seguinte forma: " INVITE sip:8005551212@192.168.0.2:5060;line=eylpkkv SIP/2.0 " . O Asterisk® SCF™ então usará essa string única para corresponder a solicitação ao endpoint especificado no registro.

Examplo:

[myitsp]

type = registration

client_uri = sip:my_account@my.itsp.com

server_uri = sip:my.itsp.com

outbound_proxy = sip:192.168.0.1

line = yes

endpoint = myitsp 

Header Matching (Correspondência de Cabeçalho)

Algumas ITSPs incluem cabeçalhos " X- " em suas solicitações que contêm números de contas ou outras informações de identificação. O Asterisk® SCF™, em suas versões 13.15 e 14.5 têm um novo recurso de identificação que permite combinar as solicitações recebidas com os endpoints por meio desses cabeçalhos.

Examplo: 

[myitsp]

type = identify

match_header = X-My-Account-Number: 12345678

endpoint = myitsp 

Inbound Proxy (Proxy de Entrada)

Em um cenário de provedor de serviços (ITSP), o Asterisk® SCF™ provavelmente estará atrás de um proxy separado da internet pública e dos clientes, sejam eles telefones ou PBXes ou o que quer que seja. Nesse caso, a carga de configuração muda do Asterisk® SCF™ para o proxy. Você provavelmente desejará configurar o proxy para lidar com autenticação, qualificação, direção de mídia para gateways de mídia, servidores de correio de voz etc., e tudo isso está além do escopo deste documento. Contribuições que contenham instruções para proxies populares serão muito bem-vindas.

Fonte: https://wiki.asterisk.org/

Por George Joseph.