Subject: Re: [Sipping] sipping-sip-offeranswer-05: comments and questions

From: "Fred Seymour" <[email-masked]>
Date: Thu, 7 Feb 2008 19:21:51 +0900

Hi.

I have a question regarding Paul's comment.

my comment inline.

Fred.

Paul Kyzivat <[email-masked]>
>Brett,
>
>OK, I now see that this isn't just a matter of clarifying wording. It is
>truly a discussion of the proper interpretation of 3262.
>
>The question is:
>
>If a PRACK contains a new offer, is it valid to respond to it with a 488
>or 606 to indicate unhappiness with the offer?
>
>The problem with returning any error to a PRACK that legitimately
>matches a response is that by rejecting it you have also (IMO) prevented
>it from serving its primary role of acknowledging the earlier response.
>I has assumed it was inappropriate for that reason. (Which of course
>leaves a case not covered by the specs.)

When rejecting the offer in PRACK, It only has to send 200 OK response for
PRACK with the SDP that has port number in m line set to zero.

IMHO, the response code of PRACK should be irrelevant to offer/answer.

>
>How do we resolve that and proceed?
>
>- we could decide that with careful enough reading the spec does cover
>this case, one way or another. If so then we can craft the offeranswer
>draft to explain this clearly.
>
>- we can conclude that this case is not normatively specified and so is
>ambiguous, and requiring of a normative fix. We can call that out for
>future work, and put best practice guidance into the offeranswer draft
>on how best to function in the presence of this ambiguity. This is what
>I think the draft is currently attempting to do.
>
>       Thanks,
>       Paul
>
>Brett Tate wrote:
>>> Brett Tate wrote:
>>>>>> The following are some questions and comments concerning
>>>>>> draft-ietf-sipping-sip-offeranswer-05.
>>>>>>
>>>>>> The draft mentions "PRACK request should not be rejected".
>>>>>> Is this actually mentioned/explained within an RFC or only within
>>>>>> this draft?
>>>>>> I agree that offers within a PRACK should be discouraged.
>>>>>> However I don't a recall an RFC mentioning that PRACK
>>>>>> offer cannot be rejected with 488.
>>>>> In RFC 3262, section 3, is the following: "... If the PRACK does
>>>>> match an unacknowledged reliable provisional response, it MUST be
>>>>> responded to with a 2xx response. ..."
>>>> Hi Paul,
>>>>
>>>> Certainly some context matters associated with that sentence.
>>> Yes, that is true.
>>>
>>>> Besides the 481 mentioned within that paragraph,
>>>> certainly other responses are possible: 100 (per rfc4320),
>>> Not legal for PRACK due to NIT draft (RFC now)
>>
>> RFC 4320 still allows it; see section 4.1.
>>
>>
>>>> 401, 407, 500, 503, etcetera.  Tables 1 and 2 reflect
>>>> all kinds of responses for PRACK; and certainly the
>>>> quoted sentence was not intended to severely limit
>>>> the possible responses.
>>> Yes, agreed.
>>
>> If so, why should the sentence in question only prevent 488 and 606
>> (other body related responses?) without preventing all the other sip
>> responses?
>>
>>
>>>> I've always interpreted that sentence in relation
>>>> to what follows it since it makes little sense to
>>>> do otherwise.
>>>>
>>>> "If the PRACK does match an unacknowledged reliable
>>>> provisional response, it MUST be responded to with
>>>> a 2xx response.  The UAS can be certain at this point
>>>> that the provisional response has been received
>>>> in order.  It SHOULD cease retransmissions of the
>>>> reliable provisional response, and MUST remove it
>>>> from the list of unacknowledged provisional responses."
>>> Yup. And IMO the offeranswer draft is talking about that
>>> context when it makes its statement.
>>>
>>>> A rewording of the sentence as follows might avoid
>>>> some difference of interpretation.
>>> You are talking about rewording the sentence in 3262, right?
>>
>> I'm only indicating that it potentially could be better worded to avoid
>> people reading the sentence out of context.
>>
>> I think sipping-sip-offeranswer-05 is reflecting a misinterpretation of
>> the sentence by not mentioning PRACK 488 response within section 2.2.
>> The misinterpretation is also evident within sections 3.2 and 4.1:
>> "PRACK request should not be rejected".  The misinterpretation is also
>> evident within section 6.1.
>>
>>
>>>> However it causes a long sentence instead of just
>>>> requiring interpretation in relation to the 2
>>>> sentences which follow it and the rest of the RFC.
>>>>
>>>> Old: "If the PRACK does match an unacknowledged
>>>> reliable provisional response, it MUST be responded
>>>> to with a 2xx response."
>>>>
>>>> New: "If the PRACK does match an unacknowledged
>>>> reliable provisional response, it MUST be responded
>>>> to with a 2xx response if communicating that
>>>> the PRACK was successfully received by the UAS and
>>>> PRACK does not need to be tried again to stop related
>>>> retrying of 1xx."
>>> I'm sorry, but I don't understand what you are trying to
>>> achieve with that change. You seem to be trying to introduce
>>> a new condition under which a non-2xx response may be sent,
>>> which wasn't included in the original text. If so, that is
>>> more than a clarification.
>>>
>>> The statements in the offeranswer draft are, AFAIK,
>>> consistent with 3262 relative to this point.
>>
>> AFAIK the statements made within the offeranswer draft are a
>> misinterpretation of the sentence in question.
>>
>>
>>> The point here is that the primary purpose of the PRACK is to
>>> confirm the receipt of the response, and the purpose of the
>>> response to the PRACK it to quench the retransmission of the
>>> PRACK. Its a problem if the PRACK is rejected because of
>>> problems with the body it is carrying.
>>
>> It is no more of a problem than rejecting for other reasons.  The UAC
>> receives the 488/606; it adjusts or removes the SDP when re-sending
>> PRACK using higher CSeq.
>>
>> <snip>
>>
>>
>>> Is there something that needs to be changed in
>>> the o/a draft given the constraint that it is not
>>> changing normative behavior?
>>
>> I think sipping-sip-offeranswer-05 is reflecting a misinterpretation of
>> the sentence in question.
>>
>> I think that the draft should mention PRACK 488 response within section
>> 2.2.
>>
>> Concerning "PRACK request should not be rejected" within sections 3.2
>> and 4.1, I don't think such a statement should be made without
>> clarification somewhere concerning the reason.
>>
>> I think that the draft should mention PRACK 488 response within section
>> 6.1.
>> _______________________________________________
>> Sipping mailing list  http://www.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
>>
>_______________________________________________
>Sipping mailing list  http://www.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
_______________________________________________
Sipping mailing list  http://www.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: Thu, 07 Feb 2008 10:26:56 -0500

Fred Seymour wrote:
> Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
>  >Brett,
>  >
> When rejecting the offer in PRACK, It only has to send 200 OK response 
> for PRACK with the SDP that has port number in m line set to zero.

There is a distinction between rejecting the offer as a whole, thus 
preserving the status of the prior o/a, and refusing *parts* of the 
offer and agreeing to keep the remainder.

So yes, you can return a 200 and zero out the port, if that accomplishes 
what you want to accomplish.  But suppose you had previously negotiated 
media that seem fine to you, and the new offer is not even syntactically 
correct. What should you do then?

> IMHO, the response code of PRACK should be irrelevant to offer/answer.

That is a different story, and is what we are debating at the moment.

Surely the response code is somewhat relevant. If you are returning a 
4xx to a prack with an offer, the the 4xx will not be containing an answer.

	Paul

>  >> Use [email-masked] 
> <mailto:[email-masked]> for questions on current sip
>  >> Use [email-masked] <mailto:[email-masked]> for new developments of core SIP
>  >>
>  >Use [email-masked] 
> <mailto:[email-masked]> for questions on current sip
>  >Use [email-masked] <mailto:[email-masked]> for new developments of core SIP
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Fred Seymour" <[email-masked]>
Date: Fri, 8 Feb 2008 11:07:03 +0900

thank you for your reply.

Though it is likely to become a different scenario.
when PRARK is rejected by 401/407, if PRACK include an answer,is the
answer effective ?  Or, if PRACK include an offer , is the offer
effective ?

Fred.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Feb 2008 11:40:24 -0500

> answer effective ?  Or, if PRACK include an offer , is the offer

Presumably not. In case of 407 it is virtually certain that the UAS 
hasn't seen it.

	Paul