Subject: RE: [Sip] Path scenario outside of 3GPP requirements

From: "Christian Huitema" <[email-masked]>
Date: Mon, 25 Feb 2002 16:01:46 -0800

> Christian wrote:
> > Dea nWrote
> > > 1) Give my home phone knowledge of the proxy it's behind, and have
it
> > > insert
> > > an adjusted Contact: in the REGISTER. This of course requires
> > replacing
> > > all
> > > the phone software, and is a pain in the behind (I have a 3Com
phone
> > right
> > > now, no software updates available as far as I know).
> >
> > There is actually a spec on how to do just that -- check the UPNP
> > standard for Internet Gateway Devices at
> > http://www.upnp.org/resources/standards.asp. I know of at least one
SIP
> > UA that implements this spec.
> 
> Don't all the UPNP documents say "Microsoft Corporation. All Rights
> Reserved" ? ;-)

Actually, according to the text itself, "UPnP Forum Members have rights
and licenses defined by Section 3 of the UPnP Membership Agreement to
use and reproduce the Standardized DCP in UPnP Compliant Devices", and
according to the membership agreement, "There is no fee or other charge
to execute this Membership Agreement and thereby become a Member."

> Ok, insert my original example, but instead of a home proxy firewall
I'm
> in
> a hotel using pay-per-view IP transport and have to register through a
> proxy
> that handles policy decisions . . .  (gee, sounds exactly like
one-half of
> the 3GPP problem set).

Why exactly would you have to register through such a proxy? What is
wrong with using a TLS/SSL connection to your corporate server, and
placing the connection through it?

> > Failing that, your best bet is to migrate to IPv6.
> 
> yeah, like THAT woudn't impose change requirements on my existing
> obsolete-but-beloved phone . . .

It would definitely have an impact. OTOH, it would make a number of
scenarios much simpler. And, since you mention 3GPP, isn't it the case
that 3GPP devices are supposed to use IPv6?

-- Christian Huitema

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Tue, 26 Feb 2002 10:08:18 -0600

> that 3GPP devices are supposed to use IPv6?

Well, using TLS to the coporate server wouldn't work, because I need to
coordinate with the SIP ALG in the proxy-firewall.

Yes, Christian, 3GP phones use IPV6, but they find they still have a desire
to use a similar pattern. Maybe you missed he discussion of why 3GPP wants
to do it this way, so I'll try and recap.

They (3GPP) have a requirement to provide, at operator discretion, very
strict control of network usage. It's almost as if the entire semantics of
ATM SVCs have been transplanted onto IP, with UNI replaced by
application-level control.  The operators want to do service-senstitive AAA
for the traffic. It's not the Internet.

The basic model involves:
1) a phone or UE (User Equipment), which has knowledge of link-layer
policies that apply to it.
2) a GGSN, which is a policy-enforcement-point firewall router,
3) a P-CSCF, which is a SIP proxy that also has policy-decision-point
capabilities and talks to GGSN via COPS-PR or the equivalent thereof.

Policy sets are called "PDP Contexts". Each PDP context can be though of as
effectively analagous to an SVC between the phone.

When the phone turns on, it talks to the GGSN and receives a signaling PDP
context for use with SIP. This PDP context's policy in the GGSN allows IP
traffic between the UE and the SIP port on the P-CSCF. All SIP traffic goes
between the phone and the P-CSCF over this signaling PDP context. The phone
literally can't talk any other protocol to any other endpoint.

As the phone negotiates sessions by sending and receiving SIP through the
P-CSCF, the P-CSCF provisions additional policy into the GGSN to create
aditional PDP contexts or alter the policy on existing PDP contexts as
needed.

This has some implications:

1) The P-CSCF has to see and understand the signaling used to set up any
session. If the P-CSCF can't see and understand it, then no PDP context gets
provisioned, and the traffic doesn't flow. This breaks SIP-level end-to-end
privacy.

2) Given #1, all SIP messages must traverse the P-CSCF. This means it has to
a) be magically included in the path for all initial messages, including
those inbound to the phone, and b) record-route for inclusion in subsequent
messages.

3) There may be lots of SDP that a P-CSCF doesn't understand. If it can't be
understood, it can't be provisioned in the GGSN. They therefore need a
mechanism to indicate to the phone that the proposed SDP cannot be
understood. The current proposal is to "edit" the SDP in various proxies,
and allow only conformant SDP offers and answers to be made. This of course
breaks end-to-end SIP body security. I'm open to suggestions here . . .

There are lots of other obnoxious PTT regulatory stupidities in the model as
well, but let's not go into those right now or my spleen might explode.

It might be entirely legitimate for people to tell 3GPP "You people are
breaking the Internet model completely. You're free to do that, but we don't
want to help." On the other hand, that hasn't been the apparent consensus
to-date -- we're trying to help them develop as reasonable an implementation
as is feasible within the time bounds defined by the market. It's called
"business".

--
Dean

---

From: [email-masked]
Date: Tue, 26 Feb 2002 19:01:56 +0200

> literally can't talk any other protocol to any other endpoint.

my gprs phone can already today setup pdp contexts at will and send
register and other sip messages to anybody likes to by sending and
receiving ip packets over those contexts.  i have been told that in the
next gprs release, the phone should be able to also tell the qos
requirements of these pdp contexts.  are you saying that in all ip 3g
all this is going to go away and my phone can only talk to the
operator's p-cscf?

 > well, but let's not go into those right now or my spleen might explode.

i know the regulations here pretty well and i don't think any of the 3g
stupidity is in fact caused by it.  it is caused by the operator's and
equipment vendors (because the operators feed them) desire to lock the
customer in into the walled garden.  the sip working group should not
play any part in that conspiracy.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Feb 2002 17:38:48 -0600

On Tuesday 26 February 2002 11:01 am, [email-masked] wrote:

Juha asks:
> Dean Willis writes:
>  > When the phone turns on, it talks to the GGSN and receives a
>  > signaling PDP context for use with SIP. This PDP context's policy
>  > in the GGSN allows IP traffic between the UE and the SIP port on
>  > the P-CSCF. All SIP traffic goes between the phone and the P-CSCF
>  > over this signaling PDP context. The phone literally can't talk
>  > any other protocol to any other endpoint.
>
> receiving ip packets over those contexts.  i have been told that in
> the next gprs release, the phone should be able to also tell the qos

There will be seperate GPRS "subscriptions" for IMS (Internet 
Multimedia Subsystem) service and for general Internet. You might have 
one or the other or both.

The traffic on the signaling PDP context is probably billed to the IMS 
operator, rather than being charged to you on a per kB basis.

The operator probably doesn't want to pay for your web surfing. And 
they assume you as a subscriber don't want to pay for all the 
registration bits and otehr things one  expects are "free" on GSM.

>
>  > There are lots of other obnoxious PTT regulatory stupidities in
>  > the model as well, but let's not go into those right now or my
>  > spleen might explode.
>
> i know the regulations here pretty well and i don't think any of the
> 3g stupidity is in fact caused by it.  it is caused by the operator's
> and equipment vendors (because the operators feed them) desire to
> lock the customer in into the walled garden.  the sip working group
> should not play any part in that conspiracy.

There seem to be some claims that the regulations in Germany around 
privacy require that the To: and From: fileds are always encrypted or 
contain meaningless text. Hey, I don't understand it -- I'm just 
repeating what they tell me . . . but it's just crazy enough that I 
believe it.

--
Dean