[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