Subject: RE: [Sip] B2BUA

From: Phil Reynolds <[email-masked]>
Date: Tue, 3 Dec 2002 13:53:56 -0000

The trouble with that is that the RFC stipulates the way these
intermediaries work and unless your intermediaries work in that way, you
cant put "CONFORMS TO RFCxyz" on the box and hence the spec is stifling my
creativity (and more importantly my marketability).
 
The spec should stick to defining the "on wire" protocols and let us
"creative types" come up with imaginative ways to subvert them :-)

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]] 
Sent: 03 December 2002 13:20
To: 'Phil Reynolds'
Subject: RE: [Sip] B2BUA

Phil,
 
I do see both sides of this debate, but I've yet to see it come to a
resolution to which everyone can agree, as everyone has built something
that's slightly different (and yes our marketing folks want each of ours to
be the best of such different things). Realistically, building anything
beyond a basic proxy is a tradeoff between desired (and many believe
required) functionality versus the complexity and the potential for
interworking problems. I think it's the fundamental problem that the IETF
doesn't define architectures, but rather protocols.  However, to define the
protocols, you must define some architectural elements to set the context
and that's where the problems begin, as everyone's implementation of the
architectural elements is always different because the specs don't provide
enough detail. 
 
So, perhaps the best way around this is to leave the basic SIP spec as is
and write an informational RFC defining the various flavors of entities
"Beyond SIP Proxys"  and "Towards B2BUAs" so that we can give our marketing
folks a pointer to a document that describes at some level the "flavor" of
system we provide.  I say this rather facetiously, but realistically, it
might be the most effective way to resolve this problem and end this long
debates. 
 
Regards,
Mary. 

 -----Original Message-----
From: Phil Reynolds [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 4:05 AM
To: Barnes, Mary [NGC:B602:EXCH]
Subject: RE: [Sip] B2BUA

The problem as I see it is that the RFC defines 2 distinct intermediary
entities a "SIP Proxy" which has limited functionality, i.e. it is not
allowed to modify the body of the message, and a B2BUA which is a full blown
pair of Uas with all the transactional and dialogue stuff.

What we build is something in the middle... We rely on the "real" UAs to do
all the transactions, retries dialogs etc, and we modify the messages and
SDP bodies as they go through.

Personally I don't care what the spec says. We build a system that does a
useful function, if it doesn't fit into a category that is defined by the
spec -- so what? However the marketing types don't quite see it that way ;-)

If the spec is going to define the permissible intermediaries, it SHOULD
allow for things that are not implemented as UAs but externally appear to be
so.

-----Original Message----- 
From: Mary Barnes [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: 02 December 2002 16:54 
To: 'Phil Reynolds'; [email-masked] 
Subject: RE: [Sip] B2BUA 

Hi all, 

I guess I have to ask, what's the problem with the definition in RFC 3261?