Subject: RE: [Sip] The Problem with PRACK

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 16 Mar 2006 09:45:27 -0000

I must support Erkki on this.

I'm afraid you cannot just deprecate part of the SIP 2.0 protocol just like that, particularly when there are implementations out there that support it. Moreover it is appropriate to currently build equipment that always requires both 100rel and precondition, to work on systems and with other end terminals that supposedly support it. This introduces a major backwards compatibility problem if such extensions are just deprecated.

Moreover, 3GPP has worked in conjunction with IETF to meet certain requirements so that the evolution of SIP has remained with IETF. It is not possible to say that 3GPP should go away and develop their own solution, as that would break the current 3GPP compliance with the SIP changes procedures. Any replacement is almost certain to require usage of option tags, and that requires a standards track IETF document.

If PRACK is bad, and I have not yet seen any technical evidence provided against it except that potentially it is hard to implement right, then one must ensure:

-	that operation by existing implementarions has some sort of fallback behaviour.

-	that any replacement displays some sort appropriate interworking with existing implementations.

Otherwise I'm afraid from my perspective its a SIP 3.0 issue.

I would say that I understand that usage of this extension very much depends on the media being negotiated, and on the bearer mechanisms used to support that media. The reason why usage in 3GPP has become optional (to the UAC) in release 6 in that it is very difficult to define when exactly it should be used. For negotiating MSRP as a media, it is highly likely it is not needed. For voice as a media with a charging model based on what the PSTN does now, or a charging model based on the bandwidth allocated at any time on the access, 100rel and preconditions stand a good chance of being used. There are lots of shades inbetween where it is very difficult to come up with a definitive answer.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 15 March 2006 09:29
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [Sip] The Problem with PRACK
> 
> 
> Hi,
> 
> I do not agree it would be great to make sure that the
> mobile SIP applications would never be able to interoperate
> with those applications running in desktop PCs. 
> 
> I see signs towards other kind of direction (fixed IP network
> operators planning to provide access towards 3G IMS, some PC
> vendors planning to add SIM card support to laptops etc.) So
> that is why I hope solutions could be found that satisfy the
> needs of Internet as a whole, including the way how 3G networks
> are aiming to provide the access to it.
> 
> In 3GPP they have tried to do their specifications so that
> the applications would be compliant to Internet world based
> on IETF specifications, so that e.g. multimedia sharing would
> be possible between a mobile phone and a PC. Preconditions is
> one of the few specs created within IETF that 3GPP has originally
> mandated due to radio access specific reasons, but they have
> relaxed this requirement to be a preferred option. Anyway since
> offer/answer and preconditions is one of the cornerstones in
> 3GPP specifications, any backwards incompatible changes for those
> specs will have a major impact to that community. In my opinion
> this is one of the views (amongst many other important ones)
> worth considering in this discussion.
> 
> Regards,
> 
> Erkki 
> 
> >-----Original Message-----
> >From: ext Juha Heinanen [mailto:[email-masked]] 
> >Sent: 15.March.2006 10:55
> >To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
> >Cc: [email-masked]; [email-masked]; 
> >[email-masked]; [email-masked]
> >Subject: RE: [Sip] The Problem with PRACK
> >
> >[email-masked] writes:
> >
> > > I agree with you. But this far it has been possible and
> > > there are implementations using that option, for specific
> > > reasons. I did not intend to tell more than that and still
> > > think it was relevant input for this discussion.
> >
> >my suggestion is that PRACK is deprecated and if mobile vendors still
> >need it, they can solve the problems on 3gpp mailing lists.
> >
> >-- 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
> 

_______________________________________________
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: Thu, 16 Mar 2006 12:50:56 +0200

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: Adam Roach <[email-masked]>
Date: Fri, 17 Mar 2006 18:57:35 -0600

Drage, Keith (Keith) wrote:

>If PRACK is bad, and I have not yet seen any technical evidence provided against it except that potentially it is hard to implement right...
>

You miss the point. Calling PRACK "potentially hard to implement right"
is like referring to WWII as "a trifling difference of opinions."

In Vancouver, Rohan put up a slide to demonstrate this issue
graphically, but its impact hasn't been shared on the list. To that end,
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.

All of which makes me very skeptical of arguments that we can't change
PRACK because it has been widely implemented: I offer that it's highly
unlikely that it has been implemented correctly even once.

/a

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 18 Mar 2006 10:07:23 +0200

> unlikely that it has been implemented correctly even once.

this has been my practical experience based on phones bought by users of
my proxy.

-- juha

---

From: <[email-masked]>
Date: Mon, 20 Mar 2006 11:55:24 +0200

Hello,

>That's a *lot* of code, and the chances of getting it all right are

If that is the case, I would really ask that slide with explanations
to be published in SIP mailing list. For instance I was not attending
Vancouver meeting, so I am currently lacking this piece of information.
I would especially like to be explained where this multitude of states
and transitions come from for sending offers/answers in PRACK,
especially
when compared to a solution where those could only be sent in UPDATE.

My point is that only after understanding all that it would be possible
to evaluate the effectivity of proposed simplifying solutions like the
one Rohan has suggested.

>> I went back over the 102 messages in this thread and did not hear any

>> comments on my concrete proposals:
>> :
>> comments on *this*?
>
>Out of curiosity, did you go through the exercise of putting together
an 
>offer/answer state machine that takes this change into account? Is it 
>much simpler? 

In my understanding, for 3GPP the following three proposals would be OK:

>> - 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)

but this last one would cause severe problems:

>> - deprecate *offers* in PRACK (answers are still OK)

I hope that we would be able to study the problem closer in order to
find out if there still be some other kind of simplifications to be
made, to get the state machinery smaller, while keeping the possibility
of sending offers in PRACK. Full analysis is still to be done, but it
would require the referred state machine to be scrutinized.

Regards,

Erkki

>From: ext Adam Roach [mailto:[email-masked]] 
>Sent: 18.March.2006 02:58
>To: Drage, Keith (Keith)
>Cc: [email-masked]
>Subject: Re: [Sip] The Problem with PRACK
>
>>If PRACK is bad, and I have not yet seen any technical 
>evidence provided against it except that potentially it is 
>hard to implement right...
>>
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 21 Mar 2006 10:42:44 -0600

They're in the proceedings:

I think this is the URL

http://www3.ietf.org/proceedings/05nov/slides/sipping-16/sld1.htm

--
Dean