Hi all! I would like to help with this development, could you please suggest me where I could start looking in the sources for this fix? Thanks
M. Ranganathan ha scritto: > 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 >>> >>> >> >> > > > -- Dr.Ing.Paolo Prandini Dr.Paolo Prandini Rottendorfer Str. 1 A-9560 Lindl Austria Telefon +43 (0)42765105 Fax +43 (0)427637590 S.P.E.Sistemi e Progetti Elettronici s.a.s. Via Liguria 5 I-25125 Brescia Italia Telefono +39 0302427266 Fax +39 02700406565 Email [email protected] Web http://www.spe.net CA https://ra.spe.net/pub/cacert/cacert.crt ------------------------------------------- The information contained in this e-mail message is confidential and intended exclusively for the addressee. Persons receiving this e-mail message who are not the named addressee (or his/her co-workers, or persons authorized to take delivery) must not use, forward or reproduce its contents. If you have received this e-mail message by mistake, please contact us immediately and delete this e-mail message beyond retrieval. Die Information dieses e-Mails ist vertraulich und ausschliesslich fuer den Adressaten bestimmt. Der Empfanger dieses e-Mails, der nicht der Adressat ist, (sowie einer seiner Mitarbeiter oder seiner Empfangsberechtigter), darf den Inhalt nicht verwenden, weitergeben oder reproduzieren. Sollten Sie dieses e-Mail irrtuemlich erhalten haben, informieren Sie uns bitte unverzueglich und loeschen Sie das e-Mail unwiederbringlich. Questo messaggio contiene informazioni riservate e confidenziali. Se non siete i destinatari del messaggio (o se avete ricevuto il messaggio per errore) Vi preghiamo di darcene immediata comunicazione ritornandoci il messaggio stesso. Qualsiasi copia, riproduzione in genere, uso o distribuzione del materiale contenuto o allegato al presente messaggio รจ severamente proibito. _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users
