|
Hi,
I think the definition of "in use" is:
"Whatever session parameters (SDP) have been
negotiated, AND preconditions are met on both sides for those
parameters."
The good thing with the "in use" approach is that we don't need to
distinguish "codec refine" etc inside the offer/answers.
I guess the question is about "late
commitment".
Take the following case:
1. The UAC wants to add video to a session, so it sends a
re-INVITE, with preconditions.
2. There are PRACKs, UPDATEs, etc etc, and at some point both the
UAC and the UAS indicate that preconditions are met.
3. The UAS is prompted if he wants to accept the video (I guess
it's an implementation issue exactly at what point the UAS is
prompted).
4. The UAS rejects the video, and an error response is sent for
the video.
Now, with the pure "in use" proposal there is no rollback, because
preconditions had been met before the rejection.
Using "late commitment", there would be a rollback, even if
preconditions had been met before the rejection.
I do NOT think we should start talking about billing issues
etc.
Regards,
Christer
From: gaoyang [mailto:gao.yang.seu@xxxxxxxxxxx] Sent: Thursday, February 26, 2009 6:38 PM To: Gonzalo Camarillo Cc: gao.yang2@xxxxxxxxxx; sipping@xxxxxxxx; Christer Holmberg Subject: RE: [Sipping] 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: Closing the offer/answer rollback issue 1. Make session state just out of signal control. 2. Is the session state the one user prefer? Other comments inline. > Date: Thu, 26 Feb 2009 18:20:26 +0200 > From: Gonzalo.Camarillo@xxxxxxxxxxxx > To: gao.yang.seu@xxxxxxxxxxx > CC: gao.yang2@xxxxxxxxxx; sipping@xxxxxxxx; christer.holmberg@xxxxxxxxxxxx > Subject: Re: [Sipping] 答复: Re: 答复: Re: 答复: Re: 答复: Re: 答复: Re: Closing the offer/answer rollback issue > > 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. > I just mean that the session state is not the ine user prefer. A new Re-INVITE is to fix it. > > 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. If A want to use vedio, and B reject it. But A and B can use vedio and say that they have rejected using it by signal, and operater can not bill it. > > > 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 e nd 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. > I talked it in the draft because some people treat it as solution. If you do not think it is needful, we can stop talking manual rollback. > Thanks, > > Gonzalo > MSN 9.0 正式版上线，捆绑免费25G网络硬盘！ 立刻下载！ |
_______________________________________________ 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
