[OpenSER-Users] Openser, inbound SIP "trunks" and REFER

[Robby Dermody]

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