SIP is not cure all
Joseo
Continuando con mi estudio de SIP, me he encontrado con muchas
características favorables entre las que merece mencionarse : es
Flexible, extensible, abierto, fácil de entender, implementar, etc.
Pero no puede ser la "panacea", debe tener algunas desventajas o
características no favorables . He encontrado que SIP tiene algunas
desventajas tales como : No es un protocolo de control de sesion, No
provee QoS. Quisiera preguntarles lo siguiente : Cuales son las
desventajas (características desfavorables) que tiene SIP y que
podrían mejorarse para que se convierta en un Protocolo de mayor
importancia en Internet?
Gracias por sus comentarios
Saludos
Joseo
Elias Baixas
--
Has recibido este mensaje porque estás subscrito al grupo de Google "sip-es".
Para enviar mensajes a este grupo escribe a sip...@googlegroups.com
Para anular tu subscripción envía un correo a sip-es-un...@googlegroups.com
Para más opciones visita la página del grupo:
http://groups.google.com/group/sip-es?hl=es
Iñaki Baz Castillo
<elias....@gmail.com> escribió:
> Esto es en parte porque SIP ofrece fiabilidad sobre UDP, por tanto está
> replicando todo el mecanismo de retransmisiones y timeouts que TCP
> implementa de a bajo nivel y con protocolo binario (en mi opinión, más
> acertado dejar la reliability para la capa de transporte, en vez de la de
> aplicación=).
En este punto no estoy plenamente de acuerdo. TCP ofrece garantía de
entrega, control de congestión y todo eso, pero sólo entre dos nodos
de la red (aquellos entre los que se establezca la comunicación TCP).
Pero SIP no es cliente-servidor como lo es HTTP, sino
cliente-proxy-cliente, por lo que no es una conexión TCP directa entre
clientes finales.
Además, recientemente he implementado el transactión layer en UDP y
TCP, y en TCP se reduce drásticamente la cantidad de timers y
mecanismos de retransmisión (ya que un client transaction TCP habla
con un server transaction TCP mediante una misma conexión TCP, por lo
que se aprovecha los mecanismos que ofrece TCP). Sólo se conservan
ciertos timers y retransmisiones a nivel de sesión. Específicamente si
un UAS responde un 200 a un INVITE sobre TCP y no recibe el ACK debe
retransmitir el 200 ya que el proxy intermedio no lo va a hacer (al
ser un 200) y el UAS no sabe si algún tramo desde el UAC al UAS es
UDP, por lo que debe retransmitir el 200. Hay algún caso más, pero no
gran cosa.
Donde yo creo que lo ha hecho mal SIP (o sus autores) es en estos puntos:
- Omitir la existencia del NAT en el RFC 3261, lo cuál ha sido más o
menos resuelto con un par de RFC's más: RFC 3851 para UDP con el
parámetro ;rport y el RFC 5626 para TCP (realmente complejo). Ya es
suficientemente largo y tedioso el RFC 3261 como para exigir dos RFC's
más para que el protocolo pueda medio-funcionar en el mundo real.
- Muy similar: el tema de las respuestas SIP. En cualquier otro
protocolo es super sencillo: las respuestas a un request se deben
enviar a la misma IP y puerto del que procede el request. Pero en SIP
hay una ensalada impresionante de posibilidades, el funcionamiento por
defecto en UDP es retorcido (las respuestas deben enviarse a la IP
pública de la que procede el request pero al puerto indicado en el
sent-by del top via). Luego llega el RFC 3851 para cambiar eso,
resulta que en TCP es totalmente diferente todo, etc etc. Al final
todo conduce a que las respuestas se envíen por donde ha venido el
request (lo que todo el mundo daría casi por hecho), pero para llegar
a eso hay que leer la biblia e implementar 3 RFC's. Esto no es
aceptable en mi opinión.
- Lo del parámetro maddr mejor ni lo cuento. Lamentable totalmente.
- Algunos temas de gramática BNF deberían ser más rigurosos. Me viene
a la cabeza este ejemplo:
1) From: sip:pe...@dominio.org;paramX=lalala
2) From: <sip:pe...@dominio.org;paramX=lalala>
En el caso 1 "paramX" es un parámetro de la cabecera From.
En el caso 2 "paramX" es un parámetro de la URI del From.
Demasiada flexibilidad que no aporta nada excepto confusión. Sería más
sencillo si se exigiese que el formato fuese siempre name-addr (la URI
entre < >). Como éste hay más casos.
- Alguna cosa ridícula como la sección S/MIME del RFC 3261. Nadie
NADIE NADIE implementa S/MIME.
- Sobre el tema de la presencia SIMPLE y sus amiguitos XCAP y compañía
mejor no opino porque después de haber dedicado más de un año a
aprenderlo e implementarlo (incluso programando un cliente y servidor
XCAP/OMA-XDMS) fue tal mi decepción y frustración que mi puñetazo en
la mesa se oyó en todo el IETF.
- Bueno.. sigo con lo de SIMPLE (en el área de la presencia). Una
especificación que no ha triunfado en el mundo "internet" (nadie lo
implementa, o sólo lo implementa pero de forma muuuuy básica dada la
dificultad del engendro final). Además, tal y como está especificado
SIMPLE en los RFC del IETF no es una especificación final, sino algo
muy extenso y flexible, que no dictamina nada. Si yo implemento SIMPLE
y tú lo implementas, ambos interpretando los RFC, podría ser que
nuestros respectivos clientes SIP no interoperasen en temas de
presencia. Al final, quien lleva las riendas es el GSMA/3GPP que ha
añadido sus propias capas de especificaciones sobre SIMPLE para
obtener una especificación más definida y rigurosa, con fines
claramente orientados al "business" tradicional de los telcos (cuando
leí en un documento del OpenMobileAliance lo de "facturar al usuario
por enviar un SUBSCRIBE" borré el PDF). Pero en el mundo libre
(Internet) la gente no quiere seguir los pasos de las telco,
obviamente, así que SIMPLE ni existe. Un fracaso en mi opinión, aunque
a los telcos no les importe; ellos dominan el aire y en un par de
lustros (lo que tarde en implementarse el IMS) nos cobrarán por enviar
SUBSCRIBE's y tan contentos. Quién sabe, igual es les ocurre cobrar
por "establecimiento de diálogo de subscripción de evento 'presence'".
- Y la otra gran pega es la excesiva cantidad de RFC's. Parece que
nunca hay suficiente. Por cada RFC que se implementa de forma más o
menos generalizada se han producido 10 que apenas los desarrolladores
llegan a conocer (es imposible seguir el ritmo).
Por lo demás, creo que SIP es el protocolo mejor diseñado de todos los
existentes para temas de comunicación realtime. Le da mil patadas a
XMPP en temas de routing y escalabilidad. Algunas supuestas
debilidades son en realidad virtudes si se conoce bien el protocolo.
--
Iñaki Baz Castillo
<i...@aliax.net>
Joseo
Saludos
Joseo
On 14 abr, 20:03, Iñaki Baz Castillo <i...@aliax.net> wrote:
> El día 14 de abril de 2011 18:03, Elias Baixas
> 2) From: <sip:p...@dominio.org;paramX=lalala>
Joseo
Quisiera compartir dos características de SIP, en que Alan B. Johnston
fundamenta su libro "Understanding the Session Initiation Protocol",
esta son la Simplicidad (simplicity) y el no-estado (Stateless). La
simplicidad por que es un protocolo basada en texto, en mensajes
fáciles de leer y la sencillez de su modelo transaccional. Pero la
característica de mas importante, por que rompe el modelo
tradicional de los sistemas de telecomunicaciones "propietarios" es la
naturaleza no-estado (stateless nature), a traves de dicha
caracteristica, SIP proporciona independencia a las partes que se
comunican (User Agents), ya que en una Red SIP, los servidores
"stateless" no requieren dejar un "log" o registro, es la evolución de
un sistema centralizado hacia uno descentralizado de los sistemas de
Telecomunicaciones, lo cual proporciona un gran beneficio a los
desarrolladores de servicios SIP.
Saludos
Joseo
Iñaki Baz Castillo
> es la evolución de
> un sistema centralizado hacia uno descentralizado de los sistemas de
> Telecomunicaciones, lo cual proporciona un gran beneficio a los
> desarrolladores de servicios SIP.
Estoy emocionalmente de acuerdo con lo que dices. Así es SIP en efecto.
Por desgracia, al operador tradicional le sigue interesando mucho más
el concepto de "control" total. De hecho, tengo entendido que muchos
nodos que en IMS están definidos como proxies SIP, están siendo
desarrollados a modo de B2BUA por algunos fabricantes.