Subject: [Sipping] Proposal for a solution to "3G Call Teardown Requiremen t"

From: Mayer Georg ICM N PG SP ST SN 1 <[email-masked]>
Date: Tue, 30 Oct 2001 19:04:09 +0100

Hello,

I would like to dwell a little bit more into the SUBSCRIBE/NOTIFY solution
proposal and I want to do this from the 3GPP Architecture perspective, as
this shows the additional requirements / conditions that exist for our
specific request.

Base-Scenario:
After UA-A has been assigned to P-CSCF, it registers at S-CSCF. After
successful registration, P-CSCF subscribe at the S-CSCF to an event package
that provides information about UA-A. Means the S-CSCF is able to send
NOTIFY requests at any time to P-CSCF.
At some point in time UA-A calls UA-B.

Alternative 1: S-CSCF initiated call-release
The S-CSCF determines a need to release the A-B call. It sends a NOTIFY with
the event "Release-Call-ID" and the additional information "Call-ID-234269"
(or in what ever notation) to the P-CSCF which immedately drops the bearer.
At the same time it sends a REFER message to UA-A and instructs it to send a
BYE message for Call-ID 234269. 

Some clarifications:
a) the NOTIFY to P-CSCF gurantees that the bearer is released, i.e. the
argument of fraud potential in the UE has gone away. 
b) the REFER(->BYE) method in this scenario is used in order to clear the
SIP entities involved in the call (P-/S-CSCFs and UE-B), so it will not
mandate any bearer interaction and therefore will not be handled by the
P-CSCF. The user no longer has a reason not to send the REFER.

If we want to have a secure UA, then we can have a check in there which
says: "send the BYE, which was requested by the REFER only if the bearer was
released before (by the P-CSCF/GGSN). 

Alternative 2: P-CSCF initiated call-release
UA-A walks out of radio coverage. This is detected by P-CSCF. Now P-CSCF
drops the bearer (same situation as in Alternative 1) and then sends a REFER
method to UE-B, in order to instruct it to send a BYE message. As the bearer
has already been released there will be no reason for UE-B to NOT send the
BYE. 

We could even simplify the whole thing by demanding that whenever P-CSCF has
to release the bearer due to another reason then  a BYE message (i.e. due to
NOTIFY from S-CSCF or UE-A out of radio coverage), it shall generate a
REFER(->BYE) request and send it to UE-A if available, else send it to UE-B.
Then S-CSCF in Alternative 1 would not have to send the REFER on its own.
But that is a detail.

Well, I have to admit that this approach still has an uncomfortable
side-effect: It opens the door for malicious entities to send REFER methods
to the UE - we all know that this is the second side of fraud-potential to
the REFER method (the first one is that the UE ignores the request). Now,
this is right but this argument is really true for all messages now. At any
time the UE needs to check a message received from the outside if it can
accept that message from the specific sender. 

I know - this sounds very complicated, but in my eyes it is much more easier
then a B2BUA and much more secure then a pure REFER soulution. And it seems
like a SIP-based solution that would fit into the 3G architecture. 

Thanks for reading and keep on signaling!
Georg (heading for a compromise)

_______________________________________________________
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: Roy, Radhika R, ALCTA [mailto:[email-masked]]
> Gesendet: Dienstag, 30. Oktober 2001 17:44
> An: [email-masked]; [email-masked]
> Cc: [email-masked]
> Betreff: RE: [Sipping] 3G Call Teardown Requirement
> 
> 
> Hi, Dean and Sunil:
> 
> While it is good to address some of the solutions in the 
> context of the 3G
> architecture, it is always better to generalize the solution. 
> For example, 
> 
> 1. Loss of bearer can be equally good for wire-line as well 
> as wireless
> (wireless LANs, cellular wireless, etc.) network.
> 
> 2. Generation of BYE by a SIP (B2BUA) proxy (instead of 
> saying P-CSCF etc.)
> 
> 3. Services offered by a SIP proxy that is not UA's outbound 
> proxy or UA is
> not directly communicating (instead of specifically saying 
> services provided
> by a proxy that is located in the home network while the user 
> in the visited
> network, etc.)
> 
> 4. Event packages related to SIP services among UAs and multi-proxy
> environment (e.g., for 3G arch: UE A <-> P-CSCF <-> S-CSCF 
> <-> UA B, etc.)
> 
> The idea is that any solutions or SIP extensions should be 
> applicable to a
> wide variety of things what Dean has just started to articulate in his
> requirements including 3G's specific architecture.
> 
> More comments inline [RRR].
> 
> Best regards,
> 
> Radhika R. Roy
> [email-masked]
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 30, 2001 10:26 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sipping] 3G Call Teardown Requirement
> 
> 
> Dean,
> 
> Some suggestions of my understanding on some of the open questions .
> Comments inline[SC] . These may or may not be relevant as it 
> does not have
> much information on the SIP protocol specific issues, but on 
> more relevant
> 3GPP "lower layer" aspects.
> 
> Regards
> Sunil
> > -----Original Message-----
> > From:	Dean Willis [SMTP:[email-masked]]
> > Sent:	29 October 2001 15:34
> > To:	sipping
> > Subject:	[Sipping] 3G Call Teardown Requirement
> > 
> > 
> > All this B2BUA vs Proxy discussion seems to have gone wide 
> of the mark.
> > Let's get back to some fundamentals:
> > 
> > REQUIREMENT: We must be able to release resources 
> associated with a call
> > in
> > the event of loss of signaling to all mobile terminals 
> involved in the
> > call.
> > 
> > Open question #1: How do we recognize that this condition 
> has occurred?
> > 
> --------------------------------------------------------------
> ------------
> > -
> > 
> > Proposals:
> > 
> > 1A) Use a timer on some node on the SIP signaling path, and 
> assume that
> > the
> > error has occurred if no SIP signaling is seen for some 
> period of time.
> > 
> > 1B) Detect loss of media-path signals or bearer at some 
> intermediary that
> > monitors RTP or RTCP.
> > 
> > 1C)  Report loss of bearer from a lower layer in the network.
>   [SC] This seems to be ok. I think that this information is 
> available at
> the lower layers in the network. A mechnism  is required to 
> delivery this
> information  from the lower layer (i.e. IP level) to the SIP 
> application
> layer. The GGSN has IP level connectivity to the P-CSCF.  
> 
> [SC] So a means to send this indication from the GGSN at an 
> IP level to the
> P-CSCF at the SIP level is required. Any known solutions for this?
> 
> [RRR] Probably, a new protocol is needed for communications 
> between the
> network layer entity and the application layer SIP entity. 
> Please note that
> it is not about the loss of bearer only, it can be resource 
> reservation as
> well and, a proxy may need to signal that the resource 
> reservation needs to
> be made for a given call (an analogy can be IETF's Bandwidth 
> Broker where
> the BB can coordinate the resource reservation contacting the 
> end-to-end
> entities). A policy server may also be involved. A lot of 
> other interesting
> things can be imagined. This is good for both wire-line and wireless
> network.
> 
> [SC] 3GPP details: For 3GPP the lower layers are complex (but 
> this is not
> relevant here), and the physical entites withing the GPRS PS 
> domain are
> physically distributed. However the issue is still the same.  
> In 3GPP the
> RNC (Radio Network Controller) will be aware of the loss of the radio
> connection it is managing. Its passes this information on the 
> SGSN (using
> the "lower layer" protocol: RANAP). This inturn can pass the 
> information to
> the GGSN (using the "lower layer" protocol: GTP).  So the 
> GGSN can be aware
> of the loss of the radio connections associated with a 
> particular GPRS PDP
> context.
> >  
> > Open question #2: How do we signal that this condition has 
> been detected?
> > ------------------------------------------------------
> > 
> > Proposals:
> > 
> > 2A) Generate a BYE for the call from an "additional 
> endpoint" which is
> > included in the signaling path by the architecture. This 
> might be a B2BUA,
> > or it might be a third-party controller, or it might be 
> something akin to
> > a
> > conference bridge, etc.
> > 
> 	[SC] This seems to be ok.  Assuming that the P-CSCF is able to
> generate a BYE, it could generate a BYE with a reason for 
> sending it to be
> something like "loss of radio connection". This would be for 
> the case loss
> of radio connection is detected towards a mobile that the P-CSCF is
> associated  with.
> 
> [RRR] If a proxy (B2BUA) can generate a BYE (as if, acting as 
> third party),
> it simplifies many things. However, we need to have "a common 
> agreed upon
> standard" for the B2BUA proxy that provides global 
> interoperability leaving
> no room for ambiguity. This is a very critical need (although 
> scalability
> may be a matter of implementation choices - alternative 
> proposals may also
> be compared).
> 
> > 2B) Use third-party control mechansims, such as a REFER.
> > 
> > 2C)  Use a SUBSCRIBE/NOTIFY mechanism of some sort.
> > 
> 	 [SC] This seems to be ok.  Assuming that the P-CSCF is able to
> generate a BYE, it could generate a BYE with a reason for 
> sending it  to be
> something like "network initiated release".  
> 
> [RRR] I am assuming that this is the case for the B2BUA (case 
> 1A) and the
> reason codes need to be defined as appropriate.
> 
> [SC] This would be for the case
> where the network  (e.g. S-CSCF or Application Server etc ) decides to
> release a session ( e.g. expiry of pre paid) and indicates 
> this using NOTIFY
> towards a network  entity capable of sending BYE . The  P-CSCF could
> generate a BYE with the appropriate reason.
> 
> [RRR] Your assumption is that P-CSCF is only authorized to 
> send "BYE," not
> P-CSCF. This is not generalized enough. Why are we providing the
> restrictions: 1. Only P-CSCF will send BYE, 2. S-CSCF will 
> only communicate
> via SUBSCRIBE/NOTIFY for sending a BYE by P-CSCF and, S-CSCF 
> will not be
> able to send BYE, and 3. Not extending SUBSCRIBE/NOTIFY up to 
> the UA for
> sending BYE (that may be more appropriate per SIP rule)?
> 
> > 2D) Use a non-SIP protocol.
> > 
> > 
> > Open questtion #3: Having been signalled that the event has 
> occurred, how
> > do
> > we execute the tear-down? Is this specific to the 
> particular resource
> > being
> > released?
> > -----------------------------------------------------------------
> > 
> > Proposals:
> > 
> > 3A) All resource-holding nodes are in the SIP path, so a 
> SIP teardown
> > results in release of media resources
> > 
> > 3B) All resource-holding nodes are either in the SIP path, or are
> > controlled
> > by nodes in the SIP path that can reconginze a SIP teardown 
> and command
> > appropriate action.
> > 
> 	[SC] This seems to be ok. The BYE generated (for 
> network initiated
> release, loss of radio connection etc) should be sent along 
> the SIP path and
> the "normal" way of releasing the held resources should be 
> triggered. This
> would ensure all the entties in the SIP path are aware of the 
> session being
> ended (for whatever reason) as soon as this occurs.
> 
> 	The media resources (user plane resources)  release 
> would also be
> triggered by the BYE at the SIP application level. In 3GPP the is a
> interaction with the GGSN when BYE is processed in the P-CSCF when the
> optional COPS interface is present between PCSCF/PCF - GGSN.  
> This COPS
> transactions would be the point media resources are no 
> loonger allocated to
> a specific user.
> 
> 	3GPP details: The media path may be present between the Mobile -
> RNC, RNC - SGSN, SGSN - GGSN  for the originating/terminating 
>  mobile  and
> these can be released using the standard GPRS mechanisms to 
> de-activate a
> PDP context (see TS 23.060/ TS 29.060 for detailed 
> information).  The PDP
> Context de-activation can be initiated from the GGSN as well 
> as from the
> Mobile.  In case of loss of radio connection, the GGSN would 
> be able to
> initiate the de-activate PDP context procedure for the 
> revelant PDP contexts
> if necessary. 
> 	I am not sure if there are any resources holding nodes between a
> GGSN for Mobile A (Originating) and GGSN for Mobile B 
> 	(Terminating).  If there are, these should also be cleared down.
> 
> [RRR] As soon as we find a solution for item 2 that an entity 
> can send BYE,
> we can address item 3 more conveniently.
> 
> > 3C) Some resource holding nodes are in the SIP path, and 
> others in the
> > bearer path. Each executes a teardwoin as appropriate to its nature.
> > 
> > 3D) As with 3C, except that there may be a control protocol 
> between the
> > node
> > detecting the SIP or  bearer teardown and the node holdin/releasing
> > resources.
> > 
> > Any other cases?
> > 
> 	[SC] There is another issue which may (or may not) be 
> related. It
> shows another example of the use of NOTIFY from the S_CSCF to 
> the P-CSCF to
> indicate an event
> 
> [RRR] Yes, there seems to a need to describe events between 
> the P-CSCF and
> S-CSCF (or even UE A <-> P-CSCF <-> S-CSCF <-> UE B) other 
> than BYE. These
> events can be generalized in a way that goes beyond 3G requirements
> (probably I will try to be more specific proposal in this area later).
> 
> 	[SC] start 
> 	REQUIREMENT: We must be able to release "resources" in the "old"
> P-CSCF when the mobile accesses a "new" P-CSCF
> 
> 	In 3GPP the Mobile can access a separate GPRS network in another
> country (a mobile driving between France and Germany say)  
> the connection to
> the old GPRS network is (first) lost and a new GPRS 
> connection is (then)
> established at the "lower layers" and in some cases, a new 
> signalling PDP
> contexts is allocated, a new IPV6 address is allocated, and a 
> new P-CSCF is
> allocated.  In this case the "old" and "new" P-CSCF are allocated
> 
> 	Note that In some cases, there existing signalling 
> context is setup
> between a "new"  SGSN and the "old" GGSN via the normal GPRS 
> procedures (see
> TS 23.060). This is the normal preferred case and the same 
> GGSN, a same IPV6
> address is used, and  the same P-CSCF is used. Hence this is 
> no impact at
> all to the SIP, and not discussed anymore even though this 
> the more the
> normal case.
> 
> 
> 	Open question #4: How do we recognize that this condition has
> occurred?
> 	
> --------------------------------------------------------------
> -------------
> 
> 	Proposals:
> 
> 	4A) This is detected in the S-CSCF at the time of new 
> registration.
> The Identity of the P-CSCF is transported in the Register 
> message and this
> value of the P-CSCF identity is compared to that stored in 
> the S-CSCF for
> the current registration. The identity of the P-CSCF as well 
> as the visited
> network identity need to be transported at SIP level.
> 
> 
> 	Open question #5: How do we signal that this condition has been
> detected?
> 	------------------------------------------------------
> 
> 	Proposals:
> 
> 	5A)  Use a SUBSCRIBE/NOTIFY mechanism of some sort.
> 
> 	Could use NOTIFY to inform the "old" P-CSCF to release 
> all resources
> associated with a particular user. In this case, resources 
> are the the SIP
> signalling related data which was stored to allow SIP 
> messages to be routed
> between the P-CSCF and the S-SCSF (possibly via the I-CSCF)
> 	[SC] end 
> > --
> > Dean
> > 
> 
> _______________________________________________
> 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