Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

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.

 SIP ALG

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 labels