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 : gao.yang2@xxxxxxxxxx
===================================
| Paul Kyzivat <pkyzivat@xxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx 2010-05-10 23:34 |
|
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
Internet-Drafts@xxxxxxxx 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
> I-D-Announce@xxxxxxxx
> 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
