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
gao.yang2@xxxxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
