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

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 1 Feb 2001 09:40:59 -0000

William Marshall wrote:
> 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.

I disagree with this.  I think it is fine for a proxy to pull
responses "out of the air".  What's it's not allowed to do is
modify fundamental transaction-identifying headers (From, To,
Call-ID, CSeq, Via immediately spring to mind).

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

Okay, I would agree that this -- the way that you describe it,
anyway -- cannot be done without a B2BUA.  However, Session
Timer might go some way towards achieving similar goals....

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

Base CPL does not offer a way to describe how to achieve all of
these things; however, I would say that it is still acceptable
for a proxy to do any of them.

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

That maybe so.  I must admit that I'm not sure knowing that
something is a proxy or a B2BUA is helpful anyway.  I don't
really care what it is, as long as it performs the services
I think are neat.

Cheers,

 - Jo.

_______________________________________________
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: Neil Deason <[email-masked]>
Date: Thu, 01 Feb 2001 10:25:44 +0000

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

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.

> I'm not familiar with CPL, so maybe those can be done with stateful proxies.

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.

> 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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 1 Feb 2001 08:09:57 -0800 (PST)

Henning G. Schulzrinne writes:
 > 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.

   [Duh bulb goes on] Yes, I like this idea a lot.

 > B2BUA, like proxies, can, but don't have to modify SDP. Proxies serving
 > as part of NAT ALGs may need to, for example.

   The advantage to what you suggest above is that
   you cons up a UAS as necessary which still 
   preserves the e2e semantics. This still allows
   you to authenticate e2e which seems
   advantageous. While it doesn't mean that 
   the consed up UAS couldn't turn itself into
   a B2BUA and thus break the e2e semantics, 
   modeling initially as a B2BUA explicitly 
   encourages that which seems like a bad
   precedent to me.

		Mike