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

From: [email-masked]
Date: Wed, 11 Jul 2001 13:41:03 +0200

The main reason for B2BUA is to take control over the service to be provided to the end user.
So, if SIP is strictly used as a "rendez-vous" protocol over the public Best Effort Internet network, there is in principle no need for such functionality.
This can become quite different if you need to handle the user plane, as in the case of conference controllers.
This is still worse if you are intended to provide services having guaranteed characteristics, like confidentiality, QoS, roaming, etc. A simple SIP proxy can not provide that, then you need a more complex functionality (because the service is more
complex) allowing you to take control over the user request, and that can be done with B2BUA servers.
Best regards
Juan Carlos

Paul Kyzivat <[email-masked]> on 11/07/2001 00:36:46

 To:      Jay Batson <[email-masked]>                    
                                                              
 cc:      [email-masked](bcc: Juan-Carlos ROJAS/FR/ALCATEL)     

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

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

_______________________________________________
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

_______________________________________________
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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Jul 2001 08:48:06 -0400

UAs (and B2B UAs) make sense when the UA also needs to terminate media,
as for large-scale conference bridges and anonymizers. I don't think
anybody is arguing with that, although for conference bridges, one would
hope that they are transient phenomena. (Despite the bad press,
multicast is slowly emerging as an option again, at least in selected
environments, such as Internet2.)

I have no idea why you would need B2B UAs for roaming or what they have
to do with QoS (except that they generally are likely to make QoS
worse.)

An additional use of B2BUAs is for media translation, but this is really
only likely for multiparty calls, as quality is much better if you can
avoid transcoding. (I may be underestimating the effect of the screwy
licensing for G.72x and various other low-rate codecs here, which also
could lead to more transcoding than is technically called for.)

---

From: [email-masked]
Date: Wed, 11 Jul 2001 16:32:14 -0500

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
>
> avoid transcoding.

Sort of. Wireless-to-landline calls go through a GSM-to-G.711
transcoder; most wireless-to-wireless calls go GSM-to-G.711-to-GSM.
(Substitute various other heavily-compressed codecs for "GSM" to
make the above sentence apply all over the world).

Since the audio characteristics of most phones is so crappy, and
since an 8 kHz sampling rate is rather dismal, most people don't
even notice.

> (I may be underestimating the effect of the screwy

Three letters: AMR

3GPP is going for AMR as a default codec, with the implication that
G.711 *will* *not* be used.

Bakeoffs have shown that many firmware SIP implementations use
G.711 exclusively.

In the short term, transcoders will abound.

This is why (I feel) we need to come up with a good architecture
to support transcoding which doesn't require a B2BUA. No, I'm not
proposing a work item (we do protocols, not architectures); I'm
just thinking out loud.

/a

---

From: Michael Hammer <[email-masked]>
Date: Wed, 11 Jul 2001 19:25:05 -0400

You may also be interested to know that in TIA there was a feature called 
vocoder-bypass that essentially mapped the bits into only part of the 64k 
stream and left it in codec form when it was known that both sides used the 
same codec.  That was to avoid the small but additive degradation that 
occurred at every coding-decoding interface.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 11 Jul 2001 16:51:38 -0700 (PDT)

> proposing a work item (we do protocols, not architectures); I'm

   Well, stop it :-)

   I sense that what you're hoping for is the moral equivalent
   of an RTP NAT and to that I say TANSTAAFL. There's a variety
   of ways that you could implement and/or control your transcoder
   box, but let's not allow delusion to creep in here that what
   is finally shaked and baked isn't, in fact, a form of an
   application layer gateway, lest the curse of Deering be upon
   you :-)

	Mike

---

From: [email-masked]
Date: Wed, 11 Jul 2001 19:53:08 -0500

> From: Michael Thomas [mailto:[email-masked]]
> 

Okay, now you've provoked me. :)

The fact that you would assume that the *signalling* needs to go through
some special box to allow transcoding just highlights how entrenched the
mindset that I'm railing against has become. This is a fallacy that no
one seems to even question.

Allow me to clarify.

If we have network-provided transcoding, we'll need to send the RTP
through some transcoder box. There are two ways to achieve this.

The trivial solution is to send the signaling through some transcoder
control box; it acts as a B2BUA, in much the same way that a conference
bridge would. (This is extremely simple for terminals to do: if you send
me an INVITE for a codec I don't know, I send you a 305 response to tell
you to go to my transcoder -- or, if I get a 488 or 606, I send a new
invite through my transcoder).

Alternately, when a codec mismatch is detected, you can set up some
relationship whereby the terminal communicates with a transcoder using
an appropriate protocol (H.248 comes to mind) to pre-arrange the fact
that media coming in to the transcoder on a negotiated port will be
transcoded and sent to the terminal (and the same thing in the reverse
direction).

Both approaches work, and one of them will *need* to be deployed. 

The former has all the drawbacks of a B2BUA combined with the drawbacks of
needing a transcoder in the network; the latter merely has the drawbacks
of having a transcoder. Unfortunately, most people seem to be leaning
towards the first solution -- which is terrible, in my mind. Just because
we're having to use a transcoder should not mean that feature transparency
is destroyed. I'm trying to being attention to the fact that using a B2BUA
for this application is EVIL, and should be avoided when possible.

I agree that trying to put a "transparent" SIP proxy in the path to munge
the SDP is completely the wrong answer, and -- lest anyone be confused --
such a solution is absolutely nothing like what I was suggesting.

/a

---

From: Michael Thomas <[email-masked]>
Date: Thu, 12 Jul 2001 07:19:44 -0700 (PDT)

> one seems to even question.

   Ectually, I didn't make that assumption. In fact, "control"
   was meant to allude to what you describe below...
   
 > for this application is EVIL, and should be avoided when possible.

   It really depends, I suspect. The drawback of using MGC/MG
   like decompositions is that there is:

   a) a lot of code needed to drive the MG if you're the MGC
   b) a fundamental assumption of trust between the MGC and MC.
   c) (soft) real time requirements between MG and MGC

   For a simple handset, say, pretending to be a big old
   honkin' MGC is probably overkill, and may run afoul of
   the flash memory gods. The trust issue might be overcome
   by properly "virtualizing" the MG, but there's some question
   in my mind whether that could be done in practice. For (c),
   you'd *really* have to careful... if I were trying to control
   an MG over a krufty cellular link, say, it would be interesting
   times, as they say.

   I'm not dissing the idea, mind you. It's just that it's
   not with its own set of considerations.

	    Mike

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 12 Jul 2001 14:44:18 -0500

agree, except
>H.248 comes to mind

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wednesday, July 11, 2001 7:53 PM
To: 'Michael Thomas'; [email-masked]
Cc: 'Henning Schulzrinne'; [email-masked]; Paul Kyzivat;
Jay Batson; [email-masked]
Subject: RE: Transcoding != B2BUA (was RE: [Sip] Forking: a modest
proposal.)

Allow me to clarify.

The former has all the drawbacks of a B2BUA combined with the drawbacks
of
needing a transcoder in the network; the latter merely has the drawbacks
of having a transcoder. Unfortunately, most people seem to be leaning
towards the first solution -- which is terrible, in my mind. Just
because
we're having to use a transcoder should not mean that feature
transparency
is destroyed. I'm trying to being attention to the fact that using a
B2BUA
for this application is EVIL, and should be avoided when possible.

I agree that trying to put a "transparent" SIP proxy in the path to
munge
the SDP is completely the wrong answer, and -- lest anyone be
confused --
such a solution is absolutely nothing like what I was suggesting.

/a