Subject: Re: [Sipping] 3G entities: Proxy or B2BUA?

From: William Marshall <[email-masked]>
Date: Thu, 25 Oct 2001 16:24:19 -0400 (EDT)

I posted a long discussion of this "transparent" B2BUA
several months ago, apparently during the period when there
were no archives of the sip mail list.  And my email archives
are on a lost backup disk.  So it goes.

The main point I tried to make was that a network entity that
receives a SIP request, processes it, and sends one (or more) SIP 
requests could be a stateless-proxy, or could be a stateful-proxy,
or could be a Rohan-style-B2BUA, or could be a Miguel-style-B2BUA,
or could be something in between.

In fact I believed then (and still do) that a statefuo proxy is a subset
of the set of SIP-elements, with certain defined restrictions on the
request/response processing that it does.  A stateless proxy is
an even more-restricted SIP-element.  They should be defined as such.

So the key question here is whether there are other subsets of
the general class of SIP-elements (larger than the stateful proxy),
that are both useful to define, and preserve new-feature 
transparency.  I believe there are.

So for a simple example, consider a "stateful-proxy++" that also
expands the CSeq values - it takes the input request with a
CSeq value n, and generates a request with value 2*n.  Responses
with CSeq value x turn into responses with value x/2.  Useful?
I doubt it.  But by the rules of bis-04, it is a B2BUA, and
the popular religion says B2BUAs break feature transparency.
That is the wrong thinking, that my trivial example discredits.

A "stateful-proxy++" that generates BYE requests (with the proper 
From, To, Call-ID, CSeq, and Route headers) and sends them to
both endpoints is in the same category of "safe" B2BUAs.
Likewise a "stateful-proxy++" that strips Via headers, 
and Record-Route headers (and restores them in future requests
for this call) is similarly in the safe category (though, granted,
it needs to do more work for loop detection than a normal proxy
would).

It would be very useful in the next bis draft to attempt to define
what is safe behavior and what is feature-breaking behavior for
these "stateful-proxy++" SIP elements.  The hope is that the P-CSCF
is a safe one.

Bill Marshall
[email-masked]

excerpt of current discussion:
<mega-snip>
>> >The main problem with B2BUA, as it is defined by the bis
>> draft, it that it acts as a UA on both sides. Therefore, it
>> needs to understand every method, header, codec, etc that
>> the UA sends. If it does not understand anything, it has to
>> reject it.
>> 
>> This assumption is fortunately not correct.  It is possible,
>> reasonable, and legal to implement a B2BUA that
>> transparently passes headers, method, and bodies that it
>> does not directly understand.  An anonymizer is a perfect
>> example of such a B2BUA--it only needs to understand a few
>> headers, plus the SDP, and pass the rest transparently.
>
>I don't think it is possible to transparently pass headers, 
>methods, bodies, etc. For instance, manyfolks already specifies
>actions when the a=qos attribute is present in SDP with the 
>parameter "confirm" (COMET is triggered). The B2BUA will need
>to understand the confirm to trigger the COMET. How is this
>going to interact with the QoS reservation?

I disagree, I think it is possible.  A B2BUA is a *logical* 
entity and does not literally need to act like an autonomous 
UA.  If the spec says that a UA needs to send back an error 
if such-and-such header/event/body/method is not understood, 
it is reasonable for the UA to ask another entity if 
it "supports" or "understands" that 
header/event/body/method.  In this case the "other entity" 
is the target UA.
<mega-snip>

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 26 Oct 2001 12:30:28 +0100

> are on a lost backup disk.  So it goes.

Unfortunately, I can't find this either.  Still, I
have been thinking about this very issue recently,
and I think it would be worthwhile exploring it
(especially now the Pantheon has returned (:&).

[In fact, if this doesn't fizzle out immediately,
perhaps it should be moved to SIP WG?]

Anyway.

> an even more-restricted SIP-element.  They should be defined as such.

Interesting.

I've only had the very briefest of briefly brief looks
at bis-05, but that small comprehension (which can prob
be mostly attributed to Jonathan's summary) does tend
to suggest that this is almost falling out of the new
way things have been written / layered; specifically,
the moving of INVITE-2xxs & their ACKs more into the
application domain.

This was the only thing that really separated UA and
proxy behaviour from a client / server point of view,
IMO; this migration now means that the machines should
be identical.

Well, stateless proxies are slightly different, but
they're too boring for me to consider here. &:)

> That is the wrong thinking, that my trivial example discredits.

Yeah.  I've always been of the opinion that a proxy
can't mess with any of {From, To, Call-ID, CSeq, Via}.
I'm trying to work through whether I still think this
is the case.

I think that my original reasoning was that if none
of these headers were changed, then if the proxy (or
state-sharing farm, or whatever) broke, then there was
still a chance that an particularly intelligent element
would be able to heal the break, by missing out a
hop or similar.  However, I'm wondering if such
aggressive medicine could prove to be insidious in
general; after all, there was probably a good reason
for the now-broken proxy to be in the loop, right?

So maybe it's okay to change these things?

Well, I have perhaps come up with a reason why it
really is not.  Perhaps.

Imagine two UAs in a call with a proxy in the
middle that is translating From headers (because
it's functioning as some sort of anonymizer).
This proxy completely groks dialogs (call-legs --
thanks), so knows to munge the From for ACKs
and re-INVITEs and BYEs and INFOs and OPTIONS
alike.  Everybody happy, right?

Well no, because one of the UAs decides to send
a REFER using Replaces:, too.  Unfortunately,
clever proxy doesn't know anything about Replaces:,
and thus completely fails to munge the from-/to-tag.

Oh dear.

Now it might be argued that a proxy changing
any header runs this risk -- I think I'm ambivalent.
But initially it seems to me that these headers --
the really fundamental ones -- are going to be
far more intolerant of any sort of frobnication.

> both endpoints is in the same category of "safe" B2BUAs.

Ah.  I would consider this taking things a step
further.  For instance, the BYE will now be seen
to be travelling in a different direction depending
on where Record-Route:d proxies are on the path.
Maybe this has service implications....

> it needs to do more work for loop detection than a normal proxy

I would still see loop detection as trivial.  But
messing with these things makes me very uneasy.

> these "stateful-proxy++" SIP elements.  The hope is that the P-CSCF

Well, I don't know about the P-CSCF, but I would
like to see this nailed down.  (Please excuse if
this has already been done in bis-05.)

 - Jo.