| WangLiBo135681/user/zte_ltd
2009-02-19 08:33 |
|
Hi Christer,
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.
[gaoyang] I agree with Wang Libo here.
By limiting UDPATEs for new modification outside re-INVITE,we can find the
right state to fallback.
[gaoyang] It is BCP thing. And the solution in theory can solve it, even if UPDATE/200OK
with Offer/Answer is a new modification during Re-INVITE.
What do you think about this?
Best wishes,
Eric.wang
"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.
_______________________________________________ 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
