Callback Profile

Is there a need for a callback profile, where an initiator peer asks the
listener peer to initiate a new session between the same two peers.
(i.e. peer A wishes peer B to initiate a session to peer A, but peer A
needs to tell peer B to do this - hence the callback profile). 

The motivation would be firstly to enhance security in certain
environments (a highly secure peer may only permit incoming connections
to request a callback, but expose no other functionality [apart from the
tuning profiles] to them), and secondly to work in environments when
there are business/technical restrictions on the number and direction of
open connections. 

A peer running on Windows XP Home can only maintain five simultaneous
incoming connections, and a peer running on Windows XP Professional can
only have 10 simultaneous incoming connections. 
[see http://support.microsoft.com/default.aspx?scid=kb;en-us;Q314882]
There are no restrictions on Windows 2000 Server or Windows .NET Server
on the number of incoming connections. For all the versions of Windows
mentioned, there are no restrictions on the number of outgoing
connections. 

One expensive option is to set up a traditional Windows client-server
network, which usually involves Windows Domains. This requires you to
buy 
Windows XP Professional for machines that only act as client (XP Home
will not suffice for Windows Domains), buy the Windows Server product
for machines that might have more than 10 incoming connections, and buy
a "Client Access License" for each client to permit it to access a
server. (you Linux guys can stop laughing now).

A much better option is to just put Windows XP Home on all the machines,
and using the callback profile arrange them as required - maybe point to
point, or maybe hub-and-spoke [if one peer exposes a service that many
other wish to use]. 

How would a callback profile work?
==================================
1) A peer [we call it the provider peer] that provides a popular service
or a high-security service based on BEEP would list the Callback Profile
in its Greeting message. Depending on local configuration this could be
the initial greeting message, or the one after the tuning reset
following TLS setup; also authentication may be required. 

2) A peer wishing to use the remote service [the user peer] would
establish a connection to the provider peer, configure security as
appropriate, and upon detecting the Callback Profile in the Greeting
message, would create a channel based on this profile. 

3) The user peer sends a single message on the callback channel to the
provider peer identifying the transport mapping details to use for the
callback - e.g. transport mapping type [RFC 3081, SCTP, multiple TCP
connections] and addressing [for RFC 3081, IP address and port to use].

4) The existing session is shut down. 

5) The provider peer initiates a session with the user peer based on the
addressing information provided. After that, it works just as normal. 

My questions:
=============

Anyone see any problems with this approach?

Anyone got a better solution?

Anyone got a good reference to security issues that have been uncovered
with other types of callback usage - e.g. ftp. 

An alternative to the callback profile in BEEP would be a simple UDP
message, but I would have security concerns about that. 

Eamon