Subject: [Sipping] I-D Action:draft-ietf-sipping-sip-offeranswer-13.txt

From: [email-masked]
Date: Mon, 10 May 2010 08:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title           : SIP (Session Initiation Protocol) Usage of the Offer/Answer Model
	Author(s)       : O. Shinji, P. Kyzivat
	Filename        : draft-ietf-sipping-sip-offeranswer-13.txt
	Pages           : 32
	Date            : 2010-05-10

The Session Initiation Protocol (SIP) utilizes the offer/answer model
to establish and update multimedia sessions using the Session
Description Protocol (SDP).  The description of the offer/answer
model in SIP is dispersed across multiple RFCs.  This document
summarizes all the current usages of the offer/answer model in SIP
communication.

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 May 2010 11:34:47 -0400

I'd like to thank Shinji for doing this new draft.
I had run out of gas to keep updating this, while new insights were 
coming forward, notably from Shinji and Gao.

I believe it addresses all the outstanding comments,
including the long discussion of a couple of weeks ago.
And it also provides some new tables that simplify understanding of what 
should be done when implementing o/a.

I request that people who have been following this draft take another 
careful look to see if this accurately reflects the consensus that has 
been reached on the list. We'd really like to ship this draft off to the 
iesg!

     Thanks,
     Paul

[email-masked] wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: [email-masked]
Date: Tue, 11 May 2010 08:55:42 +0800

Paul,

I will find time to do the review soon. 

And thanks for your unremitting contribution on this topic. Meanwhile, 
thanks for Shinji too.

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Paul Kyzivat <[email-masked]> 
发件人:  [email-masked]
2010-05-10 23:34

收件人
[email-masked]
抄送

主题
Re: [Sipping] I-D Action:draft-ietf-sipping-sip-offeranswer-13.txt

     Thanks,
     Paul

[email-masked] wrote:
>                Filename        : 
draft-ietf-sipping-sip-offeranswer-13.txt

_______________________________________________
Sipping mailing list  https://www.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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: [email-masked]
Date: Tue, 11 May 2010 11:09:34 +0800

Hi,

Discussion:

The 488 response is another proposed solution, UAS may respond with a 
488 response and then UAC should send again a PRACK request without 
an offer. 
 
          NOTE: In [RFC3262], the following restriction is defined with 
          regard to responding to a PRACK request. 
 
          "If the PRACK does match an unacknowledged reliable provisional 
          response, it MUST be responded to with a 2xx response." 
 
          This description is not completely correct.  There are cases 
where 
          it is unacceptable to send a 2xx response.  For example, 401 
          response can not be avoided. 

Allowing 488 for rejecting of PRACK's Offer has a long discussion. I'd 
like to rearrange my points:

1. I once proposed a solution for PRACK's authentication as: doing 
challenge in 1xx of 100-rel(such as 183) while not in PRACK, then PRACK 
would not be rejected by 401. So, I guess RFC3262's text *could keep 
right*(just my feeling). In fact, this issue(allowing 4xx of PRACK) is 
more broad sense than the issue of rejecting PRACK's Offer. May we delay 
this complex issue and just let this draft go on by avoiding the 
discussion of RFC3262's correctness. So, I prefer the NOTE part shoule be 
cut down.

2. I'd like to emphasize that I am not the person to *put grit in the 
machine* for the issue of allowing 4xx of PRACK. I just not prefer it. And 
I am OK with the proposal of 488 of PRACK's Offer in this INFORMATIVE 
text. And I'd like to point out that, as currently, most of the UAC can 
not handle 4xx of PRACK, it may just terminate the dialog by the 4xx. So, 
I'd prefer the text as:
The 488 response is another proposed solution, UAS may respond with a 488 
response and then UAC may send again a PRACK request without an offer or 
just terminate the dialog.(we should not make the UAC re-send PRACK as 
*SHOULD*, as it may be normative.).

Comments:

I am OK with almost all of the text. And I am glad to find more detailed 
use cases of glare cases.

Thanks,

Gao

收件人
[email-masked]
抄送

主题

     Thanks,
     Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 11 May 2010 12:18:00 +0900

Hi all,

Sorry, I forgot to put the last fixes in Page 22.

correct texts are:

   UAC-IU:   While an INVITE transaction is incomplete, and an ACK or a
             PRACK transaction associated with an offer-answer is
             incomplete, a UA should not send an UPDATE request.
 ...
   UAS-IcU:  While an INVITE client transaction is incomplete, and an
             ACK or a PRACK transaction associated with an offer-answer is
             incomplete, a UA should reject an UPDATE request with a 491
             response.
   UAS-IsU:  While an INVITE server transaction is incomplete, and an
             ACK or a PRACK transaction associated with an offer-answer is
             incomplete, a UA should reject an UPDATE request with a 500
             response.

Regards,
Shinji

[email-masked]
Mon, 10 May 2010 08:00:01 -0700 (PDT)
>-------------------------------text/plain-------------------------------

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 11 May 2010 16:07:32 +0900

Hi Gao,

[email-masked]
Tue, 11 May 2010 11:09:34 +0800
>          This description is not completely correct.  There are cases where 
>Allowing 488 for rejecting of PRACK's Offer has a long discussion.

I tried to read again the mail regarding the discussion in
last January.

IMO, Paul, Christer and I agree with this NOTE.
And in previous discussions it seems to be agreed.
Therefore, I think this is not a normative change but a BCP text.

>I'd like to rearrange my points:
>

I agree "or just may terminate the dialog".
But I think "send again a PRACK" is more effective than
"terminate the dialog". Therefore, we should make the UAC
re-send PRACK as *should*.

>use cases of glare cases.

Thank you so much.

Regards,
Shinji

---

From: [email-masked]
Date: Tue, 11 May 2010 15:33:00 +0800

Hi Shinji,

> Therefore, I think this is not a normative change but a BCP text.

Considering personal feeling or tendency, it is OK. But I just feel in 
INFORMATIVE text, it is not proper to put conclusion as parts of RFC3262 
is not correct. 

I'd like show my concession here. I am not against for text might like 
"NOTE: 4xx of PRACK need further evaluation, and one niceargument is 401". 

The difference is this type of description would be moderate. And I still 
think that put challenge in 1xx(100-rel) is also *nice* argument for 
people dislike of re-sending of PRACK. 

> re-send PRACK as *should*.

I just feel the *should* is more than INFORMATIVE.

Please refer to the text about NOTE I mentioned above. I guess the 
phraseology here is close relating to the NOTE.

Thanks,

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 May 2010 10:54:56 -0400

> INFORMATIVE text, it is not proper to put conclusion as parts of RFC3262 

Do we agree that the issue here is the following from section 3 of 3262:

    If a PRACK request is received by the UA core that does not match any
    unacknowledged reliable provisional response, the UAS MUST respond to
    the PRACK with a 481 response.  If the PRACK does match an
    unacknowledged reliable provisional response, it MUST be responded to
    with a 2xx response.  The UAS can be certain at this point that the
    provisional response has been received in order.  It SHOULD cease
    retransmissions of the reliable provisional response, and MUST remove
    it from the list of unacknowledged provisional responses.

Because of the "MUST be responded to with a 2xx response", we would be 
recommending violation by recommending a 488.

I do agree this is a *bug* in in 3262, since there are cases (such as 
authorization failures) where it would be entirely unacceptable to send 
a 2xx response. This case is not *that* bad - it is *possible* to send a 
2xx, though the outcome from doing so is not so good.

I think I agree with Gao here that we must not *advocate* sending 488 
here. We might still note that the 488 might be sent anyway, and what to 
do if it is received.

	Thanks,
	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 11 May 2010 13:03:09 -0700

If it's a bug in RFC 3261 then maybe the proper thing to do is to issue 
an errata? That way this informational doc can either not get into the 
matter or reiterate the errata.

Thanks,
Anders

On 5/11/2010 7:54 AM, Paul Kyzivat wrote:
>> INFORMATIVE text, it is not proper to put conclusion as parts of
>> RFC3262 is not correct.
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 12 May 2010 13:05:02 +0900

Hi,

I'll modify these sentences as follows.

   There is a possibility for UAC to receive a 488 response.
   In that case, UAC may send again a PRACK request without an offer
   or send a CANCEL request to terminate the INVITE transaction.

      This restriction is not clear.  There are cases where
      it is unacceptable to send a 2xx response.  For example, 401
      response can not be avoided.  This is an open issue and out of
      the scope for this document.

Regards,
Shinji

Paul Kyzivat <[email-masked]>
Tue, 11 May 2010 10:54:56 -0400

---

From: [email-masked]
Date: Wed, 12 May 2010 12:08:29 +0800

Hi Shinji,

I am OK with the new text.

Thanks,

Gao

OKUMURA Shinji <[email-masked]> 
发件人:  [email-masked]
2010-05-12 12:05

收件人
[email-masked]
抄送

Hi,

Regards,
Shinji

>> INFORMATIVE text, it is not proper to put conclusion as parts of 
RFC3262