From: "Robby Dermody" <[EMAIL PROTECTED]> 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.
Though I think you could avoid having the proxy rewrite the RURI by having the Refer-To address be something like <sip:[EMAIL PROTECTED]> -- then the proxy would only have to validate that the auth-token matched ext. 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. Yes, SIP trunk providers generally do only what POTS lines would do, and that doesn't include handling REFERs correctly. Which is pretty nasty, because eventually the "trunk" is going to be a real Internet connection, and in general you want the REFER to reach the far end. 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. That is the "quasi-proxy/quasi-B2BUA" that people like to talk about, but it's difficult to implement correctly. For example, the INVITE to A2 has to have a CSeq number, and you have to ensure that any later request from the outside to A2 has a higher CSeq number. And since you have to renegotiate the SDP, you're going to send a re-INVITE to the outside... Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
