/
Problemas com BYE

Problemas com BYE

Owned by Gabriel Furtado Piaia
Last updated: Dec 27, 2024 by Jeferson Fernando Quintana
4 min read

Há casos onde o cliente alega que o proxy não está repassando o BYE de B para A em uma ligação sainte ou até mesmo repassando para um endereço “errado”.

Este comportamento geralmente é relatado quando o cliente está realizando testes e utiliza um softphone.A causa pode ser o campo <contact> mau formatado. O softswitch se baseia na RFC3261 e nela é definido formas válidas de enviar o campo contact e como tratar ele.

Exemplos de contact válido:

Contact: <sip:35666507@177.92.84.76:5060>

Contact: <177.92.84.76:5060>

Contact: <177.92.84.76>

Acima temos o invite vindo de um softphone (Microsip) registrado em um denreço local e saindo pelo ip público. Observe que o contact vem com o endereço local que receberá a sinalização de volta.

Ao passar pelo próxy é enviado para ponta B o contact com a flag NAT = YES indicando que deverá ser feita a tradução do nat no retorno da sinalização.

 

Há dois problemas que podem ocorrer ao receber um BYE mal formatado:

 

Proxy não repassar o bye e descartar a sinalização:

Observe o contact enviado para o gateway no formato <sip:ip>.

Observando o retorno do BYE vindo do gateway:

O opensips não está preparado para processar um bye vindo dessa forma ( @IP ) não repassa a sinalização.

Também é gerado um erro no log:

PROXY- /usr/sbin/opensips[29663]: --- error route class=1 level=3#012 info=error parsing incoming uri rcode=400 rreason=bad i-uri --- - linha=3306

Neste caso é necessário é indicado orientar o cliente a entrar em contato com o responsável pelo tratamento da sinalizão por parte do gateway/terminação e indicar o ajuste no BYE baseado na RFC.

 

BYE repassado para endereço diferente da origem do INVITE:

No print abaixo podemos ver o invite vindo do softphone (Bria) com um endereço público no contact.

O proxy repassa o invite entendendo que aquele é o endereço que deve retornar a sinalização e não há tradução de nat no envio do proxy para o gateway/terminação.

 

O proxy recebe o BYE enviado para o contact que o cliente mandou e envia para o endereço de destino.

Observe que a porta ofertada no Invite é difefente da porta ofertada no contact fazendo com que o BYE seja enviado para uma porta na qual o softphone não espera receber. Com isso a chamada é desligada pelo destino porém fica em curso para a origem.

 

Este comportamento pode ser causado por um roteador que utilize a funcionalidade SIP ALG ou então até mesmo pelo softphone do cliente.

O SIP ALG manipula cabeçalhos de protocolos de rede (SIP), agindo diretamente no roteador para atuar em consenso com a função de NAT (Network Address Translation), traduzindo IP’s públicos em IP’s privados, utilizando a comunicação por portas.

 

Proxy alterando o contact:

Habilitar/Desabilitar ocultação de topologia na configuração do assinante.

 

 

No FREESWITCH. Para caso conforme abaixo utilizar no sip_profile em questão que esta em /usr/local/freeswitch/conf/sip_profiles/PROFILE_NAME.xml (SUP-12027/Baldussi SBC B2B)

image-20241227-194542.png

 

OBS: Adicionar esta configuração e testar

<param name="aggressive-nat-detection" value="true"/>

 

Caso não seja suficiente, adicionar as abaixo:

<param name="force-contact" value="NDLB-connectile-dysfunction"/> <param name="NDLB-force-rport" value="true"/>

 

Em ambas alterações deve-se realizar os seguintes procedimentos:

fs_cli sofia profile rescan sofia profile restart (por desencargo)

 

SIPPulse Routing and Billing Solutions for SIP