Hi, Note that I originally posted this to the OpenSer-Users list, but then realized it's really more about SIP than OpenSer. Thus I'm posting it here...doesn't seem to be OT but my apologies if it is.
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. One earlier response to my dilemma was that both options were not really good. The first option was unrealistic to expect a SIP provider to do, and the 2nd was not good from a technical standpoint. This is actually development work for a platform that will eventually (hopefully) be pushing through many, many calls per day. So with that I'm wondering if getting the first option working is just a matter of having the cash and partnership worked out with a provider (who? Any ideas?). With the 2nd option, is there some tweak I can make to that so that it is more technically sound (like using a B2BUA somewhere in there, etc)? Basically I'm just looking for a way to make this work without having A1 set up a leg to A2 (like Trunk<->Proxy<->A1<->A2). At best, that would be somewhat OK for proof of concept, but definitely not for production. Thanks for any input, Robby _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
