Subject: RE: [Sip] B2BUA

From: William Marshall <[email-masked]>
Date: Mon, 2 Dec 2002 14:59:55 -0500 (EST)

Juan Carlow wrote, in part:
> 2.- UAs are not "concateneted" in the B2BUA, but they are linked by some
> application logic which is by definition, a non-standard element. This is
                    ~~~~~~~~~~~~~~~~~~~~~~
> the key element that should be precised in the RFC3261 to avoid confusion.

This is the exact point that I disagree with.  

The entity that we are describing receives SIP requests on one side,
processes them internally, and generates SIP requests on the other side.
Responses are handled in the reverse path.  I don't think there is any
disagreement so far.

There is wide variation possible in the algorithms used internally
to process the requests and responses.  But they are all B2BUAs.
One of the possible algorithms is defined in section 16 of rfc3261.
Many other possible algorithms exist, and are not covered in rfc3261.
The definition needs to cover all of these possibilities, not just
the non-standard ones.

At some point we need to define exactly what the requirements are
for the internal processing algorithm, such that new services will
work through it.  Section 16 is one example.  But I don't think we 
are ready yet to generalize this.

Bill Marshall
[email-masked]

-----original message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 02, 2002 11:20 AM
To: Barnes, Mary [NGC:B602:EXCH]
Cc: [email-masked]
Subject: RE: [Sip] B2BUA

Hello,
Well, if from times to times there are questions and debates on a given
subject, it is surely because the definition needs to be improved, or at
least clarified.

"Since it is a concatenation of a UAC and UAS"
1.- A B2BUA is not a "concatenation of a UAC and UAS", but a collection of
several UAs (two, three or more), which behave individually as UAS or UAC
according to SIP rules (and are seen as such from the outside of the
B2BUA). For example, a conference server where all the participants send
INVITE messages to the server could be made with UAS only (do note that
this is strictly a matter of application definition, and cannot be subject
to standardisation).
2.- UAs are not "concateneted" in the B2BUA, but they are linked by some
application logic which is by definition, a non-standard element. This is
the key element that should be precised in the RFC3261 to avoid confusion.
You cannot define the behaviour of a B2BUA, you can define only the
behaviour of each UA (and this is actually done by the SIP specification).

Hoping this answers your questions
Best regards
Juan Carlos

_______________________________________________
Sip mailing list  https://www1.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: "Cullen Jennings" <[email-masked]>
Date: Mon, 2 Dec 2002 22:12:17 -0800

One problem is that people often want a definition of what a B2BUA can or
can not do. It is not clear that it is possible to define a SIP speaking
systems this way.

What function can a proxy provide? Well just about anything as long as the
responses it sends are compliant with the constraints of a thing called a
proxy in 3261. How a proxy determines the next hop for an requested targeted
to it is completely up to the proxy and not specified in SIP.

We run into the same problem with defining what can a B2BUA do. The answer
is, well lots of things. It can handle multiple different dialogs at the
same time and the message sent on each dialogs will meet the constraints of
a what 3261 calls a UA. How the message on one dialog relate to the message
on another dialog is completely up to the B2BUA and not specified in SIP.

I recognize this is not a very satisfactory way to help people understand
B2BUA so I have a proposal. Trying to have an all encompassing functional
definition of a B2BUA is very hard. However, it is possible to have call
flows that show some common application of B2BUA. Perhaps even form some sub
classification of a B2BUA that specify how a given class of B2B will
interact with messages.

If you think about it, this is similar to the SIP to QSIG mapping. We say
how messages on one side will get mapped to message on the other side. It's
not a normative part of SIP.

I think a few folks are already working on this - perhaps we will get a
whole taxonomy of different variants of the B2BUA beast.

Cullen

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 3 Dec 2002 17:44:21 -0000

One issue that the recent B2BUA discussion has raised in my mind is what a
B2BUA (whatever its decided that should be) should do with Max-Forwards.

This may have been discussed before, but while RFC 3261 says a B2BUA is a
back to back UAS / UAC, and the coupling is not specified in the RFC,
perhaps it ought to say that the max-forwards parameter MUST be propagated
from the incoming request to the outgoing request using the same rules as a
regular proxy.  This would seem helpful for the avoidance of loops.

Any comments?

Pete.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 03 Dec 2002 15:11:37 -0600

Pete Cordell wrote:
> from the incoming request to the outgoing request using the same rules 
> as a regular proxy.  This would seem helpful for the avoidance of loops.

I have a feeling that specialized handling of headers for B2BUAs is yet
another nightmare in the making.

A B2BUA is a UA, period.  So long as the request made it to one half
of the B2BUA before Max-Forwards reached 0, the protocol constraints
on that request have been satisfied.  What the other half of the
B2BUA wants to do with the Max-Forwards header is entirely up to it.

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 3 Dec 2002 18:44:06 -0800

A related question to this was how to stop routing loops that included some
PSTN hops. One solution to this was to make sure that as a call was passed
from SIP to SS7 there was a mapping of the number of hops. A trivial 1:1
mapping would be unlikely to work.

I really don't really care that much if something like this is documented or
not but I imagine that some devices will do it to stop routing loops that
eat infinite amounts of resources.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Pete
> Cordell
> Sent: Tuesday, December 03, 2002 9:44 AM
> To: [email-masked]
> Subject: [Sip] B2BUA & Max-Forwards
>
>

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 4 Dec 2002 19:23:23 -0600

> One issue that the recent B2BUA discussion has raised in my 
> mind is what a B2BUA (whatever its decided that should be) 
> should do with Max-Forwards.

It does the same thing as it does with any other header or body part,
which is the same thing that ANY 500-pound gorilla does to somebody's
body parts -- whatever it wants.

What you're asking is "what is the transparency of this node with
respect to max-forwards", which is "#4 -- Header Transaprency" in my
top-10 list. The specification of a back-to-back user agent doesn't
mandate any level of transparency on this or any other header.

--
Dean

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 5 Dec 2002 12:38:00 -0000

Cullen,

That's an interesting question.  But I don't think that SIP to SS7 being a
difficult problem should stop us recommending simple behaviour that can help
protect the integrity of SIP networks where B2BUAs are involved.

Pete.

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 5 Dec 2002 12:09:36 -0000

Dean,

Firstly, your statement that "The B2BUA doesn't change headers that transit
it." seems inconsistent with the statement "It does the same thing as ...
ANY 500-pound gorilla does".  I don't understand.

Secondly, I think max-forwards is a special case.  It is important for the
protection of SIP systems as it prevents loops.

Indeed, there is a major difference between a UAS and a B2BUA and that is
that the former terminates a request, and the latter terminates a request
AND ALSO forwards an associated request (or more).  The impact of this
difference should be covered in the spec in the interests of protecting
other SIP systems.

Pete.

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 05 Dec 2002 09:02:29 -0500

--On Thursday, December 05, 2002 12:09 PM +0000 Pete Cordell 
<[email-masked]> wrote:

> Dean,
>
> Firstly, your statement that "The B2BUA doesn't change headers that
> transit it." seems inconsistent with the statement "It does the same
> thing as ... ANY 500-pound gorilla does".  I don't understand.
>
Once a dialog is terminated at a UAS it's up to the application to do loop 
prevention. SIP is not involved any more. The application could compute a 
value of Max-forwards for initiating outgoing calls based on incoming calls 
which preserves the "strictly decreasing" invariant, or alternatively it 
could just use the default MAx-Forwards in outgoing requests and execute a 
contant memory loop suppression algorithm such as Knuth's even-odd 
iterator. In either event the SIP spec(s) need say nothing about this.

> AND ALSO forwards an associated request (or more).
I disagree. A UAS is a UAS. It's behavior is completely specified by 
RFC3261 (unless there's a hole in the spec of course...). What it means to 
originate (NOT FORWARD!!!!) an "associated request" is completely 
application dependent. If I program my child's phone to initiate a SIP call 
to my surrepititious recording device every time it receives a call and 
give that device first chance to over-ride policy of the child's phone is 
the phone a B2BUA? Yes, no, maybe so, but who cares? Tell me what the 
applciation is and I can write some specs for that application and how it 
has to originate, terminate and process SIP transactions to do that 
application.

I think the botom line is that there is not a single, well defined 
appliation that one can point to and say "that's a B2BUA".

> The impact of this
I disagree.

>> mandate any level of transparency on this or any other header.

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 5 Dec 2002 17:24:08 -0000

Dave,

To save your disagreeableness, can we say something like:

"A B2BUA MUST perform loop prevention.  One way to do this is to propagate
the Max-Forwards header from the incoming request to the outgoing request in
the same way that a proxy does."

It's the loops that I'm worried about, not the Max-Forwards per se.

This addresses my concern, and I think James' and possibly yours.

Pete.

----- Original Message -----
From: "David R. Oran" <[email-masked]>
To: "Pete Cordell" <[email-masked]>; "Dean Willis"
<[email-masked]>; <[email-masked]>
Sent: 05 December 2002 14:02
Subject: Re: [Sip] B2BUA & Max-Forwards

---

From: Michael Thomas <[email-masked]>
Date: Thu, 5 Dec 2002 09:54:56 -0800 (PST)

> It's the loops that I'm worried about, not the Max-Forwards per se.

   And prevent me from building a SIP Cyclotron?

   Hell no.

	Mike

---

From: David Oran <[email-masked]>
Date: Thu, 05 Dec 2002 14:10:34 -0500

--On Thursday, December 05, 2002 5:24 PM +0000 Pete Cordell 
<[email-masked]> wrote:

> the Max-Forwards header from the incoming request to the outgoing request
> in the same way that a proxy does."
>
I don't understand what it means to have normative language for a beast 
which is fundamentally undefined. Suppose I write a piece of code which 
accepts SIP requests, issues tachyon commands to alpha centauri, and 
meanwhile receives routing instructions from a chronosynclastic 
infundibulum (for the unintiated, that is a device which effects reverse 
causality based on the message to alpha centauri whose response would not 
normally arrive for 7.8 years). It then uses those routing instructions to 
formulate an outbound SIP request to the destination received through the 
chronosynclastic infundibulum.

Question: is this application a B2BUA and hence required to have a 
Max-Forwards value in the request whose value is strictly less than the 
value received in the SIP request? Beats me.

> It's the loops that I'm worried about, not the Max-Forwards per se.
There are many ways to suppress loops. Using application semantics is 
actually safer than lower-layer protocol machinery because of the hazards 
introduced by protocol translation (e.g. the PSTN hop case mentioned 
earlier, or a SIP<->H.323 conversion somewhere else).

> This addresses my concern, and I think James' and possibly yours.
Sorry, not mine. From where I sit, the less said about B2BUAs the better, 
including asymptotically toward zero.

Cheers, Dave.

>> Once a dialog is terminated at a UAS it's up to the application to do
>> loop prevention. SIP is not involved any more. The application could
>> compute a value of Max-forwards for initiating outgoing calls based on
>> incoming
> calls
>> could just use the default MAx-Forwards in outgoing requests and execute
>> a contant memory loop suppression algorithm such as Knuth's even-odd
>> RFC3261 (unless there's a hole in the spec of course...). What it means
>> to originate (NOT FORWARD!!!!) an "associated request" is completely

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Dec 2002 01:58:54 -0500

> the same way that a proxy does."

A statement like this is completely out of scope for rfc3261. It might 
be a reasonable statement to make in some kind of application document 
that describes a particular type of b2bua. However, it makes no more 
sense to say this in RFC 3261 as it would be to discuss the ways in 
which to build a focus or a 3pcc controller (both of which are also 
informational, by the way).

I can't resist pointing out that much of this is deja vu. Folks may 
recall heated discussions in Adelaide, where there was a bof (I think) 
that wanted to have a working group to specify SIP to H.323 conversion. 
THe same arguemtns that were made there are being made here; its an 
application level issue, there are many ways to do it, don't stifle 
creativity, etc. In fact I recall that Dave was, as always, quite 
vociferous on these points.

The eventual conclusion in the h323/sip conversion case was to write an 
INFORMATIONAL RFC that documents reasonable practices in building such a 
device. I believe the same logic and conclusions apply here. If folks 
have a particular type of b2bua application they are fond of, please 
feel free to write up your implementation advice and I am sure sipping 
would consider whether or not it would make a useful informational RFC.

However, it is completely inappropriate to ever make such application 
logic normative, and even more inappropraite for such wording to be in 
rfc3261.

Anyway, I too am tired of this thread. I think, in fact, there is 
"rough" consensus to remove the definition of b2bua entirely from 
rfc3261 in its next revision (which is quite some time in the future 
anyway). However, I'll let the chairs decide that.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 6 Dec 2002 15:33:16 -0000

Jonathan,

As principle author of the document you obviously have a major say on
what's in scope or not.

However, I would argue that RFC 3261 says much about what a proxy must do to
be a proxy.  However, it does not do it in complete detail.  For example, it
does not say that it must do a SQL query to find a user records, or ask the
Ferengi.  It says enough about the proxy to make it functional from a SIP
point of view.

I'm only arguing that the spec should have the same scope for B2BUAs.  There
are actually less SIP issues for a B2BUA than there are for a proxy.
However, I think prevention of loops is one thing it should say, as this has
a direct impact on the integrity of SIP systems, and this must surely be a
primary concern of the RFC.

If there is no need to say something about it for B2BUAs, then I see no need
to say anything about it for proxies!

---

As for removing the definition of B2BUA from the RFC, that may be a sensible
thing to do.  The upshot of doing that is that people might start calling
what is now a B2BUA, a proxy.  This wouldn't be unreasonable as the
functionality of a B2BUA is analogous to an FTP proxy.

How about the following as a definition of a B2BUA?  Or is it too loose?

"Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical
entity that has one or more egress SIP dialogs associated with an ingress
SIP dialog, but does not conform to the definition of a proxy.  The manner
in which the ingress and egress dialogs are associated is purely an
implementation issue and outside the scope of this document.  When it
receives a request it appears from an external point of view to process the
request as if it were a user agent server (UAS).  On a transaction by
transaction basis, to determine how the request should be handled it may
generate and send SIP requests such that from an external point of view it
appears as one or more user agent clients (UAC), or it may respond to the
request locally."

Pete.

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Pete Cordell" <[email-masked]>
Cc: "David R. Oran" <[email-masked]>; "Dean Willis"
<[email-masked]>; <[email-masked]>
Sent: 06 December 2002 06:58
Subject: Re: [Sip] B2BUA & Max-Forwards

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 6 Dec 2002 13:36:42 -0000

Please see inline...

----- Original Message -----
From: "David Oran" <[email-masked]>

> value received in the SIP request? Beats me.

If you read what I said, you would see that the cyborg (or whoever) didn't
actually have to know about Max-Fowards.  They could use the colonic drive
if they wished to.

> earlier, or a SIP<->H.323 conversion somewhere else).

Which is what I was agreeing to.

> including asymptotically toward zero.

But not quite zero then.  Mentioning taking steps to prevent loops doesn't
seem much.

> >> > Secondly, I think max-forwards is a special case.  It is important
for
> > the
> >> > Indeed, there is a major difference between a UAS and a B2BUA and
that
> > is