[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Draft: Essential correction for re-INVITE rollback in RFC3261
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
"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 at ericsson.com>
2009-01-12 18:08
|
|
收件人
| <gao.yang2 at zte.com.cn>
|
|
抄送
| "sipping LIST"
<sipping at ietf.org>, <sipping-bounces at ietf.org>
|
|
主题
| RE: [Sipping] 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 at ericsson.com>
发件人: sipping-bounces at ietf.org
2009-01-09 17:32
收件人
"sipping LIST"
<sipping at ietf.org>
抄送
主题
[Sipping] 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP