Subject: RE: [Sipping] 3G Call Teardown Requirement

From: [email-masked]
Date: Tue, 30 Oct 2001 15:26:02 -0000

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.  

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?

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.

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

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

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

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 30 Oct 2001 11:43:52 -0500

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,

Regards
Sunil

[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

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

	 [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

[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)?

[RRR] As soon as we find a solution for item 2 that an entity can send BYE,
we can address item 3 more conveniently.

[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 

	

	Proposals:

	Proposals:

---

From: Michael Hammer <[email-masked]>
Date: Tue, 30 Oct 2001 14:59:11 -0500

Sunil,

When you refer to the IP layer below, is the GGSN acting as an
application layer media GW?  Although this may be IP to IP, is that
any different than a MGW that does TDM to IP control.  If not, then
wouldn't MGCP or MegacoP provide the notification mechanisms between the
bearer control and the session control?

Separate thought.  In the legacy TDM world, session setup and
mobility aspects were handled in two parts:  ISUP and MAP.
Some of the core-network aspect mobility-related items below suggest that
you want to supercede and cover both in SIP.  Or am I reading too
much into this?  Does 3GGP cover those aspects with other
interfaces?

Mike

At 03:26 PM 10/30/2001 +0000, [email-masked] wrote:

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

Regards

Sunil

> 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

So a means to send this indication from the GGSN at an IP level to
the

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.

[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

associated  with.

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

[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

The media
resources (user plane resources)  release would also be

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

(Terminating).
If there are, these should also be cleared down.

[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

[SC] start

REQUIREMENT:
We must be able to release "resources" in the
"old"

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

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

[SC] end

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

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

---

From: [email-masked]
Date: Tue, 30 Oct 2001 21:04:44 -0000

Michael,

Some answers inline

Regards

Sunil
> From:	Michael Hammer [SMTP:[email-masked]]
> Sent:	30 October 2001 19:59
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> When you refer to the IP layer below, is the GGSN acting as an application
> layer media GW?  
	 [SC] No I was not thinking that the GGSN is an application layer
media gateway.  Functionally, it is acting as IP packet relay from/to
packets to the SGSN and has a control (GTP signalling) relasionship to the
the SGSN for mobility managements between SGSN (GTP-C protocol).  The GGSN
is not aware of any MediaGateway functionality at the moment (for furture
work in 3GPP these type of architecture may evolve to support media
transcoding as part of the application layer media gateway. This would be a
SA2 architecture decision )

	We have an additional function node in 3GPP architecture - the MGCF
and the associated MGW when connecting to the circuit switdhed networks.
Here the interface between the MGCF and the MGW is excatly what you refer to
and is H.248 (megaco) The S-CSCF in the  has a SIP interface to the MGCF. 

> Although this may be IP to IP, is that any different than a MGW that does
> TDM to IP control.  If not, then wouldn't MGCP or MegacoP provide the
> notification mechanisms between the bearer control and the session
> control?
> [SC] At the moment, there is only the Go interface to the P-CSCF/PCF and
> the GGSN and the Gi interface at IP (IPv6) level towards other GGSNs (and
> IP networks)
> 
	[SC]  
> Separate thought.  In the legacy TDM world, session setup and mobility
> aspects were handled in two parts:  ISUP and MAP.  Some of the
> core-network aspect mobility-related items below suggest that you want to
> supercede and cover both in SIP.  Or am I reading too much into this?
> Does 3GGP cover those aspects with other interfaces?
> [SC]   Good question. May be you are reading too much into this. 3GPP is
> in the process of evolving the 3G networks with new capabilities - IP
> Multimedia whilst maintaining existing capabilities for 3G. So existing
> mobility in 3G networks is just being complemented to meet what is already
> available in the current mobile networks. With a lot of layering present
> in existing 3G systems, SIP need not worry about detailed mobility related
> issue as most of these these are already taken care of.
> 
	3GPP Background:
	There are three major capabilities (subsysyems) in 3GPP networks 
	1) The "circuit switched" domain where we have MSC Servers and
associated Media gateway which provides for transcoding between AMR voice
(about 12 and lower kbit/s) to 64 Kbit used to in PSTN/ISDN legacy networks.
It also allows transcoder free operation (TrFO) between UE for voice calls
(better quality speech, less processing as no transcoding). The codec
negotiation is done using BICC/TS 24.008 protocols (not that different to
the SIP mechanism) So we have voice call at 12 kbit/s end to end with no
transcoding for mobile to mobile calls. The MSC server support ISUP/BICC
signalling as well as MAP for the basic mobility between networks and
MSC-Servers.  This is the way voice and circuit switched data calls are
handled.  This domain continues to evolve and will be aroud for a few years.
yet. For example Indeed, last year a major capability was introduces allow
the separation of the MSC into the Call server part and the Media Gateway
part. The Media gateway is the Megaco/IETF based, where as the call server -
MSC Server is using 3G protocols (ISUP/BICC/TS 24.008 access signalling but
on a IP transport network.

	2) The GPRS domain (PS domain). This is the IP transport network for
3G. It has all the required Mobility functions the higher layers can treat
is a IP transport connection with built in mobility. Here the GTP protocol
protocols and the MAP protocol provide the relevant mobility functions. So
this part of the network provide the mobility and the the QoS support
between the Mobile and the GGSN.  The IP connection provided by GPRS can to
used to connect to any other IP device.

	3)IP Multimedia core network domain. This make use of the GPRS
domain for IP transport.  This is the starting point for the SIP application
in 3GPP. This is the 3GPP IMS that people are familiar with. The IMS should
provide new IP multimedia services based on SIP (presence)  as well as
existing voice sevices available over the MSC servers/Media Gateways as in
(1).  Here SIP is used for access (instead of TS 24.008) as well as core
network between call servers (instead of ISUP/BICC).  When providing
interconnection to the PSTN and also the 3G Circuit Switched domain
ISUP/BICC will still need to be supported.  After all calls between mobile
will be required and some of the exsiting voice mobile only will need to
talk to  mobiles supporting SIP signalling for voice calls.. We have a work
item on interworking SIP with ISUP/BICC in 3GPP CN3.   
	  
> <http://www1.ietf.org/mailman/listinfo/sipping>
> <http://www1.ietf.org/mailman/listinfo/sipping>