Kobi Eshun wrote:
> Thanks for the hint. Answers to your related Qs inline. Cheers,
> On Oct 23, 2008, at 12:19 PM, Fredrik Thulin wrote:
>> Kobi Eshun wrote:
>>> I'm interested in using yxa only as a registrar and perhaps an event
>>> server, downstream of an ingress proxy that handles authentication.
>>> What is the best way to configure the incomingproxy to skip all
>>> authentication, or to authenticate by source IP/port? Thanks in advance,
>> That question has been asked before. I don't get it though - why do
>> people want to bypass authentication with SIP servers, when no one
>> would even think of doing it in an e-mail server?
> For use in a trusted network of cooperating servers -- there is
> absolutely no need for any authentication.
To be honest, I guessed this would be the answer. People build walled
gardens for SIP, but they don't for e-mail. It's an interesting paralell
though - why don't they? How come people have passwords for their e-mail
account even when accessing it using a private corporate network, but
they don't feel they need it for VoIP?
Extending YXA to allow it to trust peers with SSL client certificates
could partially adress this, although I don't generally consider
receiving a request from a authenticated peer good enough confirmation
that said peer wants me to act on the request in a certain way (like
sending it on to a costly PSTN destination for example).
>> What is missing in YXA that makes you want to put it behind another
>> server anyways?
> Crikey, I can't believe you would seriously ask that!
Sorry if I offended you - that wasn't my intention and yes, I'm very
well aware of the fact that YXA doesn't do everything possibly needed
everywhere when it comes to SIP ;). I was thinking that maybe the reason
was that your ingress server supported another authentication backend
the rest of your reply included for the list
> First of all, it
> is very common to expect to receive traffic from other proxies, in
> particular for receiving PSTN traffic. In our experience, most vendors
> prefer IP-address based authentication over 407/Proxy Auth.
> Second, even if YXA implemented all of the functionality a network
> operator might want, it is still desirable to avoid porting all
> application server logic to a new platform. And yes, I do have
> significant application server logic implement already for
> Third, YXA does not currently have all the required functionality
> readily available. What it does have is access to an elegant,
> distributed backing store for dialog state. I'd like to see if I can
> leverage that.
Yxa-devel mailing list