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

From: [email-masked]
Date: Fri, 21 Oct 2005 13:04:18 +0530

Hi Takuya,

I have some questions/comments on Section 3.1 Message Crossing Case
Handling.

[Statement]When offer2 is in a PRACK request, UA A knows it is an offer
because there never be the case that it sends another reliable
provisional response which may cause PRACK request with an offer while
UA A is waiting for the answer with a PRACK request. 

[comment] I think even in the case UA A sends another reliable
provisional response, as RAck distinguishes these PRACKs, UA A can
detect offer2 in PRACK is not answer to offer1.

[Statement]When offer2 is in a reliable provisional response or a
successful final response, UA A knows it is not the answer to the
offer1. For a reliable response to an initial INVITE request, this case
never happens. 
For a reliable response to a re-INVITE request, to avoid  this case, UA
A should not send an INVITE request without session description if it
has sent the offer which has not yet received the answer to it. 

[Comment] Even if a re-Invite is sent without SDP, UA A will be able to
detect that offer in reliable response is not answer to offer1 as these
transactions are different. I am assuming that offer1 and offer2 are in
different transactions. Is that correct.

I understood the recommendations in this section to avoid Message
Crossing but I couldn't clearly understand the requirement for UA A to
detect that session description of the offer2 is not the answer to the
offer1. Please explain.

Regards,
Ramakrishna

-----Original Message-----
From: Takuya Sawada [mailto:[email-masked]] 
Sent: Thursday, October 20, 2005 6:53 PM
To: Ramakrishna Adukuri (WT01 - Voice & Next Generation Networks);
[email-masked]; [email-masked]
Subject: Re: [Sipping] BCP for Offer/Answer Use - PLEASE COMMENT

Ramakrishna

Thanks for the comments.
> 
> A) Should Table 2, pattern 6, Rejection response be 488 UPDATE 
> Response
> 
Yes. My mistake. I will correct it. Thanks.

> B) In section 3.1. Message Crossing Case Handling states,
> 
> "When offer2 is in a reliable provisional response[...].
> For a reliable response to a re-INVITE request, to avoid this case, UA

> A should not send an INVITE request without session description if it 
> has sent the offer which has not yet received the answer to it."
> 
> Is the above statement implying that UA A can send an INVITE request 
> with SDP?
> If yes, isn't it violating the rule *UA MUST NOT generate a new offer 
> if it has generated a prior offer for which it has not yet received an

> answer or a rejection*
Of course, INVITE request with an offer MUST NOT be sent in this case.
With the above sentence I intended to mean that INVITE without offer may
be sent without violating the rule, but this should not be sent to avoid
the risk to face the crossing case.

> C) In section 3.2 Glare Case Handling, When offer2 is in PRACK 
> request[...]. To avoid this glare condition, UA
> is recommended not to send an offer, which    currently must be in an
> UPDATE request, if it has generated the reliable provisional response 
> **which it has not acknowledged with a PRACK request**.
> 
> Should this be reworded to **which is not acknowledged with a PRACK
> request**
> 
I will correct this too in the next revision.

Thanks,
Takuya

> -Ramakrishna
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
> Sent: Thursday, October 20, 2005 1:32 AM
> To: sipping
> Subject: [Sipping] BCP for Offer/Answer Use - PLEASE COMMENT
> 
> I would like to call attention to a new draft:
> 
> http://www.ietf.org/internet-drafts/draft-sawada-sipping-sip-offeransw
> er
> -00.txt
> 
> This draft attempts to codify a lot of folklore about how offer/answer

> works. The need for this is apparent from the number of times the 
> subject comes up on the sip-implementors (or sipping, or sip) lists. 
> In responding to queries I have often had to refer back to list 
> archives that are now probably almost two years old.
> 
> Thanks go to Takuya Sawada for preparing it. It would be incredibly 
> helpful to get feedback on this document, to make it clearer and more 
> complete. Feedback from two kinds of people would be especially
helpful:
> 
> - those who are confused about offer/answer:
>    Tell us if this helps, or just leaves you more confused.
> 
> - those who think they understand offer/answer:
>    Do you disagree with anything here?
>    Has anything been left out that should be here?
> 
> 	Paul
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> 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

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi,
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

_______________________________________________
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: Takuya Sawada <[email-masked]>
Date: Fri, 21 Oct 2005 19:20:15 +0900

Hi Ramakrishna,

Comments inline;
> detect offer2 in PRACK is not answer to offer1.
If answer1 is in PRACK, offer1 is in the first 1xx-rel response to 
the INVITE which was sent without session description.
In RFC 3262, it reads that the UAS MUST NOT send a second reliable 
provisional response until the first is acknowledged.
Therefore, UA A can not send another reliable provisional response 
until the PRACK with answer1 to offer1 in the first reliable response
is received.

This is the reason that I said here "there never be the case".
Of course, as you say, even if it happens, UA A can know it is not 
answer1, but it could never happen.
> different transactions. Is that correct.
Yes.

> detect that session description of the offer2 is not the answer to the
It seems to be clear that UA A is required to detect offer2 is not the 
answer1. If it can not, something may go wrong.
What I am trying to do here is, in every case, to show that UA A can detect
it and cope with it, or to make sure that it never happens, or otherwise to
propose the recomended behaviour for UA A to avoid the case.

Regarding the statement above, I think the following could be better;

----
When offer2 is in a reliable provisional response or a
successful final response, UA A knows it is not the answer to the
offer1. For a reliable response to an initial INVITE request, this case
never happens. 
For a reliable response to a re-INVITE request, UA A can detect the 
offer2 is not the answer1. In this case, as UA A can not reject offer2 in
a reliable response, it is recommended to wait for the answer1 until
sending a PRACK request with the answer to the offer2. Note that if UA
A does not send an INVITE request without session description if it
has sent the offer which has not yet received the answer to it, this
case never happens.
----

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)