On Sat, Feb 7, 2009 at 1:05 PM, Paolo Prandini <[email protected]> wrote: > 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
Its somewhat detailed and not included in our current release. Unfortunately, I have to stay focused on getting the current release completed before we look at this. Regards Ranga > > 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. > -- 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
