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

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Fri, 26 Oct 2001 13:11:13 -0400

All:

I am summarizing a little more. The complete picture looks like this:

Solution spaces:

A. UE A <-> P-CSCF1 <-> S-CSCF1 <-> UE B Communications (application layer -
e.g., calling cards, etc.)
B. UE <-> GGSN and/or GGSN <-> P-CSCF1 Communications (network layer - e.g.,
bearer etc.)

Two probable alternate solution areas:

1. B2B UAs
2. REFER/NOTIFY/SUBSCRIBE

I am only talking about the REFER/NOTIFY/SUBSCRIBE case only and, let me
analyze the requirements very briefly.

The serving proxy S-CSCF1 can be either in the visited network or in the
home network. In any situation, we can assume that S-CSCF1 will only be
responsible for services (e.g., calling cards, etc. - appln. layer), not
about the bearer. So, we can assume that P-CSCF1 needs to SUBSCRIBE to
S-CSCF1 for the service related events.

However, P-CSCF1 is only be located in the visited network and, it can be
said safely that it will be communicating with both S-CSCF1 and GGSN. It
will be aware of both services (via S-CSCF1) and media (via GGSN). So, for
any events related to media both UE and S-CSCF1 need to SUBSCRIBE to
P-CSCF1.

If this is the case, it appears that NOTIFY becomes the logical choice. So,
the SUBSCRIBE/NOTIFY becomes more attractive solution.

(If both P-CSCF1 and S-CSCF1 are aware of the media and/or service related
events, subscriptions need to be made accordingly. I have elaborated these
situations here for simplicity.)

Let me address issues raised by Georg:

a. Does P-CSCF subscribe to S-CSCF on a per-call basis or on a
per-registration basis? Yes, I agree with you that it is better to be per
registration basis.

b. What happens if S-CSCF refuses the SUBSCRIBE request from P-CSCF? The
answer is: There has to be a business relationship between the home network
and the visited network. As a result, S-CSCF1 cannot refuse a proper
SUBSCRIBE request.

c. What do we gain with the NOTIFY-based solution is a bearer release
mechanism? The biggest advantage is that we do not violate or temper any SIP
rules: UAs will be able to send BYE to terminate both session and media.

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 26, 2001 11:51 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: AW: [Sipping] 3G entities: Proxy or B2BUA?

Hi Georg et al.

You compare REFER and NOTIFY mechnisms and say (here shortend):
REFER -> UE  and  NOTIFY -> P-CSCF
 
The same way, the REFER could also be sent to the P-CSCF, which
releases bearer and clears the call state (as in walk out of
coverage case).

Thus I see no such difference between the REFER and
NOTIFY solution.

Just that the problems a) and b) you've mentioned are not an
issue in the REFER to P-CSCF solution.

This is why I think the REFER is a better way, as REFER is meant to
trigger an action, wheras as NOTIFY is meant to inform about some
happening.

So we have nwo 4 alternatives to the B2BUA:

i) REFER to P-CSCF
ii) REFER to UA
iii) NOTIFY to P-CSCF
iv) NOTIFY to P-CSCF (is probably not so useful.)

Let's continue discussing about these alternatives and
elaborate the most useful solution to avoid the B2BUA!

cheers
 Bernie

>-----Original Message-----
>From: ext Mayer Georg ICM N MC MI E71
>[mailto:[email-masked]]
>Sent: 26. October 2001 12:52
>To: 'Miguel A. Garcia'; Anders Kristensen
>Cc: Michael Hammer; 'Sean Olson (EUS)'; 'Rohan Mahy'; [email-masked]
>Subject: AW: AW: [Sipping] 3G entities: Proxy or B2BUA?
>
>
>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?
>
>b) What happens if S-CSCF refuses the SUBSCRIBE request from P-CSCF? 
>
>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. 
>
>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. 
>
>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
>

_______________________________________________
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:05:06 +0300

Hi:

See my comments below.

/Miguel

"Roy, Radhika R, ALCTA" wrote:
> home network. 

Miguel> This is wrong. The S-CSCF can be located ONLY in the home network.
This is to guarantee that your services are still available even when you roam.
But this does not change any assumption of the discussion.

> In any situation, we can assume that S-CSCF1 will only be
> said safely that it will be communicating with both S-CSCF1 and GGSN. 

Miguel> That is also not exactly right. There are combinations where the 
P-CSCF communicates with the S-CSCF (e.g., non roaming case). But there
are situations where there is a hiding proxy (I-CSCF) in between the 
P-CSCF and the S-CSCF. 

> It

---

From: "Bert Culpepper" <[email-masked]>
Date: Fri, 26 Oct 2001 14:30:31 -0400

I see the discussion moving from a proxy sending a BYE to proxies
subscribing to and notifying each other, all to support a network
initiated termination requirement.

Just to be clear, as soon as a SIP proxy generates *any* SIP request it
is no longer a SIP proxy by definition.

So let the p-CSCF, s-CSCF, x-CSCF send a BYE when it wants to and be done
with it.  It is only *not* a SIP proxy for that one SIP transaction.  No
changes to the SIP spec are required and this behavior breaks nothing in
the SIP network.

Maybe I'm missing something here and simplifying too much.  If so, I
apologize :(

Regards,
Bert