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
