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

From: [email-masked]
Date: Tue, 23 Oct 2001 12:05:52 +0300

Hi!

Concerning this prepaid (run-out-of-credit) problem,
I see a SIP compliant solution:

 Send a REFER to the UA to trigger a BYE for a
 run-out-of-credit session.

 Below the general idea (without abnormal cases) is
 depicted (AS = Application server for prepaid service):

 UA A         P-CSCF          AS           UA B
 
  | --INVITE--> | --INVITE--> | --INVITE--> |
  | <--200 OK-- | <--200 OK-- | <--200 OK-- |
  | ----ACK---> | ----ACK---> | ----ACK---> |
 
 Session established...
 
 Later the credit goes to zero...
 
  | <--REFER--- | <--REFER--- |
  | ----BYE---> | ----BYE---> | ----BYE---> |
  | <--200 OK-- | <--200 OK-- | <--200 OK-- |

 If the UA ignores the REFER, then some means
 at the outbound-proxy (i.e. P-CSCF) have to enfore
 the policy, e.g. the release of the media streams.
 
 I could immagine, that the P-CSCF sets a timer
 (e.g. 5 s) and cuts media steams, in case
 no BYE is sent by the UA.

Any comments?

cheers,
 Bernie

>-----Original Message-----
>From: ext Roy, Radhika R, ALCTA [mailto:[email-masked]]
>Sent: 22. October 2001 19:23
>To: Michael Hammer; 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
>
>
>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
>

_______________________________________________
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: Tue, 23 Oct 2001 12:45:36 +0300

Hi Bernhard:

Some people have many concerns on the REFER method. 
There are concerns on security issues (some peole don't
want to allow the REFER method in a terminals, as it could
be used for abuse). Further more, some non-compliant terminal
could just ignore the REFER, and therefore, no BYE is sent.
Then you need the fallback solution based on timers, and
therefore, why bothering with a REFER method if you need the
timer?

/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