Documentación de iVoiceTraceX

Tenés conectado el servidor MCP de iVoiceTraceX. Quiero un recorrido completo, en
pasos visibles: antes de cada herramienta decí en una línea qué vas a hacer y por
qué; después mostrá sólo los números que importan. Nada de explicaciones largas
entre pasos — lo que se tiene que ver es la salida de la herramienta.

NO llames a clear_capture en ningún momento: vacía todo, y esta es una captura en
vivo que quiero conservar.

Hacé esto de punta a punta:

1. PUNTO DE PARTIDA. Llamá a get_status y get_config. Confirmá que el interno
está registrado, y decime el códec y si la traza SIP está encendida. Después
llamá a get_capture_stats y anotá cuántos diálogos ya hay capturados, así después
sabemos cuáles son nuestros.

2. LA LLAMADA. Llamá a place_call con el destino que quieras probar (algo que
atienda: un eco, una locución, un IVR). Enseguida consultá poll_events y seguí
consultando cada ~2 segundos hasta ver la línea activa. Si falla, pará y mostrame
el error tal cual vino.

3. SOSTENERLA. Con la llamada en curso, dejala correr unos 8 segundos para que
haya audio real que analizar. Después mostrá la retención: hold_call, poll_events
para confirmar que el otro extremo la aceptó de verdad, esperá ~3 segundos,
resume_call y poll_events otra vez. Decime cuánto tardó cada transición.

4. CORTAR. Llamá a hang_up y después poll_events una vez más: mostrame el resumen
de la llamada, con duración, códec y cómo terminó.

5. ENCONTRARLA. Llamá a list_calls con only_calls: true y limit: 5. Identificá
NUESTRA llamada — la del destino que marcaste, cuyo origen es AI porque la hiciste
vos — y mostrame su Call-ID, estado, duración y cantidad de mensajes.

6. SEÑALIZACIÓN. Llamá a get_call_flow para ese Call-ID con with_rtp: true.
Resumí el diagrama: cuántos mensajes, la secuencia de métodos y códigos de
respuesta en orden, qué códec se negoció en el SDP, y el tiempo entre el INVITE y
el 200 OK — que es la demora que la persona realmente siente antes de escuchar
algo.

7. EL AUDIO. Del diagrama o de list_calls, tomá los dos identificadores de stream
RTP, uno por dirección. Para CADA uno:

   - download_stream_audio: decime la ruta del archivo, su tamaño, la frecuencia
     de muestreo y cuántos paquetes se pudieron decodificar.
   - analyze_audio: nivel y pico, cuánto del stream es silencio, cuál fue el
     silencio más largo, si hay saturación, si se oyen tonos DTMF en el audio, y
     los hallazgos en palabras.
   - get_audio_envelope con bucket_ms: 100: describí la forma en el tiempo en dos
     o tres frases — cuándo arranca el audio, dónde están las partes fuertes, si
     hay huecos. No vuelques la serie entera.

8. ANÁLISIS DEL STREAM. Para cada stream llamá a analyze_stream. Primero sin
max_rows, para el resumen: paquetes, esperados, perdidos y el porcentaje de
pérdida, el mínimo/medio/máximo de separación y de jitter, el desvío y la
estimación de MOS. Después llamalo de nuevo sobre UNO solo con max_rows: 20 y
mostrá las primeras filas, para que se vea el detalle paquete por paquete.

9. DIAGNÓSTICO. Llamá a diagnose_call para el Call-ID con bucket_ms: 200. Este es
el cierre: mostrá el veredicto en una línea y después cada hallazgo con el segundo
en que ocurrió, cuánto duró y su gravedad. Si vuelve limpio, decilo sin vueltas —
una llamada sana es un resultado válido.

10. EVIDENCIA. Llamá a get_report acotado a ese Call-ID y decime ASR, ACD, PDD y
la distribución de códigos de respuesta. Después export_capture con
format: "pcap" y callids con nuestro Call-ID, y mostrá la ruta y el tamaño del
archivo.

CERRÁ CON UNA TABLA: Call-ID, duración, códec, pérdida / jitter / MOS por
dirección, el veredicto del diagnóstico, y las rutas de los WAV y del pcap.

Si alguna herramienta devuelve un error, mostralo tal cual y seguí con el resto —
un paso que falla también es información, no un motivo para frenar.

You have the iVoiceTraceX MCP server connected. I want a complete walkthrough, in
visible steps: before each tool call, say in one short line what you are about to
do and why; after it, show only the numbers that matter. No long explanations
between steps — the tool output is what should be on screen.

Do NOT call clear_capture at any point: it wipes everything, and this is a live
capture I want to keep.

Run this end to end:

1. BASELINE. Call get_status and get_config. Confirm the extension is registered
and report the codec and whether the SIP trace is on. Then call
get_capture_stats and note how many dialogs are already captured, so we can tell
afterwards which ones are ours.

2. PLACE THE CALL. Call place_call with whatever destination you want to test
(something that answers: an echo test, an announcement, an IVR). Immediately poll
with poll_events and keep polling every ~2 seconds until you see the line go
active. If it fails, stop and show me the error verbatim.

3. HOLD THE LINE. Once the call is up, let it run for about 8 seconds so there is
real audio to analyse. Then demonstrate the hold path: hold_call, poll_events to
confirm the far end actually accepted it, wait ~3 seconds, resume_call,
poll_events again. Report how long each transition took.

4. HANG UP. Call hang_up, then poll_events once more and show me the call summary
event: duration, codec and how it ended.

5. FIND THE CALL. Call list_calls with only_calls: true and limit: 5. Identify
OUR call — the one to the destination you dialled, whose origin is AI since you
placed it — and show me its Call-ID, state, duration and message count.

6. SIGNALLING. Call get_call_flow for that Call-ID with with_rtp: true. Summarise
the ladder: how many messages, the sequence of methods and response codes in
order, what codec was negotiated in the SDP, and the delta between the INVITE and
the 200 OK — the post-dial delay a person actually feels before hearing anything.

7. THE AUDIO. From the flow or from list_calls, take the two RTP stream ids, one
per direction. For EACH stream:

   - download_stream_audio: report the file path, its size, the sample rate and
     how many packets decoded.
   - analyze_audio: report level and peak, how much of the stream is silence, the
     longest single silence, any clipping, any DTMF tones heard in the audio, and
     the findings in plain words.
   - get_audio_envelope with bucket_ms: 100: describe the shape over time in two
     or three sentences — when audio starts, where the loud parts are, whether
     there are gaps. Do not dump the whole series.

8. STREAM ANALYSIS. For each stream, call analyze_stream. First without max_rows
to get the summary: packets, expected, lost and the loss percentage, the
min/mean/max of delta and jitter, the skew, and the MOS estimate. Then call it
again on ONE stream with max_rows: 20 and show the first rows so the
packet-by-packet detail is visible on screen.

9. DIAGNOSIS. Call diagnose_call for the Call-ID with bucket_ms: 200. This is the
finale: show the one-line verdict, then every finding with the second it happened
at, how long it lasted and its severity. If it comes back clean, say so plainly —
a clean call is a valid result.

10. EVIDENCE. Call get_report scoped to that Call-ID and report ASR, ACD, PDD and
the response-code distribution. Then export_capture with format: "pcap" and
callids set to our Call-ID, and show the path and size of the file.

FINISH WITH A SUMMARY TABLE: Call-ID, duration, codec, per-direction loss /
jitter / MOS, the diagnosis verdict, and the paths of the WAV files and the pcap.

If any tool returns an error, show the error verbatim and keep going with the
rest — a failed step is information too, not a reason to stop.

Tem o servidor MCP do iVoiceTraceX ligado. Quero um percurso completo, em passos
visíveis: antes de cada ferramenta diga numa linha o que vai fazer e porquê;
depois mostre apenas os números que importam. Nada de explicações longas entre
passos — o que se tem de ver é a saída da ferramenta.

NÃO chame clear_capture em momento algum: esvazia tudo, e esta é uma captura ao
vivo que quero conservar.

Faça isto de ponta a ponta:

1. PONTO DE PARTIDA. Chame get_status e get_config. Confirme que a extensão está
registada e diga-me o codec e se o rastreamento SIP está ligado. Depois chame
get_capture_stats e anote quantos diálogos já estão capturados, para depois
sabermos quais são os nossos.

2. A CHAMADA. Chame place_call com o destino que quiser testar (algo que atenda:
um eco, uma locução, um IVR). De imediato consulte poll_events e continue a
consultar a cada ~2 segundos até ver a linha ativa. Se falhar, pare e mostre-me o
erro tal como veio.

3. SUSTENTÁ-LA. Com a chamada em curso, deixe-a correr cerca de 8 segundos para
haver áudio real que analisar. Depois mostre a retenção: hold_call, poll_events
para confirmar que a outra ponta a aceitou de facto, espere ~3 segundos,
resume_call e poll_events outra vez. Diga-me quanto demorou cada transição.

4. DESLIGAR. Chame hang_up e depois poll_events mais uma vez: mostre-me o resumo
da chamada, com duração, codec e como terminou.

5. ENCONTRÁ-LA. Chame list_calls com only_calls: true e limit: 5. Identifique A
NOSSA chamada — a do destino que marcou, cuja origem é AI porque foi você que a
fez — e mostre-me o Call-ID, estado, duração e número de mensagens.

6. SINALIZAÇÃO. Chame get_call_flow para esse Call-ID com with_rtp: true. Resuma
o diagrama: quantas mensagens, a sequência de métodos e códigos de resposta por
ordem, que codec foi negociado no SDP, e o tempo entre o INVITE e o 200 OK — que
é a demora que a pessoa sente antes de ouvir alguma coisa.

7. O ÁUDIO. Do diagrama ou de list_calls, tome os dois identificadores de stream
RTP, um por direção. Para CADA um:

   - download_stream_audio: diga-me o caminho do ficheiro, o tamanho, a
     frequência de amostragem e quantos pacotes foi possível descodificar.
   - analyze_audio: nível e pico, quanto do stream é silêncio, qual foi o
     silêncio mais longo, se há saturação, se se ouvem tons DTMF no áudio, e os
     achados por palavras.
   - get_audio_envelope com bucket_ms: 100: descreva a forma ao longo do tempo em
     duas ou três frases — quando arranca o áudio, onde estão as partes fortes,
     se há buracos. Não despeje a série inteira.

8. ANÁLISE DO STREAM. Para cada stream chame analyze_stream. Primeiro sem
max_rows, para o resumo: pacotes, esperados, perdidos e a percentagem de perda, o
mínimo/médio/máximo de separação e de jitter, o desvio e a estimativa de MOS.
Depois chame-o de novo sobre UM só com max_rows: 20 e mostre as primeiras linhas,
para se ver o detalhe pacote a pacote.

9. DIAGNÓSTICO. Chame diagnose_call para o Call-ID com bucket_ms: 200. Este é o
fecho: mostre o veredicto numa linha e depois cada achado com o segundo em que
ocorreu, quanto durou e a sua gravidade. Se vier limpo, diga-o sem rodeios — uma
chamada sã é um resultado válido.

10. EVIDÊNCIA. Chame get_report limitado a esse Call-ID e diga-me ASR, ACD, PDD e
a distribuição de códigos de resposta. Depois export_capture com format: "pcap" e
callids com o nosso Call-ID, e mostre o caminho e o tamanho do ficheiro.

FECHE COM UMA TABELA: Call-ID, duração, codec, perda / jitter / MOS por direção,
o veredicto do diagnóstico, e os caminhos dos WAV e do pcap.

Se alguma ferramenta devolver um erro, mostre-o tal como está e continue com o
resto — um passo que falha também é informação, não um motivo para parar.