El Jueves, 30 de Agosto de 2007, Jesus Rodriguez escribió:
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:
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