Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path scenari o outside of 3GPP requirements)

From: "Mark Watson"<[email-masked]>
Date: Wed, 27 Feb 2002 15:59:44 -0000

Juha,

There is nothing to stop you getting an Internet Access subscription on your
3G GPRS phone and registering with any SIP Service Provider of your choice.

You will pay for the wireless QoS you request on a per kb basis - the mobile
operator will have no idea what you are using these bits for. Now exactly
how you get the QoS you need for real-time services from the edge of the
Wireless Access network to your destination is another question.

If on the other hand you subscribe to a 3G IP Multimedia Subsystem service,
then the establishment of the access QoS that you need is part of the IMS
service you are invoking, not just a request for a bit-pipe. Operators will
have the flexibility to charge based on the *service* you are invoking, not
just on the bit-pipe provision.

My guess is that it may be cheaper to make a voice call via the IMS than it
is to set up a bit-pipe to the Internet with real-time QoS suitable for
voice. [I don't just mean cheaper *per minute*, though this may be the case.
You also have to take into account cost of handset etc. I imagine operators
will subsidise handsets which are locked in to their own services, as they
do for GSM today]

There are also various radio optimisations that the access operator can
provide if it knows what the bit-pipe is being used for.

As noted by Andrew, the IMS separates out the operator providing the
wireless access to the IMS (Visited operator) from that providing the
services (Home operator), with whom you register. There is no requirement
that the Home Operator have a wireless infrastructure. (Although there are
some technicalities regarding the separation of the GPRS subscription and
IMS subscription on the SIM card(s).)

There are many restrictions and considerations which are special to cellular
wireless access. Bandwidth is a very scarce resource in this context and
needs to be carefully managed. 3GPP takes the view that in order to provide
high quality real-time services over cellular wireless access needs
interaction with the network providing that access, and that it is not
sufficient for this interation to be entirely controlled by the user. The
3GPP IMS is a platform for providing that interaction between Home and
Visited network, or Service Provider and Access Provider, using SIP.

So, noone is preventing you from doing whatever you want with your GPRS
Internet Access. Nor are they preventing competing operators from setting up
'Virtual' mobile service providers - in fact these virtual operators are a
good source of revenue for some networks, rather than direct competitors.

It is not surprising that SIP in this application needs some extensions that
are not necessarily required in the Internet - although Dean has given some
good examples where Internet-based scenarios approach the same architecture
as the 3GPP IMS.

If you prefer that the IETF have no say in how 3GPP use SIP for this
application, you can bury your head in the sand and leave 3GPP to get on
with it. On the other hand, if you think that it would be valuable for this
potentially vast constituency of SIP users to be able to interwork with
other SIP users on the Internet, and for the 3GPP extensions to be designed
in a way which aligns with the principles of SIP, you would be wise to take
the opportunity that is offered to influence the 3GPP work. This implies
constructive suggestions on how to meet the 3GPP requirements, which is what
most people on this list have been devoting their time to, rather than
repeated statements that 3GPP has the wrong arhitecture.

Regards...Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 27 February 2002 09:58
> To: Andrew Allen
> Cc: 'Dean Willis'; Christian Huitema; [email-masked]
> Subject: RE: 3GPP Arch. Why use a local proxy? (was Re: [Sip] Path
> scenari o outside of 3GPP requirements)
> 
> 
> Andrew Allen writes:
> 
>  > There are about 900 MILLION mobile phones in the world 
> growing towards 1
>  > BILLION. That's more than all the PCs out there. If most 
> of those phones in
>  > the future are using SIP what a huge base for enabling a 
> revolution in new
>  > services.
> 
> the 3gpp architecture is not enabling that revolution, but is 
> trying to
> prevent it by forcing the subscribers to use the services of its home
> 3g operator. the subscriber should have true freedom to 
> choose services
> from anywhere on the internet instead.
> 
> as a started, what freedom is it that i need to register before i can
> start making calls?  the sip spec doesn't force you to do 
> that, but 3gpp
> does.
> 
> i think enough bandwidth has already been wasted for this.  it should
> already be clear to everyone, that ietf should not have anything to do
> with 3gpp's usage of a signaling protocol that they falsely 
> try to claim
> to be sip.
> 
> -- juha
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: [email-masked]
Date: Wed, 27 Feb 2002 18:26:23 +0200

> repeated statements that 3GPP has the wrong arhitecture.

i have no desire to influence 3gpp work.  they have already made up
their minds to build yet another walled garden, this time using ip to do
it.  if they would have wanted an open architecture, then they would
have designed generic means by which *anyone* on equal terms can request
the qos that is needed to setup real time session.  these means would
have been independent of the "home" or "visited" wireless *network*
service provider and would have allows anyone on the internet to provide
the value added services.  this is how internet operates today and this
is how 3gpp should have designed their architecture.

it is totally unacceptable for 3gpp folks to waste sip working group's
time with proposals that in numerous ways break the sip service
model. if that service model is not acceptable to 3gpp, then please
destroy it on your own mailing lists.

-- juha

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 27 Feb 2002 16:20:21 -0600

> destroy it on your own mailing lists.

Curse of the capitalist model.

In many ways, I'm sympathetic to your position. But it may be relevant to
point out that with the downturn of Internet technology businesses, the
3Gish folks are actually paying for much of the current development and
deployment of SIP specifications and systems. Look at the people who worked
on the SIP spec rewrite and its compatriots now in Last Call. 3G covers my
pay check as well as those of Jonathan Rosenberg, Brian Rosen (Marconi was a
3G provider last time I looked), Robert Sparks, Gonzalo Camarillo and Adam
Roach, and the employers of Alan Johnston and Jon Peterson are into enough
different things that I woudn't be surprised to learn that they're involved
in 3G as well. I doubt anybody's boss would sign off on the hours that have
been poured into this if they didn't see some sort of business opportunity
developing from it.

This same kind of pattern holds across the working group. Some of the
people are paid for by surviving wireline operators who still have plans to
move beyond SS7, and who in many cases sell terrestrial bandwidth to the
mobile operators. Then there's the traditional Internet equipment providers
who hope to sell a whole lot of gear to mobile operators, and the software
companies that deliver operating systems, tools, and so on. There are
applications guys (media servers, etc.) who want to build systems that can
work in a converged environment. There are probably lots of other
relationships I haven't even noticed. This accounts for a fairly broad set
of interest in achieving some kind of success for 3G's needs.

The 3Gish people also represent a huge share of the constituency for the
protocol -- as Andrew Allen pointed out, the 3G adoption of IETF protocols
potentially more than doubles the reach of the Internet. If a tree falls in
the woods and there is nobody there to hear it does it still make a noise?
Who cares? How about a protocol that nobody uses? So it's potentially
important to have a constituency. I don't think Jonathan would have spent
the last five years inventing a protocol that he didn't want a lot of people
to use.

So we find ourselves in a balancing act -- trying to build a protocol that
3G  will actually use that does not REQUIRE (but perhaps allows) subversion
of the Internet model, and that allows (and encourages) increasing adoption
of the Internet model when the business can be made to prove out and the
operators reach the maturity needed to do business in that environment. We
must do so without damaging the utility of the protocol for people with more
traditionally Internet business models. Nobody said this was going to be
easy.

I suppose it would be possible to just pack all ths work off somewhere else,
but do you really want that? It might get lonely for you.

--
Dean

---

From: Chris Martin <[email-masked]>
Date: Wed, 27 Feb 2002 23:56:15 -0600

Comments inline

> destroy it on your own mailing lists.
A little off the topic of this particular email, but it gives such a
good lead in....

You, and many others keep referring to walled gardens. In todays world
of "insecurity" do you really think that firewalls and the like are
going to dissappear, ever? 

Even during the migration from IPv4 to IPv6 there is a NAT
function....is it going to break SIP???   :^)

You know, they (firewalls/private nets/walled gardens) arent only used
for NAT (which is where I hear the walled garden comment so often
referred to), they actually are used in non nat environments as well for
the purpose of protecting assets. Even when installed on a personal
computer they often present the same walled garden effect.....

As technology advances so do the middleboxes, often with more enabling
power to reduce the walled in effect while still protecting the assets.

With that said, rather than constantly debunking middleboxes and the
like an effort should be made to insure that they are developed in
parallel with the standard to insure that SIP a protocol that adds the
vulnerability to the firewall, as opposed to the firewall breaking SIP.

SIP is a good thing, but you can't berate security in the advancement of
it, or it is sure to fail, unless you know of a good, realistic, short
term, secure solution to bring it to the masses that the firewall
vendors, enterprise, ISP, and home users, and myself are unaware of.

In closing, selection of acceptable authentication mechnisms,
confidentiality mechanisms, trust mechanisms would be a good thing;
SMIME, TLS, Digest whatever. I am sure that each of these has their
place in SIP development, depending on client type etc, as with any
other type of development there is no "one" perfect silver bullet. 

Why not make a compromise and include provisions to permit development
of each in order to address different UA implementation types?
MAY...MAY...MAY....????

While making these provisions why not try to plan for the future, yes
many say PKI is an impossibility today, but you know, its really not
that far off as a reality....many firewall vendors support many of a
PKI's feature-set today, as do client vendors (VPN)...

...perhaps thinking in terms of a policy model, in preparation for X.509
certificates perhaps, for the SIP architecture, wouldnt be a bad idea
either. Since SMIME/TLS/SSL all can take advantage of these, as well as
the network layer equivalent, IPSec.

Chris.