[SIPForum-discussion] Can 180 be sent with Require:100rel and RACK header without SDP

Fri May 28 12:31:46 UTC 2010

Hi,

  I will try to give you an answer. The reference used by me is RFC 3262.

Your question has several questions within itself. Let me try to address them here...

For each part of your question, I have added My views and also provided reference to the RFC. Hope this helps:).

Q1: Can UAS send 180   with Require: 100rel?

My View:
In my opinion, you can use either 180 or 183 to act as the Reliable Provisional Response (RPR). It should also be possible to send both 180 and 183 as responses but only 183 will be RPR. So, 100rel option tag can appear in 180 or 183 depending on which one your implementation will choose for RPR. Usually, 183 is used.

RFC 3262, Sec. 3, UAS Behavior
A UAS MAY send any non-100 provisional response to INVITE reliably, so long as the initial INVITE request (the request whose provisional response is being sent reliably) contained a Supported header field with the option tag 100rel.  While this specification does not allow reliable provisional responses for any method but INVITE, extensions that define new methods that can establish dialogs may make use of the mechanism

Q2: Can UAS send 180   with Require:100rel and RACK header

My View:
No, 180/183 will not have Rack header. It will have RSeq. The PRACK is used to acknowledge the RPR and will contain the RAck which is formed with the RSeq extracted from the 183, the CSeq, and the method name.

RFC 3262, Sec. 7.2,  RAck
The RAck header is sent in a PRACK request to support reliability of provisional responses.  It contains two numbers and a method tag. The first number is the value from the RSeq header in the provisional response that is being acknowledged.  The next number, and the method, are copied from the CSeq in the response that is being acknowledged.  The method name in the RAck header is case sensitive.
Example:
      RAck: 776656 1 INVITE

Q3: Can UAS send 180 with Require:100rel and RACK header without SDP if it receives INVITE with Supported header contains 100rel

My View:
1. UAS can send a RPR with Require: 100rel or can just send a non reliable provisional response as in a regular case where media negotiation will happen with 200OK. This is because, your INVITE has 100rel in the Supported Header and not in the Require header. So, UAS can decide if it wants to send RPR or not. As per the RFC 3262, if 100rel appears in the Supported header then UAS MAY send RPR and if 100rel appears in the Require header then UAS MUST send RPR. Please note the MAY/MUST keywords used.
2. Assuming your case now, does the INVITE have SDP?
If there was an initial offer(SDP) in the INVITE and the Supported header had 100rel option tag, then UAS MAY send RPR with an Answer (SDP). But if the INVITE did not have SDP, then the first RPR for this INVITE MUST have SDP which will be the offer.
3. There are other cases possible and these are explained in the Reference.

RFC 3262, Sec. 5, The Offer/Answer Model and PRACK
If the INVITE contained an offer, the UAS MAY generate an answer in a reliable provisional response (assuming these are supported by the UAC).  That results in the establishment of the session before completion of the call.  Similarly, if a reliable provisional response is the first reliable message sent back to the UAC, and the INVITE did not contain an offer, one MUST appear in that reliable provisional response.

If the UAC receives a reliable provisional response with an offer (this would occur if the UAC sent an INVITE without an offer, in which case the first reliable provisional response will contain the offer), it MUST generate an answer in the PRACK.  If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK.  If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK.

Once an answer has been sent or received, the UA SHOULD establish the session based on the parameters of the offer and answer, even if the original INVITE itself has not been responded to.

If the UAS had placed a session description in any reliable provisional response that is unacknowledged when the INVITE is accepted, the UAS MUST delay sending the 2xx until the provisional response is acknowledged.  Otherwise, the reliability of the 1xx cannot be guaranteed, and reliability is needed for proper operation of the offer/answer exchange.

All user agents that support this extension MUST support all offer/answer exchanges that are possible based on the rules in Section 13.2 of RFC 3261, based on the existence of INVITE and PRACK as requests, and 2xx and reliable 1xx as non-failure reliable responses.

I hope my explanations answered your question.

Thanks and regards,
Nag.

________________________________
From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of Rambabu Achary
Sent: Wednesday, May 26, 2010 12:58 AM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] Can 180 be sent with Require:100rel and RACK header without SDP

Can UAS send 180   with Require:100rel and RACK header without SDP if it receivis INVITE with Supported header contains 100rel

________________________________
From: discussion-bounces at sipforum.org [mailto:discussion-bounces at sipforum.org] On Behalf Of Rambabu Achary
Sent: Wednesday, May 26, 2010 12:58 AM
To: discussion at sipforum.org
Subject: [SIPForum-discussion] Can 180 be sent with Require:100rel and RACK header without SDP

Can UAS send 180   with Require:100rel and RACK header without SDP if it receivis INVITE with Supported header contains 100rel

________________________________
NOTICE: The information contained in this electronic mail transmission is intended by Convergys Corporation for the use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone (collect), so that the sender's address records can be corrected.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100528/5deff79a/attachment-0002.html>