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

From: Rohan Mahy <[email-masked]>
Date: Fri, 26 Oct 2001 09:17:25 -0700

---- Original message ----
>Date: Fri, 26 Oct 2001 11:51:44 +0200
>From: Mayer Georg  ICM N MC MI E71 
<[email-masked]>
>Subject: AW: AW: [Sipping] 3G entities:  Proxy or B2BUA?
>To: "'Miguel A. Garcia'" <[email-masked]>, 
Anders Kristensen <[email-masked]>
>Cc: Michael Hammer <[email-masked]>, "'Sean Olson 
(EUS)'" <[email-masked]>, "'Rohan Mahy'" 
<[email-masked]>, [email-masked]
>
>Good morning,
>
>> Your proposal sounds to me like a REFER for a BYE, rather 
>> than a NOTIFY.
>
>There is a difference between the NOTIFY proposal and the 
usage of 
>REFER:
>
>NOTIFY: P-CSCF subscribes to a S-CSCF event package, i.e. P-
CSCF acts 
>as a
>UE in that case. If the network initiated call release 
event ("nicre" -
>spells nearly as nice, but sounds different) occurs at the 
S-CSCF it 
>sends a
>NOTIFY ->to the P-CSCF<- which is directly addressed. The P-
CSCF then
>releases the bearer. 
>
>REFER: Upon occurence of "nicre", the S-CSCF sends a REFER -
>to the 
>UE<-.
>The P-CSCF - if it wants to release the bearer immediately 
(which it 
>should
>do, as the user has no money anymore - i.e. nobody pays for 
the bearer) 
>has
>to sneak into the REFER method, which is destined to the 
user. To be 
>sure it
>does not miss one of these "REFER instead of BYE" messages, 
the P-CSCF
>therefore needs to sneak in every REFER method.
>
>Therefore I see a real advantage in the usage of NOTIFY and 
I see it as 
>the
>first step into the right direction. In doing so there are 
still some 
>minor
>and major open issues, which I would like to discuss:
>
>a) Does P-CSCF subscribe to S-CSCF on a per-call basis or 
on a
>per-registration basis? I would recommend it should do it 
on a
>per-registration basis. Or is there any reason against that?

I would certainly recommend subscribing on a per 
registration basis

>b) What happens if S-CSCF refuses the SUBSCRIBE request 
from P-CSCF? 

that seems like a sure sign to me that the subscriber can't 
be serviced in the visiting network.

>c) What we gain with the NOTIFY-based solution is a bearer 
release
>mechanism. Still the question is open how we get the call 
control level 
>back
>to "call released/null" state. I still hope somebody is 
coming up with 
>a
>solution for that. 

i proposed that the P-CSCF (and *only* the P-CSCF) would act 
as a B2BUA so that it can send a BYE on behalf of the user 
(when radio signal drops), or a BYE on behalf of the network 
(when it is notified by the S-CSCF that no one will pay for 
calls for that subscriber anymore).

>After sending the NOTIFY, the scenario now looks exactly 
the same as 
>the
>"user walks out of radio coverage" scenario: P-CSCF 
releases the bearer 
>and
>should now inform both end entities and all proxies on the 
route about 
>the
>released call, in order to clear the call states. 

agreed.

thanks,
-rohan

>Keep on signaling!
>Georg
>_______________________________________________________
>Georg Mayer - Siemens AG
>Information and Communication Mobile
>ICM N PG SP ST SN1
>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: Miguel A. Garcia 
[mailto:[email-masked]]
>> Gesendet: Freitag, 26. Oktober 2001 08:24
>> An: Anders Kristensen
>> Cc: Michael Hammer; Mayer Georg ICM N MC MI E71; 'Sean 
Olson (EUS)';
>> 'Rohan Mahy'; [email-masked]
>> Betreff: Re: AW: [Sipping] 3G entities: Proxy or B2BUA?
>> 
>> 
>> 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
>> 
>> Anders Kristensen wrote:
>> > 
>> > 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
>> > 
>> > Michael Hammer wrote:
>> > >
>> > > 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:
>> > >
>> > > >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.
>> > >
>> > > _______________________________________________
>> > > 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
>> 
>> -- 
>> 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: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 26 Oct 2001 21:12:04 +0300

Rohan:

I disagree with you in one issue. You are trying to demonstrate
that the B2BUA is a good idea for the P-CSCF, and that only is
neede for the P-CSCF to release sessions when the mobile is
out of coverage.

However, there might be other situations that might lead to the
same conclusion for the S-CSCF. For example, section 6.14.2 in
draft-garcia-sipping-3gpp-reqs-00.txt deals with the graceful
session release. This can be used, for example, when an operator
wants to stop the conversation between two users (don't ask me
the reason, I am just imaging). If we follow your conclusion,
then the S-CSCF is also a B2BUA.

Then later somebody will think of other brillian ideas that
will lead to the I-CSCF, the application servers or any other
entities behaving as a B2BUA. And all of them filtering here
and ther a few headers, methods, services...

And then, we would have designed such a fool system that only
the fools will use it. I hope we don't get to that state.

/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