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

From: Rohan Mahy <[email-masked]>
Date: Fri, 26 Oct 2001 12:51:37 -0700

---- Original message ----
>Date: Fri, 26 Oct 2001 21:12:04 +0300
>From: "Miguel A. Garcia" <[email-masked]>
>Subject: Re: AW: AW: [Sipping] 3G entities:  Proxy or B2BUA?
>To: Rohan Mahy <[email-masked]>
>Cc: Mayer Georg ICM N MC MI E71 
<[email-masked]>, Anders Kristensen 
<[email-masked]>, Michael Hammer 
<[email-masked]>, "'Sean Olson (EUS)'" 
<[email-masked]>, [email-masked]
>
>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.

No, I am saying that the operator in the home network can 
*ask* the P-CSCF to disconnect the call.  

Actually I think the more appropriate model is for the home 
network to notify the visited network that it is no longer 
willing to *pay* for the call.  Knowing this, the P-CSCF is 
well incented to disconnect the call.

I assert that you only need one point of mid-call control 
for each mobile terminal, that the P-CSCF is the logical 
point of control, and that this point of control must be a 
transparent 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.

me either.

-r

>/Miguel
>
>Rohan Mahy wrote:
>> 
>> ---- 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
>> >>
>
>-- 
>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

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sat, 27 Oct 2001 13:15:46 +0300

Rohan:

As I said before, I think you can achieve a similar 
functionality without turning the P-CSCF into a
B2BUA. If it can be avoided for the S-CSCF, it can 
be avoided for the P-CSCF as well.

/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