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.
So, whatever solution we choose, I am sure that someone will have to "rewrite
their software".
....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.
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.
Regards,
Christer
________________________________
From: [email protected] [mailto:[email protected]]
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" <[email protected]>
2009-03-10 15:22
收件人
<[email protected]>, "Eric.wang" <[email protected]>
抄送
"SIP" <[email protected]>, "SIPPING" <[email protected]>
主题
RE: [Sipping] 答复: [Sip] "UPDATE during Re-INVITE" discussion
I support view 1.
Regards,
Christer
________________________________
From: [email protected] [mailto:[email protected]] On
Behalf Of [email protected]
Sent: 10. maaliskuuta 2009 8:54
To: Eric.wang
Cc: 'SIP'; 'SIPPING'
Subject: [Sipping] 答复: [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" <[email protected]> 写于 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.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
