SIP - Bifurcação
Às vezes, um servidor proxy encaminha uma única chamada SIP para vários terminais SIP. Este processo é conhecido como bifurcação. Aqui, uma única chamada pode tocar em vários terminais ao mesmo tempo.
Com a bifurcação SIP, você pode fazer com que seu telefone de mesa toque ao mesmo tempo que seu softphone ou um telefone SIP em seu celular, permitindo que você atenda a chamada facilmente de qualquer dispositivo.
Geralmente, em um escritório, suponha que o chefe não possa atender ou desligar a chamada, o bifurcação SIP permite que a secretária atenda chamadas em seu ramal.
A bifurcação será possível se houver um proxy com monitoração de estado disponível, pois ele precisa executar e responder entre os muitos que recebe.
Temos dois tipos de bifurcação -
- Bifurcação Paralela
- Bifurcação Sequencial
Bifurcação Paralela
Nesse cenário, o servidor proxy bifurcará o INVITE para, digamos, dois dispositivos (UA2, UA3) de cada vez. Ambos os aparelhos vão gerar 180 Ringing e quem receber a chamada vai gerar 200 OK. A resposta (suponha que UA2) que chega primeiro ao Originador estabelecerá uma sessão com UA2. Para a outra resposta, um CANCELAR será acionado.
Se o originador receber ambas as respostas simultaneamente, com base no valor q, ele encaminhará a resposta.
Bifurcação Sequencial
Nesse cenário, o servidor proxy bifurcará o INVITE em um dispositivo (UA2). Se o UA2 estiver indisponível ou ocupado naquele momento, o proxy o transferirá para outro dispositivo (UA3).
Filial - ID e Tag
Os IDs de filial ajudam os proxies a corresponder as respostas a solicitações bifurcadas. Sem os IDs de filial, um servidor proxy não seria capaz de entender a resposta bifurcada. Branch-id estará disponível no cabeçalho Via.
As marcas são usadas pelo UAC para distinguir várias respostas finais de diferentes UAS. Um UAS não pode resolver se a solicitação foi bifurcada ou não. Portanto, é necessário adicionar uma tag.
Os proxies também podem adicionar tags se isso gerar uma resposta final, eles nunca inserem tags nas solicitações ou respostas que encaminham.
Pode ser possível que uma única solicitação também seja bifurcada por vários servidores proxy. Portanto, o proxy que bifurcará deve adicionar seus próprios IDs exclusivos aos branches que criou.
Trecho de chamada e ID de chamada
Um trecho de chamada se refere a um para um relacionamento de sinalização entre dois agentes de usuário. O ID da chamada é um identificador exclusivo transportado na mensagem SIP que se refere à chamada. Uma chamada é uma coleção de trechos de chamada.
Um UAC começa enviando um CONVITE. Devido à bifurcação, ele pode receber vários 200 OK de UAs diferentes. Cada um corresponde a um trecho de chamada diferente dentro da mesma chamada.
Uma chamada é, portanto, um grupo de trechos de chamada. Um trecho de chamada refere-se à conexão ponta a ponta entre UAs.
Os espaços CSeq nas duas direções de um trecho de chamada são independentes. Em uma única direção, o número de sequência é incrementado para cada transação.
Correio de voz
O correio de voz é muito comum hoje em dia para usuários corporativos. É um aplicativo de telefone. Quando a pessoa chamada não estiver disponível ou não puder receber a chamada, o PABX anunciará ao chamador para deixar uma mensagem de voz.
O agente do usuário obterá uma resposta 3xx ou redirecionará para o servidor de correio de voz se o número da parte chamada estiver inacessível. No entanto, algum tipo de ramal SIP é necessário para indicar ao sistema de correio de voz qual caixa postal usar, ou seja, qual saudação reproduzir e onde armazenar a mensagem gravada. Existem duas maneiras de conseguir isso -
Usando uma extensão de campo de cabeçalho SIP
Usando o Request-URI para sinalizar esta informação
Suponha que para o usuário sip:[email protected] tem um sistema de correio de voz em sip: voicemail.tutorialspoint.com que fornece correio de voz, o URI de solicitação do INVITE quando é encaminhado para o servidor de correio de voz pode ser semelhante a -
sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486A ilustração a seguir mostra como o Request-URI carrega o identificador da caixa de correio e o motivo (aqui 486).
