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

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 19 Jun 2006 09:03:48 +0200

Hi Takuya,

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

[CHH] I think part of the problem are the current rules themselves - not only the fact that people don't understand them. They are very complicated. I think our aim should also be to identify ways to SIMPLIFY, otherwise I don't think the draft will make people implementing more than they've done so far. Yes, it may require changes to the rules, but it wouldn't be the first time :)

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

[CHH] I think the problem is that there may be non-SDP related reasons why a server rejects on offer. It may be due to the current load of the server - or whateve - which means it will reject the the offer no matter how "simple" it is. And, if the server has to reject an offer due to overload, it then sure isn't going to spend resources on sending UPDATEs etc. 

So, I know what I said before, but I still think it should be possible to reject an offer using only the SIP response to the request which carries the offer. And, in the case of PRACK the only solution seems to be by not including an answer.

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

[CHH] I DO think we should look into the impacts of changing the existing rules, and how we can simplify the rules. And, in any case the existing rules should be clarified, or there should be a reference to the spec/chapter where they are clarified.. WHY is it mandatory to send an offer in the first reliable 18x?

RFC3262 only says:

"Similarly, if a reliable provisional response is the first reliable message sent back to the UAC, and the INVITE did not contain an offer, one MUST appear in that reliable provisional response."

RFC3262 also says;:

"If the INVITE contained an offer, the UAS MAY generate an answer in a reliable provisional response (assuming these are supported by the UAC)."

That also needs to be clarified. Does it mean that the UAS MAY genereate a reliable provisional response, and it then MUST include an answer? OR, does it mean that the UAS MAY generate a reliable provisional response, and it then MAY include an answer? From the discussions we've had on the mailing lists I believe that it is OPTIONAL to include an answer in a reliable provisional response, and I think it should be clarified in the draft.

Comment 4 (chapter 2.2)
---------------------

The text does say it, but I think it could be more clearly pointed out that a PRACK can be used for sending an offer only when the reliable provisional response it is acknowledging contained an answer.

Comment 5 (chapter 2.3)
---------------------

One of the oldest interop problems (at least due to my experience from SIPit and the implementors mailing list) has been the what-offer-to-send-to-an-re-INVITE-without-SDP problem. It has been discussed on the lists over and over again. Maybe there even is a conclusion somewhere :) In any case I think it should be described in the draft.

Comment 6 (chapter 1.2)
--------------------

If a node cannot accept an offer in a SIP response, I think one option should also be to simply release the session. It's pretty much an implementation issue. And, mandating the clients to start sending new offers/answers simply to "synchronize" the SDP state at both ends is again very complex, and may (at least in theory) cause never-ending offer/answer loops.

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: Takuya Sawada <[email-masked]>
Date: Fri, 23 Jun 2006 19:10:59 +0900

Hi

Regarding your comment 2 and 3, discussions keep going on the thread.
Here, I make comments back on the others, comment 4 to 6.

> Comment 4 (chapter 2.2)
> ---------------------
> 
> The text does say it, but I think it could be more clearly pointed out that a 
PRACK can be used for sending an offer only when the reliable provisional 
response 
it is acknowledging contained an answer.

This point is one of errors which I corrected in this version.
I will try to make it more explicit. I would be happy if you could suggest the
wording to modify the text.
> 
> Comment 5 (chapter 2.3)
> ---------------------
> 
> One of the oldest interop problems (at least due to my experience from SIPit and 
the implementors mailing list) has been the what-offer-to-send-to-an-re-INVITE
-
without-SDP problem. It has been discussed on the lists over and over again. 
Maybe 
there even is a conclusion somewhere :) In any case I think it should be 
described 
in the draft.

So what is the offer to send to an re-INVITE without SDP?
Are there the rules or guidelines?
Sorry I have no idea...
> 
> Comment 6 (chapter 1.2)
> --------------------
> 
> If a node cannot accept an offer in a SIP response, I think one option should also
 be to simply release the session. It's pretty much an implementation issue. 
And, 
mandating the clients to start sending new offers/answers simply to "
synchronize" 
the SDP state at both ends is again very complex, and may (at least in theory)
 cause
 never-ending offer/answer loops.
I agree that to release the session is one option.
I think I can add some notes.

To avoid never-end offer/answer loops seems to be the work for the
applications. Sometimes it may require specail cares but I beleive
it is not a protocol issue.

Regards,
Takuya

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Jun 2006 08:53:46 -0400

> Are there the rules or guidelines?

AFAIK the only *rule* is to conform to 3264.

I think we could *recommend* that the UAS SHOULD offer the same SDP it
offered or answered in the previous successful offer/answer exchange,
unless something has changed in its state that suggests a different
offer is more appropriate.

This is a very weak recommendation, but IMO it is all that is
appropriate. For instance, the UAS could have been getting ready to send
a new offer on its own just before it received the reINVITE. If so, it
might as well offer what it was getting ready to send.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sat, 24 Jun 2006 15:15:40 +0200

Hi,

>>>-without-SDP problem. It has been discussed on the lists over and over again.
>>>Maybe there even is a conclusion somewhere :) In any case I think it should be
>>>described in the draft.
>>>

[CHH] I am not sure everybody would agree with you on that :) The OTHER opinion has been that the UAS should send an offer according to what it would send for a new session, including all codecs it supports etc (not only the ones in the previous successful offer/answer exchange for the specifc session). The argument has been that it is required to make some 3PCC scenarios work.

>might as well offer what it was getting ready to send.

[CHH] The problem is that there are scenarios which REQUIRES certain behavior from the UAS, and as long as we don't have clear rules people will continue to argue about it. One possible solution would be to define a way for the UAC to indicate what kind of offer it wants. 
 
Regards,
 
Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Jun 2006 20:14:18 -0400

> [CHH] I am not sure everybody would agree with you on that :) The OTHER opinion has been that the UAS should send an offer according to what it would send for a new session, including all codecs it…

Actually, now that you mention it, I agree with you. In fact I have said 
as much many times, in a slightly different way:

that you should always offer (or answer) what *you* want the state of 
the session to be, to the extent that it is permitted. (There are 
constraints - many for answerers, but also some for re-offerers in a 
dialog.)

> [CHH] The problem is that there are scenarios which REQUIRES certain behavior from the UAS, and as long as we don't have clear rules people will continue to argue about it. One possible solution wo…

What scenarios require a particular kind of behavior?

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sun, 25 Jun 2006 16:28:07 +0200

Hi Paul,
 
>>[CHH] I am not sure everybody would agree with you on that :) The OTHER opinion has been that the UAS should 
>>send an offer according to what it would send for a new session, including all codecs it supports etc (not only the ones 
>>in the previous successful offer/answer exchange for the specifc session). The argument has been that it is required to 
>>make some 3PCC scenarios work.
>

[CHH] Yes, but in some of the re-INVITE-without-SDP scenarios the UAS is supposed to send an offer according to what the UAC (the one sending the empty re-INVITE) wants. So, the UAC has to assume the UAS knows what the UAC wants

>> [CHH] The problem is that there are scenarios which REQUIRES certain behavior from the UAS, and as long as we don't 
>>have clear rules people will continue to argue about it. One possible solution would be to define a way for the UAC to 
>>indicate what kind of offer it wants.
>>

[CHH] In some of the 3PCC scenaios, where the UAC assumes, in orde to make the scenario work, that the UAS will send a certain type of offer (in the 200 response). Again, in those cases I don't think it's about what the one sending the offer wants - it's about what the one receiving the offer wants...
 
Regards,
 
Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 25 Jun 2006 14:11:35 -0400

> [CHH] In some of the 3PCC scenaios, where the UAC assumes, in orde to make the scenario work, that the UAS will send a certain type of offer (in the 200 response). Again, in those cases I don't thi…

Precisely which scenarios do you mean. It is pretty crazy to expect such 
behavior, but I am not too surprised if there are scenarios like that.

I think there are a cases that require a UAS to be psychic. (Those 
related to REFER often feel that way. Dale has recently written 
something on that.)

	Paul

---

From: [email-masked]
Date: Mon, 26 Jun 2006 15:25:16 -0400

From: Paul Kyzivat <[email-masked]>

   > [CHH] In some of the 3PCC scenaios, where the UAC assumes, in
   > orde to make the scenario work, that the UAS will send a certain
   > type of offer (in the 200 response). Again, in those cases I
   > don't think it's about what the one sending the offer wants -
   > it's about what the one receiving the offer wants...

I wrote the I-D to warn people that REFER was under-specified.
Certainly, specifications with "And then a miracle happens here!" are
to be avoided.  If there are 3PCC scenarios where the UAS must guess
correctly what offer the UAC wants, the relevant protocols need to be
rebuilt.

Personally, I suspect that 3PCC implementors already know how the UAS
will know what offer to send, but the mechanism is outside of SIP.  If
they'd put that in their drafts, it would be OK.

[Another topic, but related:]  In regard to
draft-ejzak-sipping-p-em-authnow-01, I assume the following idea has
been considered and rejected for good reasons:  A P-* header that
means "I will not render early media / I will not pass early media."
This can be inserted into requests or responses by UACs, UASs, or even
middleboxes(ugh!).  It's not very friendly, and it has all the same
interoperability problems, but at least the participating agents are
warned when non-default behavior is going to happen, rather than
having to guess psychically that this time, the absence of a P-*
header means that non-default behavior is going to happen.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Jun 2006 18:11:11 -0400

> header means that non-default behavior is going to happen.

The problem is this is that because it is a P-header, a UAS that expects 
to send or receive early media, and doesn't understand the header, is 
going to get bad results.

This could be solved with a *standard* extension, using a new 
Early-Media header and a new early-media option. Then if you include 
Require: early-media, and Proxy-Require:early-media, and an 
Early-Media:inactive header, you will know for certain that both parties 
understand the early media status - if the call completes. And of course 
on all the calls that don't complete you will know you aren't getting 
early media.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Jun 2006 23:51:50 -0500

On Jun 26, 2006, at 5:11 PM, Paul Kyzivat wrote:

> The problem is this is that because it is a P-header, a UAS that  
> expects to send or receive early media, and doesn't understand the  
> header, is going to get bad results.
>
> This could be solved with a *standard* extension, using a new Early- 
> Media header and a new early-media option. Then if you include  
> Require: early-media, and Proxy-Require:early-media, and an Early- 
> Media:inactive header, you will know for certain that both parties  
> understand the early media status - if the call completes. And of  
> course on all the calls that don't complete you will know you  
> aren't getting early media.

I fear Paul is correct. I fear Paul in general, but that's another  
matter  -- whenever he comments on my drafts, I know I have more work  
to do!

This leaves us in an interesting predicament. It seems that if we  
want to solve this problem, we need a standards-track extension.  
Process-wise, we would need an agreed set of requirements that we  
could pass over to SIP for them to execute on.

I don't quite think we have an agreed set of requirements, although I  
think we have the spirit of an agreement on those requirements, or an  
agreement "in principle".

Chairs, how shall we proceed?

--
Dean