51 — Ramais, perfis e tronco NVoIP¶

Guia de operação. Senhas, PIN, token e usuário do tronco ficam fora desta página. O checklist da stack sai em suporte.orbitall.app. O manual do Supervisor continua em docs.orbitall.app.

Há dois PABX. A faixa de ramal é a mesma. O tronco principal da NVoIP fica na VPS. O Issabel 5 do lab atende a mesma numeração interna e, quando um ramal extra da NVoIP tiver credencial própria, o menu da casa.

Ambiente	Onde	Painel	Tronco
VPS Hostinger	Issabel 4, container `issabel-prod`	`https://pbx.orbitall.app/`	`nvoip-trunk` — número principal
Lab	Issabel 5, `192.168.1.251`	`https://192.168.1.251/`	o mesmo script, só se `TRUNK_USER` estiver no `.env`

Relacionados: 44 — lab homologação · 06 — Issabel · 14 — WebRTC · 19 — Webphone Lorentz.

Mapa¶

Faixa	Perfil	Transporte	Quem atende
401–405	URA Lorentz	`chan_sip` UDP 5060	`LorentzUra.exe` via `Accounts.txt`
410–411	Softphone de teste	`chan_sip` UDP 5060	MicroSIP ou outro SIP de mesa
420–421	Webphone do Issabel	WebRTC, `wss://…/phone/ws`	navegador em `/phone/`
1001–1005	Agente	`chan_sip` UDP 5060 e CTI TCP 8000	LorentzCliente, ou o Webphone Lorentz na porta 8081
8000	Menu da casa	só dialplan, no lab	contexto `casa-haos`

401–405, 410–411 e 1001–1005 nascem como peers SIP. Não têm página de login. 420 e 421 são outra coisa: um ramal WebRTC mais um usuário do Issabel. O 8000 não é aparelho nem usuário.

Onde cada um entra¶

URA — 401 a 405¶

Não abre painel. O serviço lê C:\URA\Accounts.txt. Cada canal é uma linha:

0;401;<IP_DO_PABX>;401;<SENHA_DO_ARQUIVO>;Panasonic;C:\URA\Audio;C:\URA\Fluxo\menu.arv;

O terceiro campo é o IP do Issabel (2.25.92.168 na VPS, 192.168.1.251 no lab). O quarto é o usuário SIP, igual ao ramal. A senha sai do arquivo privado do host, citado no fim desta página.

O peer usa from-internal, G.711 (ulaw/alaw) e DTMF RFC 2833. Discando 401 a partir de um softphone do mesmo PABX, o serviço URA precisa estar registrado nesse ramal para a chamada completar.

Novo canal: o número entra na lista de lote e ganha uma linha nova no Accounts.txt. Reinicie o serviço da URA depois de gravar o arquivo.

Softphone — 410 e 411¶

App SIP no computador ou no celular da LAN. Não usa o menu do Issabel.

Campo no MicroSIP	Valor
Servidor	IP do PABX, porta 5060 UDP
Usuário	`410` ou `411`
Senha	a do arquivo privado desse ramal
Transporte	UDP

Serve para ouvir áudio e mandar DTMF sem abrir a URA nem o Cliente. Do 410, disque 1001 para o agente ou 401 para a URA.

Novo softphone de teste: escolha um número fora de 401–405, 420–421 e 1001–1005, coloque na lista de lote e aponte o app para esse usuário.

Webphone do Issabel — 420 e 421¶

Este é o telefone em https://<painel>/phone/. No lab: https://192.168.1.251/phone/.

Criar o peer SIP não basta. O módulo lê o ramal gravado no usuário do Issabel.

Em PBX → Extensões, crie o ramal com WebRTC ligado. No Issabel 5 o atalho do tema abre /admin/config.php?display=extensions dentro do quadro myframe.
Em Usuários (index.php?menu=userlist), o usuário recebe esse número no campo de ramal.
Quem só atende pelo navegador entra no grupo Webphone. Quem administra o painel pode ficar no grupo administrador e ainda assim ter ramal.
Um usuário carrega um ramal. O segundo aparelho pede outro usuário.

Usuário no lab	Ramal	Grupo	Entrada
`admin`	420	administrador	`https://192.168.1.251/phone/` com a senha do painel
`lab421`	421	Webphone	a mesma URL, senha no arquivo privado do webphone

A administração do módulo fica em index.php?menu=webphone. A tabela precisa mostrar o usuário e o ramal. Sem WebRTC no ramal, os controles do telefone ficam desligados. O navegador precisa da permissão de microfone nessa página; o teclado da chamada segue mesmo assim, porque DTMF não usa o microfone.

O WebSocket do módulo no lab é wss://192.168.1.251/phone/ws. O Apache encaminha para o Asterisk em 127.0.0.1:8088. O lorentz-webphone (http://192.168.1.250:8081/) usa esse mesmo WebSocket. O peer precisa de transporte wss, AVPF, ICE, DTLS e opus. No lab isso está em 420, 421 e 430. 401–405, 410–411 e 1001–1005 são SIP UDP: servem URA, MicroSIP e LorentzCliente, e não registram no webphone enquanto o perfil WebRTC não existir neles.

Na VM, como root:

python3 scripts/analyze-ramais-telefonia.py --webphone-url http://192.168.1.250:8081/

A saída lista o registro, o app apto e o que falta. Senha não aparece.

Agente — 1001 a 1005¶

Dois logins, em dois programas.

Voz. O LorentzCliente registra o SIP no Issabel. No Cliente Lorentz.ini: servidor SIP = IP do PABX, usuário = 1001 … 1005, senha = a do arquivo privado, codec G.711, DTMF RFC 2833.

CTI. O mesmo INI aponta o Lorentz Server em TCP 8000 (Phoenix do Supervisor em TCP 3000). O login do Supervisor (https://supervisor.orbitall.app/) é um usuário do banco LorentzCTI, não a senha SIP do ramal.

O Webphone Lorentz (porta 8081, guia 19) usa o mesmo ramal de agente por WSS na porta 8089. É outro produto: não é a página /phone/ do Issabel.

Novo agente:

Inclua o número na lista de lote (SIP).
Cadastre a pessoa no Supervisor, com esse ramal.
Grave o INI na estação: SIP + IP:8000.

Sem o passo 2 a pessoa registra o telefone e o painel de operador não a vê como agente.

Só no lab, contexto casa-haos. De qualquer ramal já registrado nesse PABX, disque 8000. Não há usuário nem peer 8000. Tecla e fala: 52 — URA da casa com voz. O ramal extra registra só nesta VM; o tronco principal fica na VPS. Requisitos e a ordem do register: URA da casa no labmini.

Cadastrar em lote¶

Três caminhos. Nenhum deles cria o usuário do /phone/.

Issabel 4 (container na VPS)¶

Lista texto, uma linha por ramal, numero|Nome:

401|URA 401
410|Softphone Lab 410
1001|Agente 1001

bash scripts/sync-issabel-extensions.sh --list-file /caminho/ramais.txt

O PHP grava users, devices e sip, roda retrieve_conf e recarrega SIP e dialplan. Senha nova vai para /root/lorentz-issabel4-ramais.txt dentro do container issabel-prod. No host da VPS esse caminho não existe. A leitura é:

docker exec issabel-prod cat /root/lorentz-issabel4-ramais.txt

Rodar de novo mantém a senha que já existe e não apaga a senha dos outros ramais do arquivo. A saída do script não imprime senha. Os ramais aparecem em PBX → Extensões. Ramal que já existe só troca o nome. Se o 411 está na lista, o código da lista telefônica passa de 411 para *411.

Uma linha pode terminar com |webrtc. Esse perfil grava transporte wss,ws, DTLS e Opus, para o mesmo ramal registrar no Operador Web e no /mobile/.

Lote 5001–5005 e os dois lados¶

5001–5005 são Agente01–Agente05, grupo Suporte no Supervisor e ramal WebRTC no Issabel. O escritório entra pelo /cliente/ com esse ramal. O campo entra pelo /mobile/ no mesmo número. Só um aparelho fica registrado por vez.

bash scripts/sync-ramais-lados.sh --lote
bash scripts/sync-ramais-lados.sh --export-issabel
bash scripts/sync-ramais-lados.sh --export-supervisor
bash scripts/sync-ramais-lados.sh --import-issabel ramais.txt
bash scripts/sync-ramais-lados.sh --import-supervisor agentes.txt

A lista do Issabel é ramal|nome ou ramal|nome|webrtc. A do Supervisor é ramal|apelido|grupo. Nenhuma das duas traz senha. A senha SIP fica no Issabel e é copiada para SenhaPABX do funcionário. A senha de login do Supervisor fica em /root/lorentz-supervisor-agentes.txt, dentro do container lorentz-supervisor. Importar a exportação inteira do Supervisor criaria no Issabel os ramais antigos (2012, 2017, 2021). O lote usa só o arquivo dos 5000.

Planilha Bulk Extensions¶

Arquivo config/asterisk-ura/issabel-extensions-lab-homolog-12.csv. A coluna Secret está com ALTERAR_SENHA_<ramal>. Troque no arquivo local, importe em PBX → Bulk Extensions e apague a planilha com senha. Tech = sip, contexto from-internal, porta 5060, ulaw&alaw.

Issabel 5 (VM do lab)¶

Estes peers ficam em /etc/asterisk/sip_lab_peers.conf. A tela de extensões não os lista.

LAB_EXTENSIONS=401,402,403,404,405,410,411,1001,1002,1003,1004,1005 \
  bash scripts/apply-issabel5-lab.sh --skip-trunk

A primeira vez monta a senha com o prefixo LabIssabel5 mais o número. O arquivo é /root/lorentz-issabel5-ramais.txt, modo restrito. Uma segunda execução não troca senha. --regen-passwords gera de novo e invalida URA, MicroSIP e Cliente até alguém atualizar esses arquivos.

Para um número novo, acrescente-o em LAB_EXTENSIONS e rode o script de novo sem --regen-passwords.

Tronco NVoIP — principal e mais cinco¶

A conta NVoIP deste contrato tem um ramal principal e cinco ramais extras. Os números ficam no painel da NVoIP e no .env da máquina. Não entram neste guia.

O principal é um único registro SIP: peer nvoip-trunk, domínio app.nvoip.com.br, contexto de entrada from-nvoip. Quem aplica é scripts/provision-nvoip-trunk.sh (--target issabel4 na VPS, --target issabel5 no lab). Variáveis no .env, sem eco no log: TRUNK_USER, TRUNK_SECRET, TRUNK_DOMAIN, TRUNK_INBOUND_EXTEN.

Saída, nos dois PABX: disque 0 e o número. O 0 sai antes do envio ao tronco.

O que o script faz hoje com a entrada¶

TRUNK_INBOUND_EXTEN recebe toda entrada: a chamada sem DID (s) e qualquer número que venha no INVITE (_X.). Na VPS esse destino é o grupo de chamada, o mesmo de CTI_SERVICO.RamalAtendedor (grupo 600 em 27/10/2026). No lab, apply-issabel5-lab.sh ainda usa o ramal 1001 quando a variável não vem no ambiente.

O bloco reescrito está marcado por BEGIN lorentz-nvoip-route / END lorentz-nvoip-route em /etc/asterisk/extensions_custom.conf. Rodar o provisionador de novo usa o valor do .env. Se a variável faltar, o Goto já gravado permanece. O script não volta sozinho para o 1001. A montagem do call center está na página 55.

Como direcionar cada um¶

Confira no painel da NVoIP se o extra é um DID no mesmo tronco ou uma conta SIP com usuário e senha próprios.

DID no tronco principal. A NVoIP manda o número discado em ${EXTEN}. Mapa no from-nvoip, depois do provisionador, e antes de publicar o dialplan:

[from-nvoip]
exten => s,1,Goto(from-internal,DESTINO,1)
exten => NUMERO_PRINCIPAL,1,Goto(from-internal,DESTINO,1)
exten => NUMERO_EXTRA_1,1,Goto(from-internal,1002,1)
exten => NUMERO_EXTRA_2,1,Goto(casa-haos,s,1)
exten => _X.,1,Goto(from-internal,DESTINO,1)

Troque DESTINO pelo grupo de chamada ou pelo ramal (TRUNK_INBOUND_EXTEN). Troque NUMERO_PRINCIPAL e NUMERO_EXTRA_n pelo número completo que a NVoIP entrega (com ou sem DDD, como aparece no NoOp de uma ligação de teste). Sem o underline no início: underline em extensão é padrão, e um padrão largo engole os extras de novo. O último _X. é a rede de segurança: o que não estiver nomeado continua no destino de entrada. O destino interno tem de existir (grupo de chamada, 1001–1005, 401–405, ou o contexto casa-haos no lab).

Grave esse mapa num include próprio, fora do bloco lorentz-nvoip-route, para o próximo provision-nvoip-trunk.sh não apagá-lo. Inclua o contexto em extensions_custom.conf e recarregue o dialplan.

Conta SIP separada. Cada extra registra com o próprio usuário. Não reutilize TRUNK_USER: um segundo registro da mesma conta derruba o tronco principal. Um peer por extra, cada um com context próprio. O menu da casa já tem esse desenho: CASA_NVOIP_USER e CASA_NVOIP_SECRET em /etc/asterisk/casa-haos.env (modo 640), peer nvoip-casa, contexto from-nvoip-casa, que cai em casa-haos. A linha register vai para sip_registrations_custom.conf, porque o sip_custom.conf entra no sip.conf fora de [general]. Senha com @, espaço, :, ; ou # quebra essa linha e o usuário não fica Registered. Com o usuário vazio, o menu só atende o 8000 interno. scripts/configure-casa-haos.sh não mexe no nvoip-trunk da VPS. Não rode o provisionador do tronco com alvo Issabel 5 enquanto o principal estiver na VPS. Detalhe operacional: URA da casa no labmini.

Quem liga	Onde cai
Número principal, sem DID ou com o DID principal	`TRUNK_INBOUND_EXTEN` (na VPS, o grupo de chamada)
Cada um dos cinco extras, no mesmo tronco	a extensão nomeada no `from-nvoip`
Extra com usuário SIP próprio (ex.: menu da casa)	o contexto daquele peer
Ramal interno do lab disca 8000	menu da casa, sem passar pela NVoIP

Depois de uma ligação de teste:

asterisk -rx "sip show registry"
asterisk -rx "sip show peer nvoip-trunk"

O registro do principal fica Registered em app.nvoip.com.br. No log da chamada, o NoOp de from-nvoip mostra o ${EXTEN} que a NVoIP mandou: é esse valor que entra na linha do mapa.

Onde está a senha¶

Segredo	Arquivo	No git
SIP 401–411 e 1001–1005 na VPS	`config/runtime/ura-sip-passwords.txt`	não
Os mesmos no Issabel 5	`/root/lorentz-issabel5-ramais.txt`	não
Usuário webphone do lab que não é o admin	`/root/lorentz-issabel5-webphone.txt`	não
Tronco NVoIP	`.env` (`TRUNK_USER`, `TRUNK_SECRET`)	não
Token do marketplace NVoIP	`.nvoip-asterisk-provisioning`	não
Menu da casa (PIN, HA, ramal extra)	`/etc/asterisk/casa-haos.env`	não

Quem for publicar este guia não cola esses arquivos. O MkDocs só leva o Markdown.

Publicar em suporte.orbitall.app¶

Na VPS, dentro de lorentz-vps-stack:

./scripts/deploy-docs.sh

O script gera o site e copia para /var/www/lorentz-suporte. Não grava em /var/www/lorentz-docs: essa pasta é o manual do Supervisor em docs.orbitall.app. A página entra no menu Instalação e operação como 51 — Ramais, perfis e troncos. Preview local, sem publicar: ./scripts/serve-docs.sh.