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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 16 Jun 2006 12:24:26 +0200

Hi,

As I've said before, I think it's good to work on a draft like this. However, even if the procedures are clarified, there still are some issues with them, highlighted in some of my comments below.

Comment 1 (chapter 1.1)
-----------------------

Re-INVITE seems to be missing as a method to send a new offer/answer in an established session.

Comment 2 (chapter 1.2)
-----------------------

As I have said before, I don't like the reject-an-offer-in-PRACK mechanism in the draft - at least not as the only option.

One solution which has been presented is to reject the PRACK offer by not including an answer in the 200/PRACK.

Because, the UAS may not support UPDATE, which means it cannot send a new offer to replace the SDP sent in 200/PRACK. And, even if the UAS does support UPDATE, there is always a risk for race conditions, and/or the fact that the UPDATE will be rejected, which will lead to SDP "unsynchronization".

I also don't like the text saying that PRACK should only be used for offers that can be assumed to be accepted. In that case we should really describe what that means (e.g. not adding new media types/codecs etc etc etc).

Comment 3 (chapter 2.1.2)
-------------------------

One thing that has been discussed is whether the first reliable response really MUST, when there is no offer in the INVITE, contain an SDP offer. I KNOW that is what the RFC currently says, but maybe this draft could also look into the impacts of not mandating it.

Regards,

Christer

-----Original Message-----
From: Takuya Sawada [mailto:[email-masked]] 
Sent: 16. kesäkuuta 2006 13:00
To: [email-masked]
Cc: [email-masked]
Subject: [Sipping] FW: I-D ACTION:draft-sawada-sipping-sip-offeranswer-01.txt

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

_______________________________________________
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, 16 Jun 2006 21:06:55 +0900

Hi Christer,

I am happy that you think it is good.
I looked back in the archive and tried to incorporate all the discussion
we had, but maybe I lost track on some of the past discussion.
It is my laziness not to update for a long time...
Thank you for pointing them out again.

Comments inline.

> 
> Hi,
> 
> As I've said before, I think it's good to work on a draft like this. However, even
 if the procedures are clarified, there still are some issues with them, 
highlighted
 in some of my comments below.
> Comment 1 (chapter 1.1)
In pattern 1 and 3, 'INVITE request' includes both initial and re- INVITE.
Table 1, 'Est' column indicates it.

> Because, the UAS may not support UPDATE, which means it cannot send a new offer to
 replace the SDP sent in 200/PRACK. And, even if the UAS does support UPDATE, 
there 
is always a risk for race conditions, and/or the fact that the UPDATE will be 
rejected, which will lead to SDP "unsynchronization".
OK, I remember this discussion.
Probably there was no clear coclusion here.
At least, "to reject the PRACK offer by not including an answer in the 
200/PRACK" requires some updates to RFC 3262 and breaks the general rules
described in RFC 3264.

> I also don't like the text saying that PRACK should only be used for offers that 
can be assumed to be accepted. In that case we should really describe what 
that 
means (e.g. not adding new media types/codecs etc etc etc).
Oh, in this part, I intended to follow your comment below.

---
[CHH] I don't like that text, because the sender can't "be sure" whether
the receiver will accept an offer or not.

However, I would support saying something like "the sender should only
use PRACK to send offers when it has strong reasons to assume the
receiver will accept". I.e. using PRACK to propose the adding of new
streams etc should be avoided.
---

I may misunderstood your concern. So adding the text like
"I.e. using PRACK to propose the adding of new streams etc should be avoided"
is OK? Sure I agree it would be better and kind for the readers.

> One thing that has been discussed is whether the first reliable response really 
MUST, when there is no offer in the INVITE, contain an SDP offer. I KNOW that 
is 
what the RFC currently says, but maybe this draft could also look into the 
impacts 
of not mandating it.
Our intention is to summarise the current SIP usage, not to modify the 
behaviour defined in RFCs. Should we look into the impact of changing
the existing rules? Probably, at least, we need clear reason to do that.

> Christer
Anyway, thank you for the comments.

Regards,
Takuya

> Sent: 16. kes臾uuta 2006 13:00
> To: [email-masked]
> Cc: [email-masked]
> 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.
> To remove yourself from the I-D Announcement list, send a message to i-d-announce-
[email-masked] with the word unsubscribe in the body of the message.  
> 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
> 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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jun 2006 15:23:29 -0400

> 200/PRACK" requires some updates to RFC 3262 and breaks the general rules

I agree that this would be a change. I'm not sure I see the need.

> is OK? Sure I agree it would be better and kind for the readers.

I don't see the issue. If a new offer tries to add a stream, and the
answerer doesn't want to accept that, it can do so without rejecting the
offer. It can simply return a zero port in the corresponding media line
in the answer.

I can't think of something that may legally be included in a subsequent
offer for which the answered could not find some meaningful answer that
should be compatible with its current state.

> the existing rules? Probably, at least, we need clear reason to do that.

There was an extensive discussion of this on the list long ago. As I
recall it died out after Rohan demonstrated plausible ways to work with
things as they are.

I think many people would agree this was an unnecessary constraint that
should not have been included. But since it was, and since there may be
implementations that depend on this, it is hard to revoke retroactively.

	Paul