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

[[e-mail]]

 
Hi Takuya,

Please see some comments line.

Regards,
Ramakrishna

-----Original Message-----
From: Takuya Sawada [mailto:[e-mail]] 
Sent: Friday, October 21, 2005 3:50 PM
To: Ramakrishna Adukuri (WT01 - Voice & Next Generation Networks);
[e-mail]; [e-mail]
Subject: Re: [Sipping] BCP for Offer/Answer Use - PLEASE COMMENT

Hi Ramakrishna,

Comments inline;
>  
> 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.
> 
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.

===========
[Ramakrishna] I think it would be better to state the paragrah, "When
offer2 is in a PRACK request,[...]. " as,
This case can never happen as UAS MUST not send a second reliable
provisional response until the first is acknowledged.

I have a question with regards to sending offer in PRACK.
>From RFC 3262 states:

"If the INVITE contained an offer, the UAS MAY generate an answer in a
reliable provisional response [..]. 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, 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."

>From the above statements I could understand that three scenarios for
offer/answer exchange are possible:
1) INVITE with Offer - Answer in reliable provisional response.
2) INVITE w/o Offer - First reliable 1xx with Offer - Corresponding
PRACK with Answer.
3) INVITE with offer - Answer in reliable provisional response - Offer
in PRACK - Answer in 2xx to PRACK.

If I interpreted the statement ("If the UAC receives a reliable
provisional response with an answer, it MAY generate an additional offer
in the PRACK") correctly, PRACK can contain additional offer **only when
a corresponding** reliable response has an answer.

But in this draft I see that offer can come in any PRACK once a
offer/answer exchange is complete(though there are some recommendations
on when to use). For example, Figure 2 seems to suggest that F7 can
contain an offer. Is this a deviation from RFC 3262. Please clarify.
===========

> 
> [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.
> 
Yes.

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

===========
[Ramakrishna] I understand that UA A has to detect that offer2 is not
answer1. But I was not clear on why the description on this was present
in this section as there was no case where UA A cannot detect offer2 is
not answer1. But with further review I understood that description is
proving that with the 6 patterns mentioned in this draft UA A will never
mistake offer 2 for answer 1 when message crossing happens. Thanks for
clarifying it.
===========

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

> Regards,
> Ramakrishna
> 
> -----Original Message-----
> From: Takuya Sawada [mailto:[e-mail]]
> Sent: Thursday, October 20, 2005 6:53 PM
> To: Ramakrishna Adukuri (WT01 - Voice & Next Generation Networks); 
> [e-mail]; [e-mail]
> 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: [e-mail] [mailto:[e-mail]] 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-offeran
> > sw
> > 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 
> > [e-mail] for questions on current sip Use 
> > [e-mail] 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 
> > [e-mail] for questions on current sip Use 
> > [e-mail] 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: [phone]
> Fax: [phone]
> [e-mail]
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP Use 
> [e-mail] for questions on current sip Use 
> [e-mail] 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: [phone]
Fax: [phone]
[e-mail]

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