Feature Request.<br>Make an offer for a paid feature.<br><br><br><br><div class="gmail_quote">On Tue, Apr 21, 2009 at 12:41 AM, Brent Thomson <span dir="ltr"><<a href="mailto:bthomson@getjive.com">bthomson@getjive.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Leif Madsen wrote:<br>
> I was not the OpenSER administrator (and do not have a ton of OpenSER<br>
> experience), but I think we ended up making all the requests and such<br>
> go to the OpenSER server, which I think had transaction support, and<br>
> used the outboundproxy option in sip.conf to make all the requests go<br>
> to the OpenSER server.<br>
><br>
> I may be able to get access to the configuration that we used, but<br>
> that is a former client and I'll have to ask for permission to get it.<br>
> Not sure if any of that information is useful or not, because it was a<br>
> couple of years ago that we did it, and I'm just remembering bits and<br>
> pieces.<br>
<br>
<br>
</div>Leif: I'd love to have a look at that if it's not too much trouble.<br>
<br>
Chris: Correct. SIP transfers using INVITE and REFER.<br>
<br>
Yehavi: I've tried sending the same handset to the same PBX every time,<br>
but this breaks down if a call is routed to the handset from elsewhere,<br>
since it could land on any PBX and then get forwarded on to the handset.<br>
The work-around for this is to either keep an entire logical PBX on a<br>
single physical PBX (so that all calls, in and out, go to the same piece<br>
of hardware), or route all calls *to* a particular handset through the<br>
same PBX where its registration landed. But that kind of defeats the<br>
whole load balancing and failover thing.<br>
<br>
I did some poking around and came across this:<br>
<br>
<a href="http://tools.ietf.org/html/rfc5359#page-58" target="_blank">http://tools.ietf.org/html/rfc5359#page-58</a><br>
<br>
The document is excellent. It full of examples relating to RFC 3261 (and<br>
some of its extensions). The example for attended transfer clearly shows<br>
Alice initiating a call with Bob, then Carol, then directing Bob to<br>
connect to Carol. Bob then sends and INVITE to Carol with a Replaces:<br>
directive to complete the transfer. Replace Alice with Phone, Bob with<br>
PBX-1, and Carol with PBX-2 and you'll see what I'm trying to do. It<br>
appears that Asterisk may not follow spec in this case. Sniffing the<br>
traffic on PBX-1 verifies that Asterisk doesn't ever attempt to contact<br>
PBX-2 when it receives a REFER referencing a Call-ID that it doesn't<br>
recognize. Does this warrant a bug report/feature request?<br>
<font color="#888888"><br>
-Brent<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
<br>
asterisk-ha-clustering mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-ha-clustering" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-ha-clustering</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Kind Regards,<br>Chris Mylonas<br>