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

From: Rohan Mahy <[email-masked]>
Date: Thu, 25 Oct 2001 11:37:10 -0700

Hi,

I think we are getting to the core of the discussion now...

---- Original message ----
>Date: Thu, 25 Oct 2001 10:30:27 +0300
>From: "Miguel A. Garcia" <[email-masked]>
>Subject: Re: [Sipping] 3G entities:  Proxy or B2BUA?
>To: Rohan Mahy <[email-masked]>
>Cc: [email-masked]
>
>[snip]
>> >The main problem with B2BUA, as it is defined by the bis
>> draft, it that it acts as a UA on both sides. Therefore, 
it
>> needs to understand every method, header, codec, etc that
>> the UA sends. If it does not understand anything, it has 
to
>> reject it.
>> 
>> This assumption is fortunately not correct.  It is 
possible,
>> reasonable, and legal to implement a B2BUA that
>> transparently passes headers, method, and bodies that it
>> does not directly understand.  An anonymizer is a perfect
>> example of such a B2BUA--it only needs to understand a few
>> headers, plus the SDP, and pass the rest transparently.
>
>I don't think it is possible to transparently pass headers, 
>methods, bodies, etc. For instance, manyfolks already 
specifies
>actions when the a=qos attribute is present in SDP with the 
>parameter "confirm" (COMET is triggered). The B2BUA will 
need
>to understand the confirm to trigger the COMET. How is this
>going to interact with the QoS reservation?

I disagree, I think it is possible.  A B2BUA is a *logical* 
entity and does not literally need to act like an autonomous 
UA.  If the spec says that a UA needs to send back an error 
if such-and-such header/event/body/method is not understood, 
it is reasonable for the UA to ask another entity if 
it "supports" or "understands" that 
header/event/body/method.  In this case the "other entity" 
is the target UA.

>In general, I think the B2BUA is evil. It needs to 
understand
>absolutly everything, and therefore, is anti-transparent.
>You can design a B2BUA that forwards some headers, methods, 
>etc. But if the B2BUA passes everything that is not 
understood
>transparently (like a proxy does), then what is the mission 
of
>the B2BUA? 

I skimmed through chapter 15 of bis again this morning, and 
I can't find why you think a B2BUA must be anti-
transparent.  I'd like to see what sections in bis lead you 
to believe this.   Perhaps there is some assumption/ 
miswording in *manyfolks* about UA behavior?

I'm also attaching the definition of B2BUA from bis-04 with 
a few comments:
> Back-to-Back User Agent: Also known as a B2BUA, this is a 
> logical entity that receives an invitation, and act as a 
> UAS to process it.  In order to determine how the request 
> should be answered, it acts as a UAC and initiates a call 
> outwards.  Unlike a proxy server, it maintains complete 
> call state and must participate in all requests for a 
> call. Since it is purely a concatenation of other logical 
> functions, no explicit definitions are needed for its 
> behavior.

I can imagine two areas of potential confusion with this 
definition:

"acts as a UAS to *process* it"

and

"must *participate* in all requests"

I interpret these to mean merely that the UAS half of the 
B2BUA must respond to each request with the same Via and 
Contact handling rules as a UA, and that it must be a party 
to each request, so that it can keep track of call-leg state 
and CSeq numbers.

>> The main advantage of a B2BUA in this environment is that 
it
>> can keep per-call-leg state and can be involved in mid-
call
>> signaling.  As a proxy is only involved in transactions, 
it
>> can only handle pre-call features.  A B2BUA can insert SIP
>> messages (for example BYE messages), run timers, and may
>> change the required headers: (To, From, Call-ID, CSeq,
>> Via).
>
>Yes, I understand that. The question is: is all needed?
>Are we willing to pay the price of having 6 or more B2BUA
>(that we don't know the behaviour for unknown headers,
>methods, bodies, etc) in the path of the call just to be 
>able to send a BYE? IMHO the price is very expensive.

I know what you are thinking--each entity that is 
labeled "proxy" in the 3G specs needs to be a B2BUA?  That's 
horrible.  That's not what I am proposing...

I can come up with an environment where only one SIP-
only "transparent" B2BUA is required (the P-CSCF).  You may 
need to add another B2BUA and a media relay if complete 
anonymity is required (but only for calls that request it).

The P-CSCF (in the visited network) needs to verify from the 
home network that there is some billing relationship between 
the visited and home networks.  The visited network can 
subscribe to the account status of the subscriber from the 
home network.  If the home network notifies the P-CSCF that 
the account status is now deactivated, the P-CSCF (as a 
B2BUA), can disconnect any calls in progress and prevent any 
additional calls.  The home network is merely informing the 
visited network that the home network will no longer 
reimburse the visited network for the subscribers calls. 

>> Also, there may be resistance to keeping lots of state on
>> the B2BUA.  It is possible (though a bit complicated) to
>> implement a B2BUA that is completely call stateless, by
>> pushing encrpyted call-state to the edges.
>
>Works fine in DCS. But in 3G wireless, where the terminals
>will be limited in memory, coverage, bearers, etc., it is
>not desirable to push states to the terminals.

I'm just offering the option.  The state needs to live 
somewhere.  I suspect the P-CSCF is a pretty good place for 
it.

[snip]
>I think the concept of a B2BUA is clear in bis-04. It is 
just
>two UA linked by some logic above. As such, the B2BUA needs 
to
>behave as two UAs. If you are thinking of something else, 
>perhaps it is not a B2BUA, but other thing. If you are 
thinking
>of a stateless B2BUA, perhaps it is not a B2BUA, and further
>more, probably not acceptable for 3G networks.

I think folks are reading a lot into a four sentence 
definition that was only recently added to bis.  ;-)

Also, I want to encourage all of you to focus less on the 
spec, and more on the behavior.  If I build a transparent 
B2BUA, and nothing breaks in SIP, this is good behavior.  We 
can make minor changes to the spec to encourage good behavior

thanks,
-rohan

[rest deleted for brevity]

_______________________________________________
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: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 26 Oct 2001 10:29:31 +0300

Rohan Mahy wrote:

[snip]

> header/event/body/method.  In this case the "other entity"

Miguel> As I understand, a B2BUA acts as a UAS for all the requests. 
To me this means understanding the information in those requests. 
If the B2BUA receives a REFER, it needs to understand the Refer-To 
and Referred-By headers (this was just an example).

> to each request, so that it can keep track of call-leg state

Miguel> This is the key question. To me, one of the capabilities 
of the B2BUA is to terminate the SIP signalling at the UAS, and 
initiate SIP signalling at the UAC. One thing the B2BUA can do is 
to change From, To, Call-ID headers, as the two signalling 
relations in the B2BUA are just correlated by some internal logic.

As such, terminating the signalling at the B2BUA means, to 
populate the headers appropriately (for instance, the Contact 
header in 200 for INVITE should point to the B2BUA). As such, the
B2BUA needs to understand all the extensions required by the 
end points, in order to decide how to process them. I have my 
doubts that one can build a B2BUA with certain transparency. And
of course, this is not what I understand from the definition of
B2BUA in the spec. Perhaps Jonathan or Henning can comment on the
intention of the definition.

> horrible.  That's not what I am proposing...

Miguel> Once you have a general proxy acting as a B2BUA, you 
need to multiply the figure by 4 (as a minimum), (originating 
and terminating P-CSCF, originating and terminating S-CSCF). 
Maybe even more if you count I-CSCF, Application servers, etc.
I would not like that in order to use a particular service 
when I call you, all 8 proxies in the network need to be 
upgraded with the latest software. If this is the case, I will
never use the IMS defined by 3GPP and use just an Internet
connection over GPRS.

> anonymity is required (but only for calls that request it).

Miguel> Don't forget the terminating side (for mobile to 
mobile call), so you have already 3 B2BUA.

Don't forget the S-CSCF, that will be the next (logical for 
certain people) step. So you have 5 B2BUA.

Don't forget the Application Server (e.g., the pre-paid application
server sending BYEs), so you have 7 B2BUA.

> reimburse the visited network for the subscribers calls.

Miguel> Charging is still unstable in 3GPP. So I will not 
comment on this until I have a clear picture of the architecture.
Certainly, the P-CSCF subscribing to the "credit status" of a
user seems to be a feasible solution. Probably there are others
as well.

> can make minor changes to the spec to encourage good behavior

Miguel> Well, this is what I am trying to do, focus on the 
behaviour. But I don't want to introduce a new entity in the 
network invented and defined by 3GPP. The SUP architecture 
defines User Agents, proxies and B2BUA. This is what we have 
as for today.

Perhaps we need to explore, as it has been suggested before,
the possibility of a new entity (read call stateful proxy) 
that is able to send JUST a BYE when the user is out of
coverage or similar situations. Will that break SIP?

/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: Henry Sinnreich <[email-masked]>
Date: Fri, 26 Oct 2001 10:16:20 -0500

>I will never use the IMS defined by 3GPP and 
>use just an Internet connection over GPRS.

This reminds us of the usefulness of ISDN: Just to have a better modem
to dial up an Internet service. Have used ISDN for two years for
Internet access and not once for anything else.

Henry

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Miguel A. Garcia
> Sent: Friday, October 26, 2001 2:30 AM
> To: Rohan Mahy
> Cc: [email-masked]
> > >I don't think it is possible to transparently pass 
> headers, methods, 
> > >bodies, etc. For instance, manyfolks already
> > specifies
> > >actions when the a=qos attribute is present in SDP with 
> the parameter 
> > >"confirm" (COMET is triggered). The B2BUA will
> > need
> > >to understand the confirm to trigger the COMET. How is 
> this going to 
> > >interact with the QoS reservation?
> > 
> entity and 
> > does not literally need to act like an autonomous UA.  If the spec 
> > says that a UA needs to send back an error if such-and-such 
> > header/event/body/method is not understood, it is 
> reasonable for the 
> > UA to ask another entity if it "supports" or "understands" that
> > >absolutly everything, and therefore, is anti-transparent. You can 
> > >design a B2BUA that forwards some headers, methods, etc. 
> But if the 
> > >B2BUA passes everything that is not
> > understood
> > > Back-to-Back User Agent: Also known as a B2BUA, this is a logical 
> > > entity that receives an invitation, and act as a UAS to 
> process it.  
> > > In order to determine how the request should be answered, 
> it acts as 
> > > a UAC and initiates a call outwards.  Unlike a proxy server, it 
> > > maintains complete call state and must participate in all 
> requests 
> > > for a call. Since it is purely a concatenation of other logical
> B2BUA must 
> > respond to each request with the same Via and Contact 
> handling rules 
> > as a UA, and that it must be a party to each request, so 
> that it can 
> > keep track of call-leg state and CSeq numbers.
> 
> header in 200 for INVITE should point to the B2BUA). As such, 
> the B2BUA needs to understand all the extensions required by the 
> doubts that one can build a B2BUA with certain transparency. 
> And of course, this is not what I understand from the 
> definition of B2BUA in the spec. Perhaps Jonathan or Henning 
> can comment on the intention of the definition.
> 
> 
> > 
> > >> can only handle pre-call features.  A B2BUA can insert 
> SIP messages 
> > >> (for example BYE messages), run timers, and may change 
> the required 
> > >> headers: (To, From, Call-ID, CSeq, Via).
> > >
> > >Are we willing to pay the price of having 6 or more B2BUA (that we 
> > >don't know the behaviour for unknown headers, methods, 
> bodies, etc) 
> > >in the path of the call just to be able to send a BYE? 
> IMHO the price 
> > >is very expensive.
> > 
> > labeled "proxy" in the 3G specs needs to be a B2BUA?  
> That's horrible.  
> > That's not what I am proposing...
> 
> Maybe even more if you count I-CSCF, Application servers, 
> etc. I would not like that in order to use a particular service 
> upgraded with the latest software. If this is the case, I 
> will never use the IMS defined by 3GPP and use just an 
> Internet connection over GPRS.
> 
> > 
> > only "transparent" B2BUA is required (the P-CSCF).  You may need to 
> > add another B2BUA and a media relay if complete anonymity 
> is required 
> > (but only for calls that request it).
>