typo corrected below.... > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Tolga > Asveren > Sent: Wednesday, November 26, 2003 10:58 AM > To: [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] targetURI update semnantics > forreINVITE/UPDATE > > > To make it more clear: > > There is a reINVITE with target refresh. reINVITE is rejected. What should > be the value of remote URI, the old value or the value in the reINVITE(new ^^^^^^^^^^ remote target > value)? > > a)old value > b) new value > c) new value as soon as reINVITE is received, and it should be > reverted back > to old value when reINVITE is rejected > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Behalf Of Tolga > > Asveren > > Sent: Tuesday, November 25, 2003 9:42 AM > > To: [EMAIL PROTECTED] > > Subject: [Sip-implementors] targetURI update semnantics for > > reINVITE/UPDATE > > > > > > 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 > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
