Section 6 of RFC3515 calls out why REFER is constructed this way. The root cause is the fixed length of any SIP non-INVITE transaction. The approach you sketch won't work as provisional responses to non-INVITE requests do _not_ lengthen the transaction. If you want a more detailed description, look at http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-problems-00.txt and http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-actions-00.txt RjS On Thu, 2004-05-06 at 23:55, Thomas Ackermann wrote: > Hi all, > > can anybody tell me why the transfer procedure needs NOTIFY message > with application/sipfrag message body? > > Why not simply keep the REFER transaction open by sending: > - a provisional response instead of the 202/Accepted and > - a final 200/OK response instead of NOTIFY(200 OK) ? > Just like the INVITE transaction with all its intermediate responses. > > Or even more simple: > The Transferee sends the BYE by itself instead of asking the Transferor > to terminate the call? > > Do you know the reason why the NOTIFY transaction has been added to > call transfer procedure? > > Thanks for your help, > Thomas > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf