Subject: RE: [Sip] The Problem with PRACK

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

Hi Juha,

[CHH] I don't understand why you keep pushing this PRACK problem on me.
All I am saying that there may be a need for multiple offer/answer
transactions - but that can be done also using UPDATE :) 

>lets say your mobile UAC first receives a 180 Ringing reply with SDP
from an UAS, where the only codec requires 14 Kbps 
>of bandwidth.  before UAC makes the phone ring, it reserves 14 Kbps
worth of access bandwidth from the network.  after 
>that the UAC receives 200 OK from ANOTHER UAS, where the only codec
requires 64 Kbps of bandwidth.  UAC then tries to 
>increase the reservation, but gets rejected by the network.  how does
your PRACK complexity with reliable provisional 
>replies help here to prevent the false ringing tone?

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

>Also, I don't know in what environment you are using your SIP phones,  
>but obvously you don't have to consider the same resource issues as  >
others must do.

>my simple PRACK-free solution DOES consider limited resource issue:
when UAC sends an invite, it lists only codecs that 
>fit into its access bandwidth reservation.  at the UAS end, the same
happens with codecs in 200 OK reply.  when UAC 
>receives 200 OK, it may be able to reduce its reservation further based
on the codec selected in 200 OK.
>
>this is a very simple working solution that lets us deprecate PRACK.
in theory, you may be able to do some small 
>optimizations, but they are not worth the added complexity.

[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".

Regards,

Christer

_______________________________________________
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: Fri, 17 Mar 2006 00:40:37 +0200

> [CHH] I don't understand why you keep pushing this PRACK problem on

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.

 > transactions - but that can be done also using UPDATE :) 

there you go!  so we can finally deprecate PRACK and have one SIP request
less.

 > reliable response I can choose to terminate that dialog, and there will

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?

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

-- juha