Before considering sipx we checked other solutions, but SBCs are not meant to be used as B2BUA and sip proxies. In fact we don't need nor want media relay and that's the main purpose of SBCs, isn't it? I think sipx could be quite the solution we're looking for, apart from writing our own.
> Overall, sipXbridge was not meant as a full scale SBC. In your instance, > you might look at OSBC or something like that which will give you (I > think) what you are looking for. I don't recall sipxbridge being meant to > be used in a solution with more than a couple of dozen connections, at > least in its current form. > >>>> "Paolo Prandini" <[email protected]> 01/26/09 4:09 PM >>> > I agree. We won't use call transfer anyway. > >> Paolo Prandini wrote: >>> Yes I understand. >>> My use case is quite special, I know. >>> We are a small ISP and deliver also VoIP services, that we >>> buy from bigger operators. The problem is that our services >>> are quite reliable, but bigger operators'ones are not...so >>> customers complain with us of service interruptions. >>> We would like to have CPE ( no NAT involved anyway ) register >>> with us ( to sipx), so we can direct outgoing calls to whatever >>> operator is working/cheapest at the moment, while receiving >>> calls from the right DIDs. But we don't want to be in the middle >>> of the media path otherwise we need a big amount of quite good >>> bandwidth... >>> Thanks anyway >>> Paolo >>> >>> >> Correct me if I am wrong but it appears that for this application you >> would not need to support call transfer ( i.e. REFER translation to >> re-INVITE). >> >> >> If so, this makes the problem much simpler. >> >> Ranga >> >>> Scott Lawrence ha scritto: >>> >>>> On Mon, 2009-01-26 at 15:00 +0100, Paolo Prandini wrote: >>>> >>>>> I managed to use the sipXbridge, very nice indeed. >>>>> I am however in the following case: >>>>> a) sipx server has a public ip, no NAT >>>>> b) sip trunk has a public ip, no NAT >>>>> c) users are on the internet with static public IP, no NAT >>>>> In this case I expect RTP to be between sip trunk and >>>>> users without media server intervention, packets should >>>>> be flowing directly between endpoints without sipx in >>>>> the middle. >>>>> What I find is that sipx stays in the media path, and >>>>> that is clearly undesiderable. >>>>> How can I obtain this result? >>>>> >>>> I might not be quite as undesirable as you think. >>>> >>>> First of all, the sipXrelay that's actually passing the RTP packets is >>>> very quick and doesn't do much harm (or any transcoding). I owe the >>>> list a posting on this, actually... >>>> >>>> The sipXbridge exists to manage your interface to the provider, >>>> especially authentication. Some providers will require that the SDP >>>> be >>>> coming from the same place the SIP came from (yes, this is a silly >>>> requirement, but...), and there are other problems that sipXbridge can >>>> take care of for you - like the fact that most providers can't deal >>>> with >>>> REFER. >>>> >>>> That having been said, it may be that sipXbridge could detect that no >>>> NAT compensation is needed and get the sipXrelay out of the way if it >>>> were configured to do so. Ranga - can this be done now? If not, we >>>> could put in an improvement issue for some future release... >>>> >>>> >>>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users >>> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >>> >> >> > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
