Conclusiones:

• El número de dispositivos LTE se ha multiplicado por 3x sólo durante el año 2011 (en Febrero contábamos con 63 dispositivos). Mayoritariamente se trata de dispositivos de datos, aunque el nº de smartphones es ya considerable, 27, aunque mayoritariamente en 700Mhz, la banda americana exclusivamente.
• En la banda de 700Mhz, en producción en US se esta desarrollando lógicamente muchísimos y 2,6Ghz va poco a poco, incluso contando con más dispositivos que 800Mhz.
• Las frecuencias TDD se están desarrollando

Se pueden descargar los informes con más detalle en los siguientes links:

• Octubre 2011
• Julio 2011
• Febrero 2011

¡Compártelo! | Twineame | Menéame

Tras su lectura, he quedo con la parte que me parece más interesante dentro de las Actuaciones Regulatorias que se pueden resumir en:

• MEJORA DE LA CALID AD EN LA PROVISIÓN MAYORISTA DE BAND A ANC HA: durante el año 2012 la CMT monitorizará la calidad de los servicios mayoristas, en particular de la OBA (Oferta de Acceso al Bucle de Abonado)
• SE COMIENZA A TRABAJAR EN EL MODELO DE COSTES PARA REGULAR LAS TARIFAS DE LAS INTERCONEXIONES IP DE REDES: el curso de 2011 la CMT inicio un estudio para implementar un modelo de costes bottom-up para interconexión de una red fija con tecnologías exclusivamente NGN e interconexión IP con otros operadores. Este estudio se deriva de la Recomendación de la Comisión Europea 2009/396/CE, en base a la cual la CMT ya está desarrollando un estudio bottom-up para red móvil. La CMT propondrá a los operadores la puesta en marcha de un foro durante el primer trimestre del 2012 para definir el modelo de interconexión de red, la facturación y los precios para los servicios mayoristas. Esto evidencia la tracción que ya tienen las interconexiones de voz a nivel IP en España.
• LANZAMIENTO DEL SERVICIO NEBA: La planificación prevista es:
  • Fase 1 (con algunas limitaciones): piloto Enero/2012 y comercial 1/Abril.
  • Fase 2 (totalmente funcional): piloto 1/Julio y comercial 1/Octubre/2012

Recordemos que las diferencias fundamentales entre NEBA y ADSL-IP o GigaADSL es que:

• Se presta sobre ADSL2+, VDSL2… y FTHH tb
• La IX con Telefónica se realiza a nivel regional a nivel Ethernet. El operador alternativo comprará a Telefónica una determinada capacidad de red (ancho de banda) y con ese ancho de banda que ha adquirido podrá configurar sus propias ofertas minoristas, diferenciadas de las de Telefónica. Por tanto, NEBA proporciona al operador la posibilidad de diferenciarse en coste y servicio del servicio minorista de acceso de Telefónica.
• En cuanto a la facturación, los operadores pagarán a Telefónica una parte correspondiente al acceso a la red de Telefónica (según tecnología ADSL2+, VDSL2 o FTTH/GPON) y otra parte por el ancho de banda (megabits por segundo) que hayan contratado en el PAI para cada calidad de servicio.
• Incluye una nueva Calidad de Servicio llamada “Real Time” que prioriza el tráfico que se cursa sobre ella con 802.1p de Ethernet, que permitirá dar servicios como VoIP sobre este acceso

¡Compártelo! | Twineame | Menéame

Todavía la seguridad en telefonía IP no es una preocupación principal, pero debería de empezar a serlo.

Dejo a continuación el vídeo de la ponencia y el link:

La ponencia se puede descargar aquí.

Conclusiones:
Alberto recomienda la implantación de TLS para securizar la señalización SIP pero no la implantación de SRTP, que aún esta poco madura y puede funcionar con algunas combinaciones de servidor SIP y clientes pero no de manera generalizada. De todos los probados sólo el softphone Blink funcionó perfectamente con Asterisk 1.8.7 como SIP server con TLS+SRTP.

Más info:
http://www.voipparanovatos.es

http://www.voip2day.net

¡Compártelo! | Twineame | Menéame

Digium se lanzó a publicar el estreno de la nueva versión al igual que TMCNet, y lo cierto es que los desarrolladores de Asterisk han decidido retrasar el lanzamiento hasta que todos los bugs encontrados hayan sido solucionados, algo que “comercialmente” no será muy bien visto, pero los usuarios seguro que lo agradecerán.

A estas horas, en downloads.asterisk.org sigue estando disponible la versión beta2.

Figura.- Vídeo presentación de la Astricon

La feature más importante que añade Asterisk 10 es el soporte para voz HD y Ultra-HD (frente a los tradicionales codecs que funcionan con un ancho de banda de 3Khz y baja calidad de audio). Con este movimiento Digium democratiza el acceso a la voz HD a cualquier empresa, y posibilita que cualquier empresa pueda usar voz HD y ésta comience a adoptar gradualmente. Digium tambiénh ha añadido en esta versión soporte para los códecs:

• SILK, el codec super-wideband de Skype
• La versión wide-band de Speex, a 32Khz
• y pass-throuh para varias variantes del códec CELT

El detalle de las features añadidas en esta versión es el siguiente:

New media engine-Asterisk 10 supports more media types and virtually any type of audio. The overhaul to the media engine allows Asterisk to support a nearly unlimited number of codecs.
More codecs-The platform includes new codecs, including the wideband version of Speex, Skype’s super-wideband SILK and pass-through support for several CELT variants.
Additional sampling rates-Asterisk previously operated on 8 and 16 kHz sampled audio, but now supports super- and ultra-wideband sampling rates as file format types for file playback or recording. Asterisk now supports 8, 12, 16, 24, 32, 44.1, 48, 96 and 192 kHz rates for superb audio quality.
New conferencing application-Digium replaced the MeetMe conferencing bridge with an HD-capable intelligent bridge application called ConfBridge. It supports all codecs and conference rates and works on any Asterisk 10 system, regardless of operating system or architecture. Intelligent mixing algorithms provide each participant with the optimal audio quality for their connection. Also, ConfBridge is fully customizable, so systems administrators and integrators can configure call-in menus on a caller-by-caller basis.
Support for videoconferencing-ConfBridge relays video of a designated speaker or the current speaker to other participants in the conference. Video-capable SIP devices that use the same codec are required.
Significant new fax capabilities-Asterisk 10 includes T.38 gateway capabilities that allow outgoing fax calls from analog fax machines to be connected to T.38 fax endpoints over SIP and incoming T.38 fax calls to be delivered directly to fax machines. This allows for more straightforward integration of fax capabilities into an Asterisk system and allows users to get delivery confirmation from other fax machines.
Text message routing-Asterisk has long been able to send and receive text messages, but can now route messages as well. Asterisk 10 supports the SIP MESSAGE and XMPP protocols, allowing it to act as a text messaging server and bridge between different messaging protocols.

Más info en la PR de Digium: http://www.digium.com/en/mediacenter/viewpress/digium-and-open-source-community-release-asterisk-10-at-astricon

¡Compártelo! | Twineame | Menéame

http://www.lightreading.com/blog.asp?blog_sectionid=244&doc_id=213842

Sprint, igual que MetroPCS tienen un déficit de espectro para dar servicios de banda ancha móvil (tiene 2 bloques de 5Mhz en 1,9Ghz, además de su espectro actual en 800Mhz que piensa usar para dar voz) en un escenario con LTE.

Sprint se esta planteando que cuando su competencia ATT o Verizon den servicios de banda ancha móvil con LTE con más espectro que ellos (tienen bloques de 10Mhz en 700Mhz para su despliegue) no podrán competir  en igualdad de condiciones y se están planteando qué hacer. Ven varias opciones:

• en primera instancia migrar a LTE-Advanced  en H1 2013 (en estudio)
• sin embargo esto podría cambiar si optimiza el uso de 800MHz actual y saca algo para LTE, añade el espectro de LightSquared en 1.6Ghz L-Band que esta licenciado por la FCC para LTE o incluso si pueden añadir tb  la capacidad de Clearwire en 2,5Ghz al mix
• hacen todo esto mientras que despliegan wifi offloading, femtocells y tecnología de optimización de tráfico

La noticia dice que Sprint estudia ir a LTE-Advanced en 2013. Lo importante de esa noticia es ver si son de los primeros en ir a LTE-Advanced y como les va. Por cierto que sus antenas son ALU, Ericsson y Samsung.

Actualización: algunas fuentes hablan de que Sprint va seguro a LTE-Advanced, igual que Clearwire.

http://gigaom.com/2011/10/25/sprint-plans-lte-advanced-deployment-for-2013/

¡Compártelo! | Twineame | Menéame

Muestra de ello son los 2 movimientos de acercamiento a plataformas móviles que ha realizado en las últimas fechas de sus plataformas de correo-e.

1) Hace unos días, la publicacion de la aplicación de Hotmail para Android, dirigida al mercado masivo de consumo.

2) Hoy, RIM ha abierto en pruebas, en más de 30 países, su servicio en la nube Business Cloud Services para Microsoft Office 365 dirigido a las empresas de tamaño medio.  Esta plataforma permitirá a las organizaciones autogestionar sus servicios para los móviles smartphones Blackberry conectados con la nube.

Las características de este servicio:

• acceso al correo electrónico, calendario y datos del organizador Microsoft Exchange Online desde la Blackberry;
• el acceso web a las funciones de seguridad del móvil
• la tecnología BlackBerry Balance, que ofrece una vista unificada del contenido del trabajo y personal en la BlackBerry mientras se nunca se mezclan dichos contenidos.
• y una consola basada en web que permite a los administradores de tecnologías de las empresas proveer, gestionar y asegurar los móviles desde cualquier lugar.

En esta ocasión aunque parece que el movimiento es liderado por RIM para captar el negocio de las empresas que desean mover sus servicios de correo a la nube y no podían hasta la fecha conservar su Blackberry, la alianza beneficia más a MS que con ello consigue lanzar sus recientes servicios de Office 365:

1) Facilitando las altas de clientes actuales de Blackberry de servicios de Office 365 en la nube.

2) Las migraciones de aquellos clientes BB que deseaban, para bajar costes de sus instalaciones “on premise”, migrarse a los servicios en la nube de Office 365 también están cubiertas de esta manera.

3) Tb RIM consigue soportar una plataforma en la nube que probablemente será muy importante para empresas en un futuro, auque ahora aún esté crecimiendo y en sus primeros pasos de vida.

Mi pregunta es, ¿cómo podrán competir los administradores de IT internos, los integradores de soluciones de MS  y BES, y los hosters ante esta competencia tal agresiva en servicios y tarifas de ambos titanes?

¡Compártelo! | Twineame | Menéame

• El códec y contenedor: típicamente se usa el códec H.264 en un contenedor MP4 Part 14 o Flash
• El protocolo: HTTP progressive download o Streaming.
• El servidor de streaming: existen buenas comparativas en Internet de ellos.
• El cliente

Aquí trataremos de explicar lo que hay que saber y tener en cuenta para dar o recibir un servicio de streaming por Internet con calidad.

El códec

Parece que el códec H.264 se impone sobre su competencia Silverlight, Flash, VP8 u otros como el standard de la industria. Por lo tanto este tema parece claro y no será objeto de este post.

Detalle del estado de los códecs soportados por los PC’s y móviles

Los protocolos de distribución de vídeo en Internet e implementaciones varias: HTTP Progressive download vs streaming

En lo que sí parece que hay más debate y cierto lío es entre los diferentes protocolos de distribución del vídeo, diferenciándose 2 familas: Download progresivo o streaming. El siguiente gráfico nos presenta la diferentes alternativas:

La experiencia de usuario usando cualquier de estos protocolos de distribución es similar, pero sin embargo son distintos.

1) El más veterano es el segundo, la distribución por media streaming. Usa los protocolos IP RTSP, RTP y RTCP o RTMP para Flash, protocolos mucho más eficientes en cuanto al consumo de ancho de banda en el servidor y cliente, pero a costa de mayor complejidad en el lado del servidor y mayores requerimientos de CPU, memoria, baterías, etc. de los dispositivos. Típicamente se distribuyen contenedores Flash y Quicktime.

2) Sin embargo, en los últimos tiempos, con la aparición del iOS y la férrea oposición de Steve Jobs/Apple a dar soporte a Flash en sus dispositivos, así como la decisión final sobre el códec a emplear en la especificación HTML5 (para etiqueta “video”) se ha popularizado adopción de protocolos de distribución de vídeo basados en HTTP.

Existen fundamentalmente 3, HTTP Live Streaming respaldado por Apple, Smooth Streaming de Microsoft y HTTP Dynamic Streaming defendido por Adobe. Todos ellos tienen algo en común: todos usan MPEG-4 H.264 como entrada.

Los tres métodos son Adaptive Bit Rate Streaming, lo que permite que la experiencia de usuario se ajuste al verdadero ancho de banda del que dispone el usuario en cada momento y del estado de su CPU. En otras palabras, un streaming adaptativo puede subir o bajar en bit rate o resolución de una transmisión en “real time” en función de las condiciones del player en un momento dado.

¿Cómo funciona el HTTP progressive download?

La siguiente es la arquitectura de streaming de HLS de Apple, quizá la más sencilla de explicar:

En la misma podemos ver la fuente de vídeo, el encoder, el segmenter, la distribución de ficheros en server web tradicional y el cliente. Trataré de explicar el funcionamiento de los protocolos de Streaming HTTP partiendo de la base éste y apoyándome en el workflow de Adobe Flash Media Server que es igual para todos.

En una configuración típica, existen 4 fases:

• Preparación: un encoder hardware (p.e. Envivio) toma el audio y video de entrada, lo codifica como vídeo H.264 y audio AAC, y lo devuelve en un archivo MPEG-2 Transport Stream, que luego se divide en una serie de pequeños ficheros multimedia de unos 10 segundos de duración (llamados chunks o segmentos) por parte de un segmenter software. Estos archivos se colocan en un servidor web normal como un Apache. El segmentador también crea y mantiene un archivo de índice que contiene una lista de los archivos en los que se ha partido el vídeo original. La dirección URL del archivo de índice se publica en el servidor web. El index file es un .M3U8, la playlist. Este proceso de codificación y segmentación se repite para cada una de las calidades que deseen emitir del vídeo (lo que es la base del Adaptative Streaming).
• Distribución: La URL del fichero index es accedida por los clientes, los cuales entonces piden los ficheros indexados en secuencia. Los ficheros son servidos por un servidor web tradicional, como Apache o IIS.
• DRM: es una etapa opcional.
• El software de cliente es el responsable de determinar los ficheros o chunks apropiados a pedir por HTTP, descargarlos y reemsamblarlos para poder presentarlos al usuario en un stream de vídeo continuo.  Si en un momento dado las condiciones del cliente varian, es el responsable de pedir chunks de calidad más baja y regular así la calidad del stream.

HTTP Dynamic Streaming de Adobe es más o menos lo mismo, pero se diferencia fundamentalmente de HLS en que la etapa del segmenter para el VoD la hacen las herramientas del propio Adobe Flash Media Server, tiene soporte de contenedores FLV y el usuario no se descarga el fichero completamente para ver el vídeo como en HLS. HTTP Smooth Streaming de Microsoft se diferencia fundamentalmente de HLS en que la etapa del segmenter para el VoD la hacen las herramientas del propio IIS y que soporta Silverlight como contenedor de vídeo tb.

Todos ellos soportan emisiones en directo, siguiendo el mismo workflow que el VoD.

Adaptive Bit Rate Streaming

Los tres métodos son Adaptive Bit Rate Streaming, lo que permite que la experiencia de usuario se ajuste al verdadero ancho de banda del que dispone el usuario en cada momento y al estado de su CPU. En otras palabras, un streaming adaptativo puede subir o bajar en bit rate o resolución de una transmisión en “real time” en función de las condiciones del player en un momento dado. Simplemente el player tiene que descargar nuevos chunks de calidad más baja y reproducir los nuevos.

Ventajas/Inconvenientes del progressive download

Ambos métodos para hacer distribución de vídeo (descarga progresiva o streaming real) son perfectamente viables. Sin embargo, a niveles de costes para el editor o distribuidor de vídeo, es más interesante hacer descarga progresiva ya que:

• Se pueden usar los mismos servidores web de siempre, no se requieren servidores de streaming específicos y licencias caras.
• Se puede usar las CDNs tradicionales web de toda la vida, ya que los chunks no son más que pequeños ficheros de vídeo bien identificados
• Sin embargo, ya que se baja un fichero temporalmente al dispositivo de cliente, es menos robusto ante el pirateo de contenidos.

Para el cliente:

• Menos exigencias de recursos para CPU, memoria
• Sin embargo, el usuario se descarga el fichero completamente para ver el vídeo (vs en streaming que sólo descarga lo que ha visto), salvo en las implementaciones de HTTP Dynamic Streaming de Adobe.
• Dado lo anterior, las exigencias de ancho de banda son mayores, ya que para un vídeo 20MB en streaming tradicional un usuario se puede bajar 20MB máximo si ve el vídeo completo, mientras que en HTTP download progresivo puede llegar a bajarse, para ver el vídeo completo, 20MB multiplicado por el nº de calidad disponibles en el servidor, p.e. 100MB

Concluyendo

El quick de la cuestión es que el “HTTP download progresivo” mejora de costes para los editores, aunque genere ineficiencias en cuanto a tráfico para el cliente final…

En cuanto a referencia quizá lo más importante sea que varios grandes emisores de video de US como la ABC, Netflix o Hulu estan adoptando HLS en sus iPad Apps. O que en UK la BBC esta haciendo pruebas HD HTTP Streaming . Mientras en España el Grupo Prisa ya usa el encoder de Envivio para hacer HLS tb.

Añadido

Como curiosidad podemos ver la arquitectura de un grande de todo esto en Internet, Justin.tv.

Más info:

http://videotechnology.blogspot.com/2011/06/hls-http-live-streaming.html

http://mashable.com/2011/01/25/adaptive-bit-rate-video-streaming/

http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/HTTPStreamingArchitecture/HTTPStreamingArchitecture.html#//apple_ref/doc/uid/TP40008332-CH101-SW2

http://blogs.adobe.com/actionscriptdocs/2010/06/tutorial_http_dynamic_streamin_1.html

http://help.adobe.com/en_US/HTTPStreaming/1.0/Using/index.html

http://www.appleinsider.com/articles/11/02/02/microsoft_announces_h_264_support_for_googles_chrome.html&page=2

http://en.wikipedia.org/wiki/Comparison_of_streaming_media_systems#General

http://www.adobe.com/products/flashmediastreaming/

http://www.adobe.com/products/httpdynamicstreaming/

http://www.wowza.com/video-streaming-server.html

¡Compártelo! | Twineame | Menéame

Sobre la teoría de Everett Rogers sobre difusión de la innovación, para que una tecnología sea adoptada debe cumplir 4 factores:

- Debe añadir una ventaja relativa clara

- Compatibilidad: El esfuerzo se requiere para cambiar de la situación actual hacia la innovación propuesta debe ser pequeño

- Complejidad: La complejidad de aprendizaje de la nueva tecnología debe ser baja.

- Facilidad de prueba. Cuanto más facil sea probar, mas rápido se difundirá la innovación.

Esta claro que NFC no es una tecnología a la que sea fácil acceder por el momento: exije inversiones en terminales no baratos (y tampoco con gran variedad aunque ahora comienza ha haberlos) en el lado del cliente, aprender nuevas rutinas para el pago y todo ello para ganar poco o nada, mientras en el lado del retail pasa un poco lo mismo (grandes inversiones para no ganar nada). Y eso que tenemos grandes iniciativas de grandes actores tecnológicos para evangelizar con su uso como Google Wallet, Isis o en España las iniciativas de Movistar.

Sin embargo Brad Greene, Senior Business Leader en Visa lo tiene claro y da en el clavo. Brad dijo en la conferencia  GigaOM’s Mobilize esta semana que la clave no son los pagos sino que la clave de la adopción de esta tecnología serán las otras features alrededor del pago como los descuentos, promociones y campañas de fidelización; éstas serán las que debe convencer a los usuarios y retailers de invertir en esta tecnología. No puedo estar más de acuerdo.

Ojala y todo el mundo alucinase tanto como los protagonistas en este vídeo difundido por Google con el pretender evangelizar… pero creo que no será tan fácil.

Fuente: Gigaom

¡Compártelo! | Twineame | Menéame

NFC por 249EUR, Nokia 603: http://es.engadget.com/2011/10/13/nokia-603-ya-oficial-nfc-accesible-a-todos-los-usuarios/

Este tablet de 7″ con Android 3.2 por 299EUR si que mola… Acer Iconia Tab A100 (no es el Amazon Kindle Fire por 199EUR, pero vamos entrando en el segmento de precio): http://www.xataka.com/tablets/acer-iconia-tab-a100-tablet-android-32-comprimido

Fujitsu propone un array de amplificadores que podría hacer más realidad el 1:128 de PON (pensado para lograr un nº más alto de endpoints por PON, que normalmente es 1:32): http://www.lightreading.com/document.asp?doc_id=213394

Movistar, Orange ofrecerán compensaciones por la avería de Blackberry: http://www.networkworld.es/Movistar-y-Orange-ofreceran-compensaciones-por-los-fallos-de/seccion-actualidad/noticia-114314

O2 empezará a ofrecer servicios de llamadas gratuitas sobre Internet (un servicio similar al de Skype) en una prueba piloto que se iniciará sólo para algunos miles de clientes escogidos en el Reino Unido: http://www.expansion.com/2011/10/13/empresas/tmt/1318484708.html

DLink lanza el DIR-657, router diseñado para la transmisión de streaming de vídeo en el hogar y con ranura SD para el server DLNA: http://www.networkworld.es/D-Link-introduce-un-router-optimizado-para-streaming-de-vide/seccion-actualidad/noticia-114297

Las cinco claves del nuevo ‘boom’ en los resultados de Google (beneficio neto fue de 2.730 millones en el tercer trimestre del año, un 26% más que en el mismo periodo del año anterior. Sus ingresos crecieron un 37%, hasta los 9.720 millones de dólares):http://www.elconfidencial.com/tecnologia/2011/10/13/las-cinco-claves-del-nuevo-boom-en-los-resultados-de-google-1230/

¡Compártelo! | Twineame | Menéame

Descansa en paz Dennis, y muchas gracias por todo.

Fuente: http://es.engadget.com/2011/10/13/muere-dennis-ritchie-creador-del-lenguaje-c-y-cocreador-de-unix/

¡Compártelo! | Twineame | Menéame