Subject: Re: [Sipping]答复: RE: RE: Re: Draft: Essential correction for re-INVITE rollback in RFC3261

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Jan 2009 11:30:30 -0500

I am very reluctant to make the decision of whether to roll back the 
state dependent on the particular content of the SDP that has been 
exchanged.

	Thanks,
	Paul

[email-masked] wrote:
> 
> Another evidence show the importance of session state:
> 
> In RFC4566(5.13.  Attributes ("a=")):
> Attribute interpretation *depends on the media tool* being invoked.
> Thus receivers of session descriptions should be configurable in
> their interpretation of session descriptions in general and of
> attributes in particular.
> 
> In RFC3264, it just restrict the "m=" lines, no evident restrict about 
> "a=" lines:
> Because of these requirements, the number of "m=" lines in a stream never
> decreases, but either stays the same or increases.
> 
> So, it is possible to define a=" line that means no change while absent 
> in subsequent Offer/Answer.
> It is useful for rich and complex media types which need much more 
> attributes to describe in the future.
> 
> In the situation mentioned above, the subsequent Offer/Answer is just 
> adjustment of session state. And
> *the modification can not be processed without the previous session 
> state as the base.*(It is
> reasonablely to find in RFC3264 that: It is assumed that the higher 
> layer protocol provides maintenance
> of some kind of context which *allows the various SDP exchanges to be 
> associated together*.)
> 
> After failure of Re-INVTE, it is still important for the two peers have 
> the same point of view of session
> state, beacause that's the base of further modification if using the 
> type of "a=" lines mentioned above.
> 
> So, we can see that, "manual rollback" using a new Re-INVITE may refresh 
> the session state, but may be no
> effective in the furure.
> 
> In session usage such as remote virtual reality that makes the sense of 
> physical immersion, it may be need
> many attributes of such media type. And it may weaken the real time 
> sense while modify session with all
> the attributes list.
> So, it is practical to omit the attributes without adjustment in SDP.
> 
> --------------------------------------------------------
> 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP