Pular para o conteúdo principal
Um tronco SIP conecta um sistema telefônico que você já opera, como um PBX ou uma plataforma de central de atendimento, às chamadas do WhatsApp de um número conectado. As chamadas recebidas do WhatsApp podem tocar no seu PBX, e o seu PBX pode ligar para usuários do WhatsApp pelo número. A Polymorfa não hospeda um PBX e não fornece números de telefone. Os troncos SIP fazem parte das Chamadas. Toda equipe que usa as Chamadas pode criar troncos em qualquer um dos seus projetos; não é preciso se inscrever. No Console, proprietários e administradores da equipe adicionam, alteram e excluem troncos. Leia o endereço SIP e as portas aos quais o seu PBX se conecta pela API ou pelo Console; consulte Encontre o endereço SIP.

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 com GET /platform/sip/endpoint. Ele exige sessions:read e aceita uma chave de equipe ou um token de projeto:
A resposta descreve o ambiente ao qual a sua chave pertence, então use os valores que ela retorna em vez dos marcadores acima. 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 host resolve.
  • Permita UDP nos dois sentidos entre as portas de mídia do seu PBX e o intervalo rtp nos mesmos endereços.
  • Prefira tls: ele criptografa a sinalização, e a exigência de SRTP dele criptografa o áudio. udp e tcp transportam os dois sem criptografia.
Você também encontra o endereço no Console, na página Troncos SIP, ou pode lê-lo com sipTrunks.endpoint() no SDK TypeScript.

Crie um tronco

A resposta retorna 201 com o tronco e, para troncos inbound e both, inboundCredentials:
A senha de entrada aparece apenas nesta resposta e em uma resposta de rotação de credenciais. Guarde-a no seu PBX imediatamente. As respostas nunca retornam senhas de novo; outbound.hasPassword mostra se há uma senha armazenada.
Um projeto comporta até 100 troncos. Cada tronco transporta no máximo maxConcurrentCalls chamadas ao mesmo tempo (de 1 a 500, padrão 30).

Envie chamadas do WhatsApp para o seu PBX

Defina estes campos em outbound: Depois, roteie as chamadas recebidas da sessão para o tronco:
O tronco precisa pertencer ao projeto da sessão e ter a direção 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>. Com sipClaim: true, o atendimento faz o claim da chamada: os outros participantes param de tocar e não podem entrar. Com sipClaim: 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.
O evento 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 host e uma porta de Encontre o endereço SIP;
  • inboundCredentials.username e password para 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 prefixo 00 é aceito.
Defina 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, anuncie opus/48000/2 no 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 com 488. 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_80 ou AES_CM_128_HMAC_SHA1_32). Ofertas de RTP simples sobre TLS e ofertas de SRTP sobre UDP ou TCP são recusadas. Use tls quando 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/10 ou fc00::/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 com sip_unavailable. Destinos de tronco em endereços privados, de loopback ou link-local são rejeitados.

Gerencie os troncos

  • PATCH altera apenas os campos que você envia. Omita authPassword para manter a senha armazenada; envie authUsername: null para remover os dois. Envie expectedRevision para recusar a alteração com 409 sip_trunk_revision_conflict quando outra pessoa tiver alterado o tronco antes.
  • Mudar direction para outbound remove as credenciais de entrada. Mudar um tronco outbound para inbound ou both cria 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_conflict para troncos outbound.
  • 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 usar clients.
  • 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.