Re: My proposal has no racing condition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Please be aware that there may also be offer/answer state aware
intermediates, of which some may have received the 4xx (F6) BEFORE they
received the UPDATE (F5), and they must all end up having the same SDP
state. Otherwise you have a mess.

Regards,

Christer

> -----Original Message-----
> From: sipping-bounces@xxxxxxxx 
> [mailto:sipping-bounces@xxxxxxxx] On Behalf Of OKUMURA Shinji
> Sent: 5. maaliskuuta 2009 13:02
> To: Ian Elz; sipping
> Subject: Re:  My proposal has no racing condition
> 
> Hi,
> 
> New rule.
> 
> UAC Behavior
> 	After receiving 4xx, if UAC receive 200 response with answer
> 	to UPDATE that sent before receiving 4xx, UAC MUST 
> treat it as if
> 	UAC sent the UPDATE after sending ACK.
> 
>       UAC                   P1                    UAS
>        |          session established              |
>        |<====================|====================>|
>        |                     |                     |
>        |            F1  re-INVITE (SDP)            |
>        |-------------------->|-------------------->|
>        |            F2 1xx-rel (SDP)               |
>        |<--------------------|<--------------------|
>        |                F3   PRACK                 |
>        |-------------------->|-------------------->|
>        |                 F4 2xx PRA                |
>        |<--------------------|<--------------------|
>        |                     |                     |
>        |F5 UPDATE(offer)  F6 4xx INV               |
>        |---------\  /--------|<--------------------|
>        |          \/         |     F7 ACK          |
>        |          /\         |-------------------->|
>        |<--------/  \        |     F5 UPDATE       |
>        |             \------>|-------------------->|
>        |                     |                     |
>        |                 F8 2xx UPDATE(answer)     |
>        |<--------------------|<--------------------|
>        |         ACK         |                     |
>        |-------------------->|                     |
> 
> What do you think of this idea ?
> 
> Regards,
> 
> Shinji
> 
> "Ian Elz" <ian.elz@xxxxxxxxxxxx>
> >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:  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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux