With bullet I didn't mean that you were trying to
shoot me, or something. "Bullet" in this context refers to the second statement
you gave :)
Hi,
| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-03-10 16:01
|
|
收件人
| <gao.yang2@xxxxxxxxxx>
|
|
抄送
| "Eric.wang"
<eric.wangxr@xxxxxxxxx>, "SIP" <sip@xxxxxxxx>,
"SIPPING" <sipping@xxxxxxxx>
|
|
主题
| RE: [Sip] "UPDATE during
Re-INVITE" discussion |
|
The reason why we have this whole discussion is because the current
specifications are unclear. If everything was clear, and everybody had the
same understanding, we wouldn't need to clarify anything.
[Gao] I think everything is clear. But people
have different view towards UPDATE. So we need clarification than
re-definition here.
So, whatever solution we choose, I am sure that
someone will have to "rewrite their software".
[Gao] Yes. But we should guard the right understanding. And
compel people with misunderstanding to "rewrite their software". I think make
every UPDATE/200OK during Re-INVITE as part of Re-INVITE is a "big" change for
some software.
I support to take
UPDATE/200OK just refreshing "precondition state table" as part of Re-INVITE.
And I think most of current software is doing so.
....IF that
software exists in the first place, that is.
I am not aware of any
deployments which would support re-INVITEs with nested UPDATEs/PRACKs. Maybe
there are such deployments, but I doubt they would all behave in the way as
you describe.
[Gao] I just
talked about if we want to obey RFC3311, it is not right to take all
UPDATE/200OK(during Re-INVITE) as part of Re-INVITE.
Regarding
your second bullet, I don't even think that one should send "nested" UPDATEs,
if they don't have anything to do with the re-INVITE. I think that is bad
application design. Non-related changes should be done outside the re-INVITE
transaction.
[Gao] It is not
bullet, just friendly discussion.
And I think the relationship of Re-INVITE and UPDATEs should be defined
by application level definition, such as precondition. We should not just
making relationship by "during".
Gao
From: gao.yang2@xxxxxxxxxx
[mailto:gao.yang2@xxxxxxxxxx]
Sent: 10. maaliskuuta 2009
9:36
To: Christer Holmberg
Cc: Eric.wang; SIP;
SIPPING
Subject: [Sip] "UPDATE during Re-INVITE"
discussion
OK. Thanks for your standpoint.
But
accepting this means:
1. Rewrite of current software to be as the
behavior defined by "draft-camarillo-sipping-reinvite-00".
2. Making all
UPDATE/200OK "during" Re-INVITE as Re-INVITE's part.
Gao
| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-03-10 15:22
|
|
收件人
| <gao.yang2@xxxxxxxxxx>, "Eric.wang"
<eric.wangxr@xxxxxxxxx>
|
|
抄送
| "SIP" <sip@xxxxxxxx>,
"SIPPING" <sipping@xxxxxxxx>
|
|
主题
| RE: 答复: [Sip] "UPDATE
during Re-INVITE" discussion |
|
I
support view 1.
Regards,
Christer
From: sipping-bounces@xxxxxxxx
[mailto:sipping-bounces@xxxxxxxx] On Behalf Of
gao.yang2@xxxxxxxxxx
Sent: 10. maaliskuuta 2009
8:54
To: Eric.wang
Cc: 'SIP'; 'SIPPING'
Subject:
答复: [Sip] "UPDATE during Re-INVITE" discussion
Yes. If we accept view 1, there would be some backward
compatible problem. And this is a change to RFC3311.
I am
waiting for more comments from people want to keep RFC3311 from
re-write.
Gao
"Eric.wang" <eric.wangxr@xxxxxxxxx> 写于 2009-03-09
20:05:51:
> Hi,
>
> I support view 2,not all update can
be considered as sub-transaction
> of re-INVITE.
> According to current
RFCs, it’s NOT proper to consider all UPDATEs
> as re-INVITE’s
sub-transaction
> Eg:
> UPDATE nested in re-INVITE for target
refresh can’t be considered
> as sub-transaction.
> There are
two thought about "UPDATE during Re-INVITE". Which one is
> better or
suits for current RFCs
>
> There are two thought about "UPDATE
during Re-INVITE".
>
> 1. All UPDATEs during Re-INVITE are
Re-INVITE's sub-transaction
> RFC3312(Precondition) is a case. As there
is such case, we can
> making all UPDATEs during Re-INVITE as
Re-INVITE's sub-transaction.
>
> 2. Not all UPDATE(during
Re-INVITE) can be considered as sub-
> transaction of Re-INVITE
>
There is really need nested-modification, such as precondition and
>
more in the future. But the cascade of nested transaction should
be
> defined in application-level, not signal-level. So, it is better to
> make Re-INVITE and UPDATE separatly expect for definition such as
> precondition. And this obeys current definition of RFC3311.
>
> In RFC3311, when the UPDATE is accepted by the other
> side(UPDATE/200OK), the change of states is committed and effort at
> once. And making all UPDATEs during Re-INVITE as Re-INVITE's
sub-
> transaction can be violation of RFC3311. So, we shold not treat
all
> UPDATEs during Re-INVITE as Re-INVITE's sub-transaction.
>
> While UPDATE/200OK just refresh "precondition state table" in
> RFC3312("precondition state table" is modified at once, so this
> obeys RFC3312), having no impat on the commitment of modification
> triggered by Re-INVITE, these UPDATE/200OK can be treated as
sub-
> transaction of Re-INVITE.
> Other UPDATE/200OK can not be
treated as sub-transaction of Re-INVITE.
>
> Comments/feeling
are welcome!
--------------------------------------------------------
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
