Subject: RE: [Sip] Forking: a modest proposal.

From: Jay Batson <[email-masked]>
Date: Tue, 10 Jul 2001 18:26:45 -0400

Bridging and conferencing problems are not sufficient justification for the 
profusion of B2BUAs.  Most endpoints I know (hard/soft phones, gateways) 
have enough signal/host processing power to mix 3-4 RTP streams.

So to effect a conference, you *can* work out call flows that let the 
endpoint bridge a small number of streams.  (We have done this just fine, 
thank you.)

This clearly doesn't scale.  But since most conferences are small anyway, 
the only products that *MUST* use B2BUAs to do this would be big, honkin 
network-based conference bridges for large conferences.  This is *not* who 
seems to be falling back on B2BUAs.  Instead, it is everybody who started 
out by building a simple proxy/redirect/registry server.

Endpoint bridging also uses slightly more bandwidth.  But we should not 
make the protocol design a slave to today's bandwidth constraints.

Conferencing itself is not sufficient justification for the predominance of 
B2BUAs.  The primary reason so many vendors seem to be falling back on 
B2BUAs is that they don't *MAKE* endpoints -- just servers.  The B2BUA is a 
convenient crutch to get more direct control over a component that is 
foreign to their solution.  Cooperate -- don't compete -- for better control.

Of course, I would agree that it is crucially important that clients remain 
clients.  But servers should not become clients, too.  It's a bad idea.

To be clear, I was not being particularly serious about trying to 
"depricate" them from the standard.  Clearly, they *are* a valid UA, and 
can be used as such.  But the industry should think hard about the clear 
DOWNSIDE to falling back on a B2BUA to solve every problem.  Thus, my 
modestly-offered podium-speech.

Comments again from the marginally qualified, but somewhat religious, gallery.
-jb

At 05:14 PM 7/10/01, Zmolek, Andrew (Andrew) wrote:

> > Of course, *that* problem could be solved by deprecating B2BUAs, which are
> > truly and deeply evil IMHO....  Watching the list from afar as I do, I
> > observe that there is a significant and growing temptation to fall back on
> > doing everything via B2BUAs now, less and less of a discipline to force
> > things into the proxy/server model, with the resulting behavior /
> > architecture starting to feel more and more like Megaco.  This is a bad 
> thing.
>
>While I sympathize with your concern, I think we have painted ourselves in a
>corner with respect to B2BUAs. There are a lot of bridging and 4+ party
>conferencing scenarios that simply aren't workable in SIP without a B2BUA.
>Regardless, even if we did depreciate them, there isn't much we could do to
>prevent them from being implemented because a B2BUA is still a valid user 
>agent.
>The key to preventing SIP from becoming Megaco isn't banishing B2BUAs, but 
>rather
>it is ensuring that clients remain clients and not slaves.
>
>--Andy Zmolek
>     Technology & Standards Engineer
>       CTO Standards
>         Avaya Inc.
>
>             [email-masked]
>               +1 720 444 4001

-------------
PingMe!
Jay Batson
CEO
Pingtel Corp.
mailto:[email-masked]
781-938-5306 (office)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jul 2001 18:36:46 -0400

Perhaps I don't fully understand the terminology - I don't recall ever
seeing a precise definition of a B2BUA. But it seems to me that an
endpoint that is managing a conference *is* acting as a B2BUA. If so,
then it seems you are objecting to a certain class of B2BUA.

	Paul Kyzivat
	Cisco Systems

Jay Batson wrote:
> 
> Bridging and conferencing problems are not sufficient justification
> for the profusion of B2BUAs.  Most endpoints I know (hard/soft phones,
> gateways) have enough signal/host processing power to mix 3-4 RTP
> streams.
> 
> endpoint bridge a small number of streams.  (We have done this just
> fine, thank you.)
> 
> This clearly doesn't scale.  But since most conferences are small
> anyway, the only products that *MUST* use B2BUAs to do this would be
> big, honkin network-based conference bridges for large conferences.
> This is *not* who seems to be falling back on B2BUAs.  Instead, it is
> everybody who started out by building a simple proxy/redirect/registry
> server.
> 
> Endpoint bridging also uses slightly more bandwidth.  But we should
> not make the protocol design a slave to today's bandwidth constraints.
> 
> Conferencing itself is not sufficient justification for the
> predominance of B2BUAs.  The primary reason so many vendors seem to be
> falling back on B2BUAs is that they don't *MAKE* endpoints -- just
> servers.  The B2BUA is a convenient crutch to get more direct control
> over a component that is foreign to their solution.  Cooperate --
> don't compete -- for better control.
> 
> Of course, I would agree that it is crucially important that clients
> remain clients.  But servers should not become clients, too.  It's a
> bad idea.
> 
> "depricate" them from the standard.  Clearly, they *are* a valid UA,
> and can be used as such.  But the industry should think hard about the
> clear DOWNSIDE to falling back on a B2BUA to solve every problem.
> Thus, my modestly-offered podium-speech.
> 
> > > architecture starting to feel more and more like Megaco.  This is
> > a bad thing.
> >
> > prevent them from being implemented because a B2BUA is still a valid
> > user agent.
> > The key to preventing SIP from becoming Megaco isn't banishing
> > B2BUAs, but rather

_______________________________________________
Sip mailing list  http://www.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