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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf