Subject: [Sip] Question on offer-answer during establishment

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 Sep 2004 14:08:24 +0100

RFC3261 states (13.2.1, second bullet):

"The UAC MUST treat the first session description it receives as the answer,
and MUST ignore any session descriptions in subsequent responses to the
initial INVITE."

Suppose SDP answer is received in a reliable provisional response. This
would complete the offer-answer sequence. The behaviour mandated here would
seem to preclude the UAS sending a further offer in a subsequent reliable
provisional response or 2xx. Is this intended, and if so for what reason?
Obviously the UAS can send an UPDATE request (or re-INVITE request after
answer) if it wishes to re-negotiate the session, but this would involve
additional messages.

John Elwell ([email-masked])

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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 30 Sep 2004 07:29:54 +0200

Hi,

>>At the previous SIPit we had some discussions about the 
>>usage of PRACK for offer/answer. The problem, as said before, 
>>is that there is currently no standard way to reject an offer 
>>received in a PRACK, because a UAS MUST answer with 200 OK, 
>>if the PRACK otherwise is ok, matches a reliabel provisional 
>>response etc. It has even been suggested that it should be 
>>forbidden to send SDPs (at least new offers) in PRACKs, but 
>>that would of course have impacts on existing nodes - 
>>depending on how many nodes currently support it in the first 
>>place, of course.
>>  
>>
>It's not mentioned in RFC 3262 how to reject an offer, but 488 (Not 
>Acceptable Here) might be a natural choice according to 
>Section 13.3.1.3 of RFC 3261, quoted below. In practice, 4xx-6xx respons to 
>PRACK (which contains offer) may also be considered rejection of offer.
> 
>"
> 
>    A UAS rejecting an offer contained in an INVITE SHOULD return a 488
>    (Not Acceptable Here) response.  Such a response SHOULD include a
>    Warning header field value explaining why the offer was rejected.
> 
>"

You are right. But, at the same time the PRACK RFC says that 200 MUST be sent, and I think is also the conclusion from previous discussions on the list.

I know about implementations that reject the offer by simply don't inserting an answer in the 200 OK. No, you don't have to tell me it's non-standard behaviour :)

Regards,

Christer Holmberg
Ericsson Finland