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

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

Hi, 

>>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".
> 
>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.

If we could reject the offer by using specific parameter values in the
"answer" it would solve lots of problem, I think, but that would need to
be defined.

I guess setting the port to zero could be used already with the existing
specifications, but the problem is that the calling party would then
have to send a new offer with a new stream, since the stream with the
zero port can't be "re-used".

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 10:36:26 -0500

> "answer" it would solve lots of problem, I think, but that would need to

Yes, there is currently no defined way to do that.

> zero port can't be "re-used".

There was once a restriction like that, but no more.
You may recycle the media lines in a subsequent offer.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 02 Nov 2005 18:56:49 +0200

Hi,

> You may recycle the media lines in a subsequent offer.

yes, that was the conclusion of the discussions on the issue we had some 
time ago. This is definitively something that should be covered in the 
draft.

Cheers,

Gonzalo