Horus ISP
Ecosistema
Plataforma
Soluciones
Preguntas
Novedades
Ver todoVideo sintético: revisión de evidencia como servicio del ISPDe ingresos de IA a margen por cámaraNVIDIA PAIR: evaluar inferencia local de eventos en el ISPVender mejoras verificadas de video analyticsOTel 2.0: operar IA dentro del datacenter del ISPMTN combina datacenter y red: una lectura para el ISP multisedeSK Horizon: invertir en datacenter a partir de servicios contratadosConectividad de IA: cómo convertir la red del ISP en un servicio visualKumul Cloud Infinity: el valor comercial de conservar el video cercaAT&T empaqueta video inteligente gestionado con edge y cloudLa AI telco pasa de piloto a ingresoLa soberanía SaaS se convierte en palanca de pricingZankore convierte la infraestructura AI del operador en activo comercialMedir latencia antes de fijar región y arquitecturaFiberCop convierte exchanges en una red nacional de edge datacentersTelefónica vuelve concreta la operación autónoma para servicios visualesAgentes de video contextuales convierten imágenes en acciónLa infraestructura AI telco ya tiene un playbook comercialUn knowledge plane privado mejora control y costosEl edge como plataforma de physical AI reduce el costo por dispositivoAI datacenter del ISP como plataforma rentableClosed loops hibridos para operar servicios visualesDigital twins para bajar MTTR en servicios visualesMonetizacion por consumo para servicios visuales AIDatos telco verificados para escalar AI confiableEficiencia AI en el datacenter del ISPSuper-resolucion de video como add-on premiumEl sitio telecom se convierte en hub edge para servicios visualesInferencia soberana distribuida para servicios visualesUn stack autonomo hibrido para bajar OPEX visualUna base AI telco-grade vuelve operables los servicios del ISPAgentes AI gobernados para operar servicios visualesData fabric unificado para escalar Horus ISPAutomatizacion unificada de baja latencia para servicios visualesEdge soberano como playbook para servicios visuales del ISPGobierno y assurance para servicios visuales soberanosEl datacenter del ISP como base para AI soberanaIngresos AI exigen servicios edge operables para ISPsControles soberanos auditables para servicios visuales reguladosSoberania como servicio para ISPs con Horus ISPSoberania AI y busqueda semantica como servicioEdge federado soberano como playbook comercialVideo intelligence mas facil de productizarDatacenters de IA y cloud soberana como nuevo negocioEdge privado y soberania como playbook de monetizacionUplink de video estable y edge eficiente para servicios criticosLa red del ISP como plataforma de IA física distribuidaArquitectura híbrida resiliente para nodos Horus ISP en el ISPAnalítica de video con costos y latencia bajo controlBúsqueda semántica de video a escala: un servicio premium para el ISPInferencia de cámaras con menor costo: una ruta para mejorar margen en video analyticsBúsqueda semántica sobre videotecas del ISP: de grabación pasiva a evidencia premiumAlta disponibilidad edge desde dos nodos: una base pragmática para lanzar servicios Horus ISPQué puede aprender un ISP del nuevo stack de video con IASoberanía de datos y menor costo de IA: por qué el datacenter del ISP gana pesoNo toda analítica de video debe correrse igualSi la IA será un nuevo ingreso telco, el ISP necesita un primer servicio vendibleInferencia distribuida Smart-X: repartir la IA mejora el costo total del servicioEdge AI no es moda telco: es una vía para crear ofertas rentables de videoEdge video analytics: procesar antes de subir protege margen y privacidadEdge, video analytics y nuevos servicios: qué vamos a seguir en esta secciónEl datacenter del ISP como nueva capa de inteligencia visualOpen Telco AI: modelos evaluables para servicios ISP gobernadosAI grids telco: cómo monetizar infraestructura ISP con video analyticsLa IA telco tiene ROI cuando se convierte en servicio operable
NosotrosContacto

Troubleshooting móvil

Guía inicial para que la primera línea del ISP atienda errores comunes de la aplicación móvil y documente casos antes de escalarlos a Horus.

Troubleshooting móvil

Objetivo

Este documento sirve como base de troubleshooting para la aplicación móvil. Parte de los errores comunes que puede ver el usuario final y define qué debe validar la primera línea del ISP antes de escalar un ticket a Horus.

La guía está pensada para crecer con el soporte: cada incidente repetido o caso resuelto por Horus puede convertirse luego en una entrada más específica.

Información mínima del caso

Antes de diagnosticar, registrar:

  • Usuario o email afectado.
  • Cliente, sitio, instancia o Horus afectado.
  • Modelo de teléfono y sistema operativo.
  • Versión de la aplicación instalada.
  • Fecha y hora aproximada del error.
  • Código visible en la aplicación, si está disponible.
  • Acción que intentaba realizar el usuario.
  • Red utilizada: WiFi del cliente, datos móviles u otra red.
  • Capturas de pantalla o video corto del flujo, cuando sea posible.

Validaciones iniciales

Primero confirmar condiciones generales:

  • Que el teléfono tenga conexión a internet.
  • Que la app esté actualizada desde la tienda correspondiente.
  • Que el usuario pueda cerrar y abrir sesión nuevamente.
  • Que el usuario esté operando sobre el sitio o Horus correcto.
  • Que los permisos del usuario no hayan cambiado.
  • Que otros usuarios del mismo sitio tengan o no el mismo problema.
  • Que el problema ocurra tanto en WiFi como en datos móviles.

Si el error desaparece al cambiar de red, reiniciar la aplicación o actualizarla, registrar la acción aplicada y cerrar el caso con esa evidencia.

Conectividad y disponibilidad

Errores relacionados: E103, E104, E113, R502, R503, R599, TIMEOUT, X167.

Síntomas habituales:

  • La app informa problemas de conexión a internet.
  • No hay conexión con el servidor.
  • El servicio aparece no disponible.
  • El dispositivo o Horus no responde.
  • El servidor no pudo procesar la solicitud.

Acciones de primera línea:

  • Pedir al usuario que pruebe con datos móviles y luego con WiFi.
  • Confirmar si otros servicios del teléfono navegan correctamente.
  • Cerrar y volver a abrir la aplicación.
  • Validar si el problema afecta a un solo usuario, a un sitio completo o a varios clientes.
  • Verificar si el Horus, gateway o dispositivo local tiene energía y conectividad.
  • Registrar fecha, hora, red utilizada y alcance del impacto.

Escalar a Horus si el error se mantiene en más de una red, afecta a varios usuarios o aparece como indisponibilidad del cloud, servidor o Horus.

Login, sesión y credenciales

Errores relacionados: R401, R410, E105, X017, X026, X063, X065, X111, X123, X124, X155.

Síntomas habituales:

  • Usuario o contraseña inválidos.
  • Sesión expirada o inválida.
  • Email ya registrado o inexistente.
  • PIN inválido o ya utilizado.
  • Usuario revocado.
  • Password actual incorrecta o nueva password fuera de política.

Acciones de primera línea:

  • Confirmar que el usuario esté usando el email correcto.
  • Validar si el usuario existe en la cuenta o instancia esperada.
  • Indicar recuperación de contraseña cuando corresponda.
  • Pedir que cierre sesión, cierre la app y vuelva a ingresar.
  • Confirmar que no haya intentos repetidos que generen bloqueo temporal.
  • Verificar si el usuario fue revocado o si perdió permisos.

Escalar a Horus si el usuario existe, las credenciales fueron restablecidas y el acceso sigue fallando, o si el mensaje indica revocación, sesión inconsistente o bloqueo no explicado.

Versión de aplicación e idioma

Errores relacionados: E084, I085, I086.

Síntomas habituales:

  • La versión instalada ya no está soportada.
  • Existe una nueva versión disponible.
  • El idioma no cambia hasta reiniciar la app.

Acciones de primera línea:

  • Solicitar actualización desde la tienda oficial.
  • Confirmar la versión instalada luego de actualizar.
  • Pedir cerrar completamente la aplicación y volver a abrirla.
  • En cambios de idioma, validar luego del reinicio de la app.

Escalar a Horus solo si el usuario ya actualizó y la app sigue indicando versión no soportada o no puede iniciar correctamente.

Cámaras, gateway y descubrimiento

Errores relacionados: E095, E096, E097, E111, E112, E114, E117, E118, E119, E120, E121, E122, E123, E124, E125, E126, X012, X130, X159.

Síntomas habituales:

  • No se encuentran cámaras.
  • La cámara no responde o no está disponible.
  • El gateway no tiene conexión.
  • La red WiFi seleccionada no es la correcta.
  • El dispositivo no está en modo discovery.
  • La cámara ya existe en la instancia.
  • La cámara no es compatible o no usa codec H264.

Acciones de primera línea:

  • Confirmar que el teléfono esté conectado a la red indicada durante el alta.
  • Verificar que el dispositivo o gateway tenga energía y conexión.
  • Confirmar que el dispositivo esté con configuración de fábrica cuando el flujo lo requiera.
  • Validar que haya un solo dispositivo en condición de discovery.
  • Revisar SSID y password ingresados por el usuario.
  • Confirmar si la cámara ya fue agregada previamente.
  • Revisar compatibilidad básica de la cámara, especialmente codec H264.

Escalar a Horus si el dispositivo cumple las condiciones de red y discovery, pero el alta o acceso a cámara falla de forma repetida, o si se sospecha un problema de compatibilidad.

Grabaciones y visualización

Errores relacionados: E115, E116, X153.

Síntomas habituales:

  • No hay grabaciones disponibles para el día y horario seleccionado.
  • La app no puede recuperar grabaciones.
  • No se encuentra una sesión en el streamer.

Acciones de primera línea:

  • Confirmar fecha, hora y zona horaria consultada.
  • Validar que la cámara tenga grabación habilitada para ese período.
  • Revisar si la cámara estuvo conectada durante el horario solicitado.
  • Probar otro rango horario o una cámara distinta del mismo sitio.
  • Registrar si el problema afecta solo grabaciones o también visualización en vivo.

Escalar a Horus si la grabación debería existir, otros usuarios tampoco pueden acceder o el error se repite sobre diferentes horarios.

Permisos, sitio e instancia

Errores relacionados: R423, X095, X102, X126, X127, X128, X132, X168, X169, X170.

Síntomas habituales:

  • El usuario no tiene permisos para la acción solicitada.
  • La instancia, sitio o Horus no aparece.
  • El Horus no fue configurado o no pudo asociarse al usuario.
  • No se recuperan instancias o pestañas del dashboard.

Acciones de primera línea:

  • Confirmar que el usuario esté operando sobre el sitio correcto.
  • Verificar rol y permisos del usuario.
  • Confirmar que el Horus esté configurado y asociado a la cuenta correcta.
  • Validar si otro usuario administrador puede ver o modificar el recurso.
  • Registrar qué acción exacta intentó ejecutar el usuario.

Escalar a Horus si los permisos parecen correctos y la aplicación no recupera instancias, pestañas o recursos que deberían estar disponibles.

Errores desconocidos o internos

Errores relacionados: error sin código, R4, R5, R400, R404, R408, X054, X056, A.

Síntomas habituales:

  • La aplicación muestra un error desconocido.
  • La solicitud no existe, está mal confeccionada o no pudo procesarse.
  • Hay errores internos al acceder a datos o ejecutar acciones.

Acciones de primera línea:

  • Registrar el código exacto y el texto mostrado.
  • Pedir captura de pantalla.
  • Documentar la acción previa al error paso por paso.
  • Confirmar si el error es reproducible.
  • Probar cerrar la app, abrirla nuevamente y repetir el flujo.

Escalar a Horus cuando el error sea reproducible, no tenga una acción correctiva clara o parezca asociado a datos, servidor o comportamiento interno de la plataforma.

Plantilla de ticket para Horus

Cuando corresponda escalar, crear el ticket en https://support.fidumtec.com con esta estructura:

  • Código de error:
  • Texto mostrado por la app:
  • Usuario/email:
  • Cliente, sitio, instancia o Horus:
  • Versión de app:
  • Teléfono y sistema operativo:
  • Red utilizada:
  • Fecha y hora:
  • Acción que intentaba realizar:
  • Pasos de troubleshooting realizados por el ISP:
  • Resultado de cada prueba:
  • Alcance: un usuario, varios usuarios, un sitio o varios sitios:
  • Evidencia adjunta:

Criterio de evolución del documento

Cada vez que soporte detecte un caso frecuente, conviene agregar una entrada específica con:

  • Código o síntoma.
  • Causa más probable.
  • Validaciones de primera línea.
  • Acción recomendada para el usuario.
  • Evidencia requerida para Horus.
  • Criterio de escalamiento.