[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sip] B2BUA & Max-Forwards
inline -
> -----Original Message-----
> From: David Oran [mailto:oran@cisco.com]
> Sent: Thursday, December 05, 2002 2:11 PM
> To: Pete Cordell; Dean Willis; sip@ietf.org
> Subject: Re: [Sip] B2BUA & Max-Forwards
>
>
> --On Thursday, December 05, 2002 5:24 PM +0000 Pete Cordell
> <pete@tech-know-ware.com> wrote:
>
> > Dave,
> >
> > To save your disagreeableness, can we say something like:
> >
> > "A B2BUA MUST perform loop prevention. One way to do this
> is to propagate
> > the Max-Forwards header from the incoming request to the
> outgoing request
> > in the same way that a proxy does."
> >
> I don't understand what it means to have normative language
> for a beast
> which is fundamentally undefined. Suppose I write a piece of
> code which
> accepts SIP requests, issues tachyon commands to alpha centauri, and
> meanwhile receives routing instructions from a chronosynclastic
> infundibulum (for the unintiated, that is a device which
> effects reverse
> causality based on the message to alpha centauri whose
> response would not
> normally arrive for 7.8 years). It then uses those routing
> instructions to
> formulate an outbound SIP request to the destination received
> through the
> chronosynclastic infundibulum.
>
> Question: is this application a B2BUA and hence required to have a
> Max-Forwards value in the request whose value is strictly
> less than the
> value received in the SIP request? Beats me.
Only if that's the way it wants to do it. You can defeat
the loops howsoever you want.
>
> > It's the loops that I'm worried about, not the Max-Forwards per se.
> >
> There are many ways to suppress loops. Using application semantics is
> actually safer than lower-layer protocol machinery because of
> the hazards
> introduced by protocol translation (e.g. the PSTN hop case mentioned
> earlier, or a SIP<->H.323 conversion somewhere else).
>
> > This addresses my concern, and I think James' and possibly yours.
> >
> Sorry, not mine. From where I sit, the less said about B2BUAs
> the better,
> including asymptotically toward zero.
>
> Cheers, Dave.
>
> > Pete.
> >
> > ----- Original Message -----
> > From: "David R. Oran" <oran@cisco.com>
> > To: "Pete Cordell" <pete@tech-know-ware.com>; "Dean Willis"
> > <dean.willis@softarmor.com>; <sip@ietf.org>
> > Sent: 05 December 2002 14:02
> > Subject: Re: [Sip] B2BUA & Max-Forwards
> >
> >
> >> --On Thursday, December 05, 2002 12:09 PM +0000 Pete Cordell
> >> <pete@tech-know-ware.com> wrote:
> >>
> >> > Dean,
> >> >
> >> > Firstly, your statement that "The B2BUA doesn't change
> headers that
> >> > transit it." seems inconsistent with the statement "It
> does the same
> >> > thing as ... ANY 500-pound gorilla does". I don't understand.
> >> >
> >> > Secondly, I think max-forwards is a special case. It is
> important for
> > the
> >> > protection of SIP systems as it prevents loops.
> >> >
> >> Once a dialog is terminated at a UAS it's up to the
> application to do
> >> loop prevention. SIP is not involved any more. The
> application could
> >> compute a value of Max-forwards for initiating outgoing
> calls based on
> >> incoming
> > calls
> >> which preserves the "strictly decreasing" invariant, or
> alternatively it
> >> could just use the default MAx-Forwards in outgoing
> requests and execute
> >> a contant memory loop suppression algorithm such as
> Knuth's even-odd
> >> iterator. In either event the SIP spec(s) need say nothing
> about this.
> >>
> >> > Indeed, there is a major difference between a UAS and a
> B2BUA and that
> > is
> >> > that the former terminates a request, and the latter terminates a
> > request
> >> > AND ALSO forwards an associated request (or more).
> >> I disagree. A UAS is a UAS. It's behavior is completely
> specified by
> >> RFC3261 (unless there's a hole in the spec of course...).
> What it means
> >> to originate (NOT FORWARD!!!!) an "associated request" is
> completely
> >> application dependent. If I program my child's phone to
> initiate a SIP
> > call
> >> to my surrepititious recording device every time it
> receives a call and
> >> give that device first chance to over-ride policy of the
> child's phone is
> >> the phone a B2BUA? Yes, no, maybe so, but who cares? Tell
> me what the
> >> applciation is and I can write some specs for that
> application and how it
> >> has to originate, terminate and process SIP transactions to do that
> >> application.
> >>
> >> I think the botom line is that there is not a single, well defined
> >> appliation that one can point to and say "that's a B2BUA".
> >>
> >> > The impact of this
> >> > difference should be covered in the spec in the
> interests of protecting
> >> > other SIP systems.
> >> >
> >> I disagree.
> >>
> >> > Pete.
> >> >
> >> > ----- Original Message -----
> >> > From: "Dean Willis" <dean.willis@softarmor.com>
> >> > To: "'Pete Cordell'" <pete@tech-know-ware.com>; <sip@ietf.org>
> >> > Sent: 05 December 2002 01:23
> >> > Subject: RE: [Sip] B2BUA & Max-Forwards
> >> >
> >> >
> >> >> > One issue that the recent B2BUA discussion has raised in my
> >> >> > mind is what a B2BUA (whatever its decided that should be)
> >> >> > should do with Max-Forwards.
> >> >>
> >> >> It does the same thing as it does with any other header
> or body part,
> >> >> which is the same thing that ANY 500-pound gorilla does
> to somebody's
> >> >> body parts -- whatever it wants.
> >> >>
> >> >> What you're asking is "what is the transparency of this
> node with
> >> >> respect to max-forwards", which is "#4 -- Header
> Transaprency" in my
> >> >> top-10 list. The specification of a back-to-back user
> agent doesn't
> >> >> mandate any level of transparency on this or any other header.
> >> >>
> >> >> --
> >> >> Dean
> >> >>
> >> >> _______________________________________________
> >> >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> >> >> This list is for NEW development of the core SIP Protocol
> >> >> Use sip-implementors@cs.columbia.edu for questions on
> current sip
> >> >> Use sipping@ietf.org for new developments on the
> application of sip
> >> >
> >> > _______________________________________________
> >> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> >> > This list is for NEW development of the core SIP Protocol
> >> > Use sip-implementors@cs.columbia.edu for questions on current sip
> >> > Use sipping@ietf.org for new developments on the
> application of sip
> >>
> >> ------------------------
> >> David R. Oran
> >> Cisco Systems
> >> 7 Ladyslipper Lane
> >> Acton, MA 01720
> >> Office: +1 978 264 2048
> >> VoIP: +1 408 571 4576
> >> Email: oran@cisco.com
> >
>
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip