[asterisk-ha-clustering] Asterisk clustering and transferring calls

[Brent Thomson]

Leif Madsen wrote:
> I was not the OpenSER administrator (and do not have a ton of OpenSER
> experience), but I think we ended up making all the requests and such
> go to the OpenSER server, which I think had transaction support, and
> used the outboundproxy option in sip.conf to make all the requests go
> to the OpenSER server.
> 
> I may be able to get access to the configuration that we used, but
> that is a former client and I'll have to ask for permission to get it.
> Not sure if any of that information is useful or not, because it was a
> couple of years ago that we did it, and I'm just remembering bits and
> pieces.


Leif: I'd love to have a look at that if it's not too much trouble.

Chris: Correct. SIP transfers using INVITE and REFER.

Yehavi: I've tried sending the same handset to the same PBX every time,
but this breaks down if a call is routed to the handset from elsewhere,
since it could land on any PBX and then get forwarded on to the handset.
The work-around for this is to either keep an entire logical PBX on a
single physical PBX (so that all calls, in and out, go to the same piece
of hardware), or route all calls *to* a particular handset through the
same PBX where its registration landed. But that kind of defeats the
whole load balancing and failover thing.

I did some poking around and came across this:

	http://tools.ietf.org/html/rfc5359#page-58

The document is excellent. It full of examples relating to RFC 3261 (and
some of its extensions). The example for attended transfer clearly shows
Alice initiating a call with Bob, then Carol, then directing Bob to
connect to Carol. Bob then sends and INVITE to Carol with a Replaces:
directive to complete the transfer. Replace Alice with Phone, Bob with
PBX-1, and Carol with PBX-2 and you'll see what I'm trying to do. It
appears that Asterisk may not follow spec in this case. Sniffing the
traffic on PBX-1 verifies that Asterisk doesn't ever attempt to contact
PBX-2 when it receives a REFER referencing a Call-ID that it doesn't
recognize. Does this warrant a bug report/feature request?

-Brent