Subject: RE: [Sip] The Problem with PRACK

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 9 Mar 2006 21:02:25 -0600

Currently offer/answer usage is one reason to support 100rel on TCP and
TLS.

SS>> This I understood. As Christer pointed out earlier, If INVITE is
empty and offer is in 1xx
     then we need to send answer in UPDATE. This requires changes. While
we are attacking PRACK
     for other issues, it should be catered too. 

Another reason is for better interoperability concerning clipping with
devices unwilling to receive/present media until receive 18x with SDP.
PRACK allows the UAS to know when the 18x has been received.  Thus it
can delay sending media until it knows the UAC received the 18x.

SS>> Correct me If I am wrong, Offerer must be prepared to receive media
as soon as It sent out 
     the offer. How does UAC indicate to UAS that it should send media
when PRACK is received ?
     They are overloading 100rel. Suppose another UA doesn't support
100rel and call is setup 
     without 100 rel extension, then this UA still has media clippings
because it is waiting for
     answer. Shouldn't these UA be fixed ? 

Thx
Samir

_______________________________________________
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: "Brett Tate" <[email-masked]>
Date: Fri, 10 Mar 2006 08:30:24 -0500

> Another reason is for better interoperability concerning 
> clipping with devices unwilling to receive/present media 
> until receive 18x with SDP. PRACK allows the UAS to know when 
> the 18x has been received.  Thus it can delay sending media 
> until it knows the UAC received the 18x.
> 
> SS>> Correct me If I am wrong, Offerer must be prepared 
> to receive media as soon as It sent out the offer. 

I agree.  Unfortunately some clients and SBCs, require the offer/answer
handshake before presenting the media.  This is usually because of security
concerns.

And various working groups are attempting to ready these security/clipping
concerns.  However PRACK helps address the situation until a better solution
is found.

> How does UAC indicate to UAS that it should send media 
> when PRACK is received ?

The clients (and SBCs) usually can't without requiring 1 or more
offer/answer handshakes or additional sip extensions.  However this type of
security/clipping concern was one thing which led to the RFCs indicating
things like offer in 18x and answer within PRACK.

And unless someone standardizes a way to clearly indicate if SDP is offer or
answer, indicating an answer within an UPDATE would likely not be a
desirable replacement to PRACK containing answer because of potential race
conditions.

> They are overloading 100rel. 

The UAS is just taking advantage of the knowledge provided by receiving
PRACK.  And it might act the same way concerning ACK.

> Suppose another UA doesn't support 100rel and call 
> is setup without 100 rel extension, then this UA 
> still has media clippings because it is waiting for 

Various working groups are attempting to remedy these security/clipping
concerns.  Maybe someday operators will no longer need/desire the security
functionality provided by the offer/answer handshake.  Until then, PRACK
provides some benefit within such an environment.