Re: [Sipping] sipping-sip-offeranswer-05: comments and questions

["Fred Seymour" <[e-mail]>]

Hi.

OK, I agree the proposed text of yours.

Regards,

Fred

On Sat, Feb 16, 2008 at 6:50 AM, Christer Holmberg
<[e-mail]> wrote:
> Hi,
>
> >I believe discussion has demonstrated that non-2xx final responses must
> >not be taken to demonstrate that the PRACK was received by the UAS,
> >because the non-2xx final response may not have come from the UAS.
>
> Correct.
>
> The problem, as has been discussed, is that the UAC doesn't know where the response comes from. So, if the UAC assumes the response comes from the UAS, it will most likely discard the re-transmitted 18x that will keep coming, and at some point the UAS will release the call. But, we can strongly recommend against sending non-2xx responses to PRACK (at least by intermediates), unless it is really unavoidable.
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
> Fred Seymour wrote:
> > Hi.
> >
> > Strictly speaking, this problem concerns not offeranswer but the
> > correction of a normative specification about rfc3262. Therefore, I
> > agree that UAS's behavior for 401 response is not described to
> > draft-offeranswer. However, should all the responses(including 401)
> > unconditionally causes the stop of the reliable provisional response ?
> >
> > Regards,
> >
> > Fred
> >
> > On Fri, Feb 15, 2008 at 7:28 PM, Christer Holmberg
> > <[e-mail]> wrote:
> >> Hi,
> >>
> >>> IMO, when PRACK request is counterfeited, UAS cease the
> >>> reliable provisional response, even if UAC has not received
> >>> the provisional response.
> >> I don't think this is a PRACK specific problem. "Fake" BYEs, re-INVITEs etc etc etc can cause much worse damages.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >>> On Fri, Feb 15, 2008 at 3:39 PM, Christer Holmberg
> >>> <[e-mail]> wrote:
> >>>> Hi Fred,
> >>>>
> >>>>> At least, I think that there is a problem concerning
> >>> security in the cease of the reliable provisional response
> >>> when UAS returns 401 responses.
> >>>> What security problem are you referring to?
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> 2008/2/12 Christer Holmberg <[e-mail]>:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Below is some proposed text (starting with "It was also
> >>>>> proposed...").
> >>>>>>
> >>>>>>
> >>>>>> 6.1. Rejecting PRACK Offer
> >>>>>>
> >>>>>>  As stated in section 2.2. and 3.2. , it is recommended
> >>>>> that an  offer
> >>>>>> not be sent in a PRACK request unless UAC has strong
> >>> reasons  to
> >>>>>> assume the receiver will accept it. Even so, there may be
> >>>>> cases  when
> >>>>>> the UAS has to reject the offer for some reason. The
> >>>>> current  RFCs do
> >>>>>> not provide a way to reject the offer and at the same time  to
> >>>>>> acknowledge the reliable response.
> >>>>>>
> >>>>>>  Several ideas were presented to resolve this issue, such
> >>>>> as sending
> >>>>>> 2xx PRACK response without SDP to reject the offer, or
> >>> sending SDP
> >>>>>> with a decreased version value in the o-line. It was also
> >>>>> propsed to
> >>>>>> allow non-2xx responses to PRACK, in order to reject an
> >>> SDP offer
> >>>>>> carried in the PRACK. The response would still acknowledge
> >>>>> the PRACK,
> >>>>>> and the UAS would cease transmission of the reliable
> >>> provisional
> >>>>>> response acknowledged by the PRACK request. Some of the
> >>>>>> candidates may also be adapted as a way to reject an
> >>> unacceptable
> >>>>>> offer in a response. Anyway, those proposals violate the current
> >>>>> rules and lose
> >>>>>> backward compatibility to some extent (e.g. section
> >>>>>>  5 of RFC 3262). It is beyond the scope of this document
> >>>>> and remains
> >>>>>> for further study.
> >>>>>>
> >>>>>>       NOTE: Deprecation of the usage of offer in PRACK may be
> >>>>>>       another solution. As the precondition mechanism
> >>> specification
> >>>>>>       [2] explicitly shows a usage of sending offer in
> >>> PRACK, its
> >>>>>>       deprecation could cause backward compatibility issues.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: [e-mail]
> >>>>>>> [mailto:[e-mail] <mailto:[e-mail]> ] On Behalf Of
> >>> Christer Holmberg
> >>>>>>> Sent: 10. helmikuuta 2008 13:57
> >>>>>>> To: Takuya Sawada; [e-mail]
> >>>>>>> Cc: [e-mail]; [e-mail];
> >>>>>>> [e-mail]
> >>>>>>> Subject: Re: [Sipping] sipping-sip-offeranswer-05:
> >>> comments and
> >>>>>>> questions
> >>>>>>>
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Again, I am not proposing to add normative text to the draft.
> >>>>>>>
> >>>>>>> But, as I have said before, I do think it is important to
> >>>>> document
> >>>>>>> discussions and different solution proposals in the draft.
> >>>>>>>
> >>>>>>> I will take a closer look at the draft in the beginning
> >>>>> of the week,
> >>>>>>> and see whether I can propose some text regarding this issue.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>> Christer
> >>>>>>>
> >>>>>>>> -----Original Message-----
>
> >>>>>>>> From: Takuya Sawada [mailto:[e-mail] <mailto:[e-mail]> ]
> >>>>>>>> Sent: 9. helmikuuta 2008 9:37
> >>>>>>>> To: Christer Holmberg; [e-mail]
> >>>>>>>> Cc: [e-mail]; [e-mail];
> >>> [e-mail];
> >>>>>>>> [e-mail]
> >>>>>>>> Subject: Re: [Sipping] sipping-sip-offeranswer-05: comments
> >>>>>>>> and questions
> >>>>>>>>
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Well, I am surprised at the huge traffic on this issue.
> >>>>>>>> I cuold not follow them at all last week...
> >>>>>>>>
> >>>>>>>> Now I also tend to agree to make this issue done as
> >>> a separate
> >>>>>>>> work like as a new normative document to correct/update
> >>>>> RFC 3262.
> >>>>>>>> Whether the summary of this discussion should be
> >>>>>>> incorporated in the
> >>>>>>>> O/A document or not, I will not be against it if good
> >>>>> and simple
> >>>>>>>> additional text can be proposed. That is the way we did
> >>>>> on editing
> >>>>>>>> this document. The only issue is the timing, I think.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Takuya
> >>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>>> We can decide what we want to do. But the O/A document is
> >>>>>>>> on track to
> >>>>>>>>>> be a BCP, not a normative change to the existing specs.
> >>>>>>> So *it* is
> >>>>>>>>>> limited in what it can do. We can record a bug in bug
> >>>>>>> tracker, and
> >>>>>>>>>> can potentially scope out
> >>>>>>>>>> *additional* work, such as another contribution to the
> >>>>>>> corrections
> >>>>>>>>>> document. But I see that as a separate piece of work.
> >>>>>>>>> The idea is that the behviour would be documented in the
> >>>>>>>> O/A document
> >>>>>>>>> as a potential way to solve the problem, while we then
> >>>>>>>> decided (as a
> >>>>>>>>> separate piece of work) how we would document it in a
> >>>>>>> normative way
> >>>>>>>>> elsewhere.
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>>
> >>>>>>>>> Christer
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Christer Holmberg wrote:
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>>> IMO we cannot, in a BCP, recommend behavior
> >>> that is an
> >>>>>>>> outright
> >>>>>>>>>>>> violation of a normative document.
> >>>>>>>>>>> My proposal is that we make a "normative" decission to
> >>>>>>>>>> allow non-2xx
> >>>>>>>>>>> responses to PRACK, in order to reject offers etc. As
> >>>>>>> you said
> >>>>>>>>>>> yourself, some parts of 3262 already seems to
> >>> allow it.
> >>>>>>>>>>>> If something is ambiguous, we can recommend a valid
> >>>>>>>>>> alternative that
> >>>>>>>>>>>> is likely to have the most favorable outcome, but we
> >>>>>>>> still can't
> >>>>>>>>>>>> count on all parties following that
> >>>>> recommendation, and so
> >>>>>>>>>> still need
> >>>>>>>>>>>> to account for the behavior when one party
> >>> follows the
> >>>>>>>>>> recommendation
> >>>>>>>>>>>> and the other party follows another, possibly legal,
> >>>>>>>>>> interpretation.
> >>>>>>>>>>> If something is ambigiuos, we fix it.
> >>>>>>>>>>>
> >>>>>>>>>>> The only thing we will have "in future" is a
> >>>>> bigger number
> >>>>>>>>>>> of implementations doing things in a specific
> >>> way, which
> >>>>>>>> means more
> >>>>>>>>>>> interop problems, and more difficulties to specify a
> >>>>>>>>>> "correct behavior".
> >>>>>>>>>>> So, let's make a decission NOW, and then bury this
> >>>>>>>>>> discussion once and
> >>>>>>>>>>> for all :)
> >>>>>>>>>>>
> >>>>>>>>>>>> In this case, I don't see how we can recommend that
> >>>>>>> a non-2xx
> >>>>>>>>>>>> response be sent to a PRACK that matches the
> >>> dialog, etc.
> >>>>>>>>>>> Sending non-2xx responses to requests, even if thet
> >>>>>>>>>>> match
> >>>>>>>>>> the dialog,
> >>>>>>>>>>> is nothing new, is it?
> >>>>>>>>>>>
> >>>>>>>>>>>> So I think the best we can do it steer people away
> >>>>>>>> from sending
> >>>>>>>>>>>> offers in PRACKs. Which is what we have already done.
> >>>>>>>>>>> That still doesn't prevent us to make a decission on
> >>>>>>>> how to solve
> >>>>>>>>>>> things. As long as it is allowed to use PRACK for
> >>>>>>>>>>> sending
> >>>>>>>>>> offers, the
> >>>>>>>>>>> problem will be there.
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>>
> >>>>>>>>>>> Christer
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Christer Holmberg wrote:
> >>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Calling things ambiguous, fixing them in the
> >>>>> future etc is
> >>>>>>>>>>>> never going
> >>>>>>>>>>>>> to make anything better - especially since
> >>> this is an
> >>>>>>>>>>>>> issue
> >>>>>>>>>>>> which is
> >>>>>>>>>>>>> raised over and over again.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I agree that it is good that the offer-answer draft
> >>>>>>> tries to
> >>>>>>>>>>>>> discourage one from using PRACK for sending
> >>>>> offers in the
> >>>>>>>>>>>> first place,
> >>>>>>>>>>>>> but that is not enough.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> My proposal would be that we in the
> >>>>> offer-answer draft say
> >>>>>>>>>>>> that it IS
> >>>>>>>>>>>>> allowed to send a non-2xx response to a
> >>> PRACK, e.g. in
> >>>>>>>>>>>> order to reject
> >>>>>>>>>>>>> an offer, as has been discussed in this draft.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Now, whether we then need to revise 3262, or we just
> >>>>>>>>>>>> consider it as a
> >>>>>>>>>>>>> clarification, we can discuss, but doing
> >>> nothing will
> >>>>>>>> not help.
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Christer
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>> From: [e-mail]
>
> >>>>>>>>>>>>>> [mailto:[e-mail] <mailto:[e-mail]> ] On Behalf Of
> >>>>> Brett Tate
> >>>>>>>>>>>>>> Sent: 6. helmikuuta 2008 23:45
> >>>>>>>>>>>>>> To: Paul Kyzivat
> >>>>>>>>>>>>>> Cc: [e-mail]; IETF Sipping List; Mary
> >>>>>>>>>>>>>> Barnes
> >>>>>>>>>>>>>> Subject: Re: [Sipping] sipping-sip-offeranswer-05:
> >>>>>>>> comments and
> >>>>>>>>>>>>>> questions
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> How do we resolve that and proceed?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - we could decide that with careful enough
> >>>>>>> reading the spec
> >>>>>>>>>>>>>> does cover
> >>>>>>>>>>>>>>> this case, one way or another. If so then we
> >>>>> can craft
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>> offeranswer
> >>>>>>>>>>>>>>> draft to explain this clearly.
> >>>>>>>>>>>>>> Hopefully this is possible.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> - we can conclude that this case is not
> >>> normatively
> >>>>>>>>>>>>>> specified and so
> >>>>>>>>>>>>>>> is ambiguous, and requiring of a normative fix.
> >>>>>>> We can call
> >>>>>>>>>>>>>> that out
> >>>>>>>>>>>>>>> for future work, and put best practice
> >>>>> guidance into the
> >>>>>>>>>>>>>> offeranswer
> >>>>>>>>>>>>>>> draft on how best to function in the presence of
> >>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>> ambiguity. This
> >>>>>>>>>>>>>>> is what I think the draft is currently
> >>>>> attempting to do.
> >>>>>>>>>>>>>> I agree that sipping-sip-offeranswer-05 is wisely
> >>>>>>>> attempting to
> >>>>>>>>>>>>>> discourage sending offers within PRACK.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> If the first option is not possible, this
> >>>>> option sounds
> >>>>>>>>>>>>>> ok
> >>>>>>>>>>>> to me.  It
> >>>>>>>>>>>>>> might trigger follow-up concerning
> >>> potential need for
> >>>>>>>>>>>> rfc3262bis per
> >>>>>>>>>>>>>> SIP group discussion early 2006:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>> http://www.ietf.org/mail-archive/web/sip/current/msg13240.html <http://www.ietf.org/mail-archive/web/sip/current/msg13240.html>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>> Brett
> >>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>> Sipping mailing list
> >>>>>>>>>> http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping>
> >>>>>>>>>>>>>> This list is for NEW development of the application
> >>>>>>>> of SIP Use
> >>>>>>>>>>>>>> [e-mail] for questions on
> >>>>>>>>>> current sip Use
> >>>>>>>>>>>>>> [e-mail] 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: [phone]
> >>>>>>>> Fax: [phone]
> >>>>>>>> [e-mail]
> >>>>>>>>
> >>>>>>>>
> >>>>> ------------------------------------------------------------------
> >>>>>>>> ??:??????????KDDI????????????????
> >>>>>>>>       ?????????????????????????????
> >>>>>>>> ??????????????????????
> >>>>>>>>       ?????????????????????????????
> >>>>>>>> ?????????????????????????????
> >>>>>>>> NOTE: This electronic mail message may contain confidential
> >>>>>>>> and privileged information from KDDI Corporation. If you
> >>>>> are not the
> >>>>>>>> intended recipient, any disclosure, photocopying,
> >>>>>>>>       distribution or use of the contents of the received
> >>>>>>>>       information is prohibited. If you have received
> >>>>> this e-mail
> >>>>>>>>       in error, please notify the sender immediately and
> >>>>>>>>     permanently delete this message and all related copies.
> >>>>>>>>
> >>>>> ------------------------------------------------------------------
> >>>>>>>> -
> >>>>>>>>
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Sipping mailing list
> >>>>>>> http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping>
> >>>>>>> This list is for NEW development of the application
> >>> of SIP Use
> >>>>>>> [e-mail] for questions on current sip
> >>>>>>> Use [e-mail] for new developments of core SIP
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> Sipping mailing list
> >>> http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping>
> >>>>>> This list is for NEW development of the application of SIP Use
> >>>>>> [e-mail] for questions on
> >>> current sip Use
> >>>>>> [e-mail] for new developments of core SIP
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping>
> >>>>> This list is for NEW development of the application of SIP Use
> >>>>> [e-mail] for questions on current sip Use
> >>>>> [e-mail] for new developments of core SIP
> >>>>>
> >>> _______________________________________________
> >>> Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping>
> >>> This list is for NEW development of the application of SIP
> >>> Use [e-mail] for questions on current
> >>> sip Use [e-mail] for new developments of core SIP
> >>>
> > _______________________________________________
> > Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping>
> > This list is for NEW development of the application of SIP
> > Use [e-mail] for questions on current sip
> > Use [e-mail] for new developments of core SIP
> >
> _______________________________________________
> Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping <http://www.ietf.org/mailman/listinfo/sipping>
>
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
>
>
>
_______________________________________________
Sipping mailing list  http://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP