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
