[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] B2BUA & Max-Forwards



Hello,
Fully agree with you.
Indeed, that's what should be explicitly added to the B2BUA definition in
3261, to avoid confusion:
"Anything that deviates at all from proxy rules will need to be a b2bua and
follow b2bua rules"
"...a b2bua depends entirely on the application logic"
All the debate is around these two notions.
Best regards
Juan Carlos





Jonathan Rosenberg <jdrosen@dynamicsoft.com>@ietf.org on 05/12/2002
07:37:05

Sent by:  sip-admin@ietf.org


To:   Adam Roach <adam@dynamicsoft.com>
cc:   "'Phil Reynolds'" <preynolds@ridgewaysystems.com>, sip@ietf.org
Subject:  Re: [Sip] B2BUA & Max-Forwards


inline.

Adam Roach wrote:
> -----Original Message-----
> From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com]
>
>
>>Now your back to restricting what I can and can't do in an
>>intermediary. It can't be a B2BUA 'cos it doesn't need to
>>honour require headers (the UA at the other end does that,
>>if they were meant for my intermediary then they would be
>>proxy-require?), and it can't be a proxy 'cos of the rules
>>about not changing the body so what is it?
>
>
> Broken.

Adam is correct.

>
> The restrictions placed on nodes by 3261 (which I'm merely
> reiterating, not imposing) aren't an authoritarian attempt
> at unnecessary proscription. They serve a purpose.
>
> I'll describe one of the (several) purposes that applies
> to the situation you propose.
>
> One of the things that UAs are required to be able to do is
> sign and/or encrypt the bodies and/or some subset of the
> headers to ensure confidentiality and/or integrity. The
> protocol places restrictions on various nodes to ensure
> that this can be done. Your box is broken precisely because
> it interferes with these abilities (or, more precisely,
> these abilities interfere with it).

Let me add some more here.

Anything that deviates at all from proxy rules will need to be a b2bua
and follow b2bua rules, including processing of Require. There is no
black-or-white here. Let me give some examples.

Lets say my b2bua is a proxy in all ways, BUT it happens to muck with
SDP to enable firewall traversal. Surely then it can ignore Require,
right? WRONG. Lets say I define extension foo, which means "the content
of this SDP is not what it seems - look at this header to instead find
the real port/address for media". This extension needs a Require
(because only a UA ever looks at bodies), but not a Proxy-Require,
because proxies don't. Thus, your almost-a-proxy will fail in odd ways
because it has ignored Require when it shouldn't have.

Indeed, for any operation prohibited to a proxy, but allowed for a UA, I
can come up with an extension, indicated in a Require header, that would
need to be understood by a b2bua which breaks the proxy rules and
performs this operation. Indeed, the rules on what is a UA, and what is
a proxy, are meant precisely to help define what goes in Require, and
what goes in Proxy-Require.

Whether or not Require gets passed on by such a b2bua depends entirely
on the application logic.

-Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.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