I think the stateful proxy could well be realized as "scaled down" B2BUA
implementation that primarily implements routing and lookup logic with a
higher level of restriction being imposed by service logic control (via
primitives) and UAS-UAC interactions (via signals). The forking part is
not much different from UAC since both would have to maintain state to
handle multiple incoming responses. The advantage from implimentaion
persepective is that B2BUA could be provisioned and deployed as stateful
proxy where such a role is assumed (but the reverse is not true). In
this sense it a more generic service execution model. The service logic
control may/may not be implemented via CPL but for service control
execution B2BUA is required. However, if this model was to be
implemented fault tolerance levels would depend on the traffic exchanged
at the UAS-UAC interface, the implication of which is that stateful
proxy would operate at higher levels of tolerance. Regarding redundancy
mechnism to maintain state in B2BUA vs. stateful proxy it is not very
clear which are the scenarios that can lead to this?
-Gaurav
Subject:
Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
Date:
Thu, 01 Feb 2001 10:25:44 +0000
From:
Neil Deason <[EMAIL PROTECTED]>
Organization:
Ubiquity Software Corporation Limited
To:
William Marshall <[EMAIL PROTECTED]>
CC:
[EMAIL PROTECTED], [EMAIL PROTECTED]
References:
1
William Marshall wrote:
>
> > > P is clearly a back-to-back-UA, since it speaks SIP to
> > > both user B and terminal C. However, its need to initiate
> > > a BYE doesn't fit the profile of a proxy. Just a B2BUA.
> > >
> > > In looking at various enhanced services, it is not clear
> > > to me that a "stateful proxy" will ever exist. They will
> > > all be B2BUAs for some case or another.
> > >
> >
> > No.
> >
> > You only want to be a B2BUA if that is the only way. The
requirements for
> > fault tolerance and scale are much harder with a B2BUA (on part with
a UA,
> > not a surprise). Stateful proxies can record-route and insert vias
with
> > domain names, and the result is that these devices can still fail
and the
> > calls can be recovered by routing the request/response to an
alternate. Not
> > so for a B2BUA, which has state that now needs to be replicated in
some way
> > (I realize State header is another possibility, its still just a
form of
> > state replication).
> >
> > Many services require only a stateful proxy. Many personal mobility
services
> > fall into this category, as do all CPL types of services. This isn't
> > everything, but its a decent number.
> >
> > -Jonathan R
> I think I agree with all the points you make, but disagree with the
> conclusion.
>
> Consider a simple voicemail service, implemented by a service
provider.
> The UAS receives an INVITE, sends 180-Ringing, then 4xx/6xx and gives
up.
> The proxy changes the 4xx/6xx into a 302-Redirect with a Contact
header
> of the voicemail server.
>
> But, a proxy can't do this. So it is a B2BUA. There is nothing about
> state storage needed, nothing extra for fault tolerance and scale;
> in fact this "proxy" is probably simpler than most "stateful proxies".
> But its need to change the response from 4xx/6xx to 3xx makes it a
B2BUA.
This is not a B2BUA as it does not require a UAS|UAC
state machine. This is a stateful proxy operating in
the same way that it does to filter multiple responses
after forking. Where the 3xx arrives at the proxy
from is irrelevant.
> Second example is any kind of subscription-based service to the proxy.
> Subscriptions expire. The proxy, if it is maintaining any call state
> as a "stateful proxy", will want to terminate any pending connections
> rather than continue to provide free service. So it generates a BYE.
> Not a proxy any longer, now a B2BUA. But not any more complex than
> any other stateful proxy, (except possibly for remembering the Record-
> Route header value for the active sessions). The fault tolerance and
> scale problems are the same as the stateful proxy.
>
> I'm not familiar with CPL, so maybe those can be done with stateful
proxies.
> Can a CPL type of service re-write error responses, like a 4xx to a
3xx?
> Can a CPL type of service re-write header values, like a Contact
header
> for forwarding? Can a CPL type of service look at the SDP to pick an
> appropriate destination based on the media being requested? All
simple
> transformations, but all require a B2BUA.
Forwarding to voicemail on 4xx/6xx is trivial with CPL. It
can direct the proxy to send the INVITE on to the VM server,
this avoid having to send back a 3xx.
> Maybe I overstated the case by saying "a 'stateful proxy' will never
> exist". My suspician is that a typical session will have a proxy at
each
> end (providing service for the UAC/UAS), and several stateless proxies
> in the middle. My suspician is still that the proxy providing service
> to the endpoints will not meet the restrictions of a proxy, and will
> need to be classified a B2BUA. But this does not make this element
> any more complex than a "stateful proxy".
You have referred to this model before but never explained
what the additional stateless proxies in the middle are
needed for?
Also this is not the model that I recall seeing in the DCS
drafts. In that things like the privacy reqs that could be
better guaranteed through B2BUAs were being required of proxies.
Cheers,
Neil.
--
Ubiquity Software Corporation, UK http://www.ubiquity.net
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
