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

From: Adam Roach <[email-masked]>
Date: Wed, 4 Dec 2002 14:45:26 -0600

-----Original Message-----
From: Phil Reynolds [mailto:[email-masked]]

> 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.

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).

/a
_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Dec 2002 01:37:05 -0500

inline.

>>about not changing the body so what is it?

Adam is correct.

> 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
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 5 Dec 2002 11:46:30 -0000

This is correct.  A B2BUA can't blindly forward a request containing a
Require header.

The saving grace for a B2BUA is that it does not need to understand the
extension in detail.  It just needs to know whether it can forward a request
that contains a given Require header.  This can be easily provisioned using
some sort of ASCII configuration file, and doesn't require any new code etc.
A B2BUA could even routinely download the list of acceptable Require headers
from some sort of server.  (A smart B2BUA could even post back a set of
unknown Require headers that it has seen recently.)

Added to that, ideally extensions will avoid the need for specifying Require
as much as possible.

Thus the impact of Require headers is likely to be fairly minimal for most
B2BUAs.  As it is so easy to support the majority of Require extensions in a
B2BUA, B2BUAs will likely support the extensions before the majority of
actual UAs!

(And a firewall related B2BUA really ought to be blocking what it doesn't
understand anyway, so there is little conflict here also.)

Pete.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Dec 2002 11:16:52 -0500

> unknown Require headers that it has seen recently.)

This is a vast over-simplification.

As people have been saying over and over in this thread, there is no 
such thing as a "generic b2bua" as you seem to be implying. What is 
right in a b2bua depends entirely on what its doing. To be honest, I 
can't think of any b2bua for which the processing you describe above is 
sensible. As I mentioned in a previous note, a b2bua deviates from a 
proxy by doing some featurs that are normally associated with a UA. That 
b2bua will need to process extensions (i.e., implement them) that are 
associated with that feature.

I am at the point where I agree with the sentiment raised by others, 
that we should remove the term b2bua entirely from the specification. It 
has caused more confusion than anything else.

-Jonathan R.

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 5 Dec 2002 16:46:53 -0000

Jonathan,

I have not said anything about generic B2BUAs here.  Each B2BUA
implementation will need to have its own record (and server) of what it is
transparent to or not.  It would not be a generic list.

Perhaps it is reasonable to remove the B2BUA definition, since there is no
definition of a gateway and they are similar beasts.  Just as long as such
an action does not imply that SIP is not suitable for a certain class of
problem.

Pete.

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Pete Cordell" <[email-masked]>
Cc: "Adam Roach" <[email-masked]>; "'Phil Reynolds'"
<[email-masked]>; <[email-masked]>
Sent: 05 December 2002 16:16
Subject: Re: [Sip] B2BUA & Max-Forwards

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Dec 2002 01:25:40 -0500

> an action does not imply that SIP is not suitable for a certain class of

Removal of the definition has nothing at all to do with whether or not 
such a SIP application can be built. Clearly it can.

-Jonathan R.