Subject: RE: [Sip] The Problem with PRACK

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 15 Mar 2006 16:13:50 +0200

Hi,

I don't want to make assumptions based on how current implementations may work. 

With "early answer" I meant an answer received in a reliable 18x. And, a forking proxy WILL forward ALL of those.

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.

But, I agree with you that using PRACK for offer/answer causes issues, but I wouldn't "blame" it on the fact that people want to do multiple offer/answer transactions before 200 OK. I still think the are two separate issues...

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: Thu, 16 Mar 2006 00:06:33 +0200 (EET)

Christer Holmberg writes:

 > With "early answer" I meant an answer received in a reliable
 > 18x. And, a forking proxy WILL forward ALL of those.

christer,

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?

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

-- juha