Re: [SIP] Back-to-back UAs

Cary FitzGerald <caryfitz@cisco.com> Thu, 18 January 2001 02:15 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 VAA01756 for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 21:15: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 C5E4C44391; Wed, 17 Jan 2001 20:16:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 4BC2D4433C for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 20:15:33 -0500 (EST)
Received: from nomsg.cisco.com (nomsg.cisco.com [171.71.163.24]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA10246; Wed, 17 Jan 2001 18:15:29 -0800 (PST)
Received: from cisco.com (dhcp-171-71-147-127.cisco.com [171.71.147.127]) by nomsg.cisco.com (Mirapoint) with ESMTP id AAD14821 (AUTH caryfitz); Wed, 17 Jan 2001 18:52:06 -0800 (PST)
Message-ID: <3A6651A5.4F7F92ED@cisco.com>
From: Cary FitzGerald <caryfitz@cisco.com>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rick Dean <siplist@fdd.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Back-to-back UAs
References: <20010116113721.A26496@fdd.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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: Wed, 17 Jan 2001 18:15:01 -0800
Content-Transfer-Encoding: 7bit

Thinking about the 3pcc draft, it occurs to me that by not recording the fact that
we have passed through a 3pcc node (a 3pcc via, sort of), the 3pcc network element
is discarding useful information.  The same loop detection methods in standard SIP
could be reused.  This sort of looping is a could become a common problem in
cross-domain routing.  This sort of via is worth hiding.

Cary.

Rick Dean wrote:

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