RE: [SIP] Back-to-back UAs

Peter Mataga <PMataga@dynamicsoft.com> Thu, 18 January 2001 15:00 UTC

Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25744 for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 10:00:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C9B37443CE; Thu, 18 Jan 2001 09:01:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E53124433B for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 09:00:37 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA13411; Thu, 18 Jan 2001 10:03:08 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id <CZ9K2D9A>; Thu, 18 Jan 2001 09:57:06 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF27F41D@DYN-EXCH-001.dynamicsoft.com>
From: Peter Mataga <PMataga@dynamicsoft.com>
To: 'Rick Dean' <siplist@fdd.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Back-to-back UAs
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 09:57:06 -0500

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Tuesday, January 16, 2001 12:37 PM
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] Back-to-back UAs
> 
> 
> 
> Keith,
> 
> I apologize.  Back-to-back UA is another name for Rosenberg's
> 3rd Party Call Control.  3PCC was first published here..
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
> The draft does not use the B2BUA moniker.

Perhaps because 3pcc is not exactly the same as B2BUA, at least as used in
this thread and elsewhere. I would certainly agree that "back-to-back" UAs
*sound* like they ought to be in 3pcc mode, in the sense that both UAs are
initiating INVITE transactions in 3pcc (and thus "facing outward" :-).

However, the B2BUA moniker is being used for (or at least to include) modes
where the UAs are, well, "front-to-back"? "back-to-front"? Hmm, I guess we
can see why neither of these was used ... [Note that the 3pcc draft uses (in
a footnote) the term "virtual UAS/UAC" for the case where the entity
providing mid-call control did not initiate one of the original calls, as is
the case for most of the device control scenarios that Bill Marshall
mentions in his post to this thread.] 

The characterization of a proxy as a B2BUA with constrained behavior as in
Bill's post seems like the right idea to me. 3pcc is a specific kind of
constrained B2BUA also, but it's not the general case.

> 
> Yes, 3PCC/B2BUA can break the end to end nature.  Sometimes this
> is desired.  A company may wish to hide its internal
> routing.  A fragile gateway may need a SIP wrapper/firewall.  etc.
> 
> The biggest problem I currently experience is 
> looping.  I wish all B2BUAs would preserve 
> the call-id.  Unfortunately, I can't get rid of my biggest
> B2BUA, the public switched telephony network (PSTN).  :-/
> 
> --
> Rick
> rick_dean@3com.com
> 
> On Tue, Jan 16, 2001 at 12:57:05PM -0000, Drage, Keith (Keith) wrote:
> > I keep seeing mention of back-to-back UAs and I think I 
> understand what is
> > trying to be done with them. 
> > 
> > I do however see an issue that there is apparently no 
> documentation of this
> > concept in any draft. Therefore it leads to the question of 
> when does a
> > proxy become a back-to-back UA, and therefore perform all 
> error handling and
> > syntactic checking as a UA rather than a proxy. Because 
> there is no mention
> > in any draft, it would probably never be identified in any 
> conformance
> > statement, and an attaching UA to this concept might 
> therefore see behaviour
> > that was not expected.
> > 
> > I also see problems where, because it is not documented, 
> the impact of
> > interactions with other drafts may not have been assessed. 
> For example, is
> > there an impact on the privacy draft, such that the 
> identifiers passed using
> > the concepts of the privacy draft will never pass the 
> back-to-back UA? Do we
> > have problems with any headers that have been ciphered, 
> because we do not
> > wish to release them outside proxies?
> > 
> > I would therefore ask, if such a concept is meant to 
> legally exist, should
> > be not at least define it somewhere. (Thats assuming I 
> haven't missed it
> > somewhere!)
> > 
> > Keith Drage
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: drage@lucent.com
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> "This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip
> to subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body"
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.