Hi，
I agree, we should find a way cover all use-cases.
Firstly, i think, we should try to find a way to solve all problem in certain
terms, and then make the way as a suggestion.
Just as the words in RFC3311:
""Although UPDATE can be used on confirmed
dialogs, it is RECOMMENDED that a re-INVITE be used instead.""
Secondly, we use the finding way to all use-cases, and enrich the way with
some patches in order to let the suggested way cover all use-cases.
For UPDATEs and re-INVITEs, there are three common cases.
case 1: UPDATEs are for pre-condition in the re-INVITEs.
case 2: UPDATEs are new modifications outside the re-INVITEs.
case 3: UPDATEs are new modifications just during the re-INVITEs,
but obey the offer/answer model.
Followed are solutions for the above three case.
case 1: It's just a pre-condition notification, if failure happens,
rollback to the state before the re-INVITE.
case 2: This UPDATE can be distinguished from others easily, and should
refresh the state if successful, and remain the state just before
UDPATE if failure.
case 3: We should record the state if negotiation is successful,and rollback
to the state before UPDATE if failure happens.
And there is a rule: if both UPDATE and re-INVITE success, we should
record the state commited by UPDATE. if UPDATE successes and re-INVITE fails,
we should record the state commited by UPDATE. if UPDATE fails and re-INVITE
successes ,we should record the state commited by re-INVITE.If both fail,
we should rollback the state before re-INVITE.
This case is also mentioned in "draft-gaoyang-sipping-session-state-criterion-01"
4.3.1 Problem.
From above, UPDATEs outside re-INVITEs make the solution much more difficult,
we have to find which UPDATEs are for notifications and which are not. We should
determine which state to commit when both success.Also if UDPATEs can be raised at
any time ,more 491 and 500+retry will be found, and so on.
So i suggest UPDATEs with SDP should better be replaced by re-INVITE，but that not
means forbidden，just a suggestion.
And there also are solutions to solve all UPDATEs.
Waiting for your comments.
Begards,
Eric.wang
"Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx> 写于 2009-02-19 16:24:03:
>
> Hi,
>
>
> >In my opinion,the re-INVITE should fallback to the state before the
> re-INVITE.
> >And it doesn't matter what the precodition state is. Because the
> re-INVITE is
> >rejected,the state of its precondition state seems useless.
> >
> >By limiting UDPATEs for new modification outside re-INVITE,we can find the
> >right state to fallback.
>
> This issue does only talk about UPDATEs "inside" the re-INVITE.
>
> Regards,
>
> Christer
>
>
>
>
>
>
> "Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx> 写于
> 2009-02-19 03:24:04:
>
> > Hi,
> >
> > Let's look into this precondition proposal.
> >
> > There are some issues that needs to be taken into consideration.
> >
> > Issue 2:
> > -----------
> >
> > Assume I send a re-INVITE, and I use precondition. I modify the SDP,
> > and indicate that preconditions are not met.
> >
> > Then I receive a relaible 18x, and the first offer/answer
> > transaction has succeeded.
> >
> > Later I send an UPDATE request, where I indicate that
> preconditions are met.
> >
> > Then I receive a 200 for the UPDATE, indicating that preconditions
> > are met also at the other end.
> >
> > Then the re-INVITE fails. Now, according to the ZTE proposal, is
> > there a full fallback? The UPDATE was sent as part of the nested
> > precondition procedure, but the preconditions were fullfilled before
> > the re-INVITE failed?
> >
> > Does it matter what the precondition state is when the re-INVITE
> > fails, or is there always a full fallback?
> >
> > Regards,
> >
> > Christer
> >
>
> --------------------------------------------------------
> 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
