Re: I-D Action:draft-ietf-sipping-sip-offeranswer-13.txt

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

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



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

收件人
[email protected]
抄送

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






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 protected] wrote:
> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email protected]
> 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
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] 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.

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP