Hola, el RFC 3261 dice, en alguna parte que no recuerdo, que es aconsejable que un proxy/server no cree una transacción hasta que no se haya autenticado el request (si procede). El argumento es que una transacción consume recursos y que un atacante malicioso podría enviar una burrada de requests en paralelo para saturar el proxy/server. Es decir: 1 - Llega un request (req1). 2 - El proxy comprueba que no tiene cabecera de autenticación y lo rechaza, stateless, con un 401/407. 3 - El UAC repite el request con autenticación (req2). 4 - El proxy lo recibe y calcula el digest y tal y da por buena la autenticación. 5 - Entonces el proxy crea la transacción. 6 - Llega una retransmisión de req2 y el proxy responde lo último que se le respondió ("matchea" la transacción). Pero en un hilo en la lista de OpenSIPS, Bogdan me comenta que crear la transacción antes de autenticar puede ser positivo ya que evita el proceso de autenticación en retransmissiones del request. Es decir: 1 - Llega un request (req1). 2 - El proxy crea la transacción. 3 - El proxy comprueba que no tiene cabecera de autenticación y lo rechaza, stateful, con un 401/407. 4 - El UAC repite el request con autenticación (req2). 5 - El proxy lo recibe y se pone a calcular el digest, pero le lleva un rato. 6 - Llega una retransmisión de req2 y como ya existe la transacción no se procesa de nuevo la autenticación (BIEN). 7 - El proxy da por buena la autenticación previa. 6 - Llega una retransmisión de req2 y el proxy responde lo último que se le respondió ("matchea" la transacción). Ambas formas tienen sus inconvenientes, ¿cuál creéis que es mejor? Saludos. -- Iñaki Baz Castillo <ibc(a)aliax.net>