Subject: RE: [Sip] B2BUA & Max-Forwards

From: Gordon Ledgard <[email-masked]>
Date: Thu, 5 Dec 2002 15:03:55 -0500

inline - 

> -----Original Message-----
> From: David Oran [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 2:11 PM
> To: Pete Cordell; Dean Willis; [email-masked]
> Subject: Re: [Sip] B2BUA & Max-Forwards
> 
> 
> --On Thursday, December 05, 2002 5:24 PM +0000 Pete Cordell 
> <[email-masked]> 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" <[email-masked]>
> > To: "Pete Cordell" <[email-masked]>; "Dean Willis"
> > <[email-masked]>; <[email-masked]>
> > Sent: 05 December 2002 14:02
> > Subject: Re: [Sip] B2BUA & Max-Forwards
> >
> >
> >> --On Thursday, December 05, 2002 12:09 PM +0000 Pete Cordell
> >> <[email-masked]> 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" <[email-masked]>
> >> > To: "'Pete Cordell'" <[email-masked]>; <[email-masked]>
> >> > 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 [email-masked] for questions on 
> current sip
> >> >> Use [email-masked] 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 [email-masked] for questions on current sip
> >> > Use [email-masked] 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: [email-masked]
> >
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: David Oran <[email-masked]>
Date: Thu, 05 Dec 2002 15:16:27 -0500

> the loops howsoever you want.
Ok, then how about the following wording: "a B2BUA MUST prevent loops and 
it MUST NOT behave in such as way as to cause broadcast storms, or 
contribute to any exponential message explosion of SIP or any other 
messages. In addition, it MUST comply will all local and national fire 
codes, including the Underwriter's Laboratory flaming oil test*.

*Note: this is important guidance for implementers. I once had a device I 
helped design fail the flaming oil test for one of the six possible 
mounting orientations of the box (it passed in the other 5 orientations). 
The orientation it failed in was with all of the I/O sockets facing the 
wall (making it impossible to plug anything into the box, but that didn't 
matter to the testers).

Tiring of this subject, as should be apparent...Dave.

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 6 Dec 2002 13:45:27 -0000

----- Original Message -----
From: "David Oran" <[email-masked]>

... much deleted ...

> messages.

Preventing loops will help with this.  But more helpfully, the text used to
describe proxies in this respect might be useful guidance on how far to go.

> In addition, it MUST comply will all local and national fire

Doesn't seem a SIP issue, but if you think its helpful from a SIP point of
view...

Pete