Re: [Sipping] Rollback issue: a proposal

[[e-mail]]

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







[e-mail] 写于 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 [e-mail] for questions on current sip
> Use [e-mail] 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.