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

From: [email-masked]
Date: Tue, 23 Oct 2001 13:58:48 +0300

Hi Miguel!

Thanks for your comments! Please find mine below:

- General implementation of REFER in terminals:
  
  I assume for other scenarios (conference calling,
  call tranfer, ...) the REFER method will be implemented 
  anyway in terminals.

- security issues and abuse:

  - For the prepaid case, I could immagine a security assocation
    between the prepaid AS (or home network) and the terminal
    to authenticate REFERs
    I do not see a special case here, as there anyway need to
    be means to authenticate SIP requests.

  - alternatively REFERs could be authenticated by the P-CSCF
    on behalf of the UA (e.g. in case the above leads to an
    implementation problem) 

- For terminals not supporting the REFER method, I see
  some possible solutions.

  - 3gpp needs some other mandatory features in terminals,
    e.g. all the stuff related to the REGISTER. So why not
    to mandate also REFER. 

  - Alternativly, it could be stated, that the prepaid service
    can only be provided to terminals, which understand REFER
    or at least understand the REFER which triggers a the BYE

  - Some means with the Supported header could tell the
    prepaid AS, whether the terminal supports the REFER.
    If REFER supported in UAC, it works just fine;
    If no support indicated by the UAC, there could be 
    a more ugly solution, e.g. just cutting streams (at
    P-CSCF) without timers,send the REFER to the other
    party (maybe using  OPTIONS AS->UAS before call-setup
    to query the support of REFER), B2BUAs, ...  

Comments?

cheers,
 Bernie

>-----Original Message-----
>From: ext Miguel A. Garcia [mailto:[email-masked]]
>Sent: 23. October 2001 12:46
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]
>Subject: Re: AW: [Sipping] 3GPP network hiding and session release
>req'ts
>
>
>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
>
>[email-masked] wrote:
>> 
>> 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
>> >
>
>-- 
>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: Tue, 23 Oct 2001 14:19:04 +0300

Bernhard:

I am fine with your proposals. In fact, I was a defending cousel
of the REFERin 3GPP. I just said that not everybody seems to agree
with that proposal. And, particularly 3G operators, seemed to be
concerned with the abuse of the REFER. This concern is so much 
that they don't accept (so far) the REFER even in call transfer
scenarios.

/Miguel

---

From: Kim Liu <[email-masked]>
Date: Tue, 23 Oct 2001 08:30:34 -0400

> Thanks for your comments! Please find mine below:
[snipped]
>     e.g. all the stuff related to the REGISTER. So why not

The only issue I see with this is that making such
things mandatory in the 3GPP environment would seem
to require that 3GPP endpoints be always endpoints
and not proxies.  That is, it sounds like you could
not have a wireless 3GPP last-mile-replacement to
act as a proxy for a group of non-3GPP SIP phones
without also mandating the same requirements.  (i.e.
no 3GPP enabled computers/PDAs functioning as SIP
proxies for fax machines, handsets, etc. on a local
LAN, bluetooth network, etc.  No SIP<->3GPP<->SIP.)

If no 3GPP endpoint is going to be allowed to 
function as such a gateway proxy, then it is a
moot issue.

-- 
Kim Liu  [email-masked]    :  Everyone is a darn fool for at 
Senior Software Engineer    :  least five minutes a day;
Lucent Technologies         :  wisdom consists of not 
Clearwater, FL, 33761       :  exceeding the limit