Hi,
I agree that pre-conditions may be performed before the
user is prompted, which may then cause the re-INVITE to fail. That was also
previously discussed on the list.
Now, if resources have been reserved, and the re-INVITE
fails, there is nothing which prevents entities to release those
resources.
Also, if additional m- lines have been added, you will
need to send a new re-INVITE/UPDATE to remove it. That's what we call a "manual
fallback".
Also, if you look at the old thread, there was a
discussion about a possible race condition which could occur if you do a full
fallback.
Regards,
Christer
From: gao.yang2@xxxxxxxxxx [mailto:gao.yang2@xxxxxxxxxx]
Sent: 13. tammikuuta 2009 2:43
To: Christer Holmberg
Cc: sipping LIST; sipping-bounces@xxxxxxxx
Subject: 答复: RE: Draft: Essential correction for re-INVITE rollback in RFC3261
"draft-gaoyang-sipping-session-state-criterion-00.txt", clarify that there is no
ambiguous state of session modification using current RFC definition.
Just using current RFC definition， and without violation or new definition.
My points of view:
1、It should make the user have the capability to accept or refuse session modification
(see "Intuitionistic(user point of view) requirement for rejecting session modification").
In my points of view, IMS(3GPP) as the multimedia platform, it should be enriched with
this intuitionistic(user point of view) requirement.
Considering precondition, it is always exchange offer/answer(and modified the session parameters)
before prompting the end user.
2、offer/answer is atomic, but it can be part of a nested transaction. Such as modification with precondition
may have more than one offer/answer pair. So the modification is atomic, and the offer/answer is its part.
If the precondition is not just about resource reservation(for example, two precondition, one about
resource reservation, another about other application aspect).
So when meeting precondition about resource reservation, the session parameters have been modified(sucessfully).
But if the precondition about other application aspect is not meeted, this modification should be discard.
So, how the application level will using the offer/answer as part of a nested transaction, is just beyond the offer/answer definition.
And we should open the gate for the application level extention.
"Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx> 2009-01-12 18:08
<gao.yang2@xxxxxxxxxx> "sipping LIST" <sipping@xxxxxxxx>, <sipping-bounces@xxxxxxxx> RE: Draft: Essential correction for re-INVITE rollback in RFC3261
Hi,
>1.
>In "draft-ietf-sipping-sip-offeranswer-08.txt ", there is a use case:
>The case of
>adding a new media (like adding video to audio only session) which
>requires permission from the peer through some user interaction is
>one example.
>From the user's viewpoint, he(or she) just reject the modification of session, so
>the offer/answer should be rollback.
>So, "any session
>parameters that have been sucessfully changed during the duration of
>the re-INVITE transaction MUST remain unchanged" is not reasonable for all
>application use case.
We have agreed that we cannot define different rules for different use-cases. We need to have a generic rule, and implementors shall then use that.
There was a long discussion on which solution to go for, and the text now reflects the agreed solution (which we also informed 3GPP about).
Regards,
Christer
2.
There are nested transactions concept in application level above of offer/answer
which use a offer/answer pair as a sub-transaction. So, commit/rollback is not just
offer/answer issue, it is a application issue(such as precondition may have more than
one offer/answer pairs).And application level usage of offer/answer should be open for
the future extension.
3.
I just submitted a draft talking about session state 2009-01-08:
https://datatracker.ietf.org/idst/status.cgi?submission_id=11690
the document URL:
http://www.ietf.org/proceedings/staging/draft-gaoyang-sipping-session-state-criterion-00.txt
(the URL "http://www.ietf.org/proceedings/staging/draft-gaoyang-sipping-session-state-criterion-01.txt"
is not available, but the 00.txt is the current one)
"Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx
2009-01-09 17:32
收件人
"sipping LIST" <sipping@xxxxxxxx>
抄送
主题
Draft: Essential correction for re-INVITE rollback in RFC3261
Hi,
I've put together the first version of the draft related to the re-INVITE follback fix, based on the agreed solution.
I had some problems with the IETF submission tool, but the draft can be found at:
http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-reinvite-rollback-00.txt <http://users.piuha.net/cholmber/drafts/draft-holmberg-sipping-reinvite-rollback-00.txt>
Regards,
Christer _______________________________________________
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
--------------------------------------------------------
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
