Never tried it. While it should work, I doubt it would unless some parameters were manually tweaked within freeswitch, because freeswitch also tries to be the pbx too. In a sip header message it contains routing information, and while you want freeswitch to be involved in a phone call, you don't necessarily want it to be the destination.
For example, in 3.11.8 (dev version) freeswitch is also installed, but mainly for conference services and not as a SBC or trunking application. Jack had this issue in february: *** I've worked out the refer issues and can now get incoming calls to comeinto the auto-attendant, dial out to any extension, and have thosecalls transferred correctly. However, if I try to route incomingcalls through the gateway directly to a sipx acd queue, sipx returns404. The INVITE looks correct- [EMAIL PROTECTED] The acd queue looks correct in sipx's web interface What needs to be done to make these accessible? On Wed, Feb 20, 2008 at 11:03 AM, Picher, Michael <[EMAIL PROTECTED]> wrote: I'll ditto what Tony said here� [EMAIL PROTECTED] And I think the SBC needs to be setup as a gateway I think. Mike [EMAIL PROTECTED] On Behalf Of TonyGraziano Sent: Wednesday, February 20, 2008 10:21 AM To: [email protected] Subject: Re: [sipx-users] Sip trunking issues Was thinking aboutthis some more. It sounds like the REFER is not being handled locally byFreeswitch. I think it's fairlywell known that when using a siptrunk with a device, like an ingate siparator,that you set the REFER to be handled locally with their siptrunk modulesoftware. I have no clue how todo this, or whether i is attainable, in Freeswitch. But I think you are rightthat the REFER is wrong or is the suspect in your issue, and it needs to bechanged at Freeswitch. The same problem isevident when using a gateway (patton smartnode) to register a siptrunk. Callscan go out, but are not "transferrable". Inbound calls are not evenrouteable, so it would only be advisable to use it for "toll bypass"on outbound calls. This is why the listsrefer to ingate so much, as they have an actual working answer to this issue.Sincesipx is a proxy and most ITSP's are using a proxy, so they don't have away to handle refer's the way "both" want to see it. I am sure there iswork being done on sipxbridge to bring siptrunking into sipx natively, but itis still going to be some time before this is available. Anyone else care tochime in who's been through this before? >>> "jeff sacksteder" <[EMAIL PROTECTED]> 02/20/0801:48AM >>> I've got sip trunks coming in via Freeswitch media gateway and have some issuesto work out. Firstly, I have the the incoming lines goto the auto-attendant ([EMAIL PROTECTED]). Is there additional magicto be done? I don't know if it's related or not but I can neither forward calls to normalextensions nor transfer out of the AA into another extension. In the lattercase, the REFER message looks odd to me. I though it should be [EMAIL PROTECTED],but it's not. **** Are you trying to put a production system in place now? If so, 3.10.2 is safe to use, but I would use a FXO gateway into sipx and and fxs tied to RJ11 to a device tied and approved by your trunk provider. You might separately post a request of anyne using freeswitch as the SBC. I'm not sure what kind of luck Jack had. I think it's safe to say there is no right answer, and Ranga has been working feverishly with everyone to set up a very useable "bridge" project to integrate, called sipxbridge. http://sipx-wiki.calivia.com/index.php/SipXbridge_Overview_and_Configuration - Tony >>> Chad Leigh - Pengar Enterprises Inc <[EMAIL PROTECTED]> 11/27/08 5:53 AM >>> On Nov 27, 2008, at 3:26 AM, Tony Graziano wrote:I tried OpenSBC a long time ago and went with Ingate for siptrunks. I think there is the beginning of a wiki page started for OpenSBC: http://sipx-wiki.calivia.com/index.php/SipXecs-OpenSBC The issue you have is NAT travein your dial plan byy the providers IP address. IF you have a public IP address on your phones and your sip system with no firewalls, this would actually work. Because you are on a private network though, you can't traverse NAT natively with sipx, until the next major relase ships. So you need to: 1. Use an ATA to connect to a provider (Vonage, whatever) and connect the phone line to a FXO gateway that works with sipx 2. Use a SBC or SIP aware firewall to connect to the sip trunk, and define that device (not the provider directly) and use it as a gateway within sipx. 3. Use a standard POTS line with an FXO gateway. SIP doesn't traverse NAT through a firewall easily. Just forwarding port 5060 won't help. The media uses high ports and is random, plus a picture is worth a thousand words. http://freshmeat.net/articles/view/2079/ Something like FreeSWITCH should work as well, right? Aim sipX at FreeSWITCH and vice versa? I had calls coming and going with FreeSWITCH... Just thinking out loud here Chad </[EMAIL PROTECTED]>
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
