PRACK was initially created as means to deliver provisional responses reliably to a UA. While these messages provide additional opportunities for the offer/answer exchange, I am not sure that not doing so would break something (meaning delaying the offer/answer exchange to a 2xx response to the INVITE)? Atleast, I didnt get an answer the last time I posed a similar question to the mailing list (the only possible answer was that delaying the offer/answer to a 2xx/ACK caused delayed cut through but I would think it would be best left to the application to decide if the same behavior is acceptable or not)... If the above statement is true, may be all statements around offer/answer exchange in this RFC could be reduced to a MAY strength instead of a MUST or SHOULD as this mandates all UA's wanting to use RPR be able to participate in a offer/answer handshake prior to call establishment. Venkatesh
On 5/11/05, Kasturi Narayanan (kasnaray) <[EMAIL PROTECTED]> wrote: > > > > I ran into a specific issue where a B2BUA/PROXY needs to send a 181 > (Call being forwared) immediately after invocation of forwarding. > > In this case, the INVITE was received with No Offer and the UAS does not > have the OFFER while sending 181 because it is still in the process of > setting up the call towards the forwarded party. > > With PRACK required, how can a B2BUA send 181 reliably with Offer when > it receives Invite with No-Offer. May be we need to change the MUST to > SHLD to address the above case. > > In the sentence in Section 5 of the RFC 3262 "Similarly, if a reliable > provisional response is the first reliable message sent back to the > UAC, and the > > INVITE did not contain an offer, one "MUST" appear in that reliable > provisional response." > > Please clarify > > Thanks > > Kasturi > > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
