ACK parte de una transaccion

[Joseo]

Hola a Todos
Quisiera conocer cual es la razon por la cual ACK a veces hace parte
de una transaccion y otras no dependiendo si la respuesta es 2xx o
no. He consultado el RFC3261 pero no logro enterder. Cual es la razon
de esta separacion?
Saludos
jose

--
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]

El día 20 de abril de 2010 04:31, Joseo <joseo_...@hotmail.com> escribió:
> Hola a Todos
> Quisiera conocer cual es la razon por la cual ACK a veces hace parte
> de una transaccion y  otras no dependiendo si la respuesta es 2xx o
> no. He consultado el RFC3261 pero no logro enterder. Cual es la razon
> de esta separacion?

Cuando se recibe una respuesta final negativa (> 200) a un INVITE el
client (UAC) no tiene que hace nada más que confirmar dicha respuesta
con un ACK que envía automáticamente el client transaction del UAC, es
decir, forma parte de la misma transacción SIP.
Además, cuando el proxy recibió dicha respuesta final negativa, su
propio client transaction generó un ACK que envió al destino, y
posteriormente (o a la vez) envía la respuesta final al UAC quien
entonces envía al proxy dicho ACK. Es decir, los ACK's a respuestas
finales negativas (> 200) son hop-by-hop (el proxy se lo envía al
destino e independientemente el UAC se lo envía al proxy, ambos ACK's
no son el mismo).

En cambio cuando un UAC recibe un 2XX a un INVITE debe pasárselo a la
capa core (por encima de la capa de transacción) ya que el dispositivo
SIP tiene que validar si soporta los codecs en el SDP del 200, o si de
hecho el 200 contiene el pertinente SDP, o si tiene un exótico body
multipart (una de cuyas partes es un SDP) que no puede parsear por no
soportar multipart body, etc...
Es decir, no vale con que la lógica de transacción responda ese ACK
sino que la capa de lógica de llamada (la capa core) debe examinar
dicho 200.
Por la misma razón, el proxy que previamente ha recibido dicho 200 no
puede generar automáticamente un ACK y en cambio tiene que esperar a
que lo envíe el UAC (como una nueva transacción entonces!!!).
Un ejemplo claro: el UAC llama con un INVITE sin SDP, el proxy se lo
ruta al destino (UAS) quien responde con un 200 con SDP offer, el
proxy ruta el 200 al UAC, el UAC examina el 200 y genera un ACK con el
SDP response. El proxy ruta dicho ACK al UAS.
En este caso está claro que el proxy NO puede generar dicho 200.


--
Iñaki Baz Castillo
<i...@aliax.net>

[Joseo]

Gracias Iñaki, me quedo claro el concepto con la explicacion.
Basicamente la razon de tal separacion del ACK es debido al proceso de
validacion de los codecs en el SDP del 200OK, que realiza la capa
logica de llamada ( capa core), por lo cual se requiere un ACK como
parte de una nueva transaccion.
De nuevo Gracias :)
Saludos
Jose

On Apr 20, 4:46 am, Iñaki Baz Castillo <i...@aliax.net> wrote: