Subject: RE: [Sip] The Problem with PRACK

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 15 Mar 2006 10:43:55 +0100

Hi, 

>A simple use-case, not necessarily related only to 3G, is when one
wants  only to use a single codec. The UAC then send 
>his lists of codecs, gets  back the UAS list of codecs, and then send a
new offer with only one codec both supports.

this is theoretical, since many existing SIP implementations don't
return a list of codecs, but only one, so there would be nothing else
for the UAC to choose from.

[CHH] I am not sure I agree on that. But, in any case I don't like
making standards based on assumptions...

>if UAS would return many, why can't the UAC send a re-invite after ACK?

[CHH] One may want to do this before the call has been established.

Also, in forking scenarios an "early" answer COULD even trigger
termination of certain early dialogs.

>Another use-case is where the first offer indicates "inactive", e.g.
>because of radio bearer and/or other resource reasons, and then want to

>be able to change that to "sendrecv" before 200 OK.

i don't understand the example, but again, why can't re-invite be used?

[CHH] Again, one may want to do this before the call has been
established. There may even be regulatory issues related to this - I
don't know...

>why i'm pissed off because of PRACK is that now some non-3gpp SIP UAs
have tried to implement it and most of them have 
>done it somehow wrong.
>customers who buy these phones then complain to me about it.  if SIP UA
vendors can't get it right, the feature is 
>clearly too complicated and must be deprecated.

[CHH] I think we have two issues here.

1) Shall one be able to send new offer(s) before 200 OK? That can
already be done using UPDATE.

2) Shall it be possible to use PRACK for sending offer or answer.

My understanding is that the scope of this discussion is the second
issue, so maybe we should focus on that?

Regards,

Christer

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

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 15 Mar 2006 11:57:29 +0200

> making standards based on assumptions...

there was no assumptions, just facts regarding current SIP phone
implementations.

 > [CHH] One may want to do this before the call has been established.

yes and this "wanting" has resulted in PRACK that nobody seems to be able
to implement in an interoperable way.

 > termination of certain early dialogs.

i don't understand what you mean by "early" answer.  a proxy that does
forking, answers when it has got all replies from the forks.

 > established. There may even be regulatory issues related to this - I

your "may want" is very vague.  i would not standardize anything beased
on that kind of requirement.

 > issue, so maybe we should focus on that?

yes, and my solution is to deprecate PRACK and we are done with the
problem.

-- juha