Hi Paul,
I am not sure could I giving a rigorous answer. To be honest, I think it is a balance between cutting down PRACK's usages and allowing non-2xx of PRACK.
Allowing non-2xx of PRACK means re-acknowledgement of the 1xx of 100-rel, and the soultion is too complex for sip-stack developers. And compatible *war* would be lighted up while people do interoperability testing.
So, I prefer cutting down PRACK's usages to make thing simple if we can handle/elude all the issues well for PRACK.
For the example, I have some suggestion/feeling(just for discussion). Please see inlines.
Thanks,
Gao
===================================
Zip : 210012
Tel : 87211
Tel2 :(+86)-025-52877211
e_mail : gao.yang2@xxxxxxxxxx
===================================
Paul Kyzivat <pkyzivat@xxxxxxxxx> 写于 2010-01-19 23:13:34:
> Gao,
>
> Is your message below requesting additional changes to the draft?
>
> While I think what you say can work in *most* cases, there will continue
> to be (unlikely) cases that demand an error response. For example:
>
> - The UAS requires credentials in all requests, and the credentials
> are either not present in the PRACK, or are wrong.
We usually use INVITE/REGISTER to establish IPSec channel to elude subsequent requests' authorization. But when the equipment do not support IPSec or they just need authorization for PRACK, we still neet to handle this issue.
UAS can add WWW-Authenticate header in 1xx(100-rel) if it need UAC's credential for PRACK(this handling may need normative extension), and UAC can send credential in PRACK's Authorization header.(By doing this, UAS can elude sending 401 for PRACK).
But there isn't the proper guide for UAS to handle PRACK without credential while it has challenged the UAC. Can the UAS just terminate the dialog and session?
>
> - The request contains an offer that is syntactically incorrect,
> and so cannot be parsed by the UAS.
UAS can just terminate the dialog and session or send a new Offer in UPDATE.
>
> - The request contains an incorrect (too small) CSeq.
I am not under condition, will "too samll CSeq" can reduce "does not match any unacknowledged reliable provisional response".
If it is, then UAS can send 481, then terminate the dialog and session.
>
> Thanks,
> Paul
>
> gao.yang2@xxxxxxxxxx wrote:
> >
> > By current normative definition, UAS of PRACK MUST send 2xx when recv
> > 1xx(100rel).
> >
> > RFC3262:
> > If the PRACK does match an
> > unacknowledged reliable provisional response, it MUST be responded to
> > with a 2xx response.
> >
> > So, UAC of PRACK should make sure UAS of PRACK will accept the offer in
> > PRACK.
> >
> > If UAC of PRACK is not careful enough, UAS still MUST send Answer in 2xx
> > of PRACK(RFC3262 defines:If the UAS receives a PRACK with an offer, it
> > MUST place the answer in the 2xx to the PRACK.).
> >
> > UAS can reject the Offer by setting streams' ports as zero. If it is not
> > enough, UAS can send another Offer in UPDTAE.
> >
> > I think the process is clear and effective for all cases.
> >
> > Thanks,
> >
> > Gao
> >
> > ===================================
> > Zip : 210012
> > Tel : 87211
> > Tel2 :(+86)-025-52877211
> > e_mail : gao.yang2@xxxxxxxxxx
> > ===================================
> >
> >
> > *Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>*
> > 发件人: sipping-bounces@xxxxxxxx
> >
> > 2010-01-19 03:12
> >
> >
> > 收件人
> > Paul Kyzivat <pkyzivat@xxxxxxxxx>, "sipping-chairs@xxxxxxxxxxxxxx"
> > <sipping-chairs@xxxxxxxxxxxxxx>
> > 抄送
> > sipping <sipping@xxxxxxxx>
> > 主题
> > Re: [Sipping] New version posted:
> > draft-ietf-sipping-sip-offeranswer-11.txt
> >
> >
> >
> >
> >
> >
> >
> >
> > Hi,
> >
> > The rejecting PRACK offer is still "ongoing", but unfortuantely I have
> > not had time to do much onit lately - mostly due to INFO.
> >
> > Regards,
> >
> > Christer
> >
> > ________________________________________
> > From: sipping-bounces@xxxxxxxx [sipping-bounces@xxxxxxxx] On Behalf Of
> > Paul Kyzivat [pkyzivat@xxxxxxxxx]
> > Sent: Monday, January 18, 2010 7:48 PM
> > To: sipping-chairs@xxxxxxxxxxxxxx
> > Cc: sipping
> > Subject: [Sipping] New version posted:
> > draft-ietf-sipping-sip-offeranswer-11.txt
> >
> > I just posted a new version of the offeranswer draft.
> > This version is intended to resolve all outstanding issues.
> >
> > Here is a summary of substantial changes made:
> >
> > - the open issues that were previously in section 6 were
> > removed. The doc has been updated as needed to be consistent
> > with conclusions about how to deal with those issues.
> > Specifically:
> >
> > - Rejecting PRACK offer has simply been dropped.
> > There has been no ongoing interest in no normative work
> > to support doing that.
> >
> > - Commit/Rollback of Offer/Answer on Unsuccessful re-INVITE
> > Transaction has been resolved by reference to
> > draft-camarillo-sipcore-reinvite-01. New text referencing
> > that has been added at multiple places in the document.
> >
> > - Loosening requirement for Offer in a Reliable Response:
> > Again there has been no indication of intent to do anything
> > in this space, so the topic has simply been dropped.
> >
> > - Requesting Hold while already on Hold:
> > This was already addressed in the main body of the document.
> > The issue was whether this was appropriate, since it rests on
> > the interpretation of certain text in 3261 being non-normative.
> > That assumption has been restated in the main body.
> > I'm unaware of any argument to that in over two years.
> >
> > - The recommendations for addition of new o/a usage in sip
> > (prior section 7) has also been dropped. While these may have
> > been helpful during discussion of the draft, they aren't
> > helpful after it is finalized.
> >
> > - I rearranged the order of authors since Takuya has been unavailable
> > to work on it for some time. However I have retained him as an author
> > because the preponderance of the text is still his.
> >
> > In addition there hare assorted miscellaneous minor cleanups.
> >
> > Thanks,
> > Paul
> >
> > Internet-Draft@xxxxxxxx wrote:
> > > New version (-11) has been submitted for
> > draft-ietf-sipping-sip-offeranswer-11.txt.
> > >
> > http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-
> offeranswer-11.txt
> > > Sub state has been changed to AD Follow up from New Id Needed
> > >
> > > Diff from previous version:
> > > http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipping-sip-offeranswer-11
> > >
> > > IETF Secretariat.
> > >
> > _______________________________________________
> > 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
> > _______________________________________________
> > 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.
>
-------------------------------------------------------- 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
