Subject: [Sipping] FW: I-D ACTION:draft-sawada-sipping-sip-offeranswer-01.txt

From: Takuya Sawada <[email-masked]>
Date: Fri, 16 Jun 2006 19:00:20 +0900

Hi,

As some of you may have noticed, we updated the SIP
offer/answer usage draft.
We revised it based on the mail discussion in SIPPING.
This draft was once expired, but we want to keep it alive.

Comments are really welcome.

Regards,
Takuya

------- Forwarded Message
From: [email-masked]
To: [email-masked]
Cc: 
Subject: I-D ACTION:draft-sawada-sipping-sip-offeranswer-01.txt 
Date: Mon, 12 Jun 2006 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SIP (Session Initiation Protocol) Usage of Offer/Answer Model
	Author(s)	: T. Sawada, P. Kyzivat
	Filename	: draft-sawada-sipping-sip-offeranswer-01.txt
	Pages		: 14
	Date		: 2006-6-12
	
SIP utilizes offer/answer model to establish and update multimedia 
sessions. The descriptions on how to use offer/answer in SIP are 
dispersed in the multiple RFCs. This document summarizes all the 
current usage of offer/answer model in SIP communication.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sawada-sipping-sip-offeranswer-01.
txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the 
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sawada-sipping-sip-offeranswer-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-sawada-sipping-sip-offeranswer-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-sawada-sipping-sip-offeranswer-01.txt

Content-Type: text/plain
Content-ID: <[email-masked]>

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

------- End of Forwarded Message
--------
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: Anders Kristensen <[email-masked]>
Date: Fri, 23 Jun 2006 17:29:33 -0400

Takuya and Paul,

I think this is a very wortwhile document. I don't know if it's the 
right place to define new ways to reject offers - the approach of 
restricting the type of modifications that can be made in certain 
messages, in particular PRACKs, seems more palatable.

One thing which perhaps could be mentioned in the draft is what SDP goes 
into a 2xx response when a previously sent reliable 18x carried an 
answer and an UPDATE offer/answer exchange has taken place between the 
the 18x and 2xx. It seems odd for the 2xx to carry the by now out of 
date SDP from the 18x but that does seem to be what RFC 3261 section 
13.2.1 says to do.

Nit: On page 3 "In pattern 5, PRACK request can contain an offer only if 
the non-reliable response which it acknowledges..." - the PRACK acks a 
reliable 1xx, of course.

I thought the last two paragraphs in section 3.1 were a little hard to 
make sense of and could be clarified.

Thanks,
Anders

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Jun 2006 19:36:27 -0400

> messages, in particular PRACKs, seems more palatable.

I agree.

> date SDP from the 18x but that does seem to be what RFC 3261 section 

It is already addressed in 2.1.1. Namely that there SHOULD be no SDP in 
the 2xx in that case. And that is valid according to 3261.

I agree that 3261 says there MAY be SDP there, and if so I think it must 
be that old, now obsolete, SDP from the first answer. Clearly this is 
confusing, and encourages people to do the wrong thing. That is why we 
decided that putting no SDP there is the recommended course of action.

> make sense of and could be clarified.

Yes, it could be better. I need to consult with Takuya about it.

	Thanks,
	Paul

---

From: [email-masked]
Date: Sat, 24 Jun 2006 17:56:39 -0400

From: Anders Kristensen <[email-masked]>

Not to comment on what Paul has said as to what good practices are,
I'd like to note that the specification you mention is less odd than
it first appears.  Intuitively, it seems that offers and answers, when
arranged in the order they are sent and received, should show the
progress of the state of the session.  But that rule is fraught with
trouble, as the order of messages is not necessarily the same at both
ends of the dialog, leading to complex situations that it is difficult
to envision when defining the protocol.  It is much safer to design a
system that considers the transactions ordered by their CSeq numbers,
and require that each transaction only deal with one offer/answer
pair, because both endpoints agree on those facts.

Dale