RE: [SIP] Back-to-back UAs

["Fairlie-Cuninghame, Robert" <[e-mail]>]

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:[e-mail]]
		Sent:	Thursday, January 18, 2001 1:15 PM
		To:	Rick Dean
		Cc:	[e-mail]
		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
		> [e-mail]
		>
		> 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: [phone]
		> > Email: [e-mail]
		> >
		> > _______________________________________________
		> > SIP mailing list
		> > [e-mail]
		> > 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 [e-mail]
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 [e-mail]
with
		"subscribe sip-implementors" in the body.