Subject: RE: [Sip] The Problem with PRACK

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 14 Mar 2006 16:02:03 +0100

Hi,

I agree with Brett.

When 100rel is used it gives a possibility to ACCEPT an offer, and send
an answer BEFORE 200 OK.

Of course the UAS can reject the offer in the INVITE, but that has
nothing to do with reliable 18x:s or PRACK.

Regards,

Christer 

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: 14. maaliskuuta 2006 16:17
To: 'Juha Heinanen'
Cc: [email-masked]
Subject: RE: [Sip] The Problem with PRACK

> > As currently specified (rfc3261 section 13.2.1) for offer/answer, a 
> > 18x with SDP sent over a reliable transport without use of 100rel is

> > not considered an answer.  Thus if 100rel is not used, UPDATE cannot

> > carry a related offer since there is still an outstanding offer 
> > without an official answer.
> 
> if offer in invite is not acceptable, why not reject it and tell what 
> kind of offer would have been acceptable?

My comment has nothing to do with acceptability of the SDP.  

My comment is to indicate that reliability of transport currently has
nothing to do with "reliability" related to offer/answer rules.  Thus
100rel is currently still required on reliable transports for
offer/answer reasons.

_______________________________________________
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

_______________________________________________
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: Wed, 15 Mar 2006 00:55:28 +0200

> When 100rel is used it gives a possibility to ACCEPT an offer, and send

why is it important for the UAS to accept SDP offer before accepting or
rejecting the invite and why it is important for the UAC to be sure that
UAS has accepted the offer before accepting or rejecting the invite?

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 16:24:51 -0600

> UAS has accepted the offer before accepting or rejecting the invite?
Because people adopted the user-expectations of the PSTN as  
requirements (a mistake, I believe).

In this model, your phone doesn't ring unless there are resources  
available on the net for the call leg that will exist when you answer.

So the model is: 1) Locate target. 2) Establish resources. 3) Notify  
the user of the target. 4) Talk.

Of course, this could all have been done more easily my having first  
done an exploratory INVITE that returned a contact, using RSVP or  
NSIS to establish media resources to the contact, and then sending  
the INVITE to the contact. But people somehow though that doing it in  
a different order would make the resource management easier. In  
general, it didn't.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 00:34:20 +0200

> available on the net for the call leg that will exist when you

dean,

as i have tried to show in my previous message, this problem can be
solved without PRACK and reliable responses.  also see the example in
the previous message, which tries to show that you cannot do any better
than what i propose, i.e., UAC has to reserve resources according to the
highest bandwidth codec in its offer list before it sends out the
INVITE.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 16:45:00 -0600

> highest bandwidth codec in its offer list before it sends out the

No doubt you are correct, insofar as you go.

However, couple this with the per-committed-flow charging mentality.  
If you commit a 14kbps reservation in order to answer a call, you get  
billed for it. The 3GPP model allows the CALLER to commit the  
resource reservation, so that the CALLER gets billed for it.

You might be able to fake this with clever accounting, but in general  
its very hard to completely attribute an IP flow to a specific call  
unless your reservation protocol provides hooks for this, and this  
has been found to require some sort of request-response cycle before  
the commitment occurs. Could have been RSVP, but we ended up with  
PRACK. I don't like it, but it is what it is.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 00:54:51 +0200

> resource reservation, so that the CALLER gets billed for it.

yes, caller commits to the reservation when it reserves its own
resources and sends out invite to UAS that lists the codecs it wants to
pay for at the remote end.  i don't see how you could do any better with
PRACK.

 > PRACK. I don't like it, but it is what it is.

no need to associate IP flows to call.  see above.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Mar 2006 18:07:11 -0500

Juha,

You have been talking as if preconditions are only for QoS.
There are now other defined uses. For instance there are security 
preconditions, used to ensure that both sides know the keys and are able 
to communicate securely before the phone rings. Do you have another way 
to do that too?

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 01:17:21 +0200

> to communicate securely before the phone rings. Do you have another way 

paul,

so far only QoS has been mentioned, but the problem seems to be the same
also with security:  180 Ringing comes from a secure leg followed by
200 OK from unsecure one.  how does PRACK help you?

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Mar 2006 18:32:47 -0500

> 200 OK from unsecure one.  how does PRACK help you?

Doesn't require forking at all.

Consider Alice sends offerless invite to Bob. But Bob is only willing to 
do secure calls. So Bob returns an offer in a 183 with security 
preconditions. Bob needs an answer back that releases those 
preconditions before he is willing to ring, much less answer.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 17:52:51 -0600

On Mar 15, 2006, at 5:32 PM, Paul Kyzivat wrote:

> Consider Alice sends offerless invite to Bob. But Bob is only  
> willing to do secure calls. So Bob returns an offer in a 183 with  
> security preconditions. Bob needs an answer back that releases  
> those preconditions before he is willing to ring, much less answer.

Off-the-wall response coming.

How about:

Bob redirects Alice to himself, along with a precondition qualifier.  
Alice satisfies the preconditions, then sends Bob a new INVITE that  
indicates the aforementioned preconditions have been satisfied.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Mar 2006 20:48:06 -0500

Dean,

I don't doubt that we could come up with some different model for how to 
do each thing that would be broken by deprecating PRACK. That means 
deprecating not only PRACK, but all the other RFCs and drafts that are 
dependent on it. I'm not sure how many of those there are, probably not 
a lot, but some. Each of those things will have to either be written off 
as a bad idea, or else redefined using some other mechanism. I guess if 
they are all bad ideas then this is clearly the right way to go. If some 
of those are still things that people want, then that makes more work to 
do.

What you suggest below is a different way to do security preconditions. 
It could be the germ of a working scheme - or maybe it will be found to 
be flawed after further study. In any case it will take another cycle of 
draft development, attention units from ietf participants, and time at 
ietf meetings. Do we want that?

	Paul

Dean Willis wrote:
>> Consider Alice sends offerless invite to Bob. But Bob is only  willing 
>> to do secure calls. So Bob returns an offer in a 183 with  security

---

From: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 21:16:32 -0600

On Mar 15, 2006, at 7:48 PM, Paul Kyzivat wrote:

> Dean,
>
> I don't doubt that we could come up with some different model for  
> how to do each thing that would be broken by deprecating PRACK.  
> That means deprecating not only PRACK, but all the other RFCs and  
> drafts that are dependent on it. I'm not sure how many of those  
> there are, probably not a lot, but some. Each of those things will  
> have to either be written off as a bad idea, or else redefined  
> using some other mechanism. I guess if they are all bad ideas then  
> this is clearly the right way to go. If some of those are still  
> things that people want, then that makes more work to do.
>
> What you suggest below is a different way to do security  
> preconditions. It could be the germ of a working scheme - or maybe  
> it will be found to be flawed after further study. In any case it  
> will take another cycle of draft development, attention units from  
> ietf participants, and time at ietf meetings. Do we want that?
>

I hadn't suggested deprecating PRACK, though I believe Rohan had  
suggested simplifying it.

I do believe that the preconditions model around PRACK has become  
over-used and top-heavy, and I wish we'd found a better way.

Juha also made some suggestions on how to avoid using it.

But rather than wrestling PRACK, I'd far rather we concentrate on  
cryptographic, service, and identity transparency, elimination of  
proxy retargeting, and fixing the proxy routing model.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 07:02:27 +0200

> preconditions before he is willing to ring, much less answer.

how does that work with forking in the example i gave.  you didn't
answer. or are you saying that you deprecate forking in order to make
your precondition stuff work?  forking is one important value add of SIP
over PSTN and i don't want to thought it away.

i thought that IETF had defined some kind of KPI based system to
identify callers.  is that also gone?

what comes to your example, why can't bob return back a 4xx response
with security preconditions, the same way authentication works?

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 07:05:58 +0200

> indicates the aforementioned preconditions have been satisfied.

this is similar to my 4xx response and would work too.  it would be high
time for stop inventing new messages and use what we already have got.

current status of the discussion: no one has yet come up with any
example that would require PRACK.  also, the precondition stuff with 1xx
seems to have serious problems with forking.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 07:23:05 +0200

Paul Kyzivat writes:

 > drafts that are dependent on it. 

the more goes the better.  that gives implementers time to catch up and
in the meanwhile SIP working group can do their laundry.

 > Do we want that?

what we want is a small number of easy to understand/simple to implement
specifications.  why you got into this mess was that IETF had no guts to
say NO to the walled garden based requirement from 3gpp.  now it is high
time do so.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Mar 2006 01:33:13 -0500

Juha Heinanen wrote:
> answer.

Sorry. I saw that but seem to have misplaced it.

  or are you saying that you deprecate forking in order to make
> over PSTN and i don't want to thought it away.

No, I don't believe they conflict, any more than any other thing has 
problems with forking.

> identify callers.  is that also gone?

Huh? What does this have to do with the current discussion?

> with security preconditions, the same way authentication works?

HERFP.

Plus of course at the moment there is no such 4xx response.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Mar 2006 01:41:11 -0500

> time for stop inventing new messages and use what we already have got.

Well, I'm pretty sure PRACK was created before SUBSCRIBE. Does that mean 
that we should trash SUBSCRIBE too?

> seems to have serious problems with forking.

Nobody has come up with a case where PRACK can't be replaced by some 
other vaguely specified hypothetical new extension to sip. That isn't a 
fair comparison.

Frankly, it would be fun to throw away everything that seems wrong with 
sip and just redesign everything based on the wisdom that has been 
gained. But I don't think that is going to fly. (Look at the much 
smaller goal of replacing SDP with SDPng.)

So we are stuck for now with evolutionary changes. Incompatible changes 
are hard to do.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Mar 2006 01:31:48 -0600

On Mar 15, 2006, at 11:02 PM, Juha Heinanen wrote:

>> willing to

Well, we meet the preconditions at ALL the forked-to endpoints before  
Bob answers.

> identify callers.  is that also gone?

sip-identity?

> with security preconditions, the same way authentication works?

That might work too - a new 4xx message that returns a key to be used  
later. Hmm.

--
Dan

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Mar 2006 01:50:10 -0600

>> with security preconditions, the same way authentication works?

No, not if we could match the 4x to a contact-specific target for the  
followon request.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 12:28:14 +0200

> that we should trash SUBSCRIBE too?

if you could have implemented same functionality with existing SIP
requests, which is not likely with subscribe, but is likely with PRACK.

 > other vaguely specified hypothetical new extension to sip. That isn't a 

you can dump PRACK for resource reservation without ANY extension to SIP
as i have shown in earlier messages.  it was 3gpp folks that defended
PRACK on the basis of resource reservation, and they claims turned out
to be false.

 > So we are stuck for now with evolutionary changes. Incompatible changes 

evolution in should also mean deprecating bad ideas, not all the time
adding new RFCs to the pile.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 12:34:42 +0200

> Well, we meet the preconditions at ALL the forked-to endpoints before  

i didn't ask about answering, but when does bob's phone start to ring?
when it has got first 180 with accepted preconditions?

 > sip-identity?

yes, i was thinking of some IETF spec that lets the callee to verify using
PKI who is calling.  perhaps such beast doesn't exist.

 > That might work too - a new 4xx message that returns a key to be used  

your 3xx idea was better.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Mar 2006 08:12:08 -0500

> when it has got first 180 with accepted preconditions?

I think we are all getting confused here. Alice called Bob, so Bob won't 
ever get a 180. Bob's phone will start to ring when all preconditions 
for both alice and bob have been satisfied. At that same time Bob will 
send a 180 to Alice, and Alice will begin to hear ringback.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Mar 2006 08:15:24 -0500

> No, not if we could match the 4x to a contact-specific target for the  

Huh? In presence of forking this doesn't help. You can only return one 
4xx response.

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 15:30:07 +0200

> send a 180 to Alice, and Alice will begin to hear ringback.

what about if he call gets forked to another plain old RFC3261 UA that
replies with 200 OK after 180 has come from Bob to Alice?

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 16 Mar 2006 15:31:18 +0200

> Huh? In presence of forking this doesn't help. You can only return one 

that is why i said that Dean's 3xx idea was a better one, because proxy
is supposed to collect all 3xx replies to its reply to the caller.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Mar 2006 08:49:10 -0500

> requests, which is not likely with subscribe, but is likely with PRACK.

I guess then that the entire WG was really very stupid to have approved 
RFC3262.

> PRACK on the basis of resource reservation, and they claims turned out

I am not trying to defend the 3gpp people. But you haven't proven that 
their claims are false. You have shown that with a particular set of 
simplifying assumptions about the problem space you can do without PRACK.

I think there must be a higher bar for deprecating an RFC.

I now understand that Rohan is advocating something much less than that. 
Even that needs good justification, but might be easier to achieve.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Mar 2006 15:11:56 -0600

On Mar 16, 2006, at 7:49 AM, Paul Kyzivat wrote:

>
>
> Juha Heinanen wrote:
>> Paul Kyzivat writes:
>>  > Well, I'm pretty sure PRACK was created before SUBSCRIBE. Does  
>> that mean  > that we should trash SUBSCRIBE too?
> I guess then that the entire WG was really very stupid to have  
> approved RFC3262.

I feel stupid. It's all my fault!

There, better?

Now, I would like to point out that there is a difference between  
formally deprecating something, and just realizing that there are  
better ways of achieving the goal and using those better ways.

I rather like the mention in Adam's Hitchikers Guide of the  
deprecation of the "future perfect" tense required by the invention  
of time travel, due to the fact that travelers arriving in the future  
found it not to have been perfect after all.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 16 Mar 2006 15:06:05 -0600

On Mar 16, 2006, at 7:15 AM, Paul Kyzivat wrote:

>> No, not if we could match the 4x to a contact-specific target for  
>> the  followon request.
>
> Huh? In presence of forking this doesn't help. You can only return  
> one 4xx response.
>
Well, since it's a "new" 4xx, we could have the proxy that had the  
poor taste to fork the request roll up the timely responses and throw  
away the late ones.

Not all that pretty, I'll admit.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Mar 2006 20:56:30 -0500

> replies with 200 OK after 180 has come from Bob to Alice?

Then alice gets to talk to Bob on the phone that answered rather than 
the one that didn't.

	Paul

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 17 Mar 2006 04:09:27 +0200

> Then alice gets to talk to Bob on the phone that answered rather than 

the point was that Alice doesn't want to talk to anyone whose
preconditions were not filled.  but we can leave this now and go back to
work.

-- juha