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

From: [email-masked]
Date: Tue, 30 Oct 2001 20:30:02 +0200

Some comments inline [BG]

> -----Original Message-----
> From: ext Mayer Georg ICM N PG SP ST SN 1
> [mailto:[email-masked]]
> Sent: 30. October 2001 19:04
> To: 'Roy, Radhika R, ALCTA'; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: [Sipping] Proposal for a solution to "3G Call Teardown
> Requiremen t"
> 
> 
> 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.
P-CSCF can not drop the bearer. If there's a Go interface between PCF and
GGSN, then PCF can request from GGSN to close the gate. In case the terminal
had only one PDP context at GPRS level (used for both SIP signalling and
media) then the terminal is made unable to send a BYE. Whether a separate
PDP context will be used for SIP signalling or not, it is still to be
decided. 
Another case: The terminal is able to merge more than one media session into
one PDP context (this has already been decided). That is, terminal A after
calling B has a PDP context with some certain bandwidth, and when it calls C
in addition, it will modify the existing PDP context to fit media with C in
it. If you request from GGSN to close the gate for the PDP context, both
calls will be dropped. This case is only problematic when CSCFs ask the gate
to be closed for a reason different than going out of coverage. 

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

One reason: there is no motivation. The network has already dropped its
call, then why to send a BYE? To help the network clearing the call states? 
 
> 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
> 

_______________________________________________
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: Mayer Georg ICM N PG SP ST SN 1 <[email-masked]>
Date: Tue, 30 Oct 2001 19:50:23 +0100

Hello Gabor,

thanks for your comments - I shoot back below ;)

Keep on signaling (and enjoy the Belgium beer)!
Georg

> Von: [email-masked] [mailto:[email-masked]]
> Gesendet: Dienstag, 30. Oktober 2001 19:30
> An: Mayer Georg ICM N PG SP ST SN 1; [email-masked]; 
> [email-masked];
> Betreff: RE: [Sipping] Proposal for a solution to "3G Call Teardown
> Requir emen t"
> 
> 

If there is no Go Interface, i.e. no connection between P-CSCF and GGSN,
then the network per defintion has no means to control the bearer. So it can
only ask the user very politely to release the bearer when a BYE is sent.
This is true for any solution. 

> to be closed for a reason different than going out of coverage. 

This should be for further study - we need input from operators here if such
cases should be really handled differently. This agrument puts away ANY
solution that requests the GGSN to release the bearer - so it means we are
dependend on the BYE that is sent by somebody. I doubt if this is the case. 

> call, then why to send a BYE? To help the network clearing 

Yes, there is a good motivation: the REFER method. I can ask that question
(that you stated) for any method. 

And another reason: If the network asks the UE by sending REFER then this
should be motivation enough. 

> > > Sipping mailing list  
> http://www1.ietf.org/mailman/listinfo/sipping

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 30 Oct 2001 13:54:57 -0500

Hi, Georg:

Excellent!

We are coming closer to have the generalized solution. Let me summarize in
that direction:

1. You are assuming that no proxy is acting like B2BUA. (It is a good
alternative where people will be happy to see that there is no controversy
whether SIP rules are breaking or not).

2. If a SIP services are offered where there is a dependency among multiple
SIP proxies, event packages (SUBSCRIBE/NOTIFY) and REFER will be used as
follows: 

2a. UE <-> Proxy: REFER
2b. Proxy1 <-> Proxy2 <-> Proxy 3: SUBSCRIBE/NOTIFY

3. Each proxy will create the event packages (SUBSCRIBE/NOTIFY) as it is
responsible or need to know or to be aware of.

4. Proxies will communicate with UEs using REFER, where appropriate,
conveying the information in accordance to the event that takes place either
with itself (e.g., P-CSCF is communicating with GGNS for media) or due to
the events taking place among the proxies (e.g., S-CSCF is notifying P-CSCF
that subscription is over).

5. Security (e.g., fraud in sending the REFER, SUB/NOT) for all messages
will be considered in the context of the bigger SIP security framework.

I hope that I have been able to capture the essence of your proposal in a
generalized way.

You can easily imagine that I am envisioning a generalized solution for all
networking conditions including 3G's architecture.

Please let me know, if you have any questions.

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: Mayer Georg ICM N PG SP ST SN 1
[mailto:[email-masked]]
Sent: Tuesday, October 30, 2001 1:04 PM
To: Roy, Radhika R, ALCTA; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: [Sipping] Proposal for a solution to "3G Call Teardown
Requiremen t"

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:
successful registration, P-CSCF subscribe at the S-CSCF to an event package

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. 

> wide variety of things what Dean has just started to articulate in his

---

From: [email-masked]
Date: Tue, 30 Oct 2001 21:05:24 +0200

Some more comments inside [BG]

> has already been released there will be no reason for UE-B to 

[BG] As the terminal can not be forced but just 'instructed' to send a BYE,
the network has to be prepared for the case when the terminal will NOT send
the BYE. How to clear the call states then?
It may happen even with well-intentioned terminals: it goes out of coverage
right after getting the REFER or BYE is just lost over the air interface.

> accept that message from the specific sender. 

[BG]You forgot sg: for this approach to work one proxy has to subscribe to
another proxy as many times as many terminals register with the network.

---

From: [email-masked]
Date: Tue, 30 Oct 2001 19:35:28 -0000

All,

A couple of points which may be worth considering

1) For the general case, there are interesting 3GPP scenarios that need to
be addressed when loss of radio connection can occur. 

For example (for illustration only), consider two mobile users who are
involved in a call and these users happen to be in a train going between
London and Paris, and at some point in time, the radio connection to the
network will be lost as there is no radio coverage in the tunnel, and in
this case, for both the mobile users the connection is lost.  Somehow we
need to release the ongoing SIP sessions to the home network S_CSCF which
could be any country say, Australia as the home netwotk for user A and
Finland for user B. (users A and B happen to be roaming in UK visited
network where the GGSN and the P-SCSF is located).  The home networks are
not aware that the users are not communicating any longer and the SIP level
indication would be nice (e.g. so that the pre-paid credit is maintained).
It would be nice to have a solution that can be applied in these cases as
well. So it may not be a good idea to rely on a non existent radio
connection to transfer a message to a mobile  asking it to send another
message.

One such solution which could overcome these types of radio failures could
be to have the possibility to send a SIP BYE message from a network entity
that is aware that the radio connection no longer exists. This may be sent
from  the P-CSCF.

2) Use of REFER at the UE:

I also share the concerns of another operator of using REFER at the UE
because of the extent of fraud potential it exposes. 

So if there are other solutions, it would be nice to consider them.

As operator view was from Duncan who wrote:

One concern network operators may have with supporting the REFER method is
the ability of a rogue network to defraud a genuine customer by sending a
REFER to the terminal to (for example) force it to initiate an INVITE to a
premium rate number.

At the moment, I'm not aware of any mechanism for the terminal to be able to
guarantee the integrity of a received REFER request?

I appreciate that there may be some very nice uses for the REFER method as
well, but concerns are still there...

Regards

Sunil

> From:	Roy, Radhika R, ALCTA [SMTP:[email-masked]]
> Sent:	30 October 2001 18:55
> To:	Mayer Georg ICM N PG SP ST SN 1; [email-masked];
> Subject:	RE: [Sipping] Proposal for a solution to "3G Call Teardown
> Requir emen t"
> 
> Hi, Georg:
> 
> Excellent!
>

---

From: [email-masked]
Date: Wed, 31 Oct 2001 11:25:31 +0200

One comment below [BG]

> From: ext [email-masked] [mailto:[email-masked]]
> Sent: 30. October 2001 20:35
> To: [email-masked]; [email-masked]; [email-masked];

[BG]This could be solved very easily: when a REFER is received by a terminal
which instructs (and not forces) it to initiate an INVITE, then the terminal
will require user interaction by displaying say, 'you were requested to call
the following recipient: ... Do you want to proceed?'  And user could press
either the green or red button.
 
> > conveying the information in accordance to the event that 
> takes place
> > either
> > You can easily imagine that I am envisioning a generalized 
> solution for
> > all
> sends a NOTIFY
> > with
> instructs it to send
> > says: "send the BYE, which was requested by the REFER only 
> if the bearer
> > was
> then sends a
> > REFER
> message. As the
> > bearer
> whenever P-CSCF
> > has
> message (i.e. due
> > to
> send it to
> > UE-B.
> messages now. At
> > any
> much more
> > easier
> soulution. And it
> > seems

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 31 Oct 2001 02:18:13 -0800

> right after getting the REFER or BYE is just lost over the 

That's right. Using a REFER message for network-initiated teardown goes
against the don't trust the handset assumption/requirement.

Robert.