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.
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.
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.
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
