Subject: AW: [Sipping] 3GPP network hiding and session release req'ts

From: Mayer Georg ICM N MC MI E71 <[email-masked]>
Date: Fri, 12 Oct 2001 12:51:09 +0200

Hello Neil and Miguel,

some comments on the session release topic:

> > 
> > The graceful session release requirement (6.14.2)
> > would appear to necessitate a B2BUA in the
> > network. Where is that functionality expected to
> > feature within the various 3GPP x-CSCF entities?
> > 
> 
> My understanding is that the graceful session release is
> just needed for the prepaid service. As such, a B2BUA is
> probably needed. This functionality will be part of the
> "prepaid Application Server". So it is not part of any
> x-CSCF. If you are not a prepaid user, you don't need
> to route your session through this special application
> server.

My understanding is that pre-paid is only one of the reasons why the 3GPP
IMS network needs to release a call. We also have the case when a user walks
out of radio coverage - then it would be best if the assigned outbound proxy
(P-CSCF) would immediately clear all calls the user is involved in (just
remember: the user gets charged for these calls, as long as it is not
indicate via SIP-signalling that the call is cleard).

In general the 3GPP IMS Architecture group (SA2) wrote down that P-CSCF and
S-CSCF (the outbound and the home proxy) should be able to release calls. We
cannot think of all the possible cases why this needs to happen, but it
became clear that providers see that as an essential funtionality in the
IMS. Ok, in the home network this could be done by an application server
which acts as a B2BUA. And mybe even the outbound proxy could send something
like a NOTIFY or INFO to this server and ask it to release the call (I am
not suggesting that, I just want to show that there are several
possiblities). 

Neverthless there are some people who do not like the idea of introducing
B2BUAs - at least not too many of them. If - for charging or whatever
reasons - an entity needs to clear a call, this entity needs to act as B2BUA
from the very beginning of the call (INVITE), as it has to assign
independent CSeq-Ranges to both sides of the call. Furthermore this entity
needs to terminate the call completely (i.e. understand every header and
message and does not send anything transparently to the other side). This is
- not only from my point of view - the b2bua definition as currently given
in the bis04 Draft. And applying this would mean that some nice features
which are only known at both UEs will get lost just because of the network
release requirement or better: it's solution. Last (but possibly not least)
this would mean that if we want to be able to release the session in each
network - or each home network - the call will be split into five - or three
- parts. Anyobody out there who favours that?

Coming up with B2BUAs brings up additional problems, such as these guys need
to set up new Via / Route / Record-Route headers. So other entities in the
network will not be aware of loops or spirals any longer. 

Due to all of that we would be very happy if we could fulfil the "network
initiated call release" requirmenet without introducing B2BUAs for that
purpose.

One proposal that was made was that a Proxy which get's aware of the need to
release a call just swaps its mode of working to two independent UAs and
sends BYE messages in both directions. Then it has to handle the call
release on both sides. Well - sounds not nice (at least not for me), but
maybe it's better then splitting the call. 

Sorry if I used too much of the 3GPP terminology here - I try to convert my
thinking to IETF style and I am sure it will work better soon. 

Best regards
Georg
_______________________________________________________
Georg Mayer - Siemens AG Germany

> -----Ursprungliche Nachricht-----
> Von: Miguel A. Garcia [mailto:[email-masked]]
> Gesendet: Freitag, 12. Oktober 2001 08:20
> An: Neil Deason
> Cc: [email-masked]
> Betreff: Re: [Sipping] 3GPP network hiding and session release req'ts
> 
> 
> Neil Deason wrote:
> > 
> > Thanks to Miguel et al from the 3GPP for putting
> > this ID together. After reading this and some of
> > the relevant TS docs I have some questions.
> > 
> > How does bis-04 meets the hiding requirements? (6.12)
> 
> bis-04 already shows examples of hidden Via headers.
> Hiding is done by the SIP hiding proxy, typically a
> stateless proxy.
> 
> > 
> > To meet these requirements is it expected/accepted
> > that state will be stored somewhere in the network
> > for the duration of:
> > 
> > - Transactions for Via headers.
> > - Sessions for Route headers.
> > - UA/E registration lifetimes for Path and Contact
> > headers.
> 
> No, the current working assumption in 3GPP is to provide
> a SIP hiding proxy that is stateless. This proxy will
> tokenize/detokenize headers (Via, Record-Route...). 
> You don't need to store a state anywhere in the network.
> Responses are routed back through the same hiding proxy,
> and it will detokenize the appropriate headers.
> 
> > 
> > The graceful session release requirement (6.14.2)
> > would appear to necessitate a B2BUA in the
> > network. Where is that functionality expected to
> > feature within the various 3GPP x-CSCF entities?
> > 
> 
> My understanding is that the graceful session release is
> just needed for the prepaid service. As such, a B2BUA is
> probably needed. This functionality will be part of the
> "prepaid Application Server". So it is not part of any
> x-CSCF. If you are not a prepaid user, you don't need
> to route your session through this special application
> server.
> 
> > Cheers,
> > Neil.
> 
> 
> /Miguel
> 
> > --
> > Ubiquity Software Corporation, UK        http://www.ubiquity.net
> > 
> > _______________________________________________
> > 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
> 
> -- 
> Miguel-Angel Garcia                     Oy LM Ericsson AB
>                                         Jorvas, Finland
> mailto:[email-masked]     Phone:  +358 9 299 3553
> mailto:[email-masked]        Mobile: +358 40 5140002
> 
> _______________________________________________
> 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: "Sean Olson (EUS)" <[email-masked]>
Date: Fri, 12 Oct 2001 09:35:20 -0500

>indicate via SIP-signalling that the call is cleard).

That is certainly one possible way to do charging, but it is not
the only way. You could tie charging to the SIP signalling, or 
you could charge for the bearer instead. As the bearer seems to be
the real resource here (at least the most scarce one), pre-paid
tied to the bearer seems like a realistic alternative.

Regards,
Sean Olson
Ericsson Inc.

---

From: Mayer Georg ICM N MC MI E71 <[email-masked]>
Date: Fri, 12 Oct 2001 17:38:36 +0200

Hello Sean et al, 

> tied to the bearer seems like a realistic alternative. 

Well, we had already some discussion about that subject. I want to summarize
my opinion on that. 

The bearer (media session) is established due to the SIP signaling going on
on the call control level. This means that we first need some SIP signalling
and then can send the media packages. That's why we need a signaling
protocol. Using SIP we achieve a lot of important things, as for example the
states in the different proxies / CSCFs and we can also get the information
that is needed for charging. Please note also that the charging states are
available in the home network whilst the media is not neccesarily routed via
the home network, the P-CSCF is in control of the bearer (via some other
magic I do not want to dwell in here).

If we now want to tear down the session we need "some means" to tear down
the session when the session release in the network occurs. From my point of
view these means must be SIP means, because that's why we have a signaling
protocol - it is there to control the call. Only sending a BYE will cause
the states in the proxies and UEs to go back to null-states. And only a BYE
should be the trigger point for the P-CSCF to order release of the bearer.
If we have other means, then we need to standardize a new protocol between
the entity that finds out about the need of session clearing (i.e. the
S-CSCF in the home network) and the entity in control of the bearer (i.e.
the P-CSCF in the visited network). Then I would dare to ask why we need SIP
to establish but not to tear down sessions. 

Keep on signaling!
Georg

Georg Mayer - Siemens AG 

-----Ursprüngliche Nachricht-----
Von: Sean Olson (EUS) [mailto:[email-masked]]
Gesendet: Freitag, 12. Oktober 2001 16:35
An: Mayer Georg ICM N MC MI E71; 'Miguel A. Garcia'; Neil Deason
Cc: [email-masked]
Betreff: RE: [Sipping] 3GPP network hiding and session release req'ts

Regards, 
Sean Olson 
Ericsson Inc.

---

From: Mayer Georg ICM N MC MI E71 <[email-masked]>
Date: Fri, 12 Oct 2001 17:47:13 +0200

Hello Neil,

> This is true as long as some assumptions hold true -
> such as the only ingress points to home1.net are the
> I-CSCFs and if there are multiple I-CSCFs they can
> all decrypt headers encrypted by any other I-CSCF.

Yes, these are the working assumptions of 3GPP.

> Seems odd to me to introduce such scope for problems just
> to hide how many S-CSCFs you have from other network
> operators.

I think it is time to mention that network hiding is an optional feature, so
it is up to the operator if this feature is activated for this operators
network. As far as I know this is also a requirement from some contries
telephony regulation (even in the US). The Requirement ist therefore not
only 3G made.  

As you might have seen from 3G specifications we have also worked out the
cases for non-hiding. 

Ok, that's it for today. Have a nice week end and keep on signaling!
Georg
_______________________________________________________
Georg Mayer - Siemens AG

> Von: Neil Deason [mailto:[email-masked]]
> Gesendet: Freitag, 12. Oktober 2001 16:21
> An: Mayer Georg ICM N MC MI E71
> Cc: [email-masked]
> > -----Original Message-----
> > From: Mayer Georg ICM N MC MI E71 
> [mailto:[email-masked]]
> > Hello Neil,
> >
> > thanks for your comments.
> >
> > > Von: Neil Deason [mailto:[email-masked]]
> > >
> > > > -----Original Message-----
> > > > From: Mayer Georg ICM N MC MI E71
> > > [mailto:[email-masked]]
> > > >
> > > > Hello Neil,
> > > >
> > > > may I give some more comments on the following issue:
> > > >
> > > > > in the P-CSCF for the duration of the session. The Path
> > > > > discovered at registration meanwhile would need to be stored
> > > > > for the lifetime of the registration. I take it this is
> > > > > what is being referred to in section 6.2.3 of the draft
> > > > > to increase security, persumably by hiding network
> > > > > structure.
> > > >
> > > > Section 6.2.3 talks about Removal of Headers and what you
> > > > wrote about it is
> > > > exactly what 3G requires (from my point of view). But this
> > > > requrirement is
> > > > compeletely different from the one in section 6.12 "Hiding
> > > > requirements".
> > >
> > > I appreciate there are two types of network structure hiding
> > > at play. Headers are removed before msgs are passed to end
> > > users/UEs (which also reduces msg size). Headers are tokenised
> > > before passing between network operators.
> >
> > In fact the removal of certain headers when sending messages
> > from P-CSCF to
> > the UE is only for bandwith saving purposes, but not intended
> > for network
> > hiding.
> 
> 6.2.3 of the 3G reqt's draft says that headers are removed
> to 'increase security'. I was assuming that this meant
> security is increadsed by hiding network information from end
> users. Admittedly this doesn't buy you that much security
> for the state overhead needed to store info in the P-CSCF.
> But then I also wonder how much BW it saves you after
> compression.
> 
> > > > Network hiding is done by a proxy of the home network
> > (the so-called
> > > > I-CSCF). In fact it hides only information in messages going
> > > > OUT of the home
> > > > network, by looking into Via/Route/Record-Route/Path (is
> > > there a Path
> > > > header?) headers and encrypting the entries of its home
> > > > network entities.
> > > > This is done as some operators do not want to let their
> > > > competitors know how
> > > > many S-CSCFs they have in their network.
> > >
> > > I have to say I find this bizzare. Why don't they just
> > > multihome S-CSCFs to intimidate competitors ;)
> > >
> > > > Assume it is an INVITE that is going out from the home
> > > > network (of user B)
> > > > to the visited network. If network hiding is required, the
> > > > INVITE will pass
> > > > through an I-CSCF / proxy in the home network, it will
> > > > encrypt the above
> > > > stated information.
> > > >
> > > > If the (e.g.) 180 Ringing response for that INVITE comes
> > > back from the
> > > > visited network, the I-CSCF / proxy looks for encrypted
> > > > information and will
> > > > de-crypt it. By doing so we still enable the network to still
> > > > detect loops /
> > > > spirals.
> > >
> > > Detecting loops/spirals is important on the request path.
> > > Responses just follow the Via's back so as long
> > > as the server that can de-tokenise the headers is
> > > reached first that should be OK. Issues on the request
> > > path could arise if loops occur back to a server that
> > > then fails to recognise itself in the Via headers as
> > > they have been tokenised downstream.
> > >
> >
> > Yes, that's true, but the proposed mechanism will not prevent
> > loop detection
> > from working.
> >
> > A message outgoing from home1.net ist sent through home1's I-CSCF
> > i2.home1.net. Assume the i2.home1.net receives a Via header
> > like that (for
> > simplification I left out all the "sip:" etc.):
> >
> > Via: p.visited1.net, i1.home1.net, s1.home1.net
> >
> > It then will send out a Via header looking the following way:
> >
> > Via: p.visited1.net, token(i1.home1.net, s1.home1.net), i2.home1.net
> >
> > So, if the request is routed back to p.visited1.net, this
> > entity will still
> > be able to detect the loop / spiral.
> >
> > If the request is sent back to home1.net, it will always be
> > routed to an
> > I-CSCF (because for network hiding the I-CSCF's will be the
> > switches known
> > in DNS when a request has to be routed to the home1.net -
> > this is one of the
> > key things in this mechanism). This I-CSCF will then decrypt the
> > token(i1.home1.net, s1.home1.net), so that also the home1.net
> > entities will
> > be able to recognize loops.
> 
> This is true as long as some assumptions hold true -
> such as the only ingress points to home1.net are the
> I-CSCFs and if there are multiple I-CSCFs they can
> all decrypt headers encrypted by any other I-CSCF.
> Seems odd to me to introduce such scope for problems just
> to hide how many S-CSCFs you have from other network
> operators.
> 
> Cheers,
> Neil.
> 
>

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Fri, 12 Oct 2001 11:48:36 -0500

These are all very good points. I am not trying to say that
SIP signalling cannot be used to tear down a session. In
most cases, this is exactly what will happen. But in extraordinary
cases, it is also useful to be able to use other sources of information
to know when to tear down a session. Loss of bearer is one of these.
Assuming that you are doing time-based charging, then you want
your source of charging events to be as accurate from a time
perspective as possible. In this case, I believe loss of bearer to be
a superior source of information and it should be factored into any
pre-paid solution that is time-based. Again, I am not saying that a
BYE should not be taken into account. I am merely saying that if
you have a more timely source of information about loss of bearer,
then you should use that in a pre-paid solution.
 
Best Regards,
Sean Olson
Ericsson Inc.

-----Original Message-----
From: Mayer Georg ICM N MC MI E71 [mailto:[email-masked]]
Sent: Friday, October 12, 2001 10:39 AM
To: 'Sean Olson (EUS)'; 'Miguel A. Garcia'; Neil Deason
Cc: [email-masked]
Subject: AW: [Sipping] 3GPP network hiding and session release req'ts

Hello Sean et al, 

> tied to the bearer seems like a realistic alternative. 

Well, we had already some discussion about that subject. I want to summarize my opinion on that. 

The bearer (media session) is established due to the SIP signaling going on on the call control level. This means that we first need some SIP signalling and then can send the media packages. That's why we need a signaling protocol. Using SIP we achieve a lot of important things, as for example the states in the different proxies / CSCFs and we can also get the information that is needed for charging. Please note also that the charging states are available in the home network whilst the media is not neccesarily routed via the home network, the P-CSCF is in control of the bearer (via some other magic I do not want to dwell in here).

If we now want to tear down the session we need "some means" to tear down the session when the session release in the network occurs. From my point of view these means must be SIP means, because that's why we have a signaling protocol - it is there to control the call. Only sending a BYE will cause the states in the proxies and UEs to go back to null-states. And only a BYE should be the trigger point for the P-CSCF to order release of the bearer. If we have other means, then we need to standardize a new protocol between the entity that finds out about the need of session clearing (i.e. the S-CSCF in the home network) and the entity in control of the bearer (i.e. the P-CSCF in the visited network). Then I would dare to ask why we need SIP to establish but not to tear down sessions. 

Keep on signaling!
Georg

-----Ursprüngliche Nachricht-----
Von: Sean Olson (EUS) [mailto:[email-masked]]
Gesendet: Freitag, 12. Oktober 2001 16:35
An: Mayer Georg ICM N MC MI E71; 'Miguel A. Garcia'; Neil Deason
Cc: [email-masked]
Betreff: RE: [Sipping] 3GPP network hiding and session release req'ts

Regards, 
Sean Olson 
Ericsson Inc.

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Fri, 12 Oct 2001 14:07:18 -0400

-----Original Message-----
From: Mayer Georg ICM N MC MI E71 [mailto:[email-masked]]
Sent: Friday, October 12, 2001 11:39 AM

Hello Sean et al, 

[Roy, Radhika R, ALARC]  I think that this is a very important point for
tearing down of the SIP session using BYE from implementation point of view:
An association between the end-to-end media tearing down and the P-CSCF
which is responsible for triggering of services including media. This
requirement may be generic: Wire-line/Wireless Networks and/or Mobile or
non-Mobile users. I like to see more discussion on this point: How we can
address this important issue.

Keep on signaling!
Georg

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Fri, 12 Oct 2001 15:00:20 -0400

-----Original Message-----
From: Mayer Georg ICM N MC MI E71 [mailto:[email-masked]]
Sent: Friday, October 12, 2001 6:51 AM
To: 'Miguel A. Garcia'; Neil Deason
...

[RRR] It sounds like the third party call release (in the same token third
party call setup). We can extend this analogy a little bit. If there is a
failure in the network and no communications exist between the UAs, one of
the UAs may send BYE or timeout the session. Indirectly, the action of a
network causes an UA to react. If we think that there are "means" to
communicate between the network-based proxy to the UA so that the UA needs
to send a BYE, it may preserve the proper SIP behavior of the UA. The only
thing that we need to worry about is the "Signaling Mechanism between the
Proxy and UA (new? extension of SIP?)."

...

[RRR] The UA will not a get a BYE from the UA. It appears to be a change in
SIP behavior, but has less signaling messages.
...

Best regards
Georg

---

From: Michael Hammer <[email-masked]>
Date: Mon, 22 Oct 2001 13:26:33 -0400

Roy,

I would use as a basic assumption that, worse case, the UA's can not be
counted on to behave properly.  So any solution that relies on such
would not be a preferred means.

Mike

At 12:22 PM 10/22/2001 -0400, Roy, Radhika R, ALCTA wrote:

George and Mike:

Let me try to generalize the scenarios as follows:

1. Service related features (e.g., pre-paid cards, etc.)

2. Network (bearer) related features (e.g., radio coverage, etc.)

In both situations, SIP UAs are not involved directly that can send BYE
as

per SIP rule. However, per SIP rule, both session and media are
also

terminated as soon as BYE is sent.

One of the solutions has been to make SIP Proxies as B2B UAs. This may
not

be scalable or may have other problems. George also mentioned about

different alternatives: a. Extend SIP to allow proxy for sending BYE and
b.

Non-SIP solution.

I think that non-SIP solution may be attractive. For example,
service

related features (item 1) may be considered a kind of policy and, there
are

some proposals how policy can be extended to accomplish this. The benefit
of

this proposal is that SIP UAs can still keep its present behavior.

For the network related features (item 2), a policy server may also
be

communicated by the network layer entity to signal the SIP UA to send
the

BYE.

Any more thoughts?

Radhika

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

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

Sent: Monday, October 22, 2001 11:36 AM

To: Mayer Georg ICM N MC MI E71

Cc: 'Sean Olson (EUS)'; 'Miguel A. Garcia'; Neil Deason;
[email-masked]

Subject: Re: AW: [Sipping] 3GPP network hiding and session release
req'ts

Georg,

Assume that the S-CSCF informs the P-CSCF of the maximum amount for which
it

can reimburse the visited network.  Once, that limit is reached,
wouldn't

the visited network indicate to the GGSN that the bearer stream should
no

longer be forwarded in either direction?  If that happened, upon
detection

of loss of bearer, the SIP mechanisms would attempt to re-establish the
call

and discover that UE A is not permitted, or UE B can attempt to complete
the

call and based on its permissions be able to complete the
call-back.

Are there any assumptions about the behavior of the UE's that should
be

taken into account, even though that would be implementation
specific?

Mike

At 05:08 PM 10/22/2001 +0200, Mayer Georg  ICM N MC MI E71
wrote:

Hello Sean et al,

sorry for the late response, but I was away during the last week. Here
are

some comments on your text below.

Assume A calls B. The call is routed via P-CSCF1 (A's outbound Proxy in
the

visited network) and S-CSCF1 (A's call control function in the home
network)

- I leave out the entities for user B. The SIP signaling is sent via the
P-

and S-CSCF. Additionally there is a GGSN over which User A sends the
RTP

media streams. The RTP is also connected to P-CSCF1, which authorizes
media

access etc.

UE A -----a---- P-CSCF1 ------b--- S-CSCF1 ---c--(cloud)-- UE B

I
I

I
I p

I--------r--- GGSN

a / b / c are SIP interfaces, whereby a is over the Radio
interface.

p is the interface over which P-CSCF controls the media of the GGSN,
e.g.

COPS protocol

r is the media interface - RTP streams are running here

Now some example scenarios:

(1) Pre-Paid card runs out of money.

(1a) As Pre-Paid is handled by / at / behind the S-CSCF1 I would assume
that

a SIP BYE message is sent from the S-CSCF towards the UE. When this
BYE

passes through the P-CSCF1 it instructs the GGSN to release the
call.

Well - I imply here that the S-CSCF1 can generate a BYE message for
an

established session for which it is a (call-stateful) proxy.

Assume the S-CSCF1 is not able (due to protocol restrictions) to send a
BYE

message. Then it has to send SOMETHING in order to instruct the P-CSCF
and

the UE to release the RTP session. This something can be (1b) part of SIP
or

could be (1c) non-SIP signaling. For both cases (1b and 1c) still a
BYE

message has to be generated by one of the UEs (or somebody else in
the

network) in order to clear the signaling states etc..

My personal opinion:

- (1c) looks to me like a way around SIP - like somebody messing around
in

call control without using the proper protocol.

- (1b) sounds better, but it is additional effort for specification
and

implementation, furthermore there is already.

- (1a) is the most consequent way of doing it and solves the problem
with

already existing mechanisms.

(2) User walks out of Radio Coverage.

(2a) P-CSCF releases the bearer immediately and generates a BYE message
on

behalf of the user - perfect, but currently not allowed in SIP

(2b) P-CSCF releases the bearer and sends out a up-till-now unknown
SIP

request in order to request another entity (S-CSCF or UE B) to send a
BYE

request - Problem: Trigger of media release is not the SIP BYE
signaling,

this means we have an inconsistency here.

(2c) P-CSCF sends out the request to somebody else to generate a BYE
and

releases the bearer when the BYE arrives. Ok, I agree that we should not
do

that, as this might mean charging until the BYE is received, although
the

user has no access to the service.

Therefore the network initiated session release question really boils
down

to the question if a Proxy can generate a BYE message for an existing
call

on its own. Maybe from the above given examples it became clear, that
it

would be preferable to allow this Proxy behaviour.

The next argument might then be that it is demanded that we want
these

specific proxies to act as B2BUAs. As I already lined out in another
message

this is not as easy as it sounds, as the B2BUA brings some further

complication into the network. So maybe we can discuss the pros and cons
for

BYE generation at a Proxy for a while.

Thanks in advance and keep on signaling

Georg

_____________________________________________________

Georg Mayer - Siemens AG

-----Ursprüngliche Nachricht-----

Von: Sean Olson (EUS) [
mailto:[email-masked]

<mailto:[email-masked]>
]

Gesendet: Freitag, 12. Oktober 2001 18:49

Cc: [email-masked]

Betreff: RE: [Sipping] 3GPP network hiding and session release
req'ts

cases, it is also useful to be able to use other sources of
information

to know when to tear down a session. Loss of bearer is one of
these.

perspective as possible. In this case, I believe loss of bearer to
be

Best Regards,

Sean Olson

Ericsson Inc.

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

From: Mayer Georg ICM N MC MI E71 [
mailto:[email-masked]

<mailto:[email-masked]>
]

Cc: [email-masked]

Subject: AW: [Sipping] 3GPP network hiding and session release
req'ts

Hello Sean et al,

> tied to the bearer seems like a realistic alternative.

Well, we had already some discussion about that subject. I want to
summarize

my opinion on that.

The bearer (media session) is established due to the SIP signaling going
on

on the call control level. This means that we first need some SIP
signalling

and then can send the media packages. That's why we need a
signaling

protocol. Using SIP we achieve a lot of important things, as for example
the

states in the different proxies / CSCFs and we can also get the
information

that is needed for charging. Please note also that the charging states
are

available in the home network whilst the media is not neccesarily routed
via

the home network, the P-CSCF is in control of the bearer (via some
other

If we now want to tear down the session we need "some means" to
tear down

the session when the session release in the network occurs. From my point
of

view these means must be SIP means, because that's why we have a
signaling

protocol - it is there to control the call. Only sending a BYE will
cause

the states in the proxies and UEs to go back to null-states. And only a
BYE

should be the trigger point for the P-CSCF to order release of the
bearer.

If we have other means, then we need to standardize a new protocol
between

the entity that finds out about the need of session clearing (i.e.
the

S-CSCF in the home network) and the entity in control of the bearer
(i.e.

the P-CSCF in the visited network). Then I would dare to ask why we need
SIP

Keep on signaling!

Georg

Georg Mayer - Siemens AG

-----Ursprüngliche Nachricht-----

Von: Sean Olson (EUS) [
mailto:[email-masked]

<mailto:[email-masked]>
]

Cc: [email-masked]

Betreff: RE: [Sipping] 3GPP network hiding and session release
req'ts

>My understanding is that pre-paid is only one of the reasons

>why the 3GPP

>IMS network needs to release a call. We also have the case

>when a user walks

>out of radio coverage - then it would be best if the assigned

>outbound proxy

>(P-CSCF) would immediately clear all calls the user is

>involved in (just

Regards,

Sean Olson

Ericsson Inc.

_______________________________________________ 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: Mon, 22 Oct 2001 13:37:28 -0400

Roy,

I would use as a basic assumption that, worse case, the UA's can not be
counted on to behave properly.  

[Roy, Radhika R, ALARC]  Is it possible to elaborate on this? 
 
 So any solution that relies on such would not be a preferred means.

[Roy, Radhika R, ALARC]  Why not? All UAs need to do is to signal BYE while
decision is being made somewhere else (e.g., policy server/SIP Proxy).

Mike

George and Mike:

 
In both situations, SIP UAs are not involved directly that can send BYE as
per SIP rule. However, per SIP rule, both session and media are also
terminated as soon as BYE is sent.
 
One of the solutions has been to make SIP Proxies as B2B UAs. This may not
be scalable or may have other problems. George also mentioned about
different alternatives: a. Extend SIP to allow proxy for sending BYE and b.
Non-SIP solution.
 
I think that non-SIP solution may be attractive. For example, service
related features (item 1) may be considered a kind of policy and, there are
some proposals how policy can be extended to accomplish this. The benefit of
this proposal is that SIP UAs can still keep its present behavior.
 
For the network related features (item 2), a policy server may also be
communicated by the network layer entity to signal the SIP UA to send the
BYE.
 
Any more thoughts?
 
Radhika

-----Original Message-----
From: Michael Hammer [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Monday, October 22, 2001 11:36 AM
To: Mayer Georg ICM N MC MI E71
Cc: 'Sean Olson (EUS)'; 'Miguel A. Garcia'; Neil Deason; [email-masked]
Subject: Re: AW: [Sipping] 3GPP network hiding and session release req'ts

Georg,

Assume that the S-CSCF informs the P-CSCF of the maximum amount for which it
can reimburse the visited network.  Once, that limit is reached, wouldn't
the visited network indicate to the GGSN that the bearer stream should no
longer be forwarded in either direction?  If that happened, upon detection
of loss of bearer, the SIP mechanisms would attempt to re-establish the call
and discover that UE A is not permitted, or UE B can attempt to complete the
call and based on its permissions be able to complete the call-back.

Are there any assumptions about the behavior of the UE's that should be
taken into account, even though that would be implementation specific?

Mike

At 05:08 PM 10/22/2001 +0200, Mayer Georg  ICM N MC MI E71 wrote:

Hello Sean et al,
 
sorry for the late response, but I was away during the last week. Here are
some comments on your text below.
 
Assume A calls B. The call is routed via P-CSCF1 (A's outbound Proxy in the
visited network) and S-CSCF1 (A's call control function in the home network)
- I leave out the entities for user B. The SIP signaling is sent via the P-
and S-CSCF. Additionally there is a GGSN over which User A sends the RTP
media streams. The RTP is also connected to P-CSCF1, which authorizes media
access etc. 
 
  I               I
  I               I p
  I--------r--- GGSN 
 
a / b / c are SIP interfaces, whereby a is over the Radio interface.
p is the interface over which P-CSCF controls the media of the GGSN, e.g.
COPS protocol
r is the media interface - RTP streams are running here

(1a) As Pre-Paid is handled by / at / behind the S-CSCF1 I would assume that
a SIP BYE message is sent from the S-CSCF towards the UE. When this BYE
passes through the P-CSCF1 it instructs the GGSN to release the call.
Well - I imply here that the S-CSCF1 can generate a BYE message for an
established session for which it is a (call-stateful) proxy. 
 
Assume the S-CSCF1 is not able (due to protocol restrictions) to send a BYE
message. Then it has to send SOMETHING in order to instruct the P-CSCF and
the UE to release the RTP session. This something can be (1b) part of SIP or
could be (1c) non-SIP signaling. For both cases (1b and 1c) still a BYE
message has to be generated by one of the UEs (or somebody else in the
network) in order to clear the signaling states etc.. 
 
My personal opinion:
- (1c) looks to me like a way around SIP - like somebody messing around in
call control without using the proper protocol. 
- (1b) sounds better, but it is additional effort for specification and
implementation, furthermore there is already. 
- (1a) is the most consequent way of doing it and solves the problem with
already existing mechanisms. 

(2a) P-CSCF releases the bearer immediately and generates a BYE message on
behalf of the user - perfect, but currently not allowed in SIP
 
(2b) P-CSCF releases the bearer and sends out a up-till-now unknown SIP
request in order to request another entity (S-CSCF or UE B) to send a BYE
request - Problem: Trigger of media release is not the SIP BYE signaling,
this means we have an inconsistency here.
 
(2c) P-CSCF sends out the request to somebody else to generate a BYE and
releases the bearer when the BYE arrives. Ok, I agree that we should not do
that, as this might mean charging until the BYE is received, although the
user has no access to the service. 
 
Therefore the network initiated session release question really boils down
to the question if a Proxy can generate a BYE message for an existing call
on its own. Maybe from the above given examples it became clear, that it
would be preferable to allow this Proxy behaviour.
 
The next argument might then be that it is demanded that we want these
specific proxies to act as B2BUAs. As I already lined out in another message
this is not as easy as it sounds, as the B2BUA brings some further
complication into the network. So maybe we can discuss the pros and cons for
BYE generation at a Proxy for a while. 

 

 -----Ursprüngliche Nachricht-----
Von: Sean Olson (EUS) [ mailto:[email-masked]
<mailto:[email-masked]> 
< mailto:[email-masked] <mailto:[email-masked]> > ]
Gesendet: Freitag, 12. Oktober 2001 18:49
An: Mayer Georg ICM N MC MI E71; 'Miguel A. Garcia'; Neil Deason
Cc: [email-masked]
Betreff: RE: [Sipping] 3GPP network hiding and session release req'ts

Best Regards,
Sean Olson
Ericsson Inc.

-----Original Message-----
From: Mayer Georg ICM N MC MI E71 [ mailto:[email-masked]
<mailto:[email-masked]> 
< mailto:[email-masked] <mailto:[email-masked]> > ]
Sent: Friday, October 12, 2001 10:39 AM
To: 'Sean Olson (EUS)'; 'Miguel A. Garcia'; Neil Deason
Cc: [email-masked]
Subject: AW: [Sipping] 3GPP network hiding and session release req'ts

Hello Sean et al, 

Keep on signaling!
Georg

-----Ursprüngliche Nachricht-----
Von: Sean Olson (EUS) [ mailto:[email-masked]
<mailto:[email-masked]> 
< mailto:[email-masked] <mailto:[email-masked]> > ]
Gesendet: Freitag, 12. Oktober 2001 16:35
An: Mayer Georg ICM N MC MI E71; 'Miguel A. Garcia'; Neil Deason
Cc: [email-masked]
Betreff: RE: [Sipping] 3GPP network hiding and session release req'ts

Regards, 
Sean Olson 
Ericsson Inc. 

_______________________________________________ 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

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

---

From: Michael Hammer <[email-masked]>
Date: Mon, 22 Oct 2001 14:30:40 -0400

Roy,

It was pointed out before that the UA could do all the right SIP signals,
but still keep the media open to the distant party.  Ultimately, if
you want policy controls, enforcement must reach the (IP-IP) media
gateway at the edge of the service provider domain.

Mike

At 01:37 PM 10/22/2001 -0400, Roy, Radhika R, ALCTA wrote:

Roy,

I would use as a basic assumption that, worse case, the UA's can not
be

So any solution that relies on such would not be a preferred
means.

[Roy, Radhika R, ALARC]  Why not? All UAs need to do is to signal
BYE while

decision is being made somewhere else (e.g., policy server/SIP
Proxy).

Mike

George and Mike:

Non-SIP solution.

BYE.

Any more thoughts?

Radhika

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

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

Georg,

Mike

Hello Sean et al,

access etc.

I               I

I               I p

I--------r--- GGSN

COPS protocol

My personal opinion:

Georg

Georg Mayer - Siemens AG

-----Ursprüngliche Nachricht-----

Cc: [email-masked]

Best Regards,

Sean Olson

Ericsson Inc.

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

Cc: [email-masked]

Hello Sean et al,

my opinion on that.

Keep on signaling!

Georg

Georg Mayer - Siemens AG

-----Ursprüngliche Nachricht-----

Cc: [email-masked]

Regards,

Sean Olson

Ericsson Inc.

SIP

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 22 Oct 2001 11:57:09 -0700

It is an old issue. It all depends of whether the subscribers get IP service and an additional SIP feature, or something else. In a classic IP world, SIP is optional, and has no side effect on the network state. If for some reason an agent installs network state, then that agent has to make sure that the state is removed when it not needed any more, or not paid for anymore. So, the main burden of clearing the sate should be on the proxy, not on the UA. The involvement of the UA should be limited to advisory actions, e.g. "are you still here" or "do you still need that resource."

-- Christian Huitema

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]] 
Sent: Monday, October 22, 2001 11:31 AM
To: Roy, Radhika R, ALCTA
Cc: Mayer Georg ICM N MC MI E71; 'Sean Olson (EUS)'; 'Miguel A. Garcia'; Neil Deason; [email-masked]
Subject: RE: AW: [Sipping] 3GPP network hiding and session release req'ts

Roy,

It was pointed out before that the UA could do all the right SIP signals, but still keep the media open to the distant party.  Ultimately, if you want policy controls, enforcement must reach the (IP-IP) media gateway at the edge of the service provider domain.

Mike

Roy,

 

Mike

George and Mike:

 

 
 
Any more thoughts?
 
Radhika

-----Original Message-----
From: Michael Hammer [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Monday, October 22, 2001 11:36 AM
To: Mayer Georg ICM N MC MI E71
Cc: 'Sean Olson (EUS)'; 'Miguel A. Garcia'; Neil Deason; [email-masked]
Subject: Re: AW: [Sipping] 3GPP network hiding and session release req'ts

Georg,

Mike

Hello Sean et al,

 

 

My personal opinion:

 

 

 

 -----Ursprüngliche Nachricht-----

Best Regards,
Sean Olson
Ericsson Inc.

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

Hello Sean et al, 

Keep on signaling!
Georg

-----Ursprüngliche Nachricht-----

Regards, 
Sean Olson 
Ericsson Inc. 

_______________________________________________ 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: [email-masked]
Date: Tue, 23 Oct 2001 12:18:52 +0100

Hi Bernhard,

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,

Duncan Mills

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 23 October 2001 11:59
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: AW: [Sipping] 3GPP network hiding and session release
req'ts

Hi Miguel!

Thanks for your comments! Please find mine below:

- General implementation of REFER in terminals:
  
  I assume for other scenarios (conference calling,
  call tranfer, ...) the REFER method will be implemented 
  anyway in terminals.

- security issues and abuse:

  - For the prepaid case, I could immagine a security assocation
    between the prepaid AS (or home network) and the terminal
    to authenticate REFERs
    I do not see a special case here, as there anyway need to
    be means to authenticate SIP requests.

  - alternatively REFERs could be authenticated by the P-CSCF
    on behalf of the UA (e.g. in case the above leads to an
    implementation problem) 

- For terminals not supporting the REFER method, I see
  some possible solutions.

  - 3gpp needs some other mandatory features in terminals,
    e.g. all the stuff related to the REGISTER. So why not
    to mandate also REFER. 

  - Alternativly, it could be stated, that the prepaid service
    can only be provided to terminals, which understand REFER
    or at least understand the REFER which triggers a the BYE

  - Some means with the Supported header could tell the
    prepaid AS, whether the terminal supports the REFER.
    If REFER supported in UAC, it works just fine;
    If no support indicated by the UAC, there could be 
    a more ugly solution, e.g. just cutting streams (at
    P-CSCF) without timers,send the REFER to the other
    party (maybe using  OPTIONS AS->UAS before call-setup
    to query the support of REFER), B2BUAs, ...  

Comments?

cheers,
 Bernie

>From: ext Miguel A. Garcia [mailto:[email-masked]]
>Sent: 23. October 2001 12:46
>To: [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]
>Hi Bernhard:
>Some people have many concerns on the REFER method. 
>There are concerns on security issues (some peole don't
>want to allow the REFER method in a terminals, as it could
>be used for abuse). Further more, some non-compliant terminal
>could just ignore the REFER, and therefore, no BYE is sent.
>Then you need the fallback solution based on timers, and
>therefore, why bothering with a REFER method if you need the
>timer?
>
>/Miguel
>
>[email-masked] wrote:
>> 
>> Hi!
>> 
>> Concerning this prepaid (run-out-of-credit) problem,
>> I see a SIP compliant solution:
>> 
>>  Send a REFER to the UA to trigger a BYE for a
>>  run-out-of-credit session.
>> 
>>  Below the general idea (without abnormal cases) is
>>  depicted (AS = Application server for prepaid service):
>> 
>>  UA A         P-CSCF          AS           UA B
>> 
>>   | --INVITE--> | --INVITE--> | --INVITE--> |
>>   | <--200 OK-- | <--200 OK-- | <--200 OK-- |
>>   | ----ACK---> | ----ACK---> | ----ACK---> |
>> 
>>  Session established...
>> 
>>  Later the credit goes to zero...
>> 
>>   | <--REFER--- | <--REFER--- |
>>   | ----BYE---> | ----BYE---> | ----BYE---> |
>>   | <--200 OK-- | <--200 OK-- | <--200 OK-- |
>> 
>>  If the UA ignores the REFER, then some means
>>  at the outbound-proxy (i.e. P-CSCF) have to enfore
>>  the policy, e.g. the release of the media streams.
>> 
>>  I could immagine, that the P-CSCF sets a timer
>>  (e.g. 5 s) and cuts media steams, in case
>>  no BYE is sent by the UA.
>> 
>> Any comments?
>> 
>> cheers,
>>  Bernie
>> 
>> >From: ext Roy, Radhika R, ALCTA [mailto:[email-masked]]
>> >Sent: 22. October 2001 19:23
>> >To: Michael Hammer; Mayer Georg ICM N MC MI E71
>> ><mailto:[email-masked]> ]
>> ><mailto:[email-masked]> ]
>> ><mailto:[email-masked]> ]
>> >http://www1.ietf.org/mailman/listinfo/sipping This list is for NEW

---

From: [email-masked]
Date: Tue, 23 Oct 2001 15:48:13 +0300

Hi Duncan er al.!

About REFER to the terminal to force INVITE:

- This can be handeled in the terminal. I guess it will be
  implementation or configuration issue.

  One possible configuration I see is:

    - REFER (to trigger BYE)
      --> always send BYE immediately
          (or only in prepaid case send BYE immediately) 

    - REFER (to trigger INVITE or whatever)
      --> ask user what to do; only send INVITE if user accepts

- security aspects:

  The problem in gernerally solvable. One way is to use
  public and private keys (PKI). The AS would inform its
  public key and sign the REFERs with its private key.
  I guess the SIP security gurus know many ways
  to solve this.

  I don't know the lastest state about the 3GPP security
  architecture, but I assume that such a functionality
  is either already defined or can be easily added.
  I strongly believe, that this would not be the only
  case, where SIP messages towards the UA have to be
  authenticated.
 
  Any 3gpp security expert listening?

Comments?

I would be really interested in more concerns about this,
so that we can work out possible solutions.

cheers
 Bernie

>From: ext [email-masked]
>[mailto:[email-masked]]
>Sent: 23. October 2001 14:19
>To: [email-masked]; [email-masked]

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 23 Oct 2001 09:06:17 -0400

All:

One more point is yet to be discussed (item 2):

* Network (bearer) related features (e.g., radio coverage, etc.). That is,
communications between GGSN and P-CSCF1. Will it also be possible using the
SIP way? Or, do we need something else (e.g., policy server)?

Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, October 23, 2001 8:48 AM
To: [email-masked]; [email-masked]
Subject: RE: AW: [Sipping] 3GPP network hiding and session release
req'ts

Hi Duncan er al.!

    - REFER (to trigger BYE)

- security aspects:

 

Comments?

cheers
 Bernie

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 23 Oct 2001 08:21:47 -0500

I believe the REFER mechanism has merit
and I would encourage further study. If anyone
would like to continue work along this lines,
I would be happy to help in any way I can.

No matter what mechanism we employ, we absolutely
must have a timer in the P-CSCF to ensure that 
state / resources (bearers) are cleaned up. From 
this perspective, REFER is no worse and no better
than alternative solutions. 

I prefer REFER because it eliminates a nasty B2BUA
in the P-CSCF. Implementing REFER in the terminals
is a straightforward proposition. I don't see any
technical hurdles there.

Regards,
Sean Olson
Ericsson Inc.

>Sent: Tuesday, October 23, 2001 5:59 AM

---

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

inline [RRR]

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Monday, October 22, 2001 4:28 PM
To: Roy, Radhika R, ALCTA; 'Michael Hammer'; 'Mayer Georg ICM N MC MI
E71'

>I think that non-SIP solution may be attractive.
Nothing wrong with non-SIP solutions, as long as they fit the Internet
architecture,

[RRR] Yes, the whole purpose is to fit into the Internet architecture.

Thanks, Henry

Henry Sinnreich
WorldCom
400 International Parkway
Richardson, Texas 75081
USA

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Tue, 23 Oct 2001 08:25:51 -0500

The concern is a legitimate one. The solution
to your problem is the same solution you will
use to ensure that an INVITE is not fraudulent.
We can use the same integrity protection mechanisms
for the REFER that we use for any SIP request. 
We can provide further security guarantees if needed.

Regards,
Sean Olson
Ericsson Inc.

>From: [email-masked]
>Sent: Tuesday, October 23, 2001 6:19 AM

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 24 Oct 2001 07:22:30 +0300

>  I guess the SIP security gurus know many ways

There are several concerns with using public key technology
in this context, so we'd like to avoid that if at all possible.

In 3G networks there is however a security association between
the UA and the home network, based on symmetric crypto, and
that could be used to authenticate REFER in the same manner
as REGISTER is authenticated (though the direction of the
messages is different).

Alternatively, we could rely on the hop-by-hop security that is currently
planned. The question is if this is sufficient. Upon initial analysis, it
would seem that hop by hop is sufficient even for the protection of
this use case for REFER, assuming all networks ensure that they
don't let REFERs in that claim an inappropriate From field.

Jari