Subject: RE: [Sip] The Problem with PRACK

From: "Arunachalam Venkatraman \(arunvenk\)" <[email-masked]>
Date: Wed, 8 Mar 2006 20:05:35 -0800

Regarding 1 below about having to queue up provisionals pending PRACK
for first one, an additional nuance is that it is also required to queue
up provisionals even after the first is PRACKed and send them one at a
time, as the PRACK for each is received.
If this were not done, then the PRACKS may be received out of sequence
and mess up the CSeq check for requests received at the UAS.
Then the UAS will futilely continue to retransmit the provisionals with
no hope of ever matching the PRACKS that were returned a 500 response
due to out-of-sequence receipt.

________________________________

From: Rohan Mahy [mailto:[email-masked]] 
Sent: Wednesday, March 08, 2006 5:51 PM
To: Jonathan Rosenberg (jdrosen)
Cc: IETF SIP List
Subject: Re: [Sip] The Problem with PRACK

Hi,

A things about PRACK come immediately to mind that are a pain to
implement:

1) The UAS has to queue provisionals until it receives a PRACK for the
first provisional.  This is due to RSeq starting at an arbitrary value
instead of just starting at 1.  This is probably the simplest to fix, by
just requiring the UAC to always start with a RSeq of 1. 

2) Multiple unacknowledged provisionals can be in flight at the same
time.  We could potentially eliminate this requirement by acknowledging
the current status instead of the whole history.  In other words, when
the UAS sends a new reliable provisional, it decides which (if any) of
the previously sent provisionals are still relevant and sends all of
them (as sipfrags or something) as a single reliable request. 

3) If you "answer" and want to deliver a 200 OK, you have to queue it
and wait if you are waiting for a PRACK to an offer or answer. Keeping
track of when you can send the 200 would be easier if we did something
like I recommend in #2.  

4) Even for an acknowledged provisional, you still have to retransmit
approximately every minute (I forget exactly) to prevent old proxies
from deleting state for your transaction.  This is one of those minor
annoyances that is *almost* operationally irrelevant, and unlikely to
not get coded.  My proposal for simplification is to retransmit the
latest reliable provisional in exactly the same way that the UAS
retransmits unreliable provisionals.  Who cares if there is an extra
message or two for a call with 1 minute + post-answer delay? 

5) I would deprecate the PRACK/200 (PRACK) offer/answer exchange.  I
talked Jonathan into this, and I've been sorry I did ever since.  My
apologies to everyone for making a bad decision.

Hope this helps.
thanks,
-rohan

On 3/7/06, Jonathan Rosenberg <[email-masked]> wrote: 

	At the last IETF, there was a lot of discussion and argument
around
	PRACK. The spark of this debate was the ICE specification, which
had
	words in it requiring the usage of PRACK and UPDATE in order to
work
	with early media. There was strong pushback from many
implementors that 
	anything requiring PRACK is unacceptable. Rohan put up a slide
(IIRC)
	that showed the state machine in his implementation resulting
from
	PRACK, and it was not pretty.
	
	So, I'd like to discuss exactly what IS the problem with PRACK?
There 
	are really two pieces of state machinery in play here. One piece
is the
	complication that PRACK introduces into the offer/answer model.
With
	PRACK, you can now get a final answer in the 18x, and then send
a new
	offer in UPDATE, or even in PRACK itself. Another piece is the
state
	machinery with the retransmissions itself - correlating the
PRACK with a
	particular reliable provisional response and causing it to stop.
	
	In a chat with Flemming today, he suggested in interested remedy
to our 
	PRACK dilemma. Why not revise PRACK so that you can't send an
offer or
	answer with it; it has no impact on the set of allowed O/A
exchanges
	defined by RFC 3261. I'm not sure if that would consequently
break the
	preconditions mechanism, but maybe there are some kind of
offer/answer
	limitations that would simplify things.
	
	So, this is one idea. I'd like for people who have complained
about
	PRACK implementations to speak up and indicate what exactly
makes it so 
	complicated for them.
	
	Thanks,
	Jonathan R.
	--
	Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
	Cisco Fellow                                   Parsippany, NJ
07054-2711
	Cisco Systems 
	[email-masked]                              FAX:   (973)
952-5050
	http://www.jdrosen.net                         PHONE: (973)
952-5000
	http://www.cisco.com
	
	_______________________________________________
	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: "Samir Srivastava" <[email-masked]>
Date: Thu, 9 Mar 2006 01:48:59 -0600

We can do it, by adding more logic / header. UAS knows about all the
hops by complete via header set inspection. When sending 1xx, it need to
indicate in this new header to be defined. Is it worth
defining this ?

Thx
Samir

-----Original Message-----
From: Srivastava, Samir [SC100:8826:EXCH] 
Sent: Wednesday, March 08, 2006 11:19 PM
To: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH]
Cc: IETF SIP List
Subject: RE: [Sip] The Problem with PRACK

We can do for SIPS only.

Thx
Samir 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Wednesday, March 08, 2006 7:29 PM
To: Audet, Francois [SC100:3055:EXCH]
Cc: IETF SIP List
Subject: Re: [Sip] The Problem with PRACK

Francois Audet wrote:
> I'm ok with the suggestion to deprecate using PRACK for Offer/Answer. 
> 
> While we are at it, why not go for deprecating the use PRACK 
> altogether when TCP transport is used?

Explain to me again how you would know that reliable transport is used
end to end?

	Paul

> On Mar 8, 2006, at 15:51 , Rohan Mahy wrote:
> 
>> Hi,
>>
>> 1) The UAS has to queue provisionals until it receives a PRACK for 
>> the first provisional.  This is due to RSeq starting at an arbitrary 
>> value instead of just starting at 1.  This is probably the simplest 
>> to fix, by just requiring the UAC to always start with a RSeq of 1.
>>
>> time.  We could potentially eliminate this requirement by 
>> acknowledging the current status instead of the whole history.  In 
>> other words, when the UAS sends a new reliable provisional, it 
>> decides which (if any) of the previously sent provisionals are still 
>> relevant and sends all of them (as sipfrags or something) as a single

>> reliable request.

>> and wait if you are waiting for a PRACK to an offer or answer. 
>> Keeping track of when you can send the 200 would be easier if we did 
>> something like I recommend in #2.
>>

>> On 3/7/06, *Jonathan Rosenberg* <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
around
had
work
>>     with early media. There was strong pushback from many
implementors
>>     that
(IIRC)
from
There
With
>>     PRACK, you can now get a final answer in the 18x, and then send a
new
state
>>     machinery with the retransmissions itself - correlating the PRACK
>>     with a
offer or
exchanges
break the
offer/answer
about
>>     PRACK implementations to speak up and indicate what exactly makes
>>     it so
>>     complicated for them.
>>
>>     Thanks,
>>     Jonathan R.
>>     --
>>     [email-masked]
>>     <mailto:[email-masked]>                              FAX:  
>>     (973) 952-5050
952-5000
>>     <https://www1.ietf.org/mailman/listinfo/sip>
>>     Use [email-masked]
>>     <mailto:[email-masked]> for questions on
current sip
>>     Use [email-masked] <mailto:[email-masked]> for new
>>     developments on the application of sip
>>
>>
>> This list is for NEW development of the core SIP Protocol Use 
>> [email-masked] 
>> <mailto:[email-masked]> for questions on current 
>> sip Use [email-masked] <mailto:[email-masked]> for new 
>> developments on the application of 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: "Samir Srivastava" <[email-masked]>
Date: Mon, 13 Mar 2006 15:20:30 -0600

There is some marketing chant, as it raised the question of *using* .

As we move from the islands of deployments to connected SIP deployments,
SIP over TLS is more important. From user (Non Tech) prespective, If his
calls are not secured end to end, he will not
Like to do phone banking and other transactions / enrolling in the
services etc, where his personal
Data (SSN etc) are involved on our favourite VoIP User Agents. User gets
a call (SIP/UDP), then
They need to decide okay let us switch to secure mode, as we need to
exchange identity stuff etc.
As the call was earlier set, server impersonation might already happened
and reInvites might not
Offer the desired security. PSTN doesn't offer this user experience, but
due to unsecure hop anywhere user is going to have some unpleasant
experience of *switching over* or making a new call
with security too bad.  If SIPS is not used, reInvites in current
situations doesn't help, where 
we don't have end to end transport discovery mechanism. Sorry in our
current situation call needs
to be made again or use SIPS always at the first stage. Which makes the
case of deprecating PRACK
more strong.

Moreover Unsecure SIP hops are another gold mines for Spammers.

Let me draw a parallel, how many PCs one sees without virus protection.
Either you buy secure managed service from the provider (This is very
similar to SBC at the first hop i.e. B2BUA) or you take care of your PC
yourself. Are we waiting for a spam simliar to "I Love You Virus" and
keeping our SIP UA alerting (down) for a long as we move to "more
connected" phase. I can still live with
my PC down, but not without Phone connectivity, which is broken/less
usable (SPAMS) because of *unsecurity* in VoIP. Then I still need PSTN. 

Apart from security, as the development is going on PIDF large , SAML
also large too. We might see
1300 size going up very quickly. 

IMHO, IETF should first deprecate SIP over UDP. In the infancy days of
SIP, I read a report SIP is so simple you can run over UDP, but in
realization now it is causing more troubles then offering
benefits.

Thx
Samir

-----Original Message-----
From: Aki Niemi [mailto:[email-masked]] 
Sent: Friday, March 10, 2006 4:24 AM
To: Srivastava, Samir [SC100:8826:EXCH]
Cc: IETF SIP List
Subject: Re: [Sip] The Problem with PRACK

Inline.

ext Samir Srivastava wrote:
> ext Samir Srivastava wrote:
>> It has been around 4 years. UA MUST have TCP. We need to draw a line 
>> worrying about backward compatibility with 2543. UA is not 3261 
>> compliant and should be fixed. If still it has only UDP, they will be

>> few and we get gain for optimizing most of the UA supporting TCP.
> 
> Implementing and using are two completely different things. 
> 
> SS>> Agreed. Do you mean to say we are going to have *increasing* 
> SS>> number
> of UAs which will be 
>      ONLY supporting UDP in future, which have lot security holes 
> because TLS is not used.

I think (and hope) there will be an increasing number of UAs both
supporting *and* using TCP and TLS in the future.

> Even if the proxy wanted to use TCP for the last hop towards the UA, 
> it won't be able to connect to a host behind a NAT. This is what 
> sip-outbound is trying to fix.
> 
> SS>> How UDP is going to help here, if UA is not keeping the bindings
> alive. UA needs to keep 
>      binding alive for every flow. Pl explain. 

But if there is no contact registered for that UA that supports TCP,
then the proxy is out of luck and can only downgrade to UDP.

There's actually a wide range of associated problems with UAs I've used.
For example, some might allow you to switch over to using TCP, but after
that, the UA will only ever use TCP -- for registrations and invites
alike -- leaving domains that only accept UDP unreachable.

So again, implementing and using (let alone using wisely) are two
entirely different things.

Cheers,
Aki

Cheers,
Aki

> Cheers,
> Aki

---

From: "Samir Srivastava" <[email-masked]>
Date: Mon, 13 Mar 2006 16:14:28 -0600

<< Removed >>

So, sips still doesn't assure you end-to-end TCP. Or security, for that
matter.

SS>> I think now I should start writing my first draft, for discovering
end to end transport 
     (reliable, secure, unreliable) at UAS  and indicating it back. It
may find other use
     cases too.

<< Removed >>

Personally, I'm in favor of simply deprecating SIP/UDP (and forking, but
I can't say that).

SS>> Atleast chairs agree on deprecating SIP over UDP. Nice !! 
    (B2BUA Bell headed, Deprecate Forking Idiots , nice terminology :-)

Thx
Samir

--
Dean

---

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

Hi,
 
A long time ago, I proposed a solution which would not require the
queueing: the INVITE request would contain the RSeq value that the UAS
MUST use for the FIRST reliable provisional response.
 
Regards,
 
Christer

From: Arunachalam Venkatraman (arunvenk) [mailto:[email-masked]] 
Sent: 9. maaliskuuta 2006 6:06
To: Rohan Mahy; Jonathan Rosenberg (jdrosen)
Cc: IETF SIP List
Subject: RE: [Sip] The Problem with PRACK

Hi,

Hope this helps.
thanks,
-rohan

	

	
	Thanks,
	Jonathan R.

---

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

Hi,

I BELIEVE that the reason for allowing offer/answer in PRACK was the
precondition mechansim, but there are probably people who know more than
me about that.

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 9. maaliskuuta 2006 18:29
To: Prince A P
Cc: [email-masked]
Subject: Re: [Sip] The Problem with PRACK

Prince A P wrote:
> Hi,
>  
> If the 3262 is only for Reliability of Provisional responses, Why 
> should it mandate Offer-Answer completion?
> Was there any rationale behind clubbing Reliability with Offer-Answer?

I wasn't there when that was done, so I can't speak to the actual
motives of those who were.

But note that offer/answer has no mechanism of its own - it must be
associated with some messages in the signaling system.

Reliable provisionals, without sdp in the PRACK, are sufficient for
early completion of the offer/answer exchange when the offer is in the
invite. But that isn't sufficient to achieve early completion of
offer/answer when there is no offer in the invite. In that case the
offer is in the reliable provisional, and the obvious place for the
answer is in the PRACK. That seems to be reasonable justification for
involving PRACK in offer/answer.

Allowing an offer in PRACK is less motivated. Essentially the same thing
can be done using UPDATE. I can speculate on some reasons for allowing
PRACK to be used for this:
- done before UPDATE was invented
- efficiency - the prack is required anyway
- prack already needs to carry an answer, why not an offer

	Paul

>  
> rgds,
> Prince
> 
> 
>  
> 
>         To: "Samir Srivastava" < [email-masked]
>         <mailto:[email-masked]>>, "Paul Kyzivat"
<[email-masked]
>         <mailto:[email-masked]>>, "Francois Audet" <
>         [email-masked] <mailto:[email-masked]>>
>         From: "Samir Srivastava" < [email-masked]
>         <mailto:[email-masked]>>
>         Date: 03/09/2006 01:18PM
>         cc: IETF SIP List <[email-masked] <mailto:[email-masked]>>
>         hops by complete via header set inspection. When sending 1xx,
it
>         need to
>         From: Paul Kyzivat [ mailto:[email-masked]]
>          >> 2) Multiple unacknowledged provisionals can be in flight
at
>         the same
>          >> relevant and sends all of them (as sipfrags or something)
as
>         a single
> 
>          >> reliable request.
>          >>
>          >> 3) If you "answer" and want to deliver a 200 OK, you have
to
>         queue it
>          >> approximately every minute (I forget exactly) to prevent
old
>         proxies
>          >> latest reliable provisional in exactly the same way that
the
>         UAS
>          >> retransmits unreliable provisionals.  Who cares if there
is
>         an extra
>          >> On 3/7/06, *Jonathan Rosenberg* < [email-masked]
>         <mailto:[email-masked]>
>          >>     anything requiring PRACK is unacceptable. Rohan put up
a
>         slide
>          >>     So, I'd like to discuss exactly what IS the problem
with
>         PRACK?
>          >>     complication that PRACK introduces into the
offer/answer
>         model.
>          >>     offer in UPDATE, or even in PRACK itself. Another
piece
>         is the
>         state
>          >>     machinery with the retransmissions itself -
correlating
>         the PRACK
>          >>     with a
>          >>     particular reliable provisional response and causing
it
>         to stop.
>          >>     [email-masked] <mailto:[email-masked]>
>          >>     < mailto:[email-masked]>

>          FAX:  
>          >>     (973) 952-5050
>          >>     http://www.jdrosen.net <http://www.jdrosen.net/>

>                         PHONE: (973)
>         952-5000
>          >>     http://www.cisco.com <http://www.cisco.com/>
>          >>
>          >>     Sip mailing list  
>         https://www1.ietf.org/mailman/listinfo/sip
>          >>     <https://www1.ietf.org/mailman/listinfo/sip
>         <https://www1.ietf.org/mailman/listinfo/sip>>
>         <mailto:[email-masked]>
>          >>     <mailto:[email-masked] > for
questions on
>         current sip
>          >>     Use [email-masked] <mailto:[email-masked]> <
>         mailto:[email-masked]> for new
>          >> Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
>          >> This list is for NEW development of the core SIP Protocol
Use
>         <mailto:[email-masked]>
>         current
>          >> sip Use [email-masked] <mailto:[email-masked]> <
>         mailto:[email-masked]> for new
>          > Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
>          > This list is for NEW development of the core SIP Protocol
Use
>         current sip Use
>          > [email-masked] <mailto:[email-masked]> for new
>         current sip Use
>         [email-masked] <mailto:[email-masked]> for new
developments
>         on the application of sip
> 
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Mar 2006 09:06:22 +0200

Hi,

For my clarification, how do the implementations you are talking about REJECT an offer received in PRACK?

Regards,

Christe

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 15 Mar 2006 09:42:22 -0500

> From: Brian Stucker [mailto:[email-masked]] 
> Sent: Tuesday, March 14, 2006 11:55 AM
> To: Dean Willis; Cullen Jennings (fluffy)
> Cc: [email-masked]; Francois Audet; Paul Kyzivat (pkyzivat)
> Based on your proposals below, cryptographically transparent 
> versus redirection:
> 
> How would you go about addressing applications like CPL that 
> need to run timers for service logic and thus need to have 
> some level of control over the session (not necessarily 
> what's in the body of the messages, just where they're going) 
> if a redirection model is used?
> 
> For example, without mucking about with what's inside the 
> request, triggering off of the request URI of an INVITE to 
> forward to destination A for X seconds and then to 
> destination B. In this example the next hop changes over time 
> for the same request and does not seem possible using 
> redirection. This seems to preclude redirection as a general 
> solution and drive towards requiring a proxy to be 
> cryptographically transparent.

Is there a reason the redirect server couldn't send you to A, 
which then redirects or Refers you to B when A is done with 
it's part of the service?

It seems the proxy is best at directing traffic, while the UAS
could contain distributed feature logic.  Think of an assembly
line of robots, each which knows its part of the process, but 
not necessarily the whole.

Mike

> 
> If the proxy is transparent, then how do you go about not 
> precluding deep-packet inspection issues raised by 
> applications such as QoS enforcement, network enforced 
> identity or other services? It seems to me that HTTPS may 
> make a bad model in that I'm unaware of any HTTPS-based 
> application that has a box in the middle that needs to 
> inspect and enforce certain characteristics of the request 
> before it is handled by the final consumer of that request.
> 
> This seems to preclude cryptographic transparency as a 
> general solution. 
> 
> I'm sure either can be used effectively in many application 
> spaces, but it does not seem that either can be used as a 
> general solution in the protocol itself.
> 
> Regards,
> Brian
> 
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, March 14, 2006 1:08 AM
> To: Cullen Jennings
> Cc: [email-masked]; Audet, Francois [SC100:3055:EXCH]; Paul H Kyzivat
> On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote:
> 
> > On 3/13/06 10:27 AM, "Dean Willis" 
> <[email-masked]> wrote:
> >
> >> Right. But, SIPS is only required as far as the proxy serving the 
> >> AOR. The AOR to Contact vector could be UDP/IPSEC, or even 
> just plain 
> >> unsecured UDP.
> >
> > I think we have a gathering amount of evidence that we want 
> to update 
> > this regardless of UDP or PRACK.
> 
> 
> It's true that SIP proxies just don't work "right" with SIPS as it is.
> 
> When people first look at the "SIPS is only valid to the 
> serving proxy" model they assume that simply changing the 
> requirement to say that the proxy-to-UA leg must also be SIPS 
> protected would provide a satisfactory answer. It doesn't, 
> and this requires some careful thinking.
> 
> What security do you mandate on the serving-proxy to UA link? TLS?  
> TLS supports many different ciphersuites. What keeps the 
> crypto on the SP-UA link from being watered-down? Would other 
> protections like IPSEC suffice? How would you end-to-end 
> negotiate the cryptography so that the originating UA could 
> believe that the entire chain was protected to some minimal 
> level? And how do you offer some level of security to an IMS 
> fashion-victim who is always going to be exposed to MITM 
> attacks from his own service provider by design?
> 
> Personally, I think the only way SIPS really gives us the 
> level of protection we have come to expect from HTTPS is if 
> it is used end-to- end, either by abandoning proxy-routing in 
> favor of a redirect model, or by causing the proxies to be 
> cryptographically transparent as is done with HTTPS proxies.
> 
> This is an important thing to note: HTTPS proxies do NOT "see 
> inside"  
> the HTTPS stream. All they do is pass it along, unchanged, to 
> the next hop. It could actually be some other protocol than 
> HTTP, and they don't care and can't tell. To-date, we haven't 
> treated SIPS proxies that way, and instead presume they have 
> access to the full stream, in many cases "write access" so 
> that they can munge various header fields about.
> 
> --
> Dean
> 
> [email-masked] for questions on current sip 
> [email-masked] for questions on current sip

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 15 Mar 2006 15:12:38 -0500

The 302 can have multiple contacts.  
The originator sends INVITE to the first contact, 
and upon no answer sends to the second AoR.

The thought is that the correct end result from user experience can
occur, 
maybe just no in the exact way, with exact node sequence as before, 
with features in exactly the same place.

I am just trying to escape a single switch mentality.
Need to re-think all the features then.

Mike

> Sent: Wednesday, March 15, 2006 12:38 PM
> To: Michael Hammer (mhammer); Dean Willis; Cullen Jennings (fluffy)
> I don't know that I follow you suggestion in the specific 
> case I am talking about.
> 
> Take for instance Call Forward No Answer. In this case, A 
> never says that it's done with the call before it is 
> retargeted to B by the network. A and B have no idea that the 
> service even exists in the middle.
> 
> Regards,
> Brian
> 
> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2006 8:42 AM
> To: Stucker, Brian [RICH1:B620:EXCH]; Dean Willis; Cullen Jennings
> (fluffy)
> Cc: [email-masked]; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat
> (pkyzivat)
> > Based on your proposals below, cryptographically transparent versus 
> > redirection:
> > 
> > How would you go about addressing applications like CPL 
> that need to 
> > run timers for service logic and thus need to have some level of 
> > control over the session (not necessarily what's in the body of the 
> > messages, just where they're going) if a redirection model is used?
> > 
> > For example, without mucking about with what's inside the request, 
> > triggering off of the request URI of an INVITE to forward to 
> > destination A for X seconds and then to destination B. In 
> this example 
> > the next hop changes over time for the same request and 
> does not seem 
> > possible using redirection. This seems to preclude redirection as a 
> > general solution and drive towards requiring a proxy to be 
> It seems the proxy is best at directing traffic, while the 
> UAS could contain distributed feature logic.  Think of an 
> assembly line of robots, each which knows its part of the 
> process, but not necessarily the whole.
> 
> Mike
> 
> > 
> precluding 
> > deep-packet inspection issues raised by applications such as QoS 
> > enforcement, network enforced identity or other services? 
> It seems to 
> > me that HTTPS may make a bad model in that I'm unaware of any 
> > HTTPS-based application that has a box in the middle that needs to 
> before it 
> > is handled by the final consumer of that request.
> > 
> > This seems to preclude cryptographic transparency as a general 
> > solution.
> > 
> > I'm sure either can be used effectively in many application spaces, 
> > but it does not seem that either can be used as a general 
> solution in 
> > the protocol itself.
> > 
> > Regards,
> > Brian
> > 
> > When people first look at the "SIPS is only valid to the serving 
> > proxy" model they assume that simply changing the 
> requirement to say 
> > that the proxy-to-UA leg must also be SIPS protected would 
> provide a 
> > satisfactory answer. It doesn't, and this requires some careful 
> > thinking.
> > 
> crypto on the 
> > SP-UA link from being watered-down? Would other protections 
> like IPSEC 
> > suffice? How would you end-to-end negotiate the 
> cryptography so that 
> > the originating UA could believe that the entire chain was 
> protected 
> > to some minimal level? And how do you offer some level of 
> security to 
> > an IMS fashion-victim who is always going to be exposed to MITM 
> > Personally, I think the only way SIPS really gives us the level of 
> > protection we have come to expect from HTTPS is if it is 
> used end-to- 
> > end, either by abandoning proxy-routing in favor of a 
> redirect model, 
> > or by causing the proxies to be cryptographically transparent as is 
> > done with HTTPS proxies.
> > 
> > This is an important thing to note: HTTPS proxies do NOT 
> "see inside"
> > the HTTPS stream. All they do is pass it along, unchanged, 
> to the next 
> > hop. It could actually be some other protocol than HTTP, and they 
> > don't care and can't tell. To-date, we haven't treated SIPS proxies 
> > that way, and instead presume they have access to the full 
> stream, in 
> > many cases "write access" so that they can munge various 
> header fields 
> > about.
> > 
> > --
> > Dean
> >

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 16 Mar 2006 02:47:50 -0600

Where do we stand for deprecating PRACK for e2e reliable transport ?
 
Should we wait for other problems to be fixed first (i.e. SDP is offer
/answer indication or UPDATE with answer). By the time it is fixed,
we have PRACK already widely implemented and used on e2e reliable
transports. Shouldn't these two go in parallel ?
 
Thx
Samir

From: Rohan Mahy [mailto:[email-masked]] 
Sent: Wednesday, March 15, 2006 6:47 PM
To: Jonathan Rosenberg
Cc: IETF SIP List
Subject: Re: [Sip] The Problem with PRACK

Hi Everyone,

I went back over the 102 messages in this thread and did not hear any
comments on my concrete proposals:

- require RSeq to start at 1
- only acknowledge the most recent provisional. if the UAS wants to send
as new provisional that completely replaces a previous one it can send
immediately.  if the UAS wants to send a new provisional but wants
acknowledgement of a previous one, it has to wait for the PRACK. 
- send a provisional every 1 minute whether reliable or not.  (instead
of every one minute for unreliable and every 2.5 minutes for reliable)
- deprecate *offers* in PRACK (answers are still OK)

comments on *this*? 

thanks,
-rohan

On 3/8/06, Rohan Mahy <[email-masked]> wrote: 

	Hi,

	1) The UAS has to queue provisionals until it receives a PRACK
for the first provisional.  This is due to RSeq starting at an arbitrary
value instead of just starting at 1.  This is probably the simplest to
fix, by just requiring the UAC to always start with a RSeq of 1. 

	2) Multiple unacknowledged provisionals can be in flight at the
same time.  We could potentially eliminate this requirement by
acknowledging the current status instead of the whole history.  In other
words, when the UAS sends a new reliable provisional, it decides which
(if any) of the previously sent provisionals are still relevant and
sends all of them (as sipfrags or something) as a single reliable
request. 
	
	3) If you "answer" and want to deliver a 200 OK, you have to
queue it and wait if you are waiting for a PRACK to an offer or answer.
Keeping track of when you can send the 200 would be easier if we did
something like I recommend in #2.  
	
	4) Even for an acknowledged provisional, you still have to
retransmit approximately every minute (I forget exactly) to prevent old
proxies from deleting state for your transaction.  This is one of those
minor annoyances that is *almost* operationally irrelevant, and unlikely
to not get coded.  My proposal for simplification is to retransmit the
latest reliable provisional in exactly the same way that the UAS
retransmits unreliable provisionals.  Who cares if there is an extra
message or two for a call with 1 minute + post-answer delay? 
	
	5) I would deprecate the PRACK/200 (PRACK) offer/answer
exchange.  I talked Jonathan into this, and I've been sorry I did ever
since.  My apologies to everyone for making a bad decision.
	
	Hope this helps.
	thanks,
	
	-rohan

		At the last IETF, there was a lot of discussion and
argument around
		PRACK. The spark of this debate was the ICE
specification, which had
		words in it requiring the usage of PRACK and UPDATE in
order to work
		with early media. There was strong pushback from many
implementors that 
		anything requiring PRACK is unacceptable. Rohan put up a
slide (IIRC)
		that showed the state machine in his implementation
resulting from
		PRACK, and it was not pretty.
		
		So, I'd like to discuss exactly what IS the problem with
PRACK? There 
		are really two pieces of state machinery in play here.
One piece is the
		complication that PRACK introduces into the offer/answer
model. With
		PRACK, you can now get a final answer in the 18x, and
then send a new 
		offer in UPDATE, or even in PRACK itself. Another piece
is the state
		machinery with the retransmissions itself - correlating
the PRACK with a
		particular reliable provisional response and causing it
to stop.
		
		In a chat with Flemming today, he suggested in
interested remedy to our 
		PRACK dilemma. Why not revise PRACK so that you can't
send an offer or
		answer with it; it has no impact on the set of allowed
O/A exchanges
		defined by RFC 3261. I'm not sure if that would
consequently break the 
		preconditions mechanism, but maybe there are some kind
of offer/answer
		limitations that would simplify things.
		
		So, this is one idea. I'd like for people who have
complained about
		PRACK implementations to speak up and indicate what
exactly makes it so 
		complicated for them.
		
		Thanks,
		Jonathan R.
		--
		Jonathan D. Rosenberg, Ph.D.                   600
Lanidex Plaza
		Cisco Fellow
Parsippany, NJ 07054-2711
		Cisco Systems 
		[email-masked]                              FAX:
(973) 952-5050
		http://www.jdrosen.net                         PHONE:
(973) 952-5000
		http://www.cisco.com
		
		_______________________________________________
		Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
<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: "Brian Stucker" <[email-masked]>
Date: Wed, 15 Mar 2006 11:38:27 -0600

I don't know that I follow you suggestion in the specific case I am talking about.

Take for instance Call Forward No Answer. In this case, A never says that it's done with the call before it is retargeted to B by the network. A and B have no idea that the service even exists in the middle.

Regards,
Brian

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]]
Sent: Wednesday, March 15, 2006 8:42 AM
To: Stucker, Brian [RICH1:B620:EXCH]; Dean Willis; Cullen Jennings
(fluffy)

Mike

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 15 Mar 2006 16:45:48 -0600

I can see where this is headed... Deprecation of forking. :)

Seriously though, I don't think we can sit back and just say that this is a badly designed service. These are real services that exist in the real world that we all have to design and architect for in the near term. Are you pushing for an RFC-2543 type revolution versus RFC-3261?

We also have many esteemed colleagues in 3GPP and 3GPP2 (amongst other groups) as you well know that allow and rely on deep packet inspection (like the P-CSCF and S-CSCF) with all sorts of service and routing interactions to boot. It seemed like in your earlier reply that you were suggesting that if a SIP proxy didn't change anything in the message other than the request URI and did it more than once that it should be a BBUA. Did I read you correctly?

Regards,
Brian

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, March 15, 2006 4:39 PM
To: Stucker, Brian [RICH1:B620:EXCH]
Cc: Michael Hammer (mhammer); Cullen Jennings (fluffy); [email-masked];
Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat (pkyzivat)
Subject: Re: [Sip] The Problem with PRACK

On Mar 15, 2006, at 11:38 AM, Brian Stucker wrote:

> Take for instance Call Forward No Answer. In this case, A never  
> says that it's done with the call before it is retargeted to B by  
> the network. A and B have no idea that the service even exists in  
> the middle.

That's called a "badly designed service", from a security  
perspective. If the service can squat on the call, whats to prevent  
some other MITM?

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 16 Mar 2006 13:56:10 +0000

Paul,

You 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.

I don't think preconditions brings anything to this at all. Bob's UA could
wait for the SDP answer from Alice's UA before starting to ring Bob without
any need to perform preconditions.

However, the security precondition does appear to have a use with security.
Suppose Alice's UA sends an offer in an INVITE request to Bob's UA. Bob's UA
starts to ring Bob and, on answer, sends back an answer in the 200. If the
offer requested SRTP and Alice's UA needs the answer before being able to
decrypt the SRTP, then arrival in the 200 is a bit too late to prevent
speech clipping. Arrival in a 180 would help, but not if Bob's UA
auto-answers (sends 200 without first sending 180 or sends 200 immediately
after 180). This is where the security precondition can help, by postponing
the ringing of Bob until Alice's UA receives the SDP answer and the means to
decrypt SRTP.

John

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 16 Mar 2006 15:14:56 -0000

SIP 2.0 is every active RFC that currently exists for SIP. For an overview, see Jonathan's hitchhiker's guide document.

When we produce an RFC that starts messages with SIP 3.0, then we go to a new version. Until we do that any extension has to be compatible with all other extensions.

regards

Keith

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: 16 March 2006 10:51
> To: Drage, Keith (Keith)
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Drage, Keith (Keith) writes:
> 
>  > I'm afraid you cannot just deprecate part of the SIP 2.0 protocol.
> 
> what is SIP 2.0 protocol?  RFC3261 that most implementations today try
> to comply with, doesn't include PRACK.
> 
> -- juha
>

---

From: "Christian Jansson" <[email-masked]>
Date: Thu, 16 Mar 2006 21:24:38 +0100

>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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 16 Mar 2006 22:47:11 +0100

Hi,

Error response or 200 without SDP - as long as there is a standardized
way of doing the rejection.

I don't like the send-a-dummy-answer-follwed-by-an-UPDATE approach
either. What if the other end can't "unchange"?

Regards,

Christer

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: 15. maaliskuuta 2006 19:28
To: Christer Holmberg (JO/LMF); 'Paul Kyzivat'
Cc: 'IETF SIP List'
Subject: RE: [Sip] The Problem with PRACK

> I'm not sure I see a real problem here. An offer in a prack can't be 
> the first offer. As a subsequent offer, it is constrained it what it 
> can contain in such a way that the answer should always be able to 
> achieve something tolerable, if not desirable.
> 
> [CHH] In theory, the offer could contain one or more new streams. But,

> there can also be a technical reason why the receiver simply isn't 
> capable of processing the offer at the time it is received.
> 
> In any case, I don't a solution where one isn't able to reject an 
> offer
> - for whatever reason...

I agree; the UAS should be able to reject the PRACK's offer.  The
solution presented within draft-sawada-sipping-sip-offeranswer is to
answer the offer and trigger an immediate UPDATE to try to change things
again.  Returning responses like 488, 606, 504, etcetera seem more
appropriate.

Unfortunately, rfc3262 and rfc3311 did not clearly identify a failure
response to send when the UAS cannot accept a PRACK/UPDATE with an
offer/answer SDP.  This has led to interoperability problems with
devices desiring benefits of UPDATE and PRACK; but don't desire/support
them containing an SDP.

The 504 response mentioned within rfc3311 helps for UPDATE if devices
actually support receiving without releasing the call; however it
definitely isn't a perfect solution.  

Returning a 200 response without an SDP to PRACK offer is not a perfect
solution and is currently considered non compliant.  However it is
commonly observed when interworking with devices which implemented
(deployed) draft versions of 100rel functionality and are
unable/unwilling to disable 100rel usage.  And because it isn't
explicitly mentioned within the rfc3262, many devices currently do not
expect to receive a 504 as discussed within rfc3311.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 16 Mar 2006 23:08:17 +0100

Hi Juha,

You seem to blame everything on 3GPP. Are you saying that PRACK and
pre-conditions where defined based on requirements from 3GPP?

Regards,

Christer

-----Original Message-----
From: Juha Heinanen [mailto:[email-masked]] 
Sent: 16. maaliskuuta 2006 7:23
To: Paul Kyzivat
Cc: Dean Willis; [email-masked]; Brett Tate; Christer Holmberg (JO/LMF)
Subject: Re: [Sip] The Problem with PRACK

Paul Kyzivat writes:

 > That means deprecating not only PRACK, but all the other RFCs and  >
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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 16 Mar 2006 23:54:41 +0100

Hi, 

>[CHH] I don't understand why you keep pushing this PRACK problem on  >
me.
>
>christer,
>
>not personally on you, but on anyone who thinks PRACK is a good idea.
>as i told, i got pissed off by PRACK, when SIP phones that used to
interoperate fine with everybody stopped doing so when >they included
PRACK support and i as a proxy programmer started getting email from
angry customers although i had nothing >to do with their problems.

[CHH] All PRACK supporting SIP phones I've seen have worked fine - when
it comes to using PRACK purely for providing reliable provisional
responses. 

This discussion is about the usage of PRACK for offer/answer, and I DO
agree with you that there are issues there :)

>All I am saying that there may be a need for multiple offer/answer  
>transactions - but that can be done also using UPDATE :) 
>
>there you go!  so we can finally deprecate PRACK and have one SIP
request less.

[CHH] Well, you still need to be able to send the SDP in a reliable 18x,
and currently PRACK is the only way to do that. But, as I said, that
doesn't mean you would have to send SDP in the PRACK itself - you could
use UPDATE.

>[CHH] Of course, if there is NO reliable 18x with an answer before the

>200 there is nothing to do - one will have to send the new offer (if  
>needed) AFTER the 200. But, if I get the 64 Kbps answer in a 18x  
>reliable response I can choose to terminate that dialog, and there will

>be no false ring tones.
>
>there IS reliable 180 Ringing from ONE of the forks and then you get
200 OK from another fork with higher demand.  does 
>your phone ring or not after the reliable 180?

[CHH] What you are talking about now is the problem with forking. That
is a completely separate issue, I think. I mean, you could get a 18x
from a user, and a 4xx from the other user (or even the same user that
send 18x), and you would still get a "false" ring tone. That is a "SIP
feature".

>[CHH] "Resources" means more than bandwidth. In a 3G environment you
may  
>not have an established PDP context when you send the INVITE, and  
>therefor you indicate "inactive". Later, when you DO have the PDP  
>context, you send a new offer with "sendrecv".
>
>that is clearly something you 3gpp folks need to fix in your system
rather than messing up SIP with PRACK.

[CHH] If you have a look at the new alternative 3GPP procedures, where
the pre-condition flows are not used, you will see that PRACK is NOT
(unless I remember wrong) mandated to carry SDP (you can use UPDATE
instead). PRACK is ONLY used when you need to acknowledge a rel18x with
SDP.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 17 Mar 2006 00:01:31 +0100

Hi, 

>If you don't like the 3GPP way of sending an INVITE before the PDP  
>context has been fully established (i.e. if think it would be better to

>establish everything before you send the INVITE) I think you should go

>to 3GPP and express that view. This is not the right place.

i could care less if 3GPP system works or not and have no business to go
there.  i just told how you can make resource reservation w/o PRACK.

[CHH] And I think everybody agrees on that. The PROBLEM is that people
claim there are implementations using mechanisms that so far HAVE been
allowed.

>And, 3GPP is using mechanisms defined by IETF do to this, so I really  
>don't understand your 3GPP/walled garden "flaming". 3GPP did not define

>PRACK, or the pre-condition mechanism.

>i apologize if 3GPP requirements had nothing to do with introduction of
PRACK in SIP.  regarding "walled garden" flaming 
>stuff, see another ongoing thread on one of these list on IETF support
of 3GPP charging models.

[CHH] You may of course have other reasons to flame the walled gardens,
but I was refering to a specific topic :)

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 17 Mar 2006 08:08:20 +0100

Hi, 

>>Is there something that would NOT work by using UPDATE instead of
PRACK?
>
>If you mean for sending an *offer*, then UPDATE can work as well as
prack, at the expense of two more messages.
>
>But UPDATE doesn't substitute for sending an answer to an offer
received in a reliable 1xx.
>
>What would *not* work are UAs that are currently programmed to use
PRACK to send offers.

Of course. I was refering more to the RFCs/drafts that you said would
have to be updated.

Regards,

Christer

> Sent: 16. maaliskuuta 2006 3:48
> To: Dean Willis
> Cc: Juha Heinanen; [email-masked]; Brett Tate; Christer Holmberg 
> (JO/LMF)
> 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:
> 
>>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 
>>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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Sat, 18 Mar 2006 11:10:05 +0100

Hi, 

>>- only acknowledge the most recent provisional.
>>if the UAS wants to send as new provisional that completely replaces 
>>a previous one it can send immediately.  if the UAS wants to send a 
>>new provisional but wants acknowledgement of a previous one, it has 
>>to wait for the PRACK.
> 	
>>I assume RSeq would still be checked so UAC is able to notice out of 
>>order provisional responses.
> 
>[CHH] What to you mean by "replace a provisional response"???

My interpretation is that the UAC no longer has to follow the rfc3262
requirement to drop 1xx responses which incremented by more than 1.  And
if the contents of the prior 1xx must not be ignored, the UAS must queue
subsequent 1xx until prior one is acknowledged.  The text basically
shifts the MUST burden of ensuring no ignored 1xx's to UAS instead of
the UAC.

[CHH] I don't like the queueing. I think it should work as today, but
the UAC should be aware of the first Rseq value, which means we can get
rid of the queueing all together. The UAS sends a rel18x when it has one
to send, and the UAC shall make sure it processes the rel18xs in the
correct order, and discard responses which Rseq value is incremented by
more than 1. In real life scenarios I am pretty sure the responses will
come to the UAC in the correct order, becuase an UAS will probably
re-send a rel18x response before the next rel18x is to be sent.

>[CHH] <snip> and I DO think we should get rid of the rule by mandating 
>an offer in the first rel18x (if the INV didn't carry an offer).

(I assume "by" was not intentional within the above text.)

[CHH] Yes :)

>This is a common non compliance because of vendors deploying draft
versions of the 100rel functionality.  And vendors 
>which supported 100rel and haven't implemented/upgraded to rfc3262 are
currently required to deactivate 100rel to avoid 
>non compliance to offer/answer usages.  
>
>I agree that the MUST should be reduce to a SHOULD.  I think the text
was added for clipping and 183 type reasons; and 
>there are other reasons for it.
>The functionality is useful; however it disables the UAS from reliably
sending a 18x unless able/willing to adhere to the 
>offer/answer requirements.

[CHH] I don't even think there should be a SHOULD. If the INVITE does
not contain an offer, the offer must come in a reliable response - BUT,
that can be the first rel18x, the 10000th rel18x, or the 200 OK.
Implementation may of course choose to send the offer in the first
rel18x - if there is an offer to send at that time - but shall not be
mandated to do so.

Then, if there is some "service" which really requires the offer to be
present in the first rel18x that shall be part of the service
description - not the "core" specification.

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Mon, 20 Mar 2006 08:39:33 +0100

Hi,

I have never seen a commercial non-IMS terminal supporting the
pre-conditions mechanism - not as a UAC, and not as a UAS.

I have seen commercial non-IMS terminals supporting PRACK - for
acknowledgement of reliable provisional responses, and as far as I know
that normally works quite well (and if we could get rid of the queing I
think it would even work better). 

SOME of the those PRACK supporting terminals may be able to process an
SDP offer RECEIVED in a PRACK, but I doubt many would actually SEND an
offer in a PRACK. They probably also have different ways of rejecting an
SDP offer received in a PRACK, because there is no standardized way of
doing it (I don't buy the argument that "it never needs to be done").

However, this is just my personal view of the world, so others may of
course have another opinion.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 20. maaliskuuta 2006 4:57
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] The Problem with PRACK

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]
____________________________________