I think Gonzalo is working on clarifying "in-use", so
I DO think you should concentrate on YOUR proposal
:)
Yes.
Then, could you define clearly for "in use" for
Camarillo in the "picture". Last time you give one, but Camarillo asked me to
concentrate on his.
"Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-03-02 16:47
|
收件人
| <gao.yang2@xxxxxxxxxx>
|
抄送
| "Gonzalo Camarillo"
<gonzalo.camarillo@xxxxxxxxxxxx>, "Hadriel Kaplan"
<HKaplan@xxxxxxxxxxxxxx>, "sipping"
<sipping@xxxxxxxx>, <sipping-bounces@xxxxxxxx>
|
主题
| RE: RE: RE: RE: RE: Re: [Sipping]
Summary of Closing the offer/answer rollback
issue? |
|
In IETF pictures are normally modified (even re-painted)
MANY times before something is finally agreed :)
However, in this
case we need clear proposals.
Regards,
Christer
From: gao.yang2@xxxxxxxxxx
[mailto:gao.yang2@xxxxxxxxxx]
Sent: 2. maaliskuuta 2009
10:44
To: Christer Holmberg
Cc: Gonzalo Camarillo; Hadriel
Kaplan; sipping; sipping-bounces@xxxxxxxx
Subject: 答复: RE: RE: RE:
RE: Re: [Sipping] Summary of Closing the offer/answer rollback
issue?
Yes.
I also think we need the full picture.
I just want to know can we still modify the
"picture" after its first "painting".
"Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-03-02 16:37
|
收件人
| <gao.yang2@xxxxxxxxxx>
|
抄送
| "Gonzalo Camarillo"
<gonzalo.camarillo@xxxxxxxxxxxx>, "Hadriel Kaplan"
<HKaplan@xxxxxxxxxxxxxx>, "sipping"
<sipping@xxxxxxxx>,
<sipping-bounces@xxxxxxxx>
|
主题
| RE: RE: RE: RE: Re: [Sipping]
Summary of Closing the offer/answer rollback
issue? |
|
Hi,
>I think so now.
And you can ask Gonzalo if he think it is the only branching.
>
>But I want to know
that if I or someone else find new branching, can it be talked?
I am
not sure what you mean by "be talked", but I think we need a full picture of
the alternatives, and the difference between
them.
Regards,
Christer
"Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-03-02 15:00
收件人
<gao.yang2@xxxxxxxxxx>
抄送
"Gonzalo Camarillo"
<gonzalo.camarillo@xxxxxxxxxxxx>, "Hadriel Kaplan"
<HKaplan@xxxxxxxxxxxxxx>, "sipping" <sipping@xxxxxxxx>,
<sipping-bounces@xxxxxxxx>
主题
RE: RE: RE: Re: [Sipping] Summary of
Closing the offer/answer rollback issue?
>>Then
that is: Considering RFCs, "refine codecs" is "a new modification".
>>
>>Not considering "evolution and extension", it is
still a solution without any violation of RFCs.
>
>Yes, but that was not the point. I am trying to figure
out what the differences between the proposals are.
>
>[Gao] Yes.
>
>But what I think important for "evolution and extension" is nested
transaction. And if using something like "a= chain"(RFC3108) in Offer/Answer,
nested transaction concept can be more
>effective.
Yes, but we can have "something likes" - we need clear rules.
>So, again: is the "late commitment"
currently the ONLY difference between yours and Gonzalo's proposals, or is
there something else?
>
>[Gao]
IMO, "Late commitment" is the most important branching for current SIP/SDP
usage.
That is not what I
asked.
Regards,
Christer
"Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-03-02 14:21
收件人
<gao.yang2@xxxxxxxxxx>
抄送
"Gonzalo Camarillo"
<gonzalo.camarillo@xxxxxxxxxxxx>, "Hadriel Kaplan"
<HKaplan@xxxxxxxxxxxxxx>, "sipping" <sipping@xxxxxxxx>,
<sipping-bounces@xxxxxxxx>
主题
RE: 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
________________________________
From: gao.yang2@xxxxxxxxxx [mailto:gao.yang2@xxxxxxxxxx]
Sent: 2. maaliskuuta 2009 5:47
To: Christer Holmberg
Cc: Gonzalo Camarillo;
Hadriel Kaplan; sipping; sipping-bounces@xxxxxxxx
Subject: 答复: Re: [Sipping] Summary of Closing the offer/answer rollback
issue?
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@xxxxxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx
2009-03-02 05:30
收件人
"Hadriel Kaplan" <HKaplan@xxxxxxxxxxxxxx>,
"Gonzalo Camarillo" <gonzalo.camarillo@xxxxxxxxxxxx>, "sipping"
<sipping@xxxxxxxx>
抄送
主题
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@xxxxxxxxxxxxxx]
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@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.
--------------------------------------------------------
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.
--------------------------------------------------------
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