Subject: RE: [Sipping] BCP for Offer/Answer Use - PLEASE COMMENT

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 2 Nov 2005 12:31:59 +0100

Hi, 

>>With re-INVITE you don't have the possible problems related to 
>>forking, and the risk for "offer/answer race conditions" is not as big

>>etc, so sending a new offer is not as big issue as during session
setup.
> 
>here we are dealing with an early dialog. What extra problems 
>does forking bring to this particular early dialog?
> 
>Regarding the chances of having a race condition, I do not 
>see why they are higher ater returning a 200 OK for a PRACK 
>than after sending an ACK.

Let my try to explain one of my concerns with an example:

Assume User_A sends an offer in PRACK to User_B. User_B does not accept
it, but it still sends a "valid" answer in the 200 (PRACK).

After that, User_B sends an UPDATE back to User_A with an offer (this
offer may e.g. contain the previously agreed SDP).

However, for some reason User_A does not accept the new offer in the
UPDATE, so it rejects it.

Now, in this case the UAS MUST release the call, because the
offer/answer "states" between the UAC and UAS are out of synch. The UAC
still regards the answer received in 200 (PRACK) as valid, and just
because the UAS sends an UPDATE the UAC can't assume it's because the
answer previously sent "wasn't valid after all".

If the offer is rejcted using en empty 200 (OK) both the UAC and the UAS
have the CHOISE whether they want to continue the dialog setup or not,
and the offer/answer state between the users will be synchronized. 

Another example, showing the problem with "race conditions":

During a session setup, a number of offer/answers may be exchanged (e.g.
if pre-conditions are used). Now, User_B rejects it, but sends a "valid"
answer in the 200 (PRACK). After that User_B sends an UPDATE with a new
offer, but at the same time User_A also sends an UPDATE with a new offer
(assuming the answer receivd in the PRACK response was valid). Now, one
of the UPDATEs will have to be rejected (according to the RFC3261
procedures), and again something has to be done in order to re-synch the
offer/answer states.

But, again, if the offer in PRACK is rejected with an empty 200, User_A
has a choise what do to next, and there is no issue with the
offer/answer state un-synch.

Now, you may claim that this is all theoretical. BUT, my understanding
of BCP type of documents is that they describe what people are expected
to implement, so in this case people would have to implement handling of
this in order to be compliant with the BCP. And, from my SIPit
experience etc, I would say that it is difficult enough to find
terminals that support offer/answer with PRACK in the first place, and
I'm pretty sure this kind of complicated behaviour is not going to
improve that... We can of course say "well, then those terminals aren't
compliant", but if there is a big number of those terminals the whole
idea of the BCP document goes away...

Regards,

Christer

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Nov 2005 08:33:02 -0500

> answer previously sent "wasn't valid after all".

When User_B sends the "valid" answer it has *accepted* the offer, even 
if it does not like it. There should be no disagreement between A and B 
about what has been negotiated, though there may be a disagreement over 
the desirability of it.

The UPDATE is then an attempt to get the state to something more 
agreeable to B. If that does not result in something more acceptable 
then the only alternative may be to kill the call.

It is important to carefully decide on what answer to give in the case 
where the offer is undesirable. The answer must result in a state that 
can at least be tolerated, if not desired. For instance, if the offered 
codecs cannot be handled, then the answer might have the port=0, 
a=inactive, or c=0. This will at least result in a tolerable situation 
while an attempt is made to negotiate something better.

	Paul