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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 20 Jun 2006 11:01:36 +0200

Hi, 

>> 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".
> 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 agree that this would be a change. I'm not sure I see the need.

[CHH] I agree that a change would be needed, but I still see the need to be able to reject an offer in a simple way.

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

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

[CHH] Yes, that is true. Rejecting a new offered stream is no problem.

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

[CHH] To give a very simple example (maybe not the most likely to happen, and maybe we can forbid to do it with PRACK, but still): the new offer contains a list of codecs (formats), of which the receiver doesn't (for whatever reason) support any. But, according to RFC3264 the answer MUST contain at least one of those codecs.

Now, that's for audio. When we start talking about media types like video, there may be much more information embedded in the offer, which the receiver must be able to process and/or reserve resources for in order generate a valid answer.

And, as I said before, the problem may not be the offer itself - but the fact that the receiver simply isn't able to process it at a certain time. It may not be a problem for a SIP phone. And, e.g. in an interworking entity external signalling may even be required in order to process the offer, and generate the answer.

I haven't checked whether there could be cases related to the pre-conditions procedure, which is the reason we allowed PRACK for offer/answer usage in the first place, but maybe there is something. 

But, I am not sure we need to spend time on thinking about cases where a receiver isn't able to generate an answer. The point is that I don't want us to make that assumption. [/CHH]

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

[CHH] I see no harm in fixing something which is bad/restrictive, which seems to be one of the reasons many haven't implemented it correctly/at all, and for which we don't even seem to have a clear justification. And, in the past we have changed things in a non-backward compatible way, assuming it won't break any existing implementations. [/CHH]

Regards,

Christer

>> -----Original Message-----
>> From: Takuya Sawada [mailto:[email-masked]]
>> Sent: 16. kes臾uuta 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 
>> i-d-announce-
> [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
> 
> --------
> 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: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Jun 2006 09:47:46 -0400

> But, I am not sure we need to spend time on thinking about cases where a receiver isn't able to generate an answer. The point is that I don't want us to make that assumption. [/CHH]

OK, I give. I could swear that 3264 used to say that the codecs in a
revised media line had to include one from before, but I can't find it,
so either I remember wrong or it went away a long time ago.

And there are indeed other kinds of changes allowed by 3264 that might
just not work - such as changing the media type.

It is technically possible to still make all of this work by refusing
all the offered media streams. But that will clearly be a poorer result
than refusing the offer itself.

Interestingly, there is no concept of rejecting an offer, in 3264 or in
3261. 3264 has the concept of refusing one or more offered media lines
(up to and including all of them) but that does not have the semantic of
reverting to the prior offer/answer. And 3261 has the concept of
rejecting a message that might be carrying an offer or answer. But the
semantics of that are dependent on what the request was. In the case of
reINVITE, that has the effect of rolling back all the changes that would
have resulting, not just the offer/answer state. Same with UPDATE. And
same with PRACK, which is the one that is bothering you.

If we were to define a new way to reject an offer (rolling back to prior
completed offer/answer) without rejecting the request carrying the
offer, then we ought to do it in all the cases where offers may be
carried. For instance, a reINVITE can carry an offer/answer but may also
do a target refresh and refresh a session timer. So rejecting just the
offer in a reINVITE would let those other things go to completion. (Its
less clear what rejecting just the offer in an initial invite would
mean, but we can probably come up with something meaningful.)

This is a significant change. And of course we would have to deal with
backward compatibility. An alternative is simply to ban offers in PRACK.
Probably easier, except for the backward compatibility issues, which remain.

>From an academic perspective I think introducing a way to reject offers
without rejecting the request seems interesting. But I don't think it is
the best use of everyone's time and energy. I think *deprecating* offers
in PRACK is a possibility. But answerers would still have to deal with
the case. So it may be just as good to leave it to the discretion of
offerers to use offers in PRACK with care.

> [CHH] I see no harm in fixing something which is bad/restrictive, which seems to be one of the reasons many haven't implemented it correctly/at all, and for which we don't even seem to have a clear…

I don't have strong feelings on this one.

	Paul