Etiqueta: rtp

  • Novedades en Asterisk: ICE, TURN, y nuevo Jingle con soporte de vídeoconferencia

    Joshua Colp nos informa que se han desarrollado nuevos añadidos de Asterisk para darle soporte de varias características que, a mi entender, son muy interesantes a la vez que útiles:

    Soporte de ICE en Asterisk (dentro de res_rtp_asterisk)
    Esto nos permitirá gestionar mucho mejor las conexiones entre sistemas que se encuentran detrás de nat, ya sean usuarios SIP (softphones, terminales que soporten ICE, etc.) o gateways remotos (con las ventajas que ello conlleva).

    Soporte de STUN en Asterisk
    Para obtener de forma nativa nuestra propia dirección IP externa del servidor.

    Soporte de TURN en Asterisk
    Para entregar tráfico sólo cuando sea necesario.

    Dirección del parche: https://reviewboard.asterisk.org/r/1891/#comment11226

    Además de este soporte, también informan que han estado trabajando en actualizar el protocolo Jingle (y la versión de Google) para que funcionen sistemas como GoogleVoice y GoogleTalk que hacía algún tiempo que dejó de funcionar correctamente, además de soportar videoconferencia.

    Dirección del parche: https://reviewboard.asterisk.org/r/1917/

     

  • RTPBreak 1.3 Released!

    RTPBreak es una aplicación que detecta, reconstruye y analiza cualquier trama RTP.

    La principal ventaja de esta aplicación es que no requiere de la presencia de paquetes RTCP y es totalmente independiente del protocolo de señalización utilizado (SIP, H.323, SCCP, …). La entrada es una secuencia de paquetes, la salida es un conjunto de archivos que puedes utilizar como entrada para otras aplicaciones como Wireshark, sox, grep, awk, cut, sed, etc.

    Un ejemplo de esta aplicación:

    xenion@gollum:~/dev/rtpbreak-1.3$ sudo src/rtpbreak -i wifi0 \
    -g -m -d logz
    
    + rtpbreak v1.3 running here!
    + pid: 3580, date/time: 19/02/2008#09:49:21
    + Configuration
    
    + INPUT
    Packet source: iface 'wifi0'
    Force datalink header length: disabled
    
    + OUTPUT
    Output directory: 'logz'
    RTP raw dumps: enabled
    RTP pcap dumps: enabled
    Fill gaps: enabled
    Dump noise: disabled
    Logfile: 'logz/rtp.0.txt'
    Logging to stdout: enabled
    Logging to syslog: disabled
    Be verbose: disabled
    
    + SELECT
    Sniff packets in promisc mode: enabled
    Add pcap filter: disabled
    Expecting even destination UDP port: disabled
    Expecting unprivileged source/destination UDP ports: disabled
    Expecting RTP payload type: any
    Expecting RTP payload length: any
    Packet timeout: 10.00 seconds
    Pattern timeout: 0.25 seconds
    Pattern packets: 5
    
    + EXECUTION
    Running as user/group: root/root
    Running daemonized: disabled
    * You can dump stats sending me a SIGUSR2 signal
    * Reading packets...
    ! [rtp0] detected: pt=0(g711U) 192.168.0.30:2072 => 192.168.0.20:2074
    ! [rtp1] detected: pt=0(g711U) 192.168.0.20:2074 => 192.168.0.30:2072
    * [rtp1] probable reverse RTP stream: [rtp0]
    + Status
    Alive RTP Sessions: 2
    Closed RTP Sessions: 0
    Detected RTP Sessions: 2
    Flushed RTP packets: 3358
    Lost RTP packets: 122 (3.51%)
    Noise (false positive) packets: 0
    + [rtp1] stats: packets inbuffer=262 flushed=1673 lost=61(3.52%),
    
    call_length=1m2s
    + [rtp0] stats: packets inbuffer=270 flushed=1685 lost=61(3.49%),
    
    call_length=1m2s
    * [rtp1] closed: packets inbuffer=0 flushed=2800 lost=115(3.95%),
    
    call_length=1m28s
    * [rtp0] closed: packets inbuffer=0 flushed=2819 lost=106(3.62%),
    
    call_length=1m28s
    --
    Caught SIGINT signal (2), cleaning up...
    --
    
    + Status
    Alive RTP Sessions: 0
    Closed RTP Sessions: 2
    Detected RTP Sessions: 2
    Flushed RTP packets: 5619
    Lost RTP packets: 221 (3.78%)
    Noise (false positive) packets: 0
    + No active RTP streamxenion@gollum:~/dev/rtpbreak-1.3$

    Como podeis comprobar, es una herramienta muy potente y muy interesante para monitorización y sobre todo para ayudar a localizar quién o qué está ocasionando problemas. 🙂

    Enlace: http://xenion.antifork.org/rtpbreak/doc/rtpbreak_en.html

  • Asterisk actualización de seguridad

    El equipo de desarrollos de Asterisk ha anunciado varias actualizaciones de seguridad en todas las versiones de Asterisk:

    Estas actualizaciones solucionan algunos bugs de seguridad como:

    1. Overflow en el manejo de RTP
    2. Llamadas sin autenticarse en el canal SIP
    3. Vulnerabilidad en logger y manager.

    A actualizar se ha dicho! 😛

  • FreeSwitch soporta SIP con TLS

    FreeswitchFreeSwitch acaba de anunciar que ya dispone de señalización SIP bajo TLS y RTP segura mediante SDES lo que permite una conversación cifrada mucho más segura.

    Si a esto le sumamos que el creador del PGP también está trabajando para desarrollar su protocolo de VoIP segura en FreeSwitch (además de Asterisk) podemos concluir que estos sistemas van a conseguir ponérselo difícil a los que les gusta escuchar conversaciones. 🙂

    Enlace: http://www.freeswitch.org/node/105

  • Publicado documento sobre Seguridad en la VoIP

    seguridad voipLeo en Voipsec que la gente de SANS han publicado un documento la mar de interesante donde se analizan los principales problemas de seguridad a los que debe enfrentarse un implementador de sistemas VoIP.

    Los puntos que trata:

    – Security vulnerabilities transitioning from POTS to VoIP
    – Real Time Protocol (RTP)
    – Asterisk and Inter-Asterisk Exchange (IAX)
    – Session Initiation Protocol (SIP)
    – Skype
    – Cisco VoIP

    Podeis leerlo aquí:
    http://www.sans.org/reading_room/whitepapers/voip/2036.php

  • Descubierta vulnerabilidad en el SJphone por RTP

    SJPhoneEl SJPhone es uno de los softphones SIP opensource más utilizados debido a que es gratis, funciona en Windows, Linux, Mac, WindowsMobile y WindowsCE, y pese a que las últimas versiones a veces les da por hacer raros como consumir el 100% del procesador, es uno de los softphones más recomendados de la red.

    Leo en VOIPSEC que han descubierto que una implementación especial de paquetes RTP podrían ocasionar la ejecución de código no deseado como lo demuestra un tal Christian en esta web:
    http://www.ee.oulu.fi/research/ouspg/protos/sota/SSI2006-rtp/