When a target refreshing reINVITE is rejected, should the remote URI update
be cancelled or not?
RFC3261 12.2.2 12.2.2
"Requests sent within a dialog, as any other request are atomic. If a
particular request is accepted by a UAS, all the state changes associated
with it are performed. If the request is rejected, none of the state changes
are performed."
"When a UAS receives a target refresh request, it MUST replace the dialog's
remote target URI with the URI from the Contact header field in that
request, if present."

It is kind of strange IMO, to "reject" a target refresh. I can see that
reINVITE is rejected because of media offer is not accepted but "target
referesh" is different in nature. Rather than asking/offering UAS something,
it is more a declaration that remote target info has changed, so I tend to
think, even reINVITE(or UPDATE) is rejected, remote target should not be
reverted back to original.

For example for UPDATE, there are different scenarios, where an UPDATE has
to be rejected (e.g. a UAS receives an UPDATE before it has generated a
finbal response to a previous UPDATE). What to do in such cases? Keeping
remote target updated or not? Even in such a case, it sounds strange to me,
not to "accept" the new remote target information.


  Tolga

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to