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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 29 Oct 2001 15:31:27 -0000

This restriction has been generated by the definition of B2BUA that was
inserted in one of the recent redrafts of the bis draft.

I for one feel this definition is too restrictive, and that redrafting it to
allow the migration to a UA role in an ongoing dialog (particularly to allow
sending BYE) would not generate interoperability issues. We also seem to
have eliminated any option of "transparent" B2BUAs.

B2BUAs were meant to be outside the scope of the bis draft to specifiy, but
we seem to have inserted a definition that tries to totally restrict their
use, and then tie ourselves up in knots on that definition.

Keith 

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Miguel A. Garcia[SMTP:[email-masked]]
> Sent: 	27 October 2001 10:25
> To: 	Lawrence Conroy
> Cc: 	Roy, Radhika R, ALCTA; Bert Culpepper; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: 	Re: [Sipping] 3G entities:  Proxy or B2BUA?
> 
> 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
> 
> Lawrence Conroy wrote:
> > 
> > At 3:26 pm -0400 26/10/01, Roy, Radhika R, ALCTA wrote:
> > ><bert wrote>
> > >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.
> > 
> > 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>:
> 
> -- 
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                         Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 5140002
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Mon, 29 Oct 2001 09:33:48 -0600

All this B2BUA vs Proxy discussion seems to have gone wide of the mark.
Let's get back to some fundamentals:

REQUIREMENT: We must be able to release resources associated with a call in
the event of loss of signaling to all mobile terminals involved in the call.

Open question #1: How do we recognize that this condition has occurred?
---------------------------------------------------------------------------

Proposals:

1A) Use a timer on some node on the SIP signaling path, and assume that the
error has occurred if no SIP signaling is seen for some period of time.

1B) Detect loss of media-path signals or bearer at some intermediary that
monitors RTP or RTCP.

1C)  Report loss of bearer from a lower layer in the network.

Open question #2: How do we signal that this condition has been detected?
------------------------------------------------------

Proposals:

2A) Generate a BYE for the call from an "additional endpoint" which is
included in the signaling path by the architecture. This might be a B2BUA,
or it might be a third-party controller, or it might be something akin to a
conference bridge, etc.

2B) Use third-party control mechansims, such as a REFER.

2C)  Use a SUBSCRIBE/NOTIFY mechanism of some sort.

2D) Use a non-SIP protocol.

Open questtion #3: Having been signalled that the event has occurred, how do
we execute the tear-down? Is this specific to the particular resource being
released?
-----------------------------------------------------------------

Proposals:

3A) All resource-holding nodes are in the SIP path, so a SIP teardown
results in release of media resources

3B) All resource-holding nodes are either in the SIP path, or are controlled
by nodes in the SIP path that can reconginze a SIP teardown and command
appropriate action.

3C) Some resource holding nodes are in the SIP path, and others in the
bearer path. Each executes a teardwoin as appropriate to its nature.

3D) As with 3C, except that there may be a control protocol between the node
detecting the SIP or  bearer teardown and the node holdin/releasing
resources.

Any other cases?

--
Dean