Hi,
I am a little confused about the statements about the
"3GPP usage".
I don't think the "refine codec set" use-case is 3GPP
specific. Anyone can refine/reduce the codecs, after one has learned what set of
codecs both ends support.
Also, I am not sure whether "user permission" is needed
in order to refine the codec set. Users normally don't care (they shouldn't have
to care) what codecs are used.
So, in my opinion the 3GPP use-case is part of the
"Modifying a Media Stream" case.
Regards,
Christer
From: gao.yang2@xxxxxxxxxx [mailto:gao.yang2@xxxxxxxxxx]
Sent: 17. helmikuuta 2009 8:16
To: Christer Holmberg
Cc: sipping@xxxxxxxx
Subject: Explanation for semantics of "a new modification" //: RE: About "rollback of re-Invite"
What is a new modification? This is another good question people once asked.
Without clear definition for extension, anything or its combination defined in chapter 8 of RFC3264 MUST be treated as a new modification, that is:
Adding a Media Stream,
Removing a Media Stream,
Modifying a Media Stream,
Putting a Unicast Media Stream on Hold(or from on hold to active)
"Modifying a Media Stream" can be further divided into:
Modifying Address, Port or Transport,
Changing the Set of Media Formats,
Changing Media Types,
Changing Attributes.
And if we can say something form a nested transaction, there MUST be correspond definition. In RFCs, there are two of such definition:
1. Precondition
It is defined in RFC3312(Quality-of-Service precondition)\4032(Precondition Framework)\5027(Security Preconditions), and the suspending\resuming semantic of session modification is clear. So, it is a typical nested transaction.
2. Intuitionistic(user point of view) requirement for rejecting session modification
It is defined in RFC3261. From users's point of view, it is a kind of late committment. And it is useful for users to rejecting session modification.
3. 3GPP usage of Offer/Answer to refine(reduce) codec set
In chapter 8.3.2 of RFC3264, refining(reduce) codec set is a kind of modification, and there is no definition as RFC3312 to define sub-transaction concept. So, I do not think this kind of Offer/Answer can be treated as sub-transaction of the original one in semantics of current RFCs.
And if one side send a new UPDATE during the pending Re-INVITE, the other side can has two choose:
o if the UA can accept the UPDATE, and after Offer/Answer, the modification MUST be committed.
o if the UA can not accept the UPDATE(for example, can not accept it without the user's permition), the UA MUST reject UPDATE.
I MUST point out that in RFCs semantics, the third rule should be omitted.
But 3GPP really has such usage. And I think the original requirement of obeys the concept of nested transaction, so I list it here.
And the classification of a new modification is quit simple. At list, it is not harder than the judgement of whether Precondition has been satisfied.-------------------------------------------------------- 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
