If the UPDATE is "only refresh the precondtion state table"(I once using "a part of the original modification"), it is discarded by UAS as the failure of Re-INVITE.
Other kind of UPDATE should be treated as a normal UPDATE.(accept/reject)
Then, the key point is the property of UPDATE itself, not its order in the sequence. Then, I say it has no racing condition.
| "Ian Elz" <ian.elz@xxxxxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx 2009-03-05 18:00 |
|
Shinji,
I don't believe that your proposal to reject all UPDATEs received
between the 4xx and the ACK will solve the problem. It won't harm but
there are situations where the UPDATE may arrive after the ACK has been
received by the UAS.
This may occur when another node exists between the UAC and the UAS.
RFC3261 requires that the ACK for a non-2xx response be sent by the
transaction and hence the ACK in this case is hop-by-hop. Only an ACK to
a 2xx response is end-to-end.
This may lead to the following scenario:
1 UPDATE and 4xx/5xx/6xx of Re-INVITE
UAC P1 UAS
| session established |
|<====================|====================>|
| | |
| F1 re-INVITE (SDP) |
|-------------------->|-------------------->|
| F2 1xx-rel (SDP) |
|<--------------------|<--------------------|
| F3 PRACK |
|-------------------->|-------------------->|
| F4 2xx PRA |
|<--------------------|<--------------------|
| | |
|F5 UPDATE F6 4xx INV |
|---------\ /--------|<--------------------|
| \/ | ACK |
| /\ |-------------------->|
|<--------/ \ | UPDATE F6 |
| \------>|-------------------->|
| | |
| ACK | |
|-------------------->| |
The more intervening nodes the greater the probability that this
situation will occur.
Ian Elz
-----Original Message-----
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On
Behalf Of OKUMURA Shinji
Sent: 05 March 2009 02:48
To: sipping
Cc: Gonzalo Camarillo
Subject: Re: [Sipping] My proposal has no racing condition
Gao,
I feel your proposal is no bad for a summary.
BUT, The biggest drawback is which UPDATE is "part of the original
modification" or "new modification". it is very very ambiguous.
the distinction seems to impossible.
It is no doubt that an UPDATE without SDP is "new modification".
UPDATE after ACk is "new modification" too.
but it has a racing condition.
new UAS behavior
reject all UPDATEs received between 4xx and ACK
can the above rule solve the problem ?
Regards,
Shinji
gao.yang2@xxxxxxxxxx
>My proposal has no racing condition
>
>1 UPDATE and 4xx/5xx/6xx of Re-INVITE
>
> UAC UAS
> | session established |
> |<===================>|
> | |
> | F1 re-INVITE (SDP) |
> |-------------------->|
> | F2 1xx-rel (SDP) |
> |<--------------------|
> | F3 PRACK |
> |-------------------->|
> | F4 2xx PRA |
> |<--------------------|
> | |
> |F5 UPDATE F6 4xx INV |
> |---------\ /--------|
> | \/ |
> | /\ |
> |<--------/ \------->|
> | |
>
>Currently, there are only two cases for the Offer in UPDATE:
>
> o part of the original modification;
>
> o a new modification request.
>
>If it is part of the original modification, the session state is clear.
>That
>is the state before F1.
>
>If it is a new modification request, there are only two cases for the
> UPDATE:
>
> o accepted by 200OK;
>
> o rejected by 4xx/5xx/6xx, such as 504.
>
> If it is accepted by 200OK, the new modification is committed. And
> the session state is committed state of the modification triggered
by
> F5.
>
> If it is rejected, and the original modification failed, the session
>state is one before F1.
_______________________________________________
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
_______________________________________________
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.
_______________________________________________ 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
