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

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 1 Nov 2001 07:19:11 -0800

Hi Mike,
 
Well unless SIP in 3G is just for a bit of routing and a lot of show then
you don't want to duplicate every SIP operation will another layer of
"network-trusted" operations. 
 
It is desirable that a network-initiated teardown (let's say one that is for
purely administrative reasons and not because or carrier layer errors) is
reliably sent to and enacted at all network elements and is best-effort
towards both user terminal device in a call. 
 
So if we are using SIP for signalling, we don't want to have to do a SIP
tear down and then a second, separate & independent "phased" tear-down. For
instance, if one of the user endpoints decides not to "play-along" with the
SIP teardown, you then need to have a separate protocol to locate and
contact the elements in the original SIP call-path and initiate the tear
down. 
 
That is the advantage of the B2BUA approach in this case. SIP requests for
network-initiated actions always start from the network interior and move
towards the endpoints (in both directions). Thus, if an endpoint does not
"play-along" then it is not preventing the information from reaching any
other network elements.
 
The REFER approach however means that the teardown indicate only originates
from one of the (untrusted) endpoints. Thus you would also need another
whole layer of protocol to do a "second" phase teardown - sure there's
nothing impossible but it seems to be adding a lot of unnecessary overhead. 
 
Regards,
 
Robert.

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 5:08 PM
To: Roy, Radhika R, ALCTA
Cc: Fairlie-Cuninghame, Robert; [email-masked]';
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Sipping] Proposal for a solution to "3G Call Teardown Requir
ement"

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]
<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
<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: Michael Hammer <[email-masked]>
Date: Thu, 01 Nov 2001 11:17:08 -0500

Robert,

I am not suggesting to duplicate protocols.  What I am pointing out
is that the problem at hand is a function of pushing (distributing)
control to the end-point, which happens to be beyond the physical control
of the network operator (point one).  It is also a function of the
separation of the session from the bearer control signaling (point
two).

The first phase is to attempt to use normal SIP signaling processes to
release or modify the session as required by policy controls.  The
fact that this may not be completely successful due to point one above
means that further measures are needed.  Thus the fall-back to the
media layer.  There must be a means for the network to control its
media resources.  Thus "plan B" is to close the gate when
the gatekeeper is being ignored.  This addresses misbehaving
endpoints.

In MGC-MGW architectures, MGCP or MegacoP provides the linkage between
the signaling and media layers.  I contend that this is also needed
even when no TDM is in the signaling or media paths.  The CSCF acts
as a gatekeeper (MGC) and the GGSN is the IP-IP MGW and controlled using
the Gi interface.  (The Gi interface seems to need both signaling
and bearer layer components.  I confess I have not read TS 23.060
yet, but perhaps the 3GGP folks could fill in here.)  That
corresponds to the MGCF and MGW controlled using the Mc interface
(=H.248).  Where the architecture is not decomposed, this may be an
internal proprietary interface mechanism.

What I belive Rohan is suggesting is for the CSCF to be able to inject
some policy control into the signaling where appropriate, but not to
become a middleman for every transaction as this becomes burdensome and
reduces scalability.

Mike

At 07:19 AM 11/1/2001 -0800, Fairlie-Cuninghame, Robert wrote:

Hi Mike,

Well unless SIP in 3G is just for a bit of routing and a lot of show
then

you don't want to duplicate every SIP operation will another layer
of

It is desirable that a network-initiated teardown (let's say one that is
for

purely administrative reasons and not because or carrier layer errors)
is

reliably sent to and enacted at all network elements and is
best-effort

So if we are using SIP for signalling, we don't want to have to do a
SIP

tear down and then a second, separate & independent
"phased" tear-down. For

instance, if one of the user endpoints decides not to
"play-along" with the

SIP teardown, you then need to have a separate protocol to locate
and

contact the elements in the original SIP call-path and initiate the
tear

down.

That is the advantage of the B2BUA approach in this case. SIP requests
for

network-initiated actions always start from the network interior and
move

towards the endpoints (in both directions). Thus, if an endpoint does
not

"play-along" then it is not preventing the information from
reaching any

other network elements.

The REFER approach however means that the teardown indicate only
originates

from one of the (untrusted) endpoints. Thus you would also need
another

whole layer of protocol to do a "second" phase teardown - sure
there's

nothing impossible but it seems to be adding a lot of unnecessary
overhead.

Regards,

Robert.

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

From: Michael Hammer
[mailto:[email-masked]]

[email-masked]; [email-masked];
[email-masked];

[email-masked]

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

ement"

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

end-system.  In that latter case, you get the bearer layer informing
the

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

inline [RRR]

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

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

<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: [email-masked]
Date: Fri, 2 Nov 2001 12:09:26 +0200

Some comments inline [BG]

> From: ext Roy, Radhika R, ALCTA [mailto:[email-masked]]
> Sent: 31. October 2001 18:42
> To: Michael Hammer
> Cc: Fairlie-Cuninghame, Robert; Bajko Gabor (NET/Budapest);
> [email-masked]; [email-masked]
> Requir ement"
> Sent: Wednesday, October 31, 2001 12:08 PM
> 
> 

[BG]The bearer level can only withdraw the resources if the user asks it to
be released or if there is no activity on the PDP context for a certain
time. Another possibility would be that the signalling layer asks the bearer
layer to withdraw the resources. In this latter case the signalling layer
does not need to be informed but the bearer layer need just to confirm the
operation.

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

[BG] I would use SUBS/NOTIFY to inform the UA what was happenned, and REFER
to ask it to perform some actions.

> circuit-switched resources that also release and causes the 

[BG] I think this is a separate issue. If UE goes out of coverage, it
certanly loses all the media connections and the session shall be
terminated.
If the bearer level stops being capable of providing some resources, then it
informs the signalling layer about. As the UA still might have some active
medias within the session, it is up to him to continue the session or send a
BYE to terminate it.

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

---

From: [email-masked]
Date: Fri, 2 Nov 2001 12:08:14 -0000

Radhika,

Perhaps my example was not clear to illustrate the point I am making.  I
will have another attempt to make the point a bit clearer regarding loss of
a radio connection serving a mobile during a session and what impact this
may have to SIP signalling and the associated services that may be running
in the network in a 3G cellular environment where service handling is
typically in the home network (e.g. pre-paid type applications in the home
network).

The point I am trying to make is that in the general case, there are
situations that lead to a loss of radio connection (due to a variety of
reasons which do occur {hopefully not too often!} in the cellular
environment) with both the mobile endpoints. 

Usually the radio condition can be good, and sessions are set up fine.
During an ongoing session the radio conditions can and do change(for various
reasons) and there are cases where the loss of radio connection is complete
i.e. is no longer possible to send any information (SIP session signalling
and/or any media).  So neither of the mobiles involved in the session is
able to communicate. But we still may have services running in the (home)
network and these need to be managed gracefully. 

In the general case, this means that mechanism are required at the SIP
session signalling level that do not prevent communication between network
entities when there is a loss of radio connection.

ANOTHER EXAMPLE SCENARIO:
Consider a scenario where session is setup between mobile user A  and mobile
user B. Both users happen to be roaming into the visited network in London
when attending an IETF meeting. During a session the radio connection to the
cell site fails.

User A-  home network is in Finland. The S-CSCF and any Application Servers
are in Finland. (say a pre-paid application is running in the Finnish
network). 
User B-  home network is in USA.  The S-CSCF and any Application Servers are
in USA.
The Mobiles A, RNC, SGSN, GGSN, P-CSCF are located in UK 
The Mobiles B, RNC, SGSN, GGSN, P-CSCF are located in UK 

User A calls User B and a SIP session is setup . This happens to be a voice
call, and the media is routed  directly between the GGSN  in the UK network.
As both are calling from the same hotel then happen to be allocated the same
cellular cell site. A typical cell site can easily be serving more than 100+
users. Then  the radio connections to the cell site the are lost (for
various reasons).  

i.e. The Mobile A -- RNC and Mobile B -- RNC radio connection fails during
an ongoing session for some reason

So neither Mobile A nor Mobile can communicate with the local cell site. The
Finnish home network may not aware that there has been a problem during an
ongoing session with the local radio connection and that User A is no longer
being provided the service he was supposed to be provided.  I am sure User
would not be very happy and would complain to his operator if all the credit
on the pre-paid card was expired because the home network was not aware that
the session was terminated when there was a loss of radio connection in the
UK and assumed that there was a long call. I am also sure that Finnish
operator will not be happy with the UK operator in these cases.

Hopefully this helps to show some of the difficult cases that can do
sometimes occur in a 3G cellular environment.

Regards

Sunil

> From:	Roy, Radhika R, ALCTA [SMTP:[email-masked]]
> Sent:	31 October 2001 16:40
> To:	[email-masked]; [email-masked];
> [email-masked]
> Cc:	[email-masked]
> inline [RRR].
> 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]
> 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]
> > 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: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 7 Nov 2001 15:26:32 -0500

Hi, Sunil:

I am sorry for being late to get back to you. I appreciate your explanations
for creating the most generalized service scenarios for the 3GPP
architecture.

Kindly see my response inline [RRR].

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, November 02, 2001 7:08 AM
To: Roy, Radhika R, ALCTA; [email-masked];

Radhika,

[RRR] Yes, let us analyze the impact of the situations and draw a
communications flow. Then, let us find all alternatives solutions and,
examine pros and cons for each alternative (instead of making conclusions
that "BYE" or something else is MUST be needed).

[RRR] Agreed.

and/or any media).  

[RRR] I agree with this situation as well. That is, a SIP terminal is left
isolated all by itself because of loss of "connectivity." We cannot send any
information (signaling or media) to that terminal. Basic SIP itself has its
in-built mechanisms to take care-of situation what to be done by the
communicating entities (e.g., UAs and Proxies). Now the problems that we
need to solve are the basic SIP mechanisms: Additional service related
features between the P-CSCF and S-CSCF (I-CSCF) and P-CSCF and GGNS. We have
to take care-of additional service related events that the basic SIP
standard does not address. The things that we need to add the SIP events and
the corresponding consequences well covered by service agreements.

So neither of the mobiles involved in the session is
able to communicate. But we still may have services running in the (home)
network and these need to be managed gracefully.

[RRR] Yes, agreed. The things that we need to add the SIP events and the
corresponding consequences well covered by service agreements.

[RRR] Yes, we can do this because there is a clear separation between
"signaling" and "media" in the base SIP specs. All we need to do here is to
take advantage of this fundamental mechanism of SIP for solving the problems
of the above situation.

[SC] ANOTHER EXAMPLE SCENARIO:
Consider a scenario where session is setup between mobile user A  and mobile
user B. Both users happen to be roaming into the visited network in London
when attending an IETF meeting. During a session the radio connection to the
cell site fails.

[SC} User A-  home network is in Finland. The S-CSCF and any Application
Servers

[SC] User A calls User B and a SIP session is setup . This happens to be a
voice

[SC] i.e. The Mobile A -- RNC and Mobile B -- RNC radio connection fails
during
an ongoing session for some reason

[SC] So neither Mobile A nor Mobile can communicate with the local cell
site. The

[SC] Hopefully this helps to show some of the difficult cases that can do
sometimes occur in a 3G cellular environment.

[RRR] I did go through your above scenarios and would say that this covers
the most general case for the 3GPP architecture. I think that we can address
these scenarios using existing SIP mechanisms using the new event packages
that will cover all possible cases that you have explained. I have my own
ideas how we can solve these problems (still I do not see that the sending
of BYE messages by SIP proxies is the ONLY way to solve these problems).
However, once the requirements for mobility are completed, we can then focus
how to address the generalized mobility solution (hopefully, through some
contributions) including 3GPP's architecture.

Regards

Sunil

> Require ement"

_