Subject: RE: [SIP] Some idea on Stateful SIP Proxy for Card Service

From: William Marshall <[email-masked]>
Date: Wed, 31 Jan 2001 17:09:58 -0500 (EST)

> -----Original Message-----
> From: Jonathan Rosenberg <[email-masked]>
> To: "'William Marshall'" <[email-masked]>, [email-masked]
> Subject: RE: [SIP] Some idea on Stateful SIP Proxy for Card Service
> Date: Wed, 31 Jan 2001 13:56:46 -0500
> 
> > -----Original Message-----
> > From: William Marshall [mailto:[email-masked]]
> > Sent: Wednesday, January 17, 2001 7:47 AM
> > To: [email-masked]
> > Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
> > 
> > 
> > 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.

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.

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".

Bill Marshall
[email-masked]

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 31 Jan 2001 14:26:03 -0800 (PST)

I'm sort of on the fence about this one, but one
thing that bugs me -- maybe unduly -- is whether a
B2BUA must be party to the SDP and other end to
end kinds of things. If the answer is yes, I have
a lot of problems with any widespread usage of
B2BUA's if from nothing else an end to end privacy
standpoint.

There are certainly some things that are quite
appropriately modeled as a B2BUA -- an anoymizer
is an obvious situation where the e2e'ness is a
bug not a feature -- but I'm sort of skeptical
about the widespread use of B2BUA's. It seems like
it's just giving into the PSTN access tandem urge
which is... bad.

Live free [of network state], or die.

		 Mike

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 31 Jan 2001 17:48:22 -0500

The answering service model can also easily be accomplished by a
("virtual") UAS that is parallel-forked in the proxy. Thus, even for
those services, a B2BUA is not strictly necessary.

B2BUA, like proxies, can, but don't have to modify SDP. Proxies serving
as part of NAT ALGs may need to, for example.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs