Hi Gonzalo Camarillo，
I just read your two drafts,and at this moment I think it is a solution,
but also, it's a complex one.
In your draft:
If changes requested by a re-INVITE or any transaction within it have
already been performed, the UAS should always return a 200 (OK)
response. Even if the UAS would like to revert to the pre-INVITE
state, it would still return a 200 (OK) to the INVITE request.
I think it should be discussed more about this solution.
If re-INVITE can't be rejected, then re-INVITEs are no better than UPDATEs,I think.
There are two reasons listed in the draft to illustrate it.
First one:
- However, the UAC has no means to reject those changes
if it is unable to execute them. That is, if the UAC is unable to
revert to the pre-re-INVITE state, it will not be able to communicate
this fact to the UAS.
IMO, the best solution for the case is also in the draft.
--- 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.
If UAC raises an unrejectable request,it should contain minimum set
of changes.If it is rejected just because it contains unacceptable changes
by UAS, it deserves the rejection.
Second,
-- Since both the UPDATE request and the error response would
request changes, it would not be clear which changes would need to be
executed first. This is yet another reason why UASs should not use
error responses to undo already executed changes.
As we can make restrictions not to reject re-INVITE,why not restrict
UPDATEs in re-INVITEs.
Also, unlimited UPDATEs increase the collision.Such as the step (6) and
step (8) in figure 4 of your draft.
UAC UAS
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<----(5) 183 Session Progress SDP4----------|
| |
|-------------(6) UPDATE SDP5--------------->|
| |
|<------------(7) 200 OK SDP6----------------|
| |
| |
|<------------(8) UPDATE SDP7----------------|
| |
|-------------(9) 200 OK SDP8--------------->|
| |
|<--------------(10) 200 OK------------------|
| |
|-----------------(11) ACK------------------>|
| |
Figure 4: Rejection of a video stream by the user
Wishes,
Eric.wang
sipping-bounces@xxxxxxxx 写于 2009-03-03 21:32:50:
> Hi,
>
> I have put together the following draft. It contains a proposal for the
> rollback issue that has been discussed on the list:
>
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-reinvite-00.txt
>
> I have also written another short draft on an issue related to
> preconditions that was also discussed on the list in one of the
> rollback-related threads:
>
> http://www.ietf.org/internet-drafts/draft-camarillo-sipping-precons-00.txt
>
> Comments are welcome.
>
> Cheers,
>
> 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
-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ 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
