Dear Christer Holmberg:
I mentioned that:
Without clear definition for extension, anything or its combination defined in chapter 8 of RFC3264 MUST be treated as a new modification.
It is clear.
Gaoyang
| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-02-17 15:54 |
|
Hi,
>I am agree with you that "refining/choosing the codec" should not be "user permission" issue if the there is no special billing policy for codecs.
>
>The "user permission" is about things such as adding of media type.
>The modification triggered by F1/F2 is not committed by user, then the same one(as a new modification) triggered by F3/F4 can not be acceptted by UA itself.
>
>And it is restricted that only "refining the codec" can be treated as sub-transaction of the origianl one, "adding the codec" is not.
My issue is that it will be impossible to make sure everyone has a common understanding of what a "sub-transaction" is, and what isn't, and you will end up with interoperability problems - unless you come up with a generic and easy to understand/apply rule.
For example, if I change some properties (ptime etc) for an existing codec, is that always a sub-transaction, is it sometimes a sub-transaction, or is it never a sub-transaction?
Also, assume I use pre-conditions, and add a stream. But, the re-INVITE is then rejected. Now, since this is a "nested transaction", I assume you propose that a full fallback would be performed in this case?
Regards,
Christer
Gaoyang
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 |
|-------------------->|
| |
"Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx>
2009-02-17 14:33
收件人
<gao.yang2@xxxxxxxxxx>
抄送
<sipping@xxxxxxxx>
主题
RE: Explanation for semantics of "a new modification" //: RE: About "rollback of re-Invite" - 3GPP usage
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.
-------------------------------------------------------- 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
