All, I have a situation where I have a OpenSER server frontending a set of Asterisk boxes (call them box A1 and A2). Calls come in and are routed to one of the boxes (after doing some custom HTTP lookups using a custom perl module, rewriting the RURI, etc). This works fine, however at some point, the call will most likely need to be transferred from one internal Asterisk box to the other Asterisk box (e.g. A1 to A2). At this point, what we have set to happen is that A1 would send a REFER up through the proxy, the proxy caches an auth token record from info in the outgoing REFER and writes the token ID into the Refer-To header (along with its own address as the recipient) as the REFER goes out to the SIP trunk, and then when the subsequent invite is made from the sip trunk (to something like route_34983948-34343@<sipProxyIP> with that 34983948-34343 being the token ID) the SIP proxy will look up that auth token, rewrite the RURI with the cached info and direct the call to the appropriate internal asterisk box...A2 in this case. So that all is done and would normally work. However our SIP provider says that it only provides "inbound DID service" and thus do not have their dialplan set up to handle REFERs with custom URIs (even if it is back down to the same openser proxy, as it always is in our case). So looking at this, I have two questions: 1. Could resolving this problem just be as simple as finding a new SIP DID provider? I am a bit worried that providers may consider use of REFERs in any way as "SIP termination" (e.g. outgoing service) and either not office REFER support or charge accordingly for outbound access, even though this is clearly still inbound. 2. Those Asterisk boxes in our environment are behind a NAT, so our openser proxy does employ nathelper/rtpproxy. Given this, another alternative I see is for the openser proxy to intercept the REFER for the DID->A2 message, craft an INVITE for proxy->A2, negotiate the conversation, and reconstruct the internal RTP leg between it and A2 instead of A1. This way, the SIP trunk is none the wiser and does not even know this transfer has happened, it just gets some dead air for a second or two and everything is done behind the scenes. I know that a SIP proxy shouldn't inject new SIP messages into the stream, and the REFER way seems to be the most RFC-compliant and technically sound method. However, there is the real-world threat in my mind that it may not be very well supported among inbound DID providers, so I am interested in the community's opinion on the options. Thanks, Robby