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

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 22 Oct 2001 12:22:34 -0400

George and Mike:
 
Let me try to generalize the scenarios as follows:
 
1. Service related features (e.g., pre-paid cards, etc.)
2. Network (bearer) related features (e.g., radio coverage, etc.)
 
In both situations, SIP UAs are not involved directly that can send BYE as
per SIP rule. However, per SIP rule, both session and media are also
terminated as soon as BYE is sent.
 
One of the solutions has been to make SIP Proxies as B2B UAs. This may not
be scalable or may have other problems. George also mentioned about
different alternatives: a. Extend SIP to allow proxy for sending BYE and b.
Non-SIP solution.
 
I think that non-SIP solution may be attractive. For example, service
related features (item 1) may be considered a kind of policy and, there are
some proposals how policy can be extended to accomplish this. The benefit of
this proposal is that SIP UAs can still keep its present behavior.
 
For the network related features (item 2), a policy server may also be
communicated by the network layer entity to signal the SIP UA to send the
BYE.
 
Any more thoughts?
 
Radhika

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

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

_______________________________________________ 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: Henry Sinnreich <[email-masked]>
Date: Mon, 22 Oct 2001 15:27:42 -0500

>I think that non-SIP solution may be attractive.
Nothing wrong with non-SIP solutions, as long as they fit the Internet
architecture, not garden walls like WAP gateways...

Beware of flamethowers :-)

Thanks, Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Roy, Radhika R, ALCTA
> Sent: Monday, October 22, 2001 11:23 AM
> To: Michael Hammer; Mayer Georg ICM N MC MI E71
> Subject: RE: AW: [Sipping] 3GPP network hiding and session 
> release req'ts
> 
> 
> George and Mike:
>  
> In both situations, SIP UAs are not involved directly that 
> can send BYE as per SIP rule. However, per SIP rule, both 
> session and media are also terminated as soon as BYE is sent.
>  
> One of the solutions has been to make SIP Proxies as B2B UAs. 
> This may not be scalable or may have other problems. George 
> also mentioned about different alternatives: a. Extend SIP to 
> allow proxy for sending BYE and b. Non-SIP solution.
>  
> I think that non-SIP solution may be attractive. For example, 
> service related features (item 1) may be considered a kind of 
> policy and, there are some proposals how policy can be 
> extended to accomplish this. The benefit of this proposal is 
> that SIP UAs can still keep its present behavior.
>  
> For the network related features (item 2), a policy server 
> may also be communicated by the network layer entity to 
> signal the SIP UA to send the BYE.
>  
> Any more thoughts?
>  
> Radhika
> 
> 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
> 
> 
> 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. 
>  
> 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
>  
>  
> (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 
> 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 
> - (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. 
>  
> (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 
> 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.
> 
> 
> 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
> 
> _______________________________________________ Sipping 
> mailing list http://www1.ietf.org/mailman/listinfo/sipping 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>