Hi, > 2.1.2. Confirmed state but not enough for usage this point does not apply to the proposal because we are not performing any rollback at the media level. Whatever media parameters are being used they will still be used after the re-INVITE fails. Therefore, the point where the re-INVITE fails does not represent any discontinuity in the media session. The media session continues as it was before the failure of the re-INVITE. > 2.1.4. Illegal using session parameters > > The modification in media level can be used illegally, while the > modification is unsuccessful in signal level. this does not apply to the proposal because the proposal does not specify any new media usage. It simply tells the endpoints to continue doing what they were already doing. > 2.2. Drawback of manual rollback this does not apply to the proposal because there is no rollback at the media level. > 2.2.1. Problems for ordinary SDP > > Sections mentioned above introduced "manual rollback" using a new Re- > INVITE as the way to resume the session under ambiguous situations. > But *if the two sides have no consistent view of session state, no > matter which side sends the new Re-INVITE, the other side will treat > it as violation of session continuity* because of different view of > session state. you provided a few examples of situations where the endpoints may have inconsistent views of the session state. None of the examples were valid. If you could provide a valid example, it would help us understand if there is a problem here. In any case, if endpoints end up with an inconsistent view of the parameters in use, it would be a bigger problem than the issue we are talking about here, because it would mean that the media session between them would not work. > 2.2.2. Problems for non-integrative SDP > > Because the SDP just describes part of the session, not all aspects > of the session. It must be combined with the previous one(or ones) > to show the effects, as the formula: > > *"current session state" = "previous session state" + "modification > session description"*. > > & nbsp; Even if using a new Re-INVITE with "modification session > description", we can not rebulid the "current session state" without > the definition of the "previous session state". So, the "previous > session state" is important here, and we still need to give out a > precise definition of session state to get the "previous session > state" here. in the proposal we are discussing here, we do not need to rebuild any state because we just continue using the current media state. Therefore, this drawback does not apply to the proposal either. Thanks, 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
