On Mon, Jan 26, 2009 at 4:27 PM, Paolo Prandini <[email protected]> wrote: > 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.
The reason for a relay is because of the requirement to handle hairpinned call transfers from behind a NAT ( i.e. transfer agent behind NAT but both transferee and transfer target on the public network ). We probably cannot fit it into this release ( I think ) but possibly what you need can be prototyped and tested in your environment -- especially because call transfer is not a requirement for you. I have created a JIRA issue for this : http://track.sipfoundry.org/browse/XECS-2140 Please watch it for updates and please comment if needed. Incidentally, while media relaying should be removed from the media path when not needed, I believe (based on experiments) that sipxbridge can handle well more than a "couple of dozen connections". Ranga > > >> 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 >> >> > > > -- M. Ranganathan _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
