On Wed, 2006-11-29 at 08:04 +0200, Marnus van Niekerk wrote: > Hi, > > we came across a very similar problem in a project we are working on > and had to fix it by supplying two sets of credentials. > > However, sipXtapi is the only UA I found that has this "strict" > mapping between realm and username/password. > In fact it was the only one that explicitly asks for a realm from the > user. > > Every other UA I tried (linphone, kphone, xlite (windows and linux), > several hardphones and ata's) seem to have a "default" set of username > and password and uses it to respond to the realm presented by the > server. This way the UA does not need advance knowledge of the realm > which simplifies configuration.
But it doesn't work as well when you want multiple identities at different SIP domains. > Would it not be a good idea to allow sipXtapi to set a "default" > username and password that will be used to respond to any realm for > which it does not explicitly have credentials. I have seen a couple > of messages where people struggle to get the auth working and I'm > convinced it is because of this difficulty as opposed to other UA's > they may have used before. There is also nothing in the RFC to > suggest the realm MUST match the domain from the URI or SRV lookups. > The RFC just says the realm MUST be globally unique. > > Tx > > M > > PS: Also if you look at the RFCs, SIP digest auth was based on http > digest auth where the browser has no prior knowledge of the realm in > the challenge. But the browser is free to use a cached set of credentials when presented with a new challenge that uses the same realm, even if it's from a different server. That was part of the point of requiring the realm to be chosen so that it's unique. -- Scott Lawrence tel:+1-781-938-5306;ext=162 or sip:[EMAIL PROTECTED] sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/ _______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
