Subject: [SIP] Back-to-back UAs

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 16 Jan 2001 12:57:05 -0000

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: [email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: William Marshall <[email-masked]>
Date: Tue, 16 Jan 2001 10:47:31 -0500 (EST)

I think there is a simple solution to the documentation of back-to-back-UAs.

SIP RFC2543 defines the protocol between a client and server, UAC and UAS.

The UAS may not be able to satisfy the request by itself.  It may need to
consult with other devices or other servers.  If it uses a protocol such
as H.248/MEGACO/MGCP/TGCP/etc to do that, it is just a UAS.  But if it uses
SIP as the protocol for communicating with the other device or server, it
then includes a UAC - making it a back-to-back-UA.

The proxy server, redirect server, and others are then just profiles of
the B2BUA.  So if the B2BUA meets the restrictions imposed by the profile
definition, then it gets the title of proxy (or redirect server, or ...).

So, in the same way that a forking proxy can send out multiple INVITEs
in response to a single INVITE from the originator, the UAC initiating
the whole session could also send out multiple INVITEs, and deal with
the multiple responses, and send a CANCEL when it gets a 200-OK from
one branch, etc.  This makes a forking proxy nothing special beyond
a normal UAC.

All the rules for forwarding responses can follow from this model.
The stateful proxy generating a 100 response, and absorbing a received
100 response; the stateless proxy forwarding a 100 response; the final
destination sending a 180/183/200 instead; all are just profiles of
allowable UAC-UAS interactions on all the separate interfaces.

Since there was discussion in San Diego about restructuring the RFC,
I believe this would be a direction to simplify all the complexities
in 2543 today.

Bill Marshall
[email-masked]

-----original message-----
From: "Drage, Keith (Keith)" <[email-masked]>
To: "'SIP discussion list'" <[email-masked]>
Subject: [SIP] Back-to-back UAs
Date: Tue, 16 Jan 2001 12:57:05 -0000

Keith Drage

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 17 Jan 2001 18:24:25 -0800

Another fail-safe approach ....

As much as everybody hates the header, B2BUA's can make good use of
Max-Forwards. It will at least limit the number of loops that are possible.

Deterministic loop detection may not always be possible when two B2BUA's are
involved. However if the B2BUA decrements the Max-Forwards value each time a
call passes through it (or adds the header if it wasn't present on the input
side) then run-away looping is prevented.

Cheers,

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. -- 

		-----Original Message-----
		From:	Cary FitzGerald [mailto:[email-masked]]
		Sent:	Thursday, January 18, 2001 1:15 PM
		To:	Rick Dean
		Cc:	[email-masked]
		Subject:	Re: [SIP] Back-to-back UAs

		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
		> [email-masked]
		>
		> On Tue, Jan 16, 2001 at 12:57:05PM -0000, Drage, Keith
(Keith) wrote:
		> ----- 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 [email-masked]
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 [email-masked]
with
		"subscribe sip-implementors" in the body.

---

From: Peter Mataga <[email-masked]>
Date: Thu, 18 Jan 2001 09:57:06 -0500

> From: Rick Dean [mailto:[email-masked]]
> Sent: Tuesday, January 16, 2001 12:37 PM
> To: [email-masked]
> I apologize.  Back-to-back UA is another name for Rosenberg's

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
> routing.  A fragile gateway may need a SIP wrapper/firewall.  etc.
> 
> On Tue, Jan 16, 2001 at 12:57:05PM -0000, Drage, Keith (Keith) wrote:
> "This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> to subscribe to it, send mail to [email-masked] with

_______________________________________________
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 [email-masked] with
"subscribe sip-implementors" in the body.