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

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 31 Oct 2001 11:00:50 -0500

inline [RRR]

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 5:18 AM

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

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

[RRR] Technically, Robert may be right. BYE can be sent by a UA for many
reasons that may include both media (network layer) and signaling/services
(application layer). For problems in the media level, a UA is supposed to be
informed via its network layer interface (SIP does not specify this).
Similarly, a UA can also be informed using SIP signaling messages which may
allow to think to send BYE. It is fair question why we cannot trust UA's
network layer interface so that the UA can issue BYE if there are problems
in the network layer because, in any case, media is end-to-end (UA <-> UA)?

Robert.

_______________________________________________
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: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 31 Oct 2001 11:39:36 -0500

inline [RRR].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 30, 2001 2:35 PM
To: Roy, Radhika R, ALCTA; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] Proposal for a solution to "3G Call Teardown
Requir emen t"

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.

[RRR] Not necessarily. Let me explain. 

[RRR] Media: UAa (London) <-> (GGSN-Tunnel) <-> UAb (Paris). SIP Signaling:
UAa <-> P-CSCF (GGNS-Tunnel) <-> UAb as well as 
P-CSCF (GGNS-Tunnel) <-> S-CSCF (Finland) and P-CSCF (GGNS-Tunnel) <->
S-CSCF (Australia). First, if GGNS detects a media failure, it is expected
that UAa's and UAb's network interface will be able to detect it and, BYE
can be sent by a UA accordingly. Now there will be other communications as
well: 1. GGNS <-> P-CSCF (GGNS-Tunnel) and, it is out-of-scope of SIP
signaling, 2. P-CSCF (GGNS-Tunnel) <-> S-CSCF (Finland) and P-CSCF
(GGNS-Tunnel) <-> S-CSCF (Australia) using SIP signaling (SUBSCRIBE/NOTIFY
event packages).

[RRR] In the above scenario, I did not use REFER for P-CSCF (GGNS-Tunnel)
<-> UAa (or UAb) for requesting to send a BYE by UAs assuming that this was
the media (GGNS) related event and, UAs network interfaces will be able to
take care of it. However, REFER may be used as a backup mechanism in the
event UAs network interfaces do not sense that there is a media failure (I
do not why UAs interfaces will not be able to get this information). Of
course, if it is a problem, REFER can be used between P-CSCF and UAa/UAb to
requesting to send a BYE.

[RRR] So, I do not see why P-CSCF (GGNS-Tunnel) needs to send BYE if the
above event packages are used.

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

[RRR] Security related to REFER needs to be addressed in the bigger context
of SIP security where all signaling messages need to be addressed. (Some
suggestions specific to REFER can also be looked into.)

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];
> [email-masked]
> Cc:	[email-masked]
> Subject:	RE: [Sipping] Proposal for a solution to "3G Call Teardown
> Requir emen t"
> 
> 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]
> 
> 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:
> 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]
> > 
> >

---

From: Michael Hammer <[email-masked]>
Date: Wed, 31 Oct 2001 12:08:17 -0500

I was thinking that of necessity, this would be a phased
operation.  First, politely inform the user agent to update the
session or leave; second, via the media, bluntly withdraw the resource
from the not-well-behaving end-system.  In that latter case, you get
the bearer layer informing the  signaling layer of the loss of
resources.

This does not necessarily mean the session ends, as this could also
simply be a loss of reserved resources and reversion to best-effort,
depending on the networks being used.  Although in the 3GPP case,
there may be circuit-switched resources that also release and causes the
session to end.

Mike

At 11:00 AM 10/31/2001 -0500, Roy, Radhika R, ALCTA wrote:

inline [RRR]

-----Original Message-----

From: Fairlie-Cuninghame, Robert
[mailto:[email-masked]]

That's right. Using a REFER message for network-initiated teardown
goes

[RRR] Technically, Robert may be right. BYE can be sent by a UA for
many

reasons that may include both media (network layer) and
signaling/services

(application layer). For problems in the media level, a UA is supposed to
be

informed via its network layer interface (SIP does not specify
this).

Similarly, a UA can also be informed using SIP signaling messages which
may

allow to think to send BYE. It is fair question why we cannot trust
UA's

network layer interface so that the UA can issue BYE if there are
problems

in the network layer because, in any case, media is end-to-end (UA
<-> UA)?

Robert.

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

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 31 Oct 2001 12:41:59 -0500

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 12:08 PM

 I was thinking that of necessity, this would be a phased operation.  First,
politely inform the user agent to update the session or leave; second, via
the media, bluntly withdraw the resource from the not-well-behaving
end-system.  In that latter case, you get the bearer layer informing the
signaling layer of the loss of resources.

[Roy, Radhika R, ALARC]  Yes,  I agree with you that REFER can be used to
remind the agent politely what has happened as a back-up. In fact, I have
used the same suggestion in my last email sent to address Sunil's questions.
However, as backward compatibility, those UAs do not rely on REFER, they
need to rely on their network layer interfaces.

This does not necessarily mean the session ends, as this could also simply
be a loss of reserved resources and reversion to best-effort, depending on
the networks being used.  Although in the 3GPP case, there may be
circuit-switched resources that also release and causes the session to end.

[Roy, Radhika R, ALARC]  Yes, you are right. That is another important
reason why it may not be appropriate to delegate the "right" of UAs (I mean
the callers/callees) to a proxy in all situations for sending BYE wherever
it is possible because BYE means both the end of the "session" and
termination of "media". In 3GPP scenarios, it appears that there is a
problem in "media," and, that does not mean that the callers/callees has
decided to terminate the session and as well as media. So, a BYE may not the
"ultimate" choice from caller's/callees' point of view. If there are
alternatives available (let us consider mobility for all technologies:
Wire-line network, Wireless LANs, 3GPP, etc), users still may like to
continue the session using different connectivity (media) if the primary one
fails.

[Roy, Radhika R, ALARC]  If you consider the B2BUA proxy case where a proxy
sends a BYE acting as a UA, still question remains: UAs of the proxy are not
the callers/callees and why will these B2BUAs be allowed to send BYE if they
are "not authorized" to do so by callers/callees because bills still need to
be paid by the callers/callees (although no SIP rules are broken)? I guess
that the policy issue also need to be addressed for the B2BUA case.

Mike

inline [RRR]

-----Original Message-----
From: Fairlie-Cuninghame, Robert [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, October 31, 2001 5:18 AM

Robert.

<http://www1.ietf.org/mailman/listinfo/sipping>