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

From: [email-masked]
Date: Thu, 20 Oct 2005 17:55:43 +0530

A) Should Table 2, pattern 6, Rejection response be 488 UPDATE Response

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*

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

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

_______________________________________________
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: Thu, 20 Oct 2005 22:22:58 +0900

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.

> it has generated a prior offer for which it has not yet received an
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.

> Should this be reworded to **which is not acknowledged with a PRACK
I will correct this too in the next revision.

Thanks,
Takuya

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