Subject: RE: [Sip] The Problem with PRACK

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sun, 19 Mar 2006 16:44:27 -0000

You misconstrue.

My argument was that in the absence of a charging model, IETF has to assume that other organisations, or even the operator's themselves develop their own, and IETF has to cater for that.

Moreover the argument Juha was developing was that we have have a technical solution that would appear to preclude charging for allocated resource at the user access on a per session basis. While that may not be everyone's cup of tea, I certainly do not see anything more walled garden about that than charging for bytes transferred across the access, or charging for total bandwidth of the access pipe.

regards

Keith

> -----Original Message-----
> From: Christian Jansson [mailto:[email-masked]]
> Sent: 16 March 2006 20:25
> To: Drage, Keith (Keith); Paul Kyzivat; Juha Heinanen
> Cc: [email-masked]; Christer Holmberg (JO/LMF); Dean Willis; Brett Tate
> Subject: RE: [Sip] The Problem with PRACK
> 
> 
> 
> 
> >From: Drage, Keith (Keith) [mailto:[email-masked]]
> >
> >As IETF has not specified a charging model for SIP, or the resources
> under
> >the control of SIP, and does not intend to, I would suggest that we
> have to
> >assume there is no such restriction, and therefore have to make sure
> our
> >protocol supports a multitude of charging cases.
> 
> 
> Is your opinion that HTTP is big failure just because they did not
> specify a charging model? Is your opinion that it is impossible to get
> paid for services on the internet? 
> 
> I think the problem is the vision you have of the walled-in 
> environment,
> with the "multitude of charging cases", with "all" the specially
> selected applications that a customer would ever want in the 
> control of
> the IMS operator. In this environment the user should completely trust
> his IMS operator, no end-to-end crypto stuff allowed, because 
> as it was
> said in an earlier mail today, the cscf would probably need to do some
> "deep inspection" before letting the request go out to the open
> Internet. In contrast to the trust the user has to have for the
> operator, the operator does not even trust the user to handle 
> basic sip
> headers, that is, the topology has to be hidden. Who knows what would
> happen otherwise, perhaps the user would want to skip/replace some of
> the nice services that the operator so kindly have provided him with.
> (To me it seems that the services are more of a service to 
> the operator
> than to the user?)
> 
> Of course I think that it should be possible to get paid for 
> delivering
> VoIP services, but perhaps not exactly the same way as it was designed
> over 100 years ago, because in that case we could have stayed 
> with PSTN
> and the GSM systems that we have.
> 
> / Christian Jansson
> 
> 
> 

_______________________________________________
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: Juha Heinanen <[email-masked]>
Date: Mon, 20 Mar 2006 03:33:00 +0200

Drage, Keith (Keith) writes:

 > Moreover the argument Juha was developing was that we have have a
 > technical solution that would appear to preclude charging for
 > allocated resource at the user access on a per session basis. 

i'm tired of this bull-you-know. i specifically showed that SIP UAC and
UAS can allocated access bandwidth for a call without ANYTHING new to
rfc3261.  and if UAC and UAS can allocate access resources, sure someone
in the access network can charge for them.

-- juha

---

From: <[email-masked]>
Date: Mon, 20 Mar 2006 04:57:21 +0200

Hi, 

>i'm tired of this bull-you-know. 

Sorry Juha to bother you still once more, but Adam's comments
indicate the issue as serious ...

> I'll point out that implementing the offer/answer procedures with
PRACK
> requires a state machine with at least 52 states and 329 transitions.
> That's a *lot* of code, and the chances of getting it all right are
> pretty close to zero.

... so I would still like to understand the subject a bit better.

In your story there is something that does not yet make sense
to me. You have suggested the following:

- Preconditions and PRACK have been specified for 3GPP requirements
- You do not have any business for 3GPP environment
- Your customers have bought lots of SIP phones with PRACK
implementation
  (with offer/answer if I understand you correctly)

So do you have any idea, why those SIP phones used in non-3gpp
environment
have implemented PRACK which has caused so much problems ? I do not
believe
they have added PRACK support 

- just to cause problems and make call setup to take longer
- to have some programming fun with an interesting piece of RFC
- for 3GPP IMS compliancy - I understood it is not their business

It would be good to understand why such implementations exist in
wireline
SIP environment. If that is not well understood we do not know what
implications might deprecating offer/answer within PRACK to have and
what kind of solutions would be needed in place of that.

Do those wireline SIP phones try to do preconditions or something
else with PRACK ? If they do preconditions, what kind of (security,
resource reservation) ? What is the motivation for all that in your
business environment ?

Regards,

Erkki
____________________________________

  Erkki Koivusalo
  Nokia Mobile Software
  tel:+358 40 7571197
  mailto:[email-masked]
____________________________________

---

From: "Juha Heinanen" <[email-masked]>
Date: Mon, 20 Mar 2006 12:23:29 +0200 (EET)

>   (with offer/answer if I understand you correctly)

i don't know if with or w/o offer answer and i don't care.  the thing that
i know is that when new software has come out, phones that used to
interoperate well with others, stopped doing so.

> they have added PRACK support.

i have seen PRACK request flying in my ethernet dumps and haev identified
the reason of problems being due to PRACK.  ask cisco, why they have
implemented PRACK in their SIP/PSTN GWs, not me.

-- juha