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

From: Rohan Mahy <[email-masked]>
Date: Mon, 29 Oct 2001 08:43:07 -0800

Keith,

I don't see anything wrong with the wording preventing a 
proxy from generating a request for an existing call leg.  
An off-the-shelf proxy will not keep track of the CSeq, but 
an off-the-shelf B2BUA will.

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

Jonathan R, Jon P, Alan J, and Gonzalo are currently 
rewriting bis.  Therefore, I would like to propose the 
following two concrete proposals that could be taken to the 
SIP WG.

a) reword/clarify the definition of a B2BUA to explicitly 
allow one to act transparently.  (I believe the intent was 
to allow transparent behavior).

b) add special language in the proxy behavior section to 
this effect: "A call-stateful proxy which uses Record-Route 
for a call-leg, MAY become a B2BUA for that call-leg."

I think we definitely need a) and I would like to get some 
more feedback on whether b) is needed or useful.

thanks,
-rohan

---- Original message ----
>
>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: "Brett Tate" <[email-masked]>
Date: Mon, 29 Oct 2001 17:03:59 -0500

> to allow transparent behavior).

Sounds fine.

B2BUA's can allow transparent or 
non-transparent behavior based upon 
the intended functionality of the product
and/or situation.

> for a call-leg, MAY become a B2BUA for that call-leg."

Sounds fine.  However it requires that the 
corresponding entities along the Route will 
not ever skip the converted-to-B2BUA 
within the Route (for CSeq reasons).  
This should be fine for newer SIP products.

After a restart if a dialogue is revived,
the entity needs to know whether to act as
a B2BUA or proxy for CSeq reasons.
 
> more feedback on whether b) is needed or useful.

Both a and b are useful.

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 30 Oct 2001 00:39:57 +0200

Rohan:

Your proposal b) sounds good to me. I hope SIP does not brake
because of that.

/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: "Bert Culpepper" <[email-masked]>
Date: Tue, 30 Oct 2001 10:43:04 -0500

Hi Rohan,

I do believe that discussions of how protocol elements provide useful
functions is a good thing to help readers understand the protocol.  But
how far should the protocol document go?

More obvious observations...

I see the SIP network elements (UAC, UAS, stateful proxy, registrar, ...)
as "building blocks" that can be combined to build network devices that
provide useful functions.  When used alone they only provide limited
functionality.  An obvious example is a UAC can only initiate sessions
(originate calls), it can not terminate sessions (answer a call).  If one
wants to build a SIP phone that can do both functions, they must
implement both a UAC and UAS in the device.  And there must be logic
"linking" the two elements to handle exceptions that can occur when
providing the communications function.

Depending on the functions desired, one will most likely have to combine
SIP elements.  Even including elements from other protocols.  Of course,
care must be taken (adherence to the specification for each element) when
combining elements.  Failure to adhere to the protocol specification will
certainly "break the network".  But done properly, the result is very
useful network entities.

> to allow transparent behavior).

Since a discussion of a B2BUA was added, it should be "fixed" if it
limits otherwise protocol compliant application.

> for a call-leg, MAY become a B2BUA for that call-leg."

This is one of those aspects that one must "realize" when combining a SIP
proxy with a SIP UA.  Does this need to be added to the specification?
I'll leave that up to the authors/community.

Regards,
Bert