Subject: Re: [Sip] Re: B2BUA draft proposal

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

Hello,

"In particular, while recognizing that little can be said about the
behavior of the most general form of B2BUA, it seems possible to classify
different kinds (sub-classes)"
Good idea to give examples of implementing an application using a B2BUA,
this can illustrate what could be done with a B2BUA (even if is very likely
that this will generate a lot of debate).
But please *do not* classify B2BUA, because there will always be a new
application not fitting in your classification.

Best regards
Juan Carlos

Hal Purdy <[email-masked]>@ietf.org on 03/12/2002 21:45:21

Sent by:  [email-masked]

To:   SIP Mailng List <[email-masked]>
cc:
Subject:  [Sip] Re: B2BUA draft proposal

> This thread is, hopefully reaching an end (with an agreement to
> do some examples with call flows).  However, the above statement
> is yet one more example of the confusion people have with B2BUA.

A group of us have been contemplating writing an informational
draft in sipping that would provide examples with call flows among other
things.
We floated this idea with several people at the recent IETF meeting.

In particular, while recognizing that little can be said about the
behavior of the most
general form of B2BUA, it seems possible to classify different kinds
(sub-classes)
of B2BUAs and then take a stab at specifying "suggested" behavior for
these sub-classes
by means of call flows. To be clear, we recognize that any
"specification" of behavior
of any sort of B2BUA would not be normative and would perhaps ultimately
take the form of a BCP.

Thinking to start things simply, we considered looking at the case of a
"transparent" B2BUA with a UAC on one side and a UAS on the other. While
not
functionally interesting, this case would provide a baseline of
behavior to serve as a launching point for more interesting B2BUAs types.
Following an examination of the "transparent" B2BUA, we would hopefully
move
on to looking at a B2BUA that serves as a firewall gateway.

Naturally, my colleagues and I welcome feedback on this proposal.

I don't know if it's appropriate to move any discussion of this proposal
to the
sipping list since it seems to belong there. I'm happy to follow the
group consensus
regarding where the discussion should be held.

Hal Purdy

_______________________________________________
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

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Wed, 04 Dec 2002 17:29:04 +0200

Folks,

If my UA receives a request, it uses an API to interact with me thru the
GUI. Based on that, it will send a response.

If my SIP-PSTN gateway receives a request, it uses ISUP, Q.931, or what
have you to interact with me. Based on that, it will send a response.

If my SIP entity happens to use SIP instead of an API or ISUP to
interact with whoever of whatever it has to interact with, we call it
"B2BUA". Based on that, it will send a response. That simple. Every time
you drive your state machinery using SIP to communicate with another
entity, you are a B2BUA.

I do not think we need more definitions or examples. Things that can be
done with a B2BUA depend on how innovative are the engineers in your
company. We should not standardize them.

About a draft with B2BUA examples, it might be valuable to point out at
some stupid things you do not want to do because they may be harmful for
the network... but providing an exhaustive list of B2BUA types is a
terrible idea.

Regards,

Gonzalo