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

From: Mayer Georg ICM N MC MI E71 <[email-masked]>
Date: Wed, 24 Oct 2001 19:26:24 +0200

Hello again!

In general I think we have an interpretation problem here. 

Reading the RFC 2543bis-04 defintion of a B2BUA it clearly states that there
are two UAs. It seems to be a valid interpretation that this means the B2BUA
should act as a UA-S on the incoming and a UA-C on the outgoing side (of a
Request). Reading then the procedures of a UA (also in the other SIP related
IETF drafts) brings up all the implications that Sean and I listed. 

Ok, one could say there is a "transparent" B2BUA - but what is this? Where
is it defined? It is currently not defined and if one tries to define it,
she/he in the end needs to add the "transparent" B2BUA specific behaviour
under every line in the SIP Draft (and the supporting Drafts) which mention
UA behavior. Else the definition is either as restrictive as stated above or
it is open for interpretation - and I do not know which of these two
alternatives is really the "better" one. 

Well, I agree, we can do that - but this introduces a complete new entity -
one that I would not like to name B2BUA, because it is something like a
"call manipulating proxy". 

The problem is that if you follow the definition of UA and B2BUA, a B2BUA
does a lot of things and if you look at the 3G requirements you need to
introduce it mainly because of the case of network initiated session
release. This - furhter more - would cause that both S- and both P-CSCF need
to act as B2BUAs for every call. So each end-to-end call would be splitted
up in five (!!) call-pieces which all would have their unique call-id, etc.
etc. . 

I know, 3GPP has sent out a long wish-list for christmas (don't ask for the
year) and this specific item on the list is very ... interesting. 

Keep on signaling!

Georg

_______________________________________________________

Georg Mayer - Siemens AG

_______________________________________________________ 
Georg Mayer - Siemens AG 
Information and Communication Mobile 
ICM N MC MI E71 
Hofmannstr. 51, 81359 Munich, Germany 
Fon: +49-89-722-33114 
Fax: +49-89-722-62250 
Mobile: +49-172-5371233 
Email: [email-masked] 

-----Ursprüngliche Nachricht-----
Von: Sean Olson (EUS) [mailto:[email-masked]]
Gesendet: Mittwoch, 24. Oktober 2001 18:31
An: 'Rohan Mahy'; Miguel A. Garcia
Cc: [email-masked]
Betreff: RE: [Sipping] 3G entities: Proxy or B2BUA?

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

This would be ideal. Unfortunately I do not believe it is correct. 

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

A B2BUA has the advantage and the burden of keeping per-call-leg 
state. SIP proxies benefit from not having the complexity or 
the overhead of maintaining this call-leg state. It is precisely 
because a B2BUA maintains call state that it cannot be transparent 
as you mention.  For example, if a B2BUA is deployed that does 
not understand the REFER extension, what happens? It could 
reject the REFER request, breaking transparency. Or it could 
"proxy" the request along not understanding that call leg 
state may be modified as a result. A true UserAgent does not 
have this problem, nor does a proxy. What about future extensions 
that create "call legs" that the B2BUA does not know about? For 
example, SUBSCRIBE for RFC2543 based B2BUAs. What about the Replaces: 
or Joins: headers? What about In-Reply-To: and To-Join:? What about 
INVITE requests that use SMIL or the next generation of SDP? Does 
the B2BUA have to be updated for this? 
  
BR, 
Sean Olson 
Ericsson Inc.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 25 Oct 2001 10:11:02 -0400

All,

Another thought from left field.  In some protocols, there is the concept 
of a lower layer initiated abort.  While here, we are talking about 
signaling within the layer, not between layers, this is still the case of 
one entity using another entity to gain service.  Should we also be 
considering the possibility of using other messages?  If we assume the 
Invite/Bye messages are the domain of the end system.  Could there also be 
a Notify type message rather than a Bye that indicates, to the controlling 
UA "You are about to lose your bearer (because I control that flow to the 
public Internet/other carrier, etc.), add more credit, or terminate and 
clean up your call state."

Bye would seem more appropriate, but goes against the grain of end-user 
control.  Thought it might be useful to briefly consider if other SIP 
methods would work.

Mike

At 07:26 PM 10/24/2001 +0200, Mayer Georg  ICM N MC MI E71 wrote:

>Reading the RFC 2543bis-04 defintion of a B2BUA it clearly states that 
>there are two UAs. It seems to be a valid interpretation that this means 
>the B2BUA should act as a UA-S on the incoming and a UA-C on the outgoing 
>side (of a Request). Reading then the procedures of a UA (also in the 
>other SIP related IETF drafts) brings up all the implications that Sean 
>and I listed.
>
>under every line in the SIP Draft (and the supporting Drafts) which 
>mention UA behavior. Else the definition is either as restrictive as 
>stated above or it is open for interpretation - and I do not know which of 
>these two alternatives is really the "better" one.
>
>Well, I agree, we can do that - but this introduces a complete new entity 
>- one that I would not like to name B2BUA, because it is something like a 
>release. This - furhter more - would cause that both S- and both P-CSCF 
>need to act as B2BUAs for every call. So each end-to-end call would be 
>splitted up in five (!!) call-pieces which all would have their unique 
>call-id, etc. etc. .
>
>I know, 3GPP has sent out a long wish-list for christmas (don't ask for 
>the year) and this specific item on the list is very ... interesting.
>
>Keep on signaling!
>
>Georg
>

_______________________________________________
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: Anders Kristensen <[email-masked]>
Date: Thu, 25 Oct 2001 20:06:34 -0400

This makes a lot of sense to me. Just let the P-CSCF proxy set up an
"implicit" event subscription for the endpoint and send a NOTIFY to it
when time's up, refering to the corresponding call leg in the body.
That's not inconsistent with baseline SIP like sending a BYE would be.

Anders

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 26 Oct 2001 09:23:48 +0300

Anders:

Your proposal sounds to me like a REFER for a BYE, rather than a NOTIFY.

However, I must say that 3G operators have a lot of concerns on the power
of REFER (e.g., it could be used for abuse).

On the other hand, the REFER I-D says very clearly that the UA, upon the
reception of a REFER, should ask the user for permission to proceed. So,
if I get a REFER from the P-CSCF to send a BYE, I will always say NO, and
my client silently ignore it.

Therefore, NOTIFY seems to be a better solution.

/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