[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] Summary of Closing the offer/answer rollback issue?
Hi,
Again, I strongly do NOT think we should choose an
"evolution and extension" approach, and let organizations decide what is a new
modification, and what isn't. Again, you can have entities which belong to
DIFFERENT organizations´communicating with each other, and those should have a
common understanding of the rules.
If you have a closed network, where you know that every
entity belongs to a single organization, you can of course do whatever you want.
But, in that case you don't need to standardize
it.
Regards,
Christer
My draft is open for evolution and
extension. My view is that:
Considering RFCs, "refine codecs" is "a new modification". And if some
one(org/operator/internal usage) think "refine codecs" is part of the original
modification. It still can assure its session state by nested transaction
concept.
Some custom-built one
really treated it as part of the original modification.
"Christer Holmberg"
<christer.holmberg at ericsson.com>
发件人: sipping-bounces at ietf.org
2009-03-02 05:30
|
|
收件人
| "Hadriel Kaplan"
<HKaplan at acmepacket.com>, "Gonzalo Camarillo"
<gonzalo.camarillo at ericsson.com>, "sipping"
<sipping at ietf.org>
|
|
抄送
|
|
|
主题
| Re: [Sipping] Summary of Closing
the offer/answer rollback issue? |
|
Hi Hadriel,
I guess Gonzalo will provide his summary
soon, but I don't think there
is currently a disagreement regarding
pre-conditions. You call them
"conditional offers", Gao calls them
"notifications", but that's just
wording... :)
I think the one of
the main issues at the moment is what happens after
preconditions have been
met on both sides:
1) Is the change now commited/in-use, and a
re-INVITE failure would not
change that?
<----- "in-use"
alternative
OR
2)
Would a re-INVITE failure cause a fallback (this is what is meant by
"late
commitment")?
<---- "late
commitment"
alternative
If preconditions have NOT been met, and the re-INVITE
fails, I think
most agree that there will be a rollback to the "last
committed state".
Gao's draft also talk about other changes which
would not be considered
as "real" SDP offers, for example if you reduce
codecs. But, at least I
strongly prefer NOT to go into such details,
because that would for sure
cause interop issues. I am not sure what Gao's
view on that is at the
moment, though?
Regarding the race
condition, I think we can avoid that with some BCP-
and guidance
text.
Regards,
Christer
-----Original
Message-----
From: Hadriel Kaplan [mailto:HKaplan at acmepacket.com]
Sent:
Saturday, February 28, 2009 5:26 PM
To: Christer Holmberg; Gonzalo
Camarillo; sipping
Subject: Summary of Closing the offer/answer rollback
issue?
Is there an email in this long thread that summarizes the
issues?
It's impossible to follow this thread. :)
I'm not clear on
what the issues are with pre-conditions that make
failed offers concept
break. To me, pre-conditions are basically not
real SDP offers;
they're conditional offers. Until the *all* the
conditions are met,
it's not "committed". You continue using the last
committed state.
I know there are race conditions, but considering how
rare
pre-conditions are in the real world (especially in re-Invite's),
that I'm
having trouble imagining why we should care about corner cases
of such.
Regardless, I vote for any fixing that needs to happen because
of
pre-conditions should be around changing pre-condition logic, even if
it
means completely re-writing how pre-conditions works - don't change
normal
SIP or SDP. (not that anyone is proposing it, I just can't tell
form this
thread)
Re-Invites and SDP offer/answer have so many interop issues in
the wild
even without pre-conditions, that this whole thread scares me.
:(
-hadriel
_______________________________________________
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.