RE: [Sip] B2B UA definition

["Cullen Jennings" <fluffy@cisco.com>]

I think that a B2BUA should meet the requirements of a UAC on one side and a
UAS on the other. I am fine with it resetting max forwards and all the other
stuff you mention. If you consider a call from a UA to gateway that go
across the PSTN to another gateway to a UA, you realize the PSTN is one
large B2BUA. I don't think B2BUAs would benefit much from further definition
than it has today.

However, you could get me going about what a "transparent" B2BUA is :-)

Cullen

> -----Original Message-----
> From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Medhavi
> Bhatia
> Sent: Monday, July 29, 2002 8:51 PM
> To: sip@ietf.org
> Subject: [Sip] B2B UA definition
>
>
> Hi all,
>
> Very many times I have seen a discussion on B2B UA's end merely in a
> definition
> of a B2BUA:
>         "A back-to-back user agent (B2BUA) is a
>          logical entity that receives a request and processes it as a
>          user agent server (UAS).  In order to determine how the request
>          should be answered, it acts as a user agent client (UAC) and
>          generates requests.  Unlike a proxy server, it maintains dialog
>          state and must participate in all requests sent on the dialogs
>          it has established.  Since it is a concatenation of a UAC and
>          UAS, no explicit definitions are needed for its behavior."
>
> However I believe this is quite incomplete. For example:
>
> 1) A B2BUA behaves similar to a proxy in that it must maintain
> "timer C" on
> outgoing transactions - which is unlike a UAC.
> 2) It SHOULD maintain max forwards on request in/requests out basis.
> Moreover
> it SHOULD have a defined relationship between incoming and outgoing
> requests.
> The way the definition goes, the outgoing request can have completely new
> headers,
> which eventually will cause a problem in loop detection/ policy and
> configuration
> at a remote destination. Clearly there may be reasons for new headers, but
> certain
> headers should be maintained for proper SIP network operation.
> 3) It has a notion similar to a response context of a proxy, and thus of
> forking
> requests
>  etc etc...
>
> I believe that the SIP rfc describes a "server" role as a
> stateful/stateless
> proxy and
> completely specifies it. However a "server" can also be implemented as a
> B2BUA,
> so it should talk some more about it, or the requirements should
> be spelled
> out
> somewhere. A completely loose definition might just lead to deployment
> problems
> in future.
>
> -Medhavi.
>
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip