Dear Christer Holmberg
Perhaps the sequence of my representation makes the misconceive :).
I mean this:
Not considering the 3GPP usage, we have the same point of view. That is: "refine codec set" is part of the "Modifying a Media Stream".
Then let us discuss more on the 3GPP usage. Considering preconditon and "refine codec set":
F1: adding new media stream such as vedio. And the UA can not accept the modification without the user's permition.
F3: "refine codec set"
As precondition is used, the user will only be notified(usually with a new notification of small windows). But when it recv F3("refine codec set") ,
if UA treats it as a new modification, it can not accept it at once. So, it should be rejected with 504.
UAC UAS
| session established |
|<===================>|
| |
| F1 re-INVITE (SDP) |
|-------------------->|
| F2 1xx-rel (SDP) |
|<--------------------|
| F3 UPDATE |
|-------------------->|
| F4 2xx UPT |
|<--------------------|
| |
| F5 180 ringing |
|<--------------------|
| |
| F6 4xx/5xx/6xx INV |
|<--------------------|
| F7 ACK |
|-------------------->|
| |
To make the sequences(which usually used in 3GPP) mentioned above effective, I think we should point it out that the Offer/Answer pair in F3/F4(only "refine codec set" or precondition) is part of the one triggered by Re-INVITE(F1). I need to point out that the definition of this perhaps should be issued by 3GPP.
I think if omitting the third rule, the draft may be more clear and simple. But I think as we talked about the problem, any well known situation should be considered.
But I am not participant of 3GPP, so I am waiting for your comments.
Gaoyang
| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-02-17 14:33 |
|
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.
-------------------------------------------------------- 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
