Subject: RE: [Sipping] 3G entities: Proxy or B2BUA?

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Fri, 26 Oct 2001 15:26:37 -0400

inline [RRR]

-----Original Message-----
From: Bert Culpepper [mailto:[email-masked]]
Sent: Friday, October 26, 2001 2:36 PM
To: [email-masked]; [email-masked]; [email-masked];
 .

> If is is possible to define the functionality of a SIP
> network entity that
> can release a call at anytime (e.g. when the pre-paid credit
> has run out) by
> sending a BYE (or any other mid call message in general with
> correct SIP
> parameters i.e. CSeq...) and be transparent for unknown
> methods, headers etc
> etc. , this would be useful to progress the 3GPP work.

Yes, it's possible.  It's a SIP proxy that for isolated
moments/transactions, acts as a SIP UA.

[RRR] It is only possible, if the proxy acts as a B2BUA.

regards,
Bert

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 26 Oct 2001 21:02:06 +0100

At 3:26 pm -0400 26/10/01, Roy, Radhika R, ALCTA wrote:
><bert wrote>

To which I reply:
Enough, already.

As has already been suggested, it acts in the ->role<- of
a UA for this transaction only. The rest of the time it
acts in the ->role<- of a proxy. No contradiction, no problem.

I agree that it makes the software running on the CSCF box a
tad more complex as "receiver" code has to pass received responses
off either to a "normal" proxy processor or to a separate software
block dealing with the intermediary BYE processing, but this is
no big deal, IMHO.

It seems that some folks have a problem with this, so I think I
must be missing something too (you're not alone, Bert :).

Please can someone explain (in a little more detail) why they think
that this is not possible to implement (i.e. why it won't work).

All the best,
    Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sat, 27 Oct 2001 13:25:55 +0300

Here is the discussion:

To my understanding (somebody can correct me if I am wrong),
a proxy CANNOT send any request generated for the proxy that
logically belongs to an ongoing dialog. In other words, a 
proxy can't generated a BYE for an ongoing call. I believe
there was some wording in bis-04 about this.

A proxy, acting as a UA, can generate any request that 
does not belong to any dialog. This is considered to start 
a new dialog, and for this particularly dialog, the proxy
is not acting as a proxy, but as a UA. An example is a 
SUBSCRIBE sent by a proxy.

/Miguel

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

---

From: "Dean Willis" <[email-masked]>
Date: Mon, 29 Oct 2001 09:09:57 -0600

Bill recently requested somebody recover this old thread and put it back in
the record.
------------------------------

from wtm:
> 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
>
> > 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.