Hi Tim. In brief: yes, that is what I am thinking, a remote replyto that would work across providers after bridging. I've tried the bridge, and it is very handy. However, what I am thinking of is analogous to what you are suggesting: a remote replyto, but since replyto (which is a destination) does not apply across providers that does not seem to be a possible way to go. I'm thinking this scenario: (sorry for long post) 1) A JMS client sends a message to a queue on JBossMessaging (messageid: 1) expecting a response (on a replyto temp destination) 2) A Bridge configuration picks up message 1 and sends it to a remote provider, expecting a reply (the remote message gets a provider-specific messageid, lets say "A" to differentiate them). Here we cannot use the same replyto destination given in 1) since we are going to another provider. 3) A remote JMS client (not able to talk to JBM) receives the message (A) and replies to it to a (for him) local queue with a new message (B), using "A" as the correlation id (these legacy clients typically don't obey a replyto header anyway, they just send a response where they usually put it. They do, however, use the correlationid) 4) A Bridge configuration picks up message B and puts it on the replyto destination given by the original JMS client This scenario is quite common and is often (in the proprietary world) handled by bridging products where you configure how to map correlation/replies between providers. Now that JBM has a bridge, this kind of functionality could perhaps be added to it, making it even more powerful. If a remote client respected the replyto destination given in the header and the remote provider supports temp destinations, the "outgoing" Bridge could see that there is a destination in the original request, create a remote temp queue and send the message using a replyto with the new (remote) temp queue. However, that would require that the "receiving" Bridge configuration would have to be able to listen to dynamically created remote queues and still have no understanding of where to put the received messages. If two bridge configurations were to be "aware" of each other (lets say a bridge xml could contain BOTH an in- and outbound route) they could also share this temporary queueing, AND know the mapping of messageid's since they get the remote provider's messageid after send(). If we cannot use temp destinations, the Bridge (if configured in in/out pairs) could still map correlationid's, which would be extremely powerful. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4051997#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...