Páginas relacionadas.
Monday, July 31, 2017
Friday, July 28, 2017
Verizon Caught Blocking VoIP Traffic
I was just on a phone call with a new customer who is setting up
multiple retail locations. The reason for the call was their backup
network wasn’t working. Whenever they tested the Verizon 4G LTE
Wireless connected to Cradlepoint modem backup network, the phones would
not be able to make or receive phone calls.
Their IT staff was on the line and they were running Wireshark and grabbed a PCAP that seems to show that OnSIP at 199.7.175.101 was responding to their request with a “500 Server Error”.


The actual text was:
SIP/2.0 500 Server Internal Error
Warning: 399 sipalg “Internal Error”
Call-ID: b876f6fb4aad25a55546217e07dd4f82
CSeq: 47 REGISTER
From: “Store 032”;tag=50A423BA-17AAB00B
To:;tag=s772+1+41390005+52871245
Via: SIP/2.0/UDP 10.2.32.238:6050;received=174.201.22.7;rport=9710;branch=z9hG4bKd5770b4F5466015
Content-Length: 0
The only problem was that the packet did not come from OnSIP. The smoking gun in the second line which references the “sipalg”. Even though the PCAP shows the packet as coming from OnSIP, it really comes from the Verizon SIP ALG running on their network or running on the Cradlepoint router.
Not only are they blocking the traffic, but they’re making it look like the provider is actually the one refusing it. At least if you’re going to block traffic, let everyone know who is doing it.
HTTP traffic from the same device to the same network goes through without an issue, only the SIP traffic is refused.
Is this the future of Net Neutrality? We saw this behavior a few years ago and it appears to still be an issue.
Fuente original: http://www.un-ceo.com/2017/07/19/verizon-caught-blocking-voip-traffic/?utm_content=58253975&utm_medium=social&utm_source=twitter
Their IT staff was on the line and they were running Wireshark and grabbed a PCAP that seems to show that OnSIP at 199.7.175.101 was responding to their request with a “500 Server Error”.


The actual text was:
SIP/2.0 500 Server Internal Error
Warning: 399 sipalg “Internal Error”
Call-ID: b876f6fb4aad25a55546217e07dd4f82
CSeq: 47 REGISTER
From: “Store 032”
To:
Via: SIP/2.0/UDP 10.2.32.238:6050;received=174.201.22.7;rport=9710;branch=z9hG4bKd5770b4F5466015
Content-Length: 0
The only problem was that the packet did not come from OnSIP. The smoking gun in the second line which references the “sipalg”. Even though the PCAP shows the packet as coming from OnSIP, it really comes from the Verizon SIP ALG running on their network or running on the Cradlepoint router.
Not only are they blocking the traffic, but they’re making it look like the provider is actually the one refusing it. At least if you’re going to block traffic, let everyone know who is doing it.
HTTP traffic from the same device to the same network goes through without an issue, only the SIP traffic is refused.
Is this the future of Net Neutrality? We saw this behavior a few years ago and it appears to still be an issue.
Fuente original: http://www.un-ceo.com/2017/07/19/verizon-caught-blocking-voip-traffic/?utm_content=58253975&utm_medium=social&utm_source=twitter
Wednesday, July 19, 2017
Instalando freeswitch en netbsd 8.0.
Ejecutamos el comando para obtener pkgsrc, en este caso a traves de CVS.
Compilamos las siguientes dependencias:
git automake autoconf libtool gmake jpeg pcre speex openssl ncurses sqlite3 ldns speex speexdsp srtp libopus
Tomando en cuenta de cambiar al directorio de /usr/pkgsrc/
Ejecutamos el comando mozilla-rootcerts install, con el proposito de hacer posible las conexiones ssl
Ahora nos toca obtener el codigo fuente de freeswitch:
git clone https://stash.freeswitch.org/scm/fs/freeswitch.git
CC=gcc
LD_LIBRARY_PATH="/usr/pkg/lib"
export LDFLAGS="-L/usr/pkg/lib -I/usr/pkg/include"
CFLAGS="-Wno-error -std=gnu99"
Luego iniciamos el proceso de compilacion
cd freeswitch
./bootstrap.sh -j
./configure --prefix=/usr/pkg
gmake
Nos lanzara un error en la seccion de srtp, por lo que cambiamos al directorio
cd libs/srtp/
vi Makefile
reemplazar std=c99 por std=gnu99
cd crypto vi Makefile -- borrar -std=c99
Modificamos la linea INCDIR, agregandole -I/usr/pkg/include/srtp
INCDIR = -Iinclude -I$(srcdir)/include -I/usr/pkg/include/srtp
Regresamos al directorio anterior y ejecutar nuevamente gmake
Cambiar al directorio principal de freeswitch y ejecutar gmake
Al final de la compilacion mostrara el logo azul, no obstante se requiere otro ajuste:
cd libs/sofia-sip/libsofia-sip-ua ; cd tport
vi ws.c --
Cambiamos __bswap_64(val) por (val) en las dos lineas para luego correr gmake en ese mismo directorio
Retornamos al directorio principal de freeswitch
Ejecutamos gmake install hd-sounds-install hd-music-install
Con estos pasos ya disponemos de una instalacion de freeswitch en netbsd
Monday, July 17, 2017
FreeSWITCH corriendo en NetBSD 8.0
Finalmente logre instalar y configurar correctamente a freeswitch en un entorno NetBSD 8.0. Espere pronto la documentacion oficial.
Subscribe to:
Posts (Atom)