Subject: AW: [Sipping] 3GPP network hiding and session release req'ts

From: Mayer Georg ICM N MC MI E71 <[email-masked]>
Date: Mon, 22 Oct 2001 17:08:13 +0200

Hello Sean et al,
 
sorry for the late response, but I was away during the last week. Here are
some comments on your text below.
 
Assume A calls B. The call is routed via P-CSCF1 (A's outbound Proxy in the
visited network) and S-CSCF1 (A's call control function in the home network)
- I leave out the entities for user B. The SIP signaling is sent via the P-
and S-CSCF. Additionally there is a GGSN over which User A sends the RTP
media streams. The RTP is also connected to P-CSCF1, which authorizes media
access etc. 
 
UE A -----a---- P-CSCF1 ------b--- S-CSCF1 ---c--(cloud)-- UE B
  I               I
  I               I p
  I--------r--- GGSN 
 
a / b / c are SIP interfaces, whereby a is over the Radio interface.
p is the interface over which P-CSCF controls the media of the GGSN, e.g.
COPS protocol
r is the media interface - RTP streams are running here

Now some example scenarios:
(1) Pre-Paid card runs out of money. 
 
(1a) As Pre-Paid is handled by / at / behind the S-CSCF1 I would assume that
a SIP BYE message is sent from the S-CSCF towards the UE. When this BYE
passes through the P-CSCF1 it instructs the GGSN to release the call.
Well - I imply here that the S-CSCF1 can generate a BYE message for an
established session for which it is a (call-stateful) proxy. 
 
Assume the S-CSCF1 is not able (due to protocol restrictions) to send a BYE
message. Then it has to send SOMETHING in order to instruct the P-CSCF and
the UE to release the RTP session. This something can be (1b) part of SIP or
could be (1c) non-SIP signaling. For both cases (1b and 1c) still a BYE
message has to be generated by one of the UEs (or somebody else in the
network) in order to clear the signaling states etc.. 
 
My personal opinion:
- (1c) looks to me like a way around SIP - like somebody messing around in
call control without using the proper protocol. 
- (1b) sounds better, but it is additional effort for specification and
implementation, furthermore there is already. 
- (1a) is the most consequent way of doing it and solves the problem with
already existing mechanisms. 
 
(2) User walks out of Radio Coverage. 
 
(2a) P-CSCF releases the bearer immediately and generates a BYE message on
behalf of the user - perfect, but currently not allowed in SIP
 
(2b) P-CSCF releases the bearer and sends out a up-till-now unknown SIP
request in order to request another entity (S-CSCF or UE B) to send a BYE
request - Problem: Trigger of media release is not the SIP BYE signaling,
this means we have an inconsistency here.
 
(2c) P-CSCF sends out the request to somebody else to generate a BYE and
releases the bearer when the BYE arrives. Ok, I agree that we should not do
that, as this might mean charging until the BYE is received, although the
user has no access to the service. 
 
Therefore the network initiated session release question really boils down
to the question if a Proxy can generate a BYE message for an existing call
on its own. Maybe from the above given examples it became clear, that it
would be preferable to allow this Proxy behaviour.
 
The next argument might then be that it is demanded that we want these
specific proxies to act as B2BUAs. As I already lined out in another message
this is not as easy as it sounds, as the B2BUA brings some further
complication into the network. So maybe we can discuss the pros and cons for
BYE generation at a Proxy for a while. 
 
Thanks in advance and keep on signaling
Georg

_____________________________________________________ 
Georg Mayer - Siemens AG 

 -----Ursprüngliche Nachricht-----
Von: Sean Olson (EUS) [mailto:[email-masked]]
Gesendet: Freitag, 12. Oktober 2001 18:49
An: Mayer Georg ICM N MC MI E71; 'Miguel A. Garcia'; Neil Deason
Cc: [email-masked]
Betreff: RE: [Sipping] 3GPP network hiding and session release req'ts

These are all very good points. I am not trying to say that
SIP signalling cannot be used to tear down a session. In
most cases, this is exactly what will happen. But in extraordinary
cases, it is also useful to be able to use other sources of information
to know when to tear down a session. Loss of bearer is one of these.
Assuming that you are doing time-based charging, then you want
your source of charging events to be as accurate from a time
perspective as possible. In this case, I believe loss of bearer to be
a superior source of information and it should be factored into any
pre-paid solution that is time-based. Again, I am not saying that a
BYE should not be taken into account. I am merely saying that if
you have a more timely source of information about loss of bearer,
then you should use that in a pre-paid solution.
 
Best Regards,
Sean Olson
Ericsson Inc.

-----Original Message-----
From: Mayer Georg ICM N MC MI E71 [mailto:[email-masked]]
Sent: Friday, October 12, 2001 10:39 AM
To: 'Sean Olson (EUS)'; 'Miguel A. Garcia'; Neil Deason
Cc: [email-masked]
Subject: AW: [Sipping] 3GPP network hiding and session release req'ts

Hello Sean et al, 

> That is certainly one possible way to do charging, but it is not 
> the only way. You could tie charging to the SIP signalling, or 
> you could charge for the bearer instead. As the bearer seems to be 
> the real resource here (at least the most scarce one), pre-paid 
> tied to the bearer seems like a realistic alternative. 

Well, we had already some discussion about that subject. I want to summarize
my opinion on that. 

The bearer (media session) is established due to the SIP signaling going on
on the call control level. This means that we first need some SIP signalling
and then can send the media packages. That's why we need a signaling
protocol. Using SIP we achieve a lot of important things, as for example the
states in the different proxies / CSCFs and we can also get the information
that is needed for charging. Please note also that the charging states are
available in the home network whilst the media is not neccesarily routed via
the home network, the P-CSCF is in control of the bearer (via some other
magic I do not want to dwell in here).

If we now want to tear down the session we need "some means" to tear down
the session when the session release in the network occurs. From my point of
view these means must be SIP means, because that's why we have a signaling
protocol - it is there to control the call. Only sending a BYE will cause
the states in the proxies and UEs to go back to null-states. And only a BYE
should be the trigger point for the P-CSCF to order release of the bearer.
If we have other means, then we need to standardize a new protocol between
the entity that finds out about the need of session clearing (i.e. the
S-CSCF in the home network) and the entity in control of the bearer (i.e.
the P-CSCF in the visited network). Then I would dare to ask why we need SIP
to establish but not to tear down sessions. 

Keep on signaling!
Georg

_______________________________________________________ 
Georg Mayer - Siemens AG 

-----Ursprüngliche Nachricht-----
Von: Sean Olson (EUS) [mailto:[email-masked]]
Gesendet: Freitag, 12. Oktober 2001 16:35
An: Mayer Georg ICM N MC MI E71; 'Miguel A. Garcia'; Neil Deason
Cc: [email-masked]
Betreff: RE: [Sipping] 3GPP network hiding and session release req'ts

>Hello Neil and Miguel, 
> 
>some comments on the session release topic: 
> 
>> > 
>> > The graceful session release requirement (6.14.2) 
>> > would appear to necessitate a B2BUA in the 
>> > network. Where is that functionality expected to 
>> > feature within the various 3GPP x-CSCF entities? 
>> > 
>> 
>> My understanding is that the graceful session release is 
>> just needed for the prepaid service. As such, a B2BUA is 
>> probably needed. This functionality will be part of the 
>> "prepaid Application Server". So it is not part of any 
>> x-CSCF. If you are not a prepaid user, you don't need 
>> to route your session through this special application 
>> server. 
> 
>My understanding is that pre-paid is only one of the reasons 
>why the 3GPP 
>IMS network needs to release a call. We also have the case 
>when a user walks 
>out of radio coverage - then it would be best if the assigned 
>outbound proxy 
>(P-CSCF) would immediately clear all calls the user is 
>involved in (just 
>remember: the user gets charged for these calls, as long as it is not 
>indicate via SIP-signalling that the call is cleard). 

That is certainly one possible way to do charging, but it is not 
the only way. You could tie charging to the SIP signalling, or 
you could charge for the bearer instead. As the bearer seems to be 
the real resource here (at least the most scarce one), pre-paid 
tied to the bearer seems like a realistic alternative. 

Regards, 
Sean Olson 
Ericsson Inc.

---

From: Michael Hammer <[email-masked]>
Date: Mon, 22 Oct 2001 11:35:33 -0400

Georg,

Assume that the S-CSCF informs the P-CSCF of the maximum amount for which
it can reimburse the visited network.  Once, that limit is reached,
wouldn't the visited network indicate to the GGSN that the bearer stream
should no longer be forwarded in either direction?  If that
happened, upon detection of loss of bearer, the SIP mechanisms would
attempt to re-establish the call and discover that UE A is not permitted,
or UE B can attempt to complete the call and based on its permissions be
able to complete the call-back.

Are there any assumptions about the behavior of the UE's that should be
taken into account, even though that would be implementation
specific?

Mike

At 05:08 PM 10/22/2001 +0200, Mayer Georg  ICM N MC MI E71
wrote:

Hello
Sean et al,

sorry for the late
response, but I was away during the last week. Here are some comments on
your text below.

Assume A calls B. The
call is routed via P-CSCF1 (A's outbound Proxy in the visited network)
and S-CSCF1 (A's call control function in the home network) - I leave out
the entities for user B. The SIP signaling is sent via the P- and S-CSCF.
Additionally there is a GGSN over which User A sends the RTP media
streams. The RTP is also connected to P-CSCF1, which authorizes media
access etc.

UE A -----a----
P-CSCF1 ------b--- S-CSCF1 ---c--(cloud)-- UE B

I
I

I
I p

I--------r---
GGSN

a / b / c are SIP
interfaces, whereby a is over the Radio
interface.

p is the interface
over which P-CSCF controls the media of the GGSN, e.g. COPS
protocol

r is the media
interface - RTP streams are running here

Now some example
scenarios:

(1) Pre-Paid card runs
out of money.

(1a) As Pre-Paid is
handled by / at / behind the S-CSCF1 I would assume that a SIP BYE
message is sent from the S-CSCF towards the UE. When this BYE passes
through the P-CSCF1 it instructs the GGSN to release the
call.

Well - I imply here
that the S-CSCF1 can generate a BYE message for an established session
for which it is a (call-stateful) proxy.

Assume the S-CSCF1 is
not able (due to protocol restrictions) to send a BYE message. Then it
has to send SOMETHING in order to instruct the P-CSCF and the UE to
release the RTP session. This something can be (1b) part of SIP or could
be (1c) non-SIP signaling. For both cases (1b and 1c) still a BYE message
has to be generated by one of the UEs (or somebody else in the network)
in order to clear the signaling states etc..

My personal
opinion:

- (1c) looks to me
like a way around SIP - like somebody messing around in call control
without using the proper protocol.

- (1b) sounds better,
but it is additional effort for specification and implementation,
furthermore there is already.

- (1a) is the most
consequent way of doing it and solves the problem with already existing
mechanisms.

(2) User walks out of
Radio Coverage.

(2a) P-CSCF releases
the bearer immediately and generates a BYE message on behalf of the user
- perfect, but currently not allowed in SIP

(2b) P-CSCF releases
the bearer and sends out a up-till-now unknown SIP request in order to
request another entity (S-CSCF or UE B) to send a BYE request - Problem:
Trigger of media release is not the SIP BYE signaling, this means we have
an inconsistency here.

(2c) P-CSCF sends out
the request to somebody else to generate a BYE and releases the bearer
when the BYE arrives. Ok, I agree that we should not do that, as this
might mean charging until the BYE is received, although the user has no
access to the service.

Therefore the network
initiated session release question really boils down to the question if a
Proxy can generate a BYE message for an existing call on its own. Maybe
from the above given examples it became clear, that it would be
preferable to allow this Proxy behaviour.

The next argument
might then be that it is demanded that we want these specific proxies to
act as B2BUAs. As I already lined out in another message this is not as
easy as it sounds, as the B2BUA brings some further complication into the
network. So maybe we can discuss the pros and cons for BYE generation at
a Proxy for a while.

Thanks in advance and
keep on signaling

Georg

Georg Mayer - Siemens
AG

-----Ursprüngliche
Nachricht-----

Von: Sean Olson (EUS)
[mailto:[email-masked]]

An: Mayer Georg ICM N MC MI E71; 'Miguel A. Garcia'; Neil
Deason

Cc: [email-masked]

Betreff: RE: [Sipping] 3GPP network hiding and session release
req'ts

These
are all very good points. I am not trying to say
that

SIP signalling cannot be
used to tear down a session. In

most cases, this is
exactly what will happen. But in extraordinary

cases, it is also useful
to be able to use other sources of information

to know when to tear
down a session. Loss of bearer is one of these.

Assuming that you are
doing time-based charging, then you want

your source of charging
events to be as accurate from a time

perspective as possible.
In this case, I believe loss of bearer to be

a superior source of
information and it should be factored into any

pre-paid solution that
is time-based. Again, I am not saying that a

BYE should not be taken
into account. I am merely saying that if

you have a more timely
source of information about loss of bearer,

then you should use that
in a pre-paid solution.

Best
Regards,

Sean
Olson

Ericsson
Inc.

-----Original
Message-----

From: Mayer Georg ICM N MC MI E71
[mailto:[email-masked]]

Cc: [email-masked]

Subject: AW: [Sipping] 3GPP network hiding and session release
req'ts

Hello Sean et al,

> That is certainly
one possible way to do charging, but it is not

> tied to the bearer seems like a realistic alternative.

Well, we had already
some discussion about that subject. I want to summarize my opinion on
that.

The bearer (media
session) is established due to the SIP signaling going on on the call
control level. This means that we first need some SIP signalling and then
can send the media packages. That's why we need a signaling protocol.
Using SIP we achieve a lot of important things, as for example the states
in the different proxies / CSCFs and we can also get the information that
is needed for charging. Please note also that the charging states are
available in the home network whilst the media is not neccesarily routed
via the home network, the P-CSCF is in control of the bearer (via some
other magic I do not want to dwell in here).

If we now want to tear
down the session we need "some means" to tear down the session
when the session release in the network occurs. From my point of view
these means must be SIP means, because that's why we have a signaling
protocol - it is there to control the call. Only sending a BYE will cause
the states in the proxies and UEs to go back to null-states. And only a
BYE should be the trigger point for the P-CSCF to order release of the
bearer. If we have other means, then we need to standardize a new
protocol between the entity that finds out about the need of session
clearing (i.e. the S-CSCF in the home network) and the entity in control
of the bearer (i.e. the P-CSCF in the visited network). Then I would dare
to ask why we need SIP to establish but not to tear down sessions.

Keep on signaling!

Georg

Georg Mayer - Siemens
AG

-----Ursprüngliche
Nachricht-----

Von: Sean Olson (EUS)
[mailto:[email-masked]]

An: Mayer Georg ICM N MC MI E71; 'Miguel A. Garcia'; Neil
Deason

Cc: [email-masked]

Betreff: RE: [Sipping] 3GPP network hiding and session release
req'ts

>indicate via SIP-signalling that the call is
cleard).

That is certainly one possible way to do charging,
but it is not

the only way. You could tie charging to the SIP
signalling, or

you could charge for the bearer instead. As the
bearer seems to be

the real resource here (at least the most scarce
one), pre-paid

tied to the bearer seems like a realistic
alternative.

Regards,

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