Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx> >Hi, > >> IMO, it is not correct that "a 200 (OK) response to the re-INVITE >> would accept the latest target refresh". Because 200 response is >> returned by not Contact but Via header, 200 is unrelated to the >> Contact of the UPDATE request. > >you should read the paragraph above. It explains that the change has >already been implicitly accepted. All the 200 OK to the re-INVITE does >is formally accept the change. That is, this paragraph just clarifies >that the state after the 200 OK to the re-INVITE does not change. The >target continues to be the one the UPDATE request updated before. I have understood that the target continues to be use. the change has already been explicitly accepted by 200 to UPDATE. If re-INVITE rejected, I think, it doesn't influence the remote target. That is, in this case, 200 to re-INVITE is unrelated to the remote target. that's just wording. >>> 5. UAC Behavior >>> so that the session can continue. This new offer/answer exchange >>> should contain the minimum set of changes needed to continue the >>> session in order to minimize the chances of the UAS rejecting it as >>> well. >> >> "the minimum set" I think is, >> as if all o/a exchange had been done by UPDATE, UAC should >> revert to the pre-INVITE state. > >That paragraph deals with the case where the UAC *cannot* revert to the >pre-INVITE state for some reason. Sorry, it is the behavior of "the UAC *cannot* revert". I said the behavior of "the UAC *can* revert". But I think that "the UAC *can* revert" need to send an UPDATE request too. >> RFC3312 restrick downgrading the desired strength. >> IMO "removing the precondition" is equal to downgrading >> the desired strength, isn't it? > >No, the semantics of an m line without preconditions are clear in SDP. >It means that the stream is established. This is what all UAs without >support for preconditions continuously do. Does RFC3312 or 4566 says that ? Give me the pointer of the semantics, please. >Thanks for your comments, > >Gonzalo _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
