Como um tronco funciona
Um tronco pertence a um projeto e tem uma direção:
Em uma chamada, o tronco é um participante chamado
server:sip:<trunkId>. A
conexão dele informa o transporte sip. As pessoas no WhatsApp sempre ouvem o
seu PBX, e o seu PBX sempre as ouve. Ele nunca ouve o próprio áudio. Se o seu
PBX e os seus outros participantes ouvem uns aos outros depende do
modo conferência da sessão:
ativado (o padrão), eles se ouvem; desativado, cada um ouve apenas as pessoas
no WhatsApp. Os troncos SIP transportam apenas áudio.
Gerencie os troncos com a Platform API. A leitura exige sessions:read; toda
alteração exige sessions:manage. Use uma chave de equipe com projectId, ou
um token de projeto para o próprio projeto. Tokens de cliente não podem
gerenciar troncos.
O SDK TypeScript gerencia os troncos com sipTrunks; consulte Conecte um tronco SIP. Você também pode gerenciar os troncos no Console: abra um
projeto, acesse Chamadas e escolha Gerenciar troncos SIP. Consulte
Chamadas no Console.
Encontre o endereço SIP
Todos os troncos de todos os projetos usam o mesmo endereço SIP. Leia-o comGET /platform/sip/endpoint. Ele exige sessions:read e aceita uma chave de
equipe ou um token de projeto:
Quando
status é sip_not_hosted, o ambiente não tem um endereço SIP ao qual
um PBX possa se conectar, e a resposta não retorna host nem portas.
Configure o seu firewall com estes valores:
- Permita SIP nas portas listadas, nos dois sentidos, entre o seu PBX e os
endereços para os quais
hostresolve. - Permita UDP nos dois sentidos entre as portas de mídia do seu PBX e o
intervalo
rtpnos mesmos endereços. - Prefira
tls: ele criptografa a sinalização, e a exigência de SRTP dele criptografa o áudio.udpetcptransportam os dois sem criptografia.
sipTrunks.endpoint() no SDK TypeScript.
Crie um tronco
201 com o tronco e, para troncos inbound e both,
inboundCredentials:
maxConcurrentCalls chamadas ao mesmo tempo (de 1 a 500, padrão 30).
Envie chamadas do WhatsApp para o seu PBX
Defina estes campos emoutbound:
Depois, roteie as chamadas recebidas da sessão para o tronco:
outbound ou
both. As configurações que você omite mantêm os valores; uma atualização
posterior sem sipTrunkId mantém o tronco. Para parar de enviar chamadas ao
tronco, envie "inboundRoute": "clients", o que também limpa sipTrunkId. Em
um número da Cloud API, as chamadas recebidas só chegam ao tronco quando
hostCloudApiCalls é true; consulte
Números da Cloud API. Consulte
Update call settings.
Quando uma chamada roteada toca, a Polymorfa liga para targetUri. A chamada
continua tocando para os participantes do seu SDK, e eles podem atendê-la
primeiro. A requisição para o seu PBX leva o ID da chamada do WhatsApp no
cabeçalho X-Polymorfa-Call-ID.
- Quando o seu PBX atende, a Polymorfa atende a chamada do WhatsApp como
server:sip:<trunkId>. ComsipClaim: true, o atendimento faz o claim da chamada: os outros participantes param de tocar e não podem entrar. ComsipClaim: false, a chamada continua compartilhada e outros participantes podem entrar. Consulte Atender, entrar ou recusar. - Quando o seu PBX não atende, a chamada do WhatsApp continua tocando para os seus outros participantes até ser atendida ou recusada, ou até a janela de toque terminar.
- Quando o seu PBX desliga, a conexão dele sai. Se o tronco fez o claim da chamada, a chamada termina. Quando a chamada do WhatsApp termina, a Polymorfa desliga o seu PBX.
call.connection_left do tronco informa por que a conexão dele saiu:
Um tronco que nunca atendeu informa apenas a saída, sem uma entrada anterior.
Os controles de mídia ao vivo informam
call_ended quando uma conexão
estabelecida fecha porque a chamada terminou. Um desligamento normal pelo PBX
continua como left. Os webhooks encerram as conexões ainda abertas com
call.ended, sem um evento call.connection_left adicional.
Ligue para o WhatsApp a partir do seu PBX
Configure o seu PBX com:- o
hoste uma porta de Encontre o endereço SIP; inboundCredentials.usernameepasswordpara a autenticação digest; e- o número do WhatsApp a chamar, no formato E.164, como parte de usuário da URI
da requisição, por exemplo
sip:+14155550100@SIP_HOST. O+inicial é opcional e um prefixo00é aceito.
inbound.session como a sessão que faz as chamadas. A Polymorfa só
aceita uma chamada quando as credenciais digest são válidas, a requisição vem de
um dos allowedAddresses, o tronco está ativado, o projeto dele está ativo e o
número corresponde a um dos allowedDestinations (ou a lista está vazia). A
chamada conta para o mesmo limite por minuto de chamadas realizadas que as
chamadas feitas pela API a partir dessa sessão.
O tronco faz o claim de toda chamada que faz. O seu PBX recebe:
Toda recusa de autenticação é o mesmo
403, então a resposta não revela qual
verificação falhou. Falhas repetidas de autenticação bloqueiam temporariamente
o endereço de origem. Quando o seu PBX cancela uma chamada que está tocando, a
chamada do WhatsApp termina. Quando o seu PBX desliga uma chamada conectada, a
chamada termina para todos.
Mídia e segurança
- Codecs. PCMU e PCMA (8 kHz) e Opus (48 kHz, mono), na ordem de
codecs. Para Opus, anuncieopus/48000/2no SDP; o áudio continua mono. Se um mapeamento de Opus for inutilizável, um codec PCMU ou PCMA oferecido pode transportar a chamada. O seu PBX precisa oferecer mídia no INVITE inicial; chamadas sem oferta são recusadas com488. As respostas a chamadas da Polymorfa precisam manter o número de carga RTP de um codec oferecido. Alterações de mídia durante a chamada são recusadas. - Pacotes. 20 ms de áudio por pacote RTP.
- Criptografia. Com
tls, a sinalização é criptografada e a mídia usa SRTP com chaves SDES (AES_CM_128_HMAC_SHA1_80ouAES_CM_128_HMAC_SHA1_32). Ofertas de RTP simples sobre TLS e ofertas de SRTP sobre UDP ou TCP são recusadas. Usetlsquando o seu PBX estiver acessível pela internet. - Endereços. Envie mídia a partir do endereço na descrição de sessão do seu PBX ou a partir do endereço de onde vem a sua sinalização. A Polymorfa envia a mídia de volta ao endereço de onde chega o seu primeiro pacote de mídia.
- PBX atrás de NAT. Um endereço privado (
10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,100.64.0.0/10oufc00::/7) na descrição de sessão só funciona quando a sua sinalização vem de um endereço público. Nesse caso, a Polymorfa não envia mídia até que o primeiro pacote de mídia do seu PBX chegue desse endereço de sinalização, então o seu PBX precisa começar a enviar mídia. - Endereços recusados. Descrições de sessão com um endereço de mídia de
loopback, link-local, multicast, não especificado ou reservado são recusadas:
a chamada do seu PBX recebe
488, e uma chamada para o seu PBX termina comsip_unavailable. Destinos de tronco em endereços privados, de loopback ou link-local são rejeitados.
Gerencie os troncos
PATCHaltera apenas os campos que você envia. OmitaauthPasswordpara manter a senha armazenada; envieauthUsername: nullpara remover os dois. EnvieexpectedRevisionpara recusar a alteração com409 sip_trunk_revision_conflictquando outra pessoa tiver alterado o tronco antes.- Mudar
directionparaoutboundremove as credenciais de entrada. Mudar um troncooutboundparainboundoubothcria um novo usuário; faça a rotação das credenciais dele para obter a senha. - A rotação de credenciais substitui a senha. A senha antiga deixa de funcionar
em cerca de um minuto. A rotação retorna
409 state_conflictpara troncosoutbound. - Excluir um tronco para o qual uma sessão ainda envia chamadas retorna
409 sip_trunk_in_use. Antes, faça a sessão voltar a usarclients. - As alterações chegam ao roteamento de chamadas em cerca de um minuto. As chamadas em andamento continuam.
- Quando o projeto de um tronco é desativado, alterar o tronco ou fazer a
rotação das credenciais dele retorna
404 resource_not_found. A Polymorfa deixa de enviar chamadas ao tronco e recusa as chamadas do PBX dele em cerca de um minuto. Você ainda pode listar, ler e excluir o tronco.
Erros
Consulte Erros para o formato completo de erro.