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>

Open

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.

Open

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

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:

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.

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.

Proxy alterando o contact:

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