30 Aug
2007
30 Aug
'07
6:56 a.m.
El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
Valeee, entendido.. es mucho mejor usar UPDATE (si el UAS lo soporta) que
re-INVITE's porque el re-INVITE implica una oferta y debería replicar todo el
SDP igual que estaba y tal.
http://tools.ietf.org/html/rfc4028 - 7.4 :
"
A re-INVITE generated to refresh the session is a normal re-INVITE,
and an UPDATE generated to refresh a session is a normal UPDATE. If
a UAC knows that its peer supports the UPDATE method, it is
RECOMMENDED that UPDATE be used instead of a re-INVITE. A UA can
make this determination if it has seen an Allow header field from its
peer with the value 'UPDATE', or through a mid-dialog OPTIONS
request. It is RECOMMENDED that the UPDATE request not contain an
offer [4], but a re-INVITE SHOULD contain one, even if the details of
the session have not changed. In that case, the offer MUST indicate
that it has not changed. In the case of SDP, this is accomplished by
including the same value for the origin field as did previous SDP
messages to its peer. The same is true for an answer exchanged as a
result of a session refresh request; if it has not changed, that MUST
be indicated.
"
Supongo que si estos mensajes los debe enviar el proxy SIP (en caso de que los
UAC's no los soportaasen) entiendo que usar re-INVITE significa memoría para
recordar cada SDP de cada diálogo vivo, mientras que un UPDATE sería más
económico. ¿Es así? Bueno, nada, cuando me acabe de leer ese RFC ya lo sabré
XD
--
Iñaki Baz Castillo
Ahora que lo
pienso, ¿no es un poco bestia que un proxy tenga que
enviar
re-INVITEs para comprobar el diálogo?
quiero decir: un OPTIONS es algo "inofensivo" pero enviar un INVITE
que no
fastidie nada supone recordar como había sido el INVITE, tener en
cuenta
posibles re-INVITES que se hayan hecho los usuarios durante la
llamada, etc.
¿no?
Así es como funcionan los session-timers:
http://tools.ietf.org/html/rfc4028