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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Oct 2005 16:02:04 -0400

I would like to call attention to a new draft:

http://www.ietf.org/internet-drafts/draft-sawada-sipping-sip-offeranswer-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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 30 Oct 2005 13:03:19 +0200

Hi,

regarding the track for this draft, we will need to discuss whether BCP
is the right way to go. The draft clarifies certain aspects of the
offer/answer model without introducing any new normative text. Maybe
Informational could be enough.

I believe this is a useful exercise and that folks will find this draft
useful. Thanks for putting it together. In any case, the draft needs 
further editing to make it flow better.

When the draft talks about different SIP messages carrying session 
descriptions, it would be good to note that some messages carry session 
descriptions that are capability descriptions, and not offers or 
answers. Examples of these messages are 200 OK responses for OPTIONS and 
488 responses for INVITE.

Table 1: row 4 should have an "O" in the Early column, because the
reliable 1xx response and the PRACK are both sent within an early dialog.

Section 2.1: the explanation of the "preview" answers should be
clarified. Now it is confusing. Note that per RFC 3261, Section 13.2.1,
"preview" answers send in unreliable 1xx responses must be *identical* 
to the answer sent in the reliable response (e.g., in the 200 OK).

    "Concretely, the above rules specify two exchanges for UAs compliant
    to this specification alone - the offer is in the INVITE, and the
    answer in the 2xx (and possibly in a 1xx as well, with the same
    value)"

Section 2.3: another difference between re-INVITE and UPDATE is that 
re-INVITEs allow the UAS to interact with the callee, while UPDATES need 
to be answered automatically by the UAS. Also, I would add a note to 
that section explaining that re-INVITEs should be answered immediately 
unless such user interaction is needed. Otherwise, some 3pcc flows would 
break.

Cheers,

Gonzalo

Paul Kyzivat wrote:
> 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.
> 
> - 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

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 31 Oct 2005 21:58:49 +0900

Hi, Gonzalo,

Thank you for the comments.

Comments inline.
> Informational could be enough.
Actually I am not so sure about where is the border between BCP and
Informational. We can discuss it and are willing to take more appropriate
way to go.

> further editing to make it flow better.
Yes. We will incorprate the comments including yours into the draft and 
revise it probably soon after the meeting.

> 488 responses for INVITE.
Good idea.

> reliable 1xx response and the PRACK are both sent within an early dialog.
Yes, PRACK is sent within an early dialog. And 1xx response may be sent
to establish an early dialog or may be sent within an early dialog.
My intension was to highlite the two types of ways to exchange new 
offer/answer within an early dialog after the first offer/answer is
completed and to compare them later.
I will clarify this or change this part entirely.

>     answer in the 2xx (and possibly in a 1xx as well, with the same
We will clarify the term "preview".
> unless such user interaction is needed. Otherwise, some 3pcc flows would 
Make sense. We will add it.

Regards,
Takuya

> > anything here? Has anything been left out that should be here?

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