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
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
