/
Problemas com BYE

Problemas com BYE

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.

 

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)

 

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:

 

Related content

O trapezóide SIP
More like this
Componentes de uma rede SIP
Componentes de uma rede SIP
More like this
Fluxo de um diálogo SIP
Fluxo de um diálogo SIP
More like this

SIPPulse Routing and Billing Solutions for SIP