> 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