Subject: RE: [Sip] B2BUA & Max-Forwards

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Tue, 3 Dec 2002 16:07:55 -0500

inline [RRR]

-----Original Message-----
From: Pete Cordell [mailto:[email-masked]]
Sent: Tuesday, December 03, 2002 12:44 PM
To: [email-masked]
Subject: [Sip] B2BUA & Max-Forwards

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.

[RRR] It depends. Proxy MUST abide by its own rules as specified in RFC 3261. Similarly, UAs also MUST need to obey all SIP rules. These two (i.e., Proxy and B2BUA) act independently as per their SIP rules. The question then comes: How do people build services/applications that have the dependency between B2BUA and proxy function? SIP does not define these rules. That is why, people are coming to the conclusion let there should an informational RFC in defining B2BUA functionalities along with call flows (as Brain and others pointed out).

Any comments?

Pete.

_______________________________________________
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: [email-masked]
Date: Tue, 3 Dec 2002 17:26:45 -0500

I've been following two threads on the B'to'BUA definition and looks like 
both are pretty similar. So Here are my 2c:

* First, hope I am not offending someone by using BtoBUA instead of B2BUA. 
Beleive it or not, this '2' also is another source
of confusion for many people who seem to think '2' means the number two 
and implies '1 UA and 1 UAS' and therefore should
be really called BnBUA :-)

* How a  BtoBUA functions depends on what application is being implemented 
by it. Therefore, it does not make sense
to me trying to dictate or suggest how the BtoB associates one or more UAS 
instances with one or more UAC instances.

Therefore, a BtoB can only be defined as how its seen from the 'outside' 
-> i.e. as Vijay points out, 

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

* How the BtoB 'associates' one or more UAS instances with one or more UAC 
instances is dependent on an algorithm
which MAY associate using defined SIP protocol semantics or some other 
application level semantic which cannot be standardized.

* 'transparent' , 'semi-transparent', 'evil' <and other such terms> 
BtoBUAs reflect different algorithms that a BtoB
applies to a message after a inbound SIP message is received and before an 
associated SIP message is sent out.

* Therefore, trying to define what a BtoBUA should do with a message 
without defining what is the application that is using this
model seems like it will simply add to the confusion instead of trying to 
solve it.

In summary, as suggested by some  others, the only way to 'describe' what 
a BtoB may do, makes sense only if we define
call-flows with specific applications in mind. Trying to generalize an 
application-specific entity is going to confuse implementors
much more. 

In addition, these call flows should describe how one can achieve certain 
end services (specific)  instead of trying to project the message 
that this is how a BtoB should really work (generic). 

Atleast now implementors know they can do what they want with the B2B 
internally as long as external interfaces are standard.
While this may seem like sacrilege, it makes a lot of sense to keep it 
this way . Opinions on what should or should not be done
really depends on a particular scenario and deployment case (as proven 
time and again by 3G CSCFs as well as FCPs, media proxies et al).

regds
arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-997-0066

"Vijay K. Gurbani" <[email-masked]>
Sent by: [email-masked]
12/03/2002 04:11 PM

        To:     Pete Cordell <[email-masked]>
        cc:     [email-masked]
        Subject:        Re: [Sip] B2BUA & Max-Forwards

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: Adam Roach <[email-masked]>
Date: Tue, 3 Dec 2002 18:36:50 -0600

-----Original Message-----
From: Padma Suresh [mailto:[email-masked]]
 
> A B2BUA needs to propagate some of the headers received in a
> request/response to the other endpoint. Example: Require...

No. As emphatically as possible: NO. This is completely wrong,
and it appears to be a growing -- and dangerous -- misconception.

A B2BUA cannot transparently pass Require through. It must
understand and invoke the extension indicated.

  "The Require header field contains a list of option tags, described in
   Section 19.2.  Each option tag defines a SIP extension that MUST be
   understood to process the request."

A back to back user agent *is* a UAS, and *is* bound by this
provision.

Whether the UAC portion then turns around and imposes the same
requirement on the UAS it contacts is a local decision.

/a

---

From: [email-masked]
Date: Wed, 4 Dec 2002 08:51:13 +0100

Hello,

As it was already stated in this discusion thread, a B2BUA is an
*application* linking several UAs
As such, the behaviour of a B2BUA cannot be standardised.

Therefore, one cannot say that "A B2BUA needs to propagate some of the
headers received".
However, you can say that the application "x" behaves as a B2BUA, and that
the application "x" "needs to propagate" the a-header or the b-header etc.
for the needs of the application. This is the choice of the application,
that's all.

Best regards
Juan Carlos

Adam Roach <[email-masked]>@ietf.org on 04/12/2002 01:36:50

To:   "'Padma Suresh'" <[email-masked]>, [email-masked],
      [email-masked]
cc:   [email-masked]
Subject:  RE: [Sip] B2BUA & Max-Forwards

-----Original Message-----

/a

---

From: [email-masked]
Date: Wed, 4 Dec 2002 09:01:56 +0100

Hello,

The following text comes from RFC 3261, page 39
"A UAC MUST insert a Max-Forwards header field into each request it
originates with a value that SHOULD be 70"

Now, a B2BUA handles several UAs.
For a given UA, when behaving as UAC, the Max-Forwards header has to be
*initialised* by the UA. The RFC3261 recommends to use the value 70, but
this is not mandatory (to fixe the initial value of Max-Forwards, RFC3261
uses a SHOULD and not a MUST).

Therefore, a B2BUA acting as an application can freely choose for a UAC
which it is handling:
- Initialise Max-Forwards to 70, as recommended by RFC3261 for a UAC
- Initialise Max-Forwards with the value possibly received in a UA acting
as UAS.
- Initialise Max-Forwards to any other value, according to the application
definition

Once again, this is a question of application defintion.

Best regards
Juan Carlos

"Pete Cordell" <[email-masked]>@ietf.org on 03/12/2002 18:44:21

To:   <[email-masked]>
cc:

Any comments?

Pete.

---

From: Adam Roach <[email-masked]>
Date: Wed, 4 Dec 2002 14:55:15 -0600

Unless you were merely trying to agree at length with the
final paragraph of my previous message, I'm afraid that
you missed my point rather broadly.

I'll reiterate the main point concisely: a B2BUA is a UAS
attached to a UAC by application logic.

Read that carefully: Part of a B2BUA is a UAS.

That UAS is bound by RFC 3261 to certain behaviors.

One of those behaviors is honoring "Require" headers.

/a

> From: [email-masked] 
> [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2002 1:51
> To: Adam Roach
> Cc: 'Padma Suresh'; [email-masked]; [email-masked];
> [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Wed, 4 Dec 2002 15:03:06 -0600

> From: Vijay K. Gurbani [mailto:[email-masked]]
>
> I realize that there exist what are called 
> transparent B2BUAs that pass e2e headers through
> without operating on them.

And the point that I'm trying to make is that such network
elements are out of spec. The will run into interoperability
problems with compliant nodes.

/a

---

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Wed, 4 Dec 2002 17:43:12 -0500

Adam:

I would appreciate if you would clarify the following questions provided inline [RRR].

Radhika

> Is the UAS part in in BtoBUA is bound by the definition and rules 
> in 3261? 

Yes. I'll revise your drawing to more clearly show what is going on here.

UAC(a)--->UAS(b)===[application logic here]===UAC(b)--->UAS(c)

/a

[RRR] I like to know who has been the called party when UAC(a)) sent the INVITE message? Has it been UAS(b) or UAS(c)?

[RRR] If the answer is UAS(c), the question is: Why the call has been routed to UAS(b) by UAC(a) in the first place?

[RRR] If the answer is UAS(b), probably UAC(a) does not care.

---

From: Adam Roach <[email-masked]>
Date: Wed, 4 Dec 2002 16:58:14 -0600

> [RRR] I like to know who has been the called party when 
> UAC(a)) sent the INVITE message? Has it been UAS(b) or UAS(c)?

I'm going to first need to clarify your question.

The question I will answer is: "If an INVITE is sent through the
network described in this diagram, what is the value of the
Request-URI when UAC(a) sends it?"

The answer is: it depends. In general, yes, it will probably be
either of UAS(b) or UAS(c).

> [RRR] If the answer is UAS(c), the question is: Why the call 
> has been routed to UAS(b) by UAC(a) in the first place?

The most obvious of several plausible answers is: UAC(a)
has UAS(b) configured as a local outbound proxy.

> [RRR] If the answer is UAS(b), probably UAC(a) does not care.

About what?

/a

---

From: "Paul Long" <[email-masked]>
Date: Wed, 04 Dec 2002 18:37:13 -0500

Adam,

FWIW, a B2BUA operates identically in this regard to an H.323 routing 
gatekeeper. The gatekeeper must contain H.323 endpoint functionality 
facing each of the two "real" endpoints with "application logic" in 
between the two functional endpoints, although this is not made 
explicit in any of the Recommendations. Vendors have wedged all sorts 
of applications in between these two virtual endpoints within the 
gatekeeper. Interestingly, some H.323 vendors have undergone the same 
initial naivete as some of the posters on this reflector. The bottom 
line is that you must fully terminate the connections on both sides and 
not simply pass everything or even selectively some things through and 
hope for the best.

Paul

---

From: "Padma Suresh" <[email-masked]>
Date: Thu, 05 Dec 2002 00:16:34 +0000

For UAC (a) UAS (c) is the intended called party in the call. We have to define the intended party in a call when a B2BUA is involved. B2BUA IS an intermediate network element. It acts as some kind of a controller for a domain. It is not the called party in any call.

Regards

Padma

>From: Adam Roach

>To: "'Roy, Radhika R, ALASO'" , Adam Roach

>CC: [email-masked]

>Date: Wed, 4 Dec 2002 16:58:14 -0600

>Use [email-masked] for new developments on the application of sip

Add photos to your e-mail with MSN 8. Get 2 months FREE*.

---

From: Adam Roach <[email-masked]>
Date: Wed, 4 Dec 2002 21:58:17 -0600

> From: Nicky Song [mailto:[email-masked]]
> 
> > From: Kedar Patil [mailto:[email-masked]]
> > 
> > > This discussion raises one more doubt for me, pls. clarify. 
> > >
> > > UA1------->BtoBUA---------->UA2 
> > >
> > > Is the BtoBUA a SIP endpoint from UA1's point of view?
> > 
> > Yes.
> > 
> I'm confused. Isn't the "BtoBUA" a concept of the combination 
> of UACs and UASs? I think from the UA1's point of view, it 
> doesn't know whether its peer is a B2BUA or a normal single UA. 

Yep. It doesn't know whether its peer is a B2BUA or a "normal" UA.
So, it's a SIP endpoint from UA1's point of view.

It's not clear to me where the confusion comes in.

/a

---

From: [email-masked]
Date: Thu, 5 Dec 2002 10:34:44 +0100

Hello,
Fully agree with you.
Indeed, that's what should be explicitly added to the B2BUA definition in
3261, to avoid confusion:
"Anything that deviates at all from proxy rules will need to be a b2bua and
follow b2bua rules"
"...a b2bua depends entirely on the application logic"
All the debate is around these two notions.
Best regards
Juan Carlos

Jonathan Rosenberg <[email-masked]>@ietf.org on 05/12/2002
07:37:05

To:   Adam Roach <[email-masked]>
cc:   "'Phil Reynolds'" <[email-masked]>, [email-masked]
Subject:  Re: [Sip] B2BUA & Max-Forwards

inline.

Adam Roach wrote:
> From: Phil Reynolds [mailto:[email-masked]]
>
>
>>Now your back to restricting what I can and can't do in an
>>intermediary. It can't be a B2BUA 'cos it doesn't need to
>>honour require headers (the UA at the other end does that,
>>if they were meant for my intermediary then they would be
>>proxy-require?), and it can't be a proxy 'cos of the rules
>>about not changing the body so what is it?
>
>
> Broken.

Adam is correct.

>
> The restrictions placed on nodes by 3261 (which I'm merely
> reiterating, not imposing) aren't an authoritarian attempt
> at unnecessary proscription. They serve a purpose.
>
> I'll describe one of the (several) purposes that applies
> to the situation you propose.
>
> One of the things that UAs are required to be able to do is
> sign and/or encrypt the bodies and/or some subset of the
> headers to ensure confidentiality and/or integrity. The
> protocol places restrictions on various nodes to ensure
> that this can be done. Your box is broken precisely because
> it interferes with these abilities (or, more precisely,
> these abilities interfere with it).

Let me add some more here.

Anything that deviates at all from proxy rules will need to be a b2bua
and follow b2bua rules, including processing of Require. There is no
black-or-white here. Let me give some examples.

Lets say my b2bua is a proxy in all ways, BUT it happens to muck with
SDP to enable firewall traversal. Surely then it can ignore Require,
right? WRONG. Lets say I define extension foo, which means "the content
of this SDP is not what it seems - look at this header to instead find
the real port/address for media". This extension needs a Require
(because only a UA ever looks at bodies), but not a Proxy-Require,
because proxies don't. Thus, your almost-a-proxy will fail in odd ways
because it has ignored Require when it shouldn't have.

Indeed, for any operation prohibited to a proxy, but allowed for a UA, I
can come up with an extension, indicated in a Require header, that would
need to be understood by a b2bua which breaks the proxy rules and
performs this operation. Indeed, the rules on what is a UA, and what is
a proxy, are meant precisely to help define what goes in Require, and
what goes in Proxy-Require.

Whether or not Require gets passed on by such a b2bua depends entirely
on the application logic.

-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: [email-masked]
Date: Thu, 5 Dec 2002 10:44:44 +0100

Adam,

I don't think there is any disagreement.

I said that "However, you can say that the application "x" behaves as a
B2BUA, and that the application "x" "needs to propagate" the a-header or
the b-header etc. for the needs of the application. This is the choice of
the application"
So, I wanted to stress the fact that once again the behaviour of the B2BUA
is depending on the application logic.

Strictly speaking, I should have not said that the "application "x" needs
to propagate" the a-header, etc.
Instead, one should say that the application "x" choice is to generate the
a-header on the UAC side with the same content of the a-header received in
the UAS side.
This means that the SIP dialog on the UAS side is terminated and that the
B2BUA is generating another dialog on the UAC side.
The criteria used by the application "x" to fill the a-header are strictly
depending on the application logic, and this can be applied to any SIP
header.

Best regards
Juan Carlos

Adam Roach <[email-masked]> on 04/12/2002 21:55:15

To:   Juan-Carlos ROJAS/FR/ALCATEL@ALCATEL, Adam Roach
      <[email-masked]>
cc:   "'Padma Suresh'" <[email-masked]>, [email-masked],
      [email-masked], [email-masked]
Subject:  RE: [Sip] B2BUA & Max-Forwards

---

From: "James Undery" <[email-masked]>
Date: Thu, 5 Dec 2002 17:29:27 -0000

Pete,

By sheer coincidence at the time I wrote that email I was writting some code to access a media server directly, via a B2BUA ;). Although adding Max-Forwards wouldn't hurt, I could absolutely guarantee the request wouldn't loop so just left the default value in from our "Message Factory". The fact that there is no general B2BUA is my whole point, you need the Max-Forwards to be strictly decreasing across your B2BUA, I don't and can guarantee I don't and still have both sides conform to rfc3261 without risk of looping.

Despite actually using B2BUAs I'll have to add my voice to the "remove all references to B2BUAs" camp. Personally I found the definition easy to comprehend (even the name tells you what it is), but it is obviously a source of confusion; also letting people build two UAs that conform to the spec and linking them together by whatever innovative applications they can think of doesn't strike me as an area suitable for standardisation. 

James

> Sent: 05 December 2002 15:48
> To: James Undery; [email-masked]
> James,
> Thanks for your comments.
> 
> I think in general you CAN'T guarantee that an element you 
> route to won't
> proxy (or be a B2BUA).  And therefore loop detection is a problem.
> 
> Propagating Max-Forwards even when you know the precise 
> routing should not
> cause you any problems.
> 
> Pete.
> 
> ----- Original Message -----
> From: "James Undery" <[email-masked]>
> To: "Pete Cordell" <[email-masked]>; "Dean Willis"
> <[email-masked]>; <[email-masked]>
> Sent: 05 December 2002 13:21
> Hi,
> I think your confusion comes from mixing two email threads; the first
> statement in context says if a specific B2BUA demonstrates header
> transparency it doesn't change headers; the second statement 
> is about B2BUAs
> in general and says they can do whatever they want (without 
> commenting on
> the desirability of their actions).
> 
> Max-Forwards probably are an important case for your 
> particular application,
> in general they may not be required (e.g. routing to an 
> element you can
> guarantee not to proxy).
> 
> Your comment on Max-Forwards highlights well the difficulties faced in
> defining a B2BUA more specifically than the definition in 3261.
> 
> James
> 
> > Sent: 05 December 2002 12:10
> > To: Dean Willis; [email-masked]
> > 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.
> >
> > ----- Original Message -----
> > From: "Dean Willis" <[email-masked]>
> > To: "'Pete Cordell'" <[email-masked]>; <[email-masked]>
> > Sent: 05 December 2002 01:23
> > > > 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: [email-masked]
Date: Thu, 5 Dec 2002 18:50:08 +0100

Hello,

"I am at the point where I agree with the sentiment raised by others,
that we should remove the term b2bua entirely from the specification. It
has caused more confusion than anything else."

Yes, this is one possibility. An alternative (as I proposed in an earlier
mail) is to complete the current definition in 3261 saying explicitly that
:
1) A B2BUA handles two or more UAs, each one behaving as UAC/UAS, as
described in 3261 for UAs
2) The SIP protocol specification does not mandate for any behaviour of
such B2BUA, i.e. on how to "link" (or "concatenate") two or more UAs.

Best regards
Juan Carlos

17:16:52

To:   Pete Cordell <[email-masked]>
cc:   Adam Roach <[email-masked]>, "'Phil Reynolds'"
      <[email-masked]>, [email-masked]
Subject:  Re: [Sip] B2BUA & Max-Forwards

Pete Cordell wrote:
> This is correct.  A B2BUA can't blindly forward a request containing a
> Require header.
>
> The saving grace for a B2BUA is that it does not need to understand the
> extension in detail.  It just needs to know whether it can forward a
request
> that contains a given Require header.  This can be easily provisioned
using
> some sort of ASCII configuration file, and doesn't require any new code
etc.
> A B2BUA could even routinely download the list of acceptable Require
headers
> from some sort of server.  (A smart B2BUA could even post back a set of
> unknown Require headers that it has seen recently.)

This is a vast over-simplification.

As people have been saying over and over in this thread, there is no
such thing as a "generic b2bua" as you seem to be implying. What is
right in a b2bua depends entirely on what its doing. To be honest, I
can't think of any b2bua for which the processing you describe above is
sensible. As I mentioned in a previous note, a b2bua deviates from a
proxy by doing some featurs that are normally associated with a UA. That
b2bua will need to process extensions (i.e., implement them) that are
associated with that feature.

I am at the point where I agree with the sentiment raised by others,
that we should remove the term b2bua entirely from the specification. It
has caused more confusion than anything else.

-Jonathan R.

---

From: [email-masked]
Date: Thu, 5 Dec 2002 20:54:26 +0200

Hi, 

inline.

> described in 3261 for UAs

I don't get this.  Does two or more mean, for example, four?  And does that in turn make it a B2BB2BUA? ;)

The only minor clarification I think might be in order for RFC3261 is that it's not just a UAC/UAS concatenation, but a pair of UAC/UAS concatenations.

However, the fact that the traffic in this thread alone equals to a year's worth of emails on the SIMPLE list suggests that no clarification is enough clarification.

So I agree with the other people in that getting rid of the definition altogether is the best option.  After all, if it looks like a UA to the outside world, it must be a UA.

> such B2BUA, i.e. on how to "link" (or "concatenate") two or more UAs.

Yes, probably the reason why the definition for a B2BUA is also useless.

Cheers,
Aki

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 6 Dec 2002 09:40:17 -0600

I agree with Jonathan.  As mentioned earlier this week apparently, there is
already work underway by some individuals to write an informational draft
documenting BBUA scenarios/call flows. 

I'll keep my fingers crossed that the existence of such a document can save
us from another round of B2BUA discussions again in 3 months. 

Regards,
Mary.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, December 06, 2002 12:59 AM
To: Pete Cordell
Cc: David R. Oran; Dean Willis; [email-masked]
Subject: Re: [Sip] B2BUA & Max-Forwards

Pete Cordell wrote:
> 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."

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.

---

From: [email-masked]
Date: Mon, 9 Dec 2002 13:32:53 +0200

> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, December 05, 2002 6:17 PM
> To: Pete Cordell
> Cc: Adam Roach; 'Phil Reynolds'; [email-masked]

I agree. Just forget about this B2BUA thing. There are things called "Application Servers (AS)" that perform whatever service you wish to invent. And most importantly, they are UASs.

Think presence server. It is one type of AS. It receives SUBSCRIBE, on its UAS side, that is destined to a URI who's principle normally uses a terminal, and responds to them. Therefore needs to handle require-header.

This Presence Server may initiate a SUBSCRIBE of its own, from its UAC side, that is destined to the same user. Here we have a B2BUA, but I hate that name, so I say here we have an Application Server.

Think also presence list server. This is an example of one UAS to many UACs or one to many B2BUA. I like to call it Application Server.

So lets drop this term B2BUA and use Application Server instead. I think people understand this term better.

If 3GPP want every intermediary in the network to do something that is not SIP proxy compliant, then they better call it Application Server.

Regards,
Hisham

---

From: Kedar Patil <[email-masked]>
Date: Wed, 4 Dec 2002 17:26:47 -0600

> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2002 4:58 PM
> To: 'Roy, Radhika R, ALASO'; Adam Roach
> Cc: [email-masked]

Or most likely, when the INVITE request arrived at some outbound
proxy of UAC(a), it decided to route the request to UAS(b) as
a local polocy.

This is possible irrespective of Request-URI and To: field.

My 2-cents.

thanks,
= Kedar =

---

From: Kedar Patil <[email-masked]>
Date: Thu, 5 Dec 2002 12:01:26 -0600

Interesting.

What if a BtoBUA(UAS side) received a request with Max-forward=0?
A proxy would have responded with 483. I believe a B2BUA may not
do the same.

thanks,
= Kedar =

> Sent: Thursday, December 05, 2002 11:24 AM
> To: David R. Oran; Dean Willis; [email-masked]
> the Max-Forwards header from the incoming request to the 
> outgoing request in
> 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.
> 
>